Custom Query (424 matches)

When doing advanced PDF collections using PDF Plugin to convert pdf to images we cannot control the size of those pictures. And in fact they need to be bigger.

Do we add the options in the PDF Plugin and make them available only we convert-to image(jpg,gif,etc...) is selected? We may have to think of other options to give the user more room for customization...

The TERM and INT signal handlers on Linux do a proper job of terminating wget prematurely (when the user presses the stop download button in GLI or when CTRL-C is entered into the console in the middle of running downloadfrom.pl using a WgetDownload.pm-based downloader). The INT signal handler in WgetDownload.pm also works on Windows to terminate wget when the perl script is run from a console.

However, on Windows, the TERM handler is never called when Java does a process.destroy() upon the stop button being pressed. Other issues on Windows include the fact that the perl scripts only have access to pseudo-pids (which mean nothing to other perl scripts launched to kill wget using these pseudo-pids). Since signal handling did not work through Java/GLI on Windows, we resorted to polling the STDIN of perl to which the Java program would write when it was time to terminate wget. However, this was doing blocking IO (non-blocking IO with IO::Select did not work on Windows though it worked on Linux, see ​http://www.perlmonks.org/?node_id=651768 ). An attempt at using a separate thread to monitor STDIN did not work. Also, I assumed that it would still be heavy on the CPU because I thought that it would be continuously polling STDIN.

The currently implemented solution is for the Java program to write out a file when it's time to stop wget. The perl script will be forever checking for the existence of this file and kill wget when it finds that the file has appeared. While it works, this continuous polling places a huge load on the CPU.

While I could not get multithreading a similar solution to work on Windows earlier, it seems that multithreading may be a better option that the current temporary fix. Oran stated that a tutor told him that while waiting for input is a blocking operation, it is not a CPU-intensive one since IO signals are interrupts, not continuous polling operations.

It may be good to attempt implementing the termination of wget in WgetDownload.pm using this last solution again (multithreading).

With the change to generating a text file instead of gdbm file, we need to be careful about exported cds.

the export to cd code needs to convert to ldb file as when you run from a cd you can't write to it. However, for a mac, this is never going to produce a file that will work on windows.

Or, should there be a standard place to look when you can't find it in index dir? On tmp somewhere?

Or, should exported cds just use sqlite?