I'm having problems knitting an R markdown document. the particular chunk that's giving mt trouble uses the "tableone" package, and gives the following error:
"Error in library(tableone): there is no package called 'tableone' "
the code chunk is (if necessary i'll upload some of the the actual data):
>pt.table1<-patient.table[,-unwanted.cols]%>%tbl_df()
>catVars<-pt.table1[sapply(pt.table1,class)=="integer"]%>%colnames()
>my.tab2<-CreateTableOne(data = pt.table1,strata =
>"cerebrovascular.pt",factorVars = catVars)
>print(my.tab2)
>summary(my.tab2)
this package is properly installed,and the chunk works fine if I just run it by itself (such as with CTRL ALT C), and of course it works when ran through the console.
I have a similar problem inn a different chunk with package 'e1071'.
other packages in the rest of the code chunks work fine.
Related
I downloaded the official example which is CGAL-5.2\examples\Triangulation_2 from the website CGAL.org.
I successfully cmake the examples.
Then I opened Triangulation_2_Examples.sln from G:\MyCGAL_code\code_1\Triangulation_2\build by VS2017.
I also successfully built all projects (without errors).
I then click the debugger in VS: the draw triangulation.exe running fine, but the Triangulation_2 Basic_viewer is empty.
I knew someone's successful results has colored triangles in the window called Triangulation_2 Basic_viewer.
Did anyone try this official example before?
The program draw_triangulation_2 takes a filename as input (the file must contains a set of 2D points).
Without parameter, it takes data/triangulation_prog1.cin by default.
Thus the working directory must contains a directory data and this directory must contains a file triangulation_prog1.cin. Otherwise, the triangulation is empty.
To solve your problem, you need either to create the data directory and copy triangulation_prog1.cin in this directory; or give a valid filename as parameter.
I have an Rmarkdown code to generate a report for multiple parameters. Therefore I am using the knit_child function in a loop where the first iteration runs fine but then it hangs infinitely and never begins a second iteration.
On my desktop (Ubuntu 18.04) the code works fine and the pdf report is generated but on our server (CentOS Linux release 7.1.1503 (Core)) the mentioned problem appears. Based on some research I tried to update pandoc (to version 2.7.2) but the problem persists. There is no difference if I run my scripts from the command line or RStudio.
for (spec in params$species) {
out = tryCatch(c(out, knit_child('child.Rmd')), error = function(e) e)
if (inherits(out, "error")) {
next
}
}
There are no errors, the script just does not move on to the next iteration. If I only provide one species the pdf is generated but not if I want to loop through multiple.
I have an application that collects heart rate data and displays in in a GUI. I don't want to change anything about how the application runs, but want to save the data into a .csv file to use with data manipulation programs. The program is called BluetoothGattHeartRate. I am running the sample code found here.
My addition to the code is just
std::fstream theDump;
theDump.open("path/to/file", std::fstream::out);
if (theDump.is_open())
{
theDump.write("ImHere", 6);
}
theDump.close();
inserted into the file called HeartRateService.cpp in the Shared directory in the void HeartRateService::Characteristic_ValueChanged(GattCharacteristic^ sender, GattValueChangedEventArgs^ args) function just before the call to ValueChangeCompleted(heartRateValue);. I'm using Microsoft Visual Studio to edit and run the code, as the tutorial online says. This exact code succeeds in editing the file when run in an independent application, but it fails to open the file (I tested for this) when run in the Gatt sample code.
I don't expect that anyone has dealt with this before, but if by some miracle one of you has figured this out, please let me know how you fixed it.
Based on one of the solutions here, I'm using the following code to strip out the EXIF data from an image:
def remove_exif_from_image(image_path):
img = Image.open(image_path)
data = list(img.getdata())
clean_img = Image.new(img.mode, img.size)
clean_img.putdata(data)
clean_img.save(image_path)
I found this function works just fine on my local machine, however, when I try to run this on my tiny DigitalOcean VPS it causes my gunicorn process to crash.
I'm guessing this is due to img.getdata() returning something huge.
How might I strip out the EXIF by reading/writing in chunks as opposed to reading the entire image into memory?
Since the primary constraint seems to be "something that runs on my tiny VPS", consider installing and using exiftool for this task, and make a system call to it:
exiftool -all= -overwrite_original tmp.jpg
This doesn't exactly answer your question about using python streams, but may solve your problem.
If you run the command-line version of unrar it logs out vital information when an archive fails to extract.
I'm trying to do the same thing with the unrar DLL.
I've already had to make some changes to the DLL source code to support registering my own callback to handle extraction progress properly.
Now I want to handle error reporting properly.
There is really no documentation on using unrar source.
So I have a working callback function that can be called
CommandData *Cmd
Cmd->ErrorCallback(ERAR_BAD_DATA, Arc.FileName, ArcFileName);
The function works great if I call it next to my progress DLL (so I know the callback works), but I just can't figure out where the errors are being handled.
Specifically I'm after handling the code ERAR_BAD_DATA which I found is handled in extract.cpp ... but that code just doesn't seem to get run.
I also found some calls to RarErrorToDll ... I put the callback there too, nothing.
Any help would be hugely appreciated.
for a bit of context, this is what I was previously doing to catch errors.
bool archiveCorrupt = false;
while((read_header_code = RARReadHeader(archive_data, &header_data)) == 0)
{
process_file_code = RARProcessFile(archive_data, RAR_EXTRACT, m_output_dir, NULL);
if(process_file_code)
{
qDebug() << "Error extracting volume!"
<< header_data.ArcName << " "
<< " with error: " << process_file_code;
archiveCorrupt = true;
break;
}
}
The reason this approach doesn't work is that the error code process_file_code tells you what went wrong, but the archive name in header_data.ArcName is the archive that the file started in, not necessarily where the corruption was. I'm dealing with multi-part archives where one large file will span multiple archives ... so I need to know which archive(s) is corrupt, not just the archive the file started in.
EDIT:
Here is a link to the unrar source code
So I've discovered a place in extract.cpp line 670 that I can place the callback and it does return an error code to my app.
ErrHandler.SetErrorCode(RARX_CRC);
#ifdef RARDLL
Cmd->ErrorCallback(RARX_CRC, Arc.FileName, ArcFileName);
However, this has the same issue as before, where it returns the error at the end of processing the file extracting, rather than at the place where the CRC fails.
If I run the unrar command-line app that you can download from the rarlabs site, it seems to handle it properly and returns the correct error. I can't find text for those errors anywhere in the unrar source, so I can only assume that the unrar source doesn't actually build the unrar app they publish on their site.
Extracting from SL - Cinematic Guitars.part02.rar
... SL - Cinematic Guitars/Cinematic Guitars/Samples/Cinematic Guitars_001.nkx 16%
SL - Cinematic Guitars/Cinematic Guitars/Samples/Cinematic Guitars_001.nkx : packed data CRC failed in volume SL - Cinematic Guitars.part02.rar
I eventually found the answer, after lots of trial and error.
My issue was, I was comparing an old command line version of unrar to the newer source code when looking for the error messages.
The error message has changed in the new source code and is now
packed data checksum error in volume
This is defined in loclang.hpp and called from uiconsole.cpp in the function uiMsgStore:Msg when the error code is UIERROR_CHECKSUMPACKED
This gets called from volume.cpp on line 25
I have added my callback here, and it catches the error perfectly.
I hope this helps someone else if they ever have the misfortune of having to hack unrar source code.