| | <<<Back 1 day (to 2014/07/21) | 2014/07/22 |
| rayjj | mvrhel: (for the logs) getting closer. I saw that you commited App.config, but somehow it wasn't pulling in my mujs/jsi.h fix, so I scrapped the local sandbox/repo and recloned it, and git submodule --init still didn't get teh jsi.h update. | 00:37.26 |
| | mvrhel: so I changed to that directory and checked out "master" for mujs and that has my fix and I am down to 3 errors: | 00:38.13 |
| | mvrhel: see: http://pastebin.com/mp3zD8G6 (verbose) but the two actual errors are: | 00:40.08 |
| | Error302error C1083: Cannot open include file: 'mupdf/pdf-tools.h': No such file or directoryc:\artifex\gsview\mupdf\platform\winrt\mupdfwinrt\muctx.h111mupdfnet | 00:40.09 |
| | Error303Resource file "Strings\en-US\Messages.resx" cannot be found.gsview | 00:40.11 |
| | I searched BOTH a "stock" mupdf git and the win_desktop and I don't see pdf-tools.h anywhere, so it may be a missing file in platform\winrt\mupdfwinrt (or some other search path) | 00:41.34 |
| | mvrhel: for the other error about the Messages.resx -- I have no idea -- maybe also something that didn't get committed. | 00:42.29 |
| | mvrhel: Sorry, and feel free to put this on the back burner, but I figure you would have to face this pain at some point anyway :-/ | 00:43.03 |
| | mvrhel: and it certainly isn't a rush | 00:43.25 |
| sam__ | Hi im looking for some help with ghostscript :) | 07:05.00 |
| kens | Well this is one possible place to get some | 07:05.15 |
| sam__ | how do i specifiy the printer tray? | 07:05.38 |
| kens | You don't, Ghostscript doesn't drive printers directly | 07:05.54 |
| | (except when built into the pritner) | 07:06.05 |
| | Perhaps if you explained what you are trying to achieve I could answer that instead | 07:06.37 |
| sam__ | im building GS into a C# application to handle PDF printing (instead of opening adobe ...) ive got all the other setting setup like duplex and paper size, but since we are printing onto headed paper then i need to specify a tray which that is stored in | 07:08.04 |
| kens | Like I said, Ghostscript doesn't drive printers. How are you using Ghostscript to 'handle PDF printing' ? | 07:08.40 |
| | Which Ghostscrtip device are you using for starters ? | 07:09.04 |
| sam__ | gswin32c -dPrinted -dBATCH -dNOPAUSE -dNOSAFER -q -dNumCopies=1 -sDEVICE=ljet4 -sOutputFile="\\spool\\\Server_Name\Printer_name" "C:\test.pdf" | 07:09.32 |
| kens | So you are sending the PCL directly to the printer. The ljet4 output doesn't include any tray switching, or other device-dependent features (eg Duplex) as far as I'm aware. You would have to add the tray selection to ther output *before* sending it to the printer. | 07:10.52 |
| sam__ | right ok | 07:14.08 |
| kens | Huh, I should have squashed those 2 commits, ooops | 08:34.32 |
| Guest50354 | hello, is there someone who can help me install Mupdf on redhat system? I get errors when intalling... (I'm mediocre unix user) | 10:04.40 |
| Robin_Watts | Guest50354: Are you installing from a distribution? | 10:06.04 |
| | Or from source? | 10:06.06 |
| Guest50354 | if I understand, then I think I tried both distribution (using git?) and also from source (website: mupdf-1.5-source.tar.gz) | 10:07.23 |
| Robin_Watts | OK, neither of those are from a distribution, they are both direct from us, and that is the good answer :) | 10:08.15 |
| | So, let's start with the mupdf-1.5.source.tar.gz | 10:08.38 |
| | Tell me what you tried, and where it went wrong? | 10:08.54 |
| Guest50354 | I see a lot of errors like :x11_main.c:957: error: XXXXXX undeclared (first use in this function), but the last row is : make: *** [build/debug/platform/x11/x11_main.o] Error 1 | 10:11.49 |
| | XXXXXX is dynamic name :) | 10:12.08 |
| Robin_Watts | Asking me to diagnose what's going wrong without showing me all the errors is like phoning a doctor and saying "I don't feel well, what's wrong with me?" | 10:13.15 |
| | But don't paste them all in here. | 10:13.23 |
| | go to pastebin.com and paste them all in there. | 10:13.32 |
| | Guest50354: Do you actually have X11 installed? i.e. does your unix box have a windowing system? | 10:14.26 |
| Guest50354 | tnx, will do.. this is my first time trying to get help without just browsing the web :) | 10:14.50 |
| | we don't have any windows system | 10:15.04 |
| Robin_Watts | OK, so that's the problem. | 10:15.18 |
| Guest50354 | this is the command I ran from the README: make prefix=/usr/local install" | 10:15.30 |
| Robin_Watts | HAVE_X11=no make prefix=/usr/local/install | 10:16.22 |
| Guest50354 | OK I ran it. I got 3 lines.. CC build/debug/platform/x11/jstest_main.o CC build/debug/platform/x11/pdfapp.o LINK build/debug/mujstest | 10:18.35 |
| | I just would like to say Thank you! in advanced :) | 10:19.21 |
| Robin_Watts | np. | 10:19.29 |
| | sorry, I got my line wrong. | 10:19.53 |
| | HAVE_X11=no make prefix=/usr/local install | 10:19.56 |
| Guest50354 | thank you!!!!!!! | 10:21.12 |
| | just ran mudraw and it's working :) | 10:21.19 |
| Robin_Watts | fab. | 10:21.25 |
| Guest50354 | is there a place for donation or such? | 10:23.32 |
| Robin_Watts | no donation site, no. | 10:24.51 |
| | but thanks. | 10:24.59 |
| Guest50354 | OK so have a great day\night! :) | 10:25.36 |
| tor8 | Robin_Watts: there's a commit on tor/master that pulls in ray's mujs fix | 11:24.26 |
| Robin_Watts | tro8: lgtm | 11:56.54 |
| | tor8: oops. segv city. | 12:58.55 |
| tor8 | Robin_Watts: where? | 13:02.16 |
| Robin_Watts | The mujstest on the cluster for your last commit. | 13:02.28 |
| | http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=4c1075d27fe7295052a8c929ca35f2a6bd7cf55c&project=mujstest | 13:02.43 |
| tor8 | oh... | 13:02.58 |
| | let me take a look | 13:03.02 |
| | Robin_Watts: oops. | 13:10.30 |
| | Robin_Watts: two fixes on tor/master | 13:16.30 |
| henrys | meeting in 5 minutes | 14:27.10 |
| mvrhel_laptop | good morning | 14:32.50 |
| marcosw | morning | 14:33.03 |
| henrys | hi mvrhel_laptop | 14:33.05 |
| | great now we have an outside source for fuzzing bugs - see the support link on workflowy | 14:33.42 |
| rayjj | morning, all | 14:33.54 |
| henrys | tor8:you have an awating_review bug from norper that propably should be moved along | 14:34.37 |
| kens2 | henrys, *where* on workflowy ? | 14:35.08 |
| | which bullet ? | 14:35.25 |
| rayjj | kens2: thanks. I was just going to ask that | 14:35.34 |
| henrys | support bugs under warm up the first link to bugzilla on the agenda | 14:36.07 |
| rayjj | henrys: thx | 14:36.18 |
| kens2 | Git it | 14:36.24 |
| | THese are all the same fuzzing as before aren't they ? Same group ? | 14:36.50 |
| rayjj | henrys: I see 7 bugs there | 14:38.27 |
| henrys | marcosw: how difficult would it be to create an archive of pcl exes as you have for gs? finding norbertâs problem will be difficult | 14:38.28 |
| | without something like that. | 14:38.43 |
| marcosw | henrys: it's not a problem, I already have a bunch of them from previous bisecting | 14:39.14 |
| tor8 | henrys: oh, right. those patches have been sitting on the ghostpdl tor/master branch for a while. guess I should just push them. | 14:39.30 |
| henrys | kens2: youâre saying they are repeats of reports marcosw already made. | 14:39.32 |
| kens2 | Not repeats, not, but the source is the same group isn't it? | 14:39.48 |
| chrisl | henrys: I can't measure accurately enough to identify 3-4 per cent speed differences...... | 14:39.56 |
| Robin_Watts | tor8: Those changes seem reasonable to me. | 14:40.16 |
| henrys | kens2: oh I donât know I thought this was a new contributor | 14:40.52 |
| kens2 | henrys I *think* its the same people as the original set of fuzzing bugs. I could easily be mistaken | 14:41.11 |
| henrys | another agenda item is here: http://bugs.ghostscript.com/show_bug.cgi?id=695373#c1 | 14:43.24 |
| | I can clean up the files in xpswrite but Iâd really rather have a complete solution for tempfiles in gs. | 14:44.45 |
| marcosw | at least some of the latest fuzzing bugs involve command lines that are different than the previous fuzzing issues (which iirc were simply gs <device> <inputFile>). I.e. http://bugs.ghostscript.com/show_bug.cgi?id=695318 which uses 'gs -dNOPAUSE <filename>.pdf <text/filename>'. | 14:45.15 |
| chrisl | henrys, paulgardiner: I thought paulgardiner was a good way through implementing a solution | 14:45.33 |
| henrys | paulgardiner: did you start? | 14:45.57 |
| Robin_Watts | I thought paulgardiner had a solution that was working for the clist temp files. | 14:46.32 |
| | but that his solution was limited to the clist temp files. | 14:46.47 |
| paulgardiner | I sort of have a fix. Sort of. It works for what's supposedly the difficult test case (using the flag that Ray suggested) but I had crashes in the cluster | 14:47.16 |
| | Haven't had time to look into it | 14:47.25 |
| chrisl | henrys: but all our thoughts on a general purpose temp file solution have rather faltered | 14:47.55 |
| | IIRC, not least because we're not at all sure how many places rely on temp files being persistent | 14:48.53 |
| paulgardiner | Trouble is I only ever find time to work on it when travelling over to meetings | 14:49.34 |
| rayjj | henrys: I think cleaning up files in xpswrite is worth doing. GS is supposed to be independent of the gp_ layer | 14:49.35 |
| | paulgardiner: can you push the branch for the changes you have in process for me to take over ? | 14:50.33 |
| henrys | rayjj: I donât think that is the issue. Temp files should be deleted when the program is interrupted. Iâve looked at python, ruby, perl - all have implementations for that on windows | 14:51.39 |
| rayjj | henrys: iirc, paulgardiner was specifically looking at it for clist files (at the clist io_procs layer) | 14:51.40 |
| paulgardiner | rayjj: it's here http://git.ghostscript.com/?p=user/paulg/ghostpdl.git;a=summary | 14:51.49 |
| chrisl | I'm tempted to say for xpswrite and future uses, we should just add a new "gp_tempfile_transient" call (or something) | 14:51.50 |
| | henrys: but none of those rely on closing an reopening temp files | 14:52.14 |
| rayjj | paulgardiner: is it on a branch ? | 14:52.20 |
| chrisl | s/an/and | 14:52.22 |
| paulgardiner | rayjj: on my master branch I believe | 14:52.59 |
| henrys | chrisl: well then clist isnât using âtempfilesâ as POSIX understands them. | 14:53.30 |
| rayjj | paulgardiner: OK. that's what it looks like | 14:53.35 |
| henrys | chrisl: so why should it use the os temp file support | 14:53.53 |
| chrisl | henrys: I don't understand that question. The clist files were the original source of this problem | 14:54.37 |
| rayjj | chrisl: yeah, but henrys introduced a new culprit | 14:54.57 |
| henrys | last item: we are coming up on a meeting - have a look at the agenda especially high priority projects. | 14:55.29 |
| chrisl | rayjj: right, but AIUI paulgardiner's solution won't work for general use temp files | 14:55.37 |
| rayjj | chrisl: but pdfwrite/ps2write and xpswrite all use temp files and if gs crashes leave them laying around | 14:55.40 |
| | chrisl: if it relies on clist io_procs, right | 14:56.18 |
| kens2 | pdfwrite uses the existing temp file support, which uses (on WINdows) WIndows temp files, so they shouldn't be left lying around | 14:56.23 |
| paulgardiner | chrisl: it might be extended for those. I restricted to the clist because that was easier and was supposedly the main culprit | 14:56.25 |
| henrys | chrisl: Iâm just saying Iâd like a general tempfile solution for gs. It sounds like that wonât work for clist | 14:56.25 |
| kens2 | I htought we had a general temp file solution, but it doesn't work for clist because that expects to be able to close a temp file and reopenit. | 14:57.01 |
| rayjj | kens2: if it uses existing tempfile support then they will be left laying around | 14:57.07 |
| kens2 | Possibly I'm just confused | 14:57.12 |
| henrys | kens2: no windows sucks and doesnât support unlinking an open file | 14:57.27 |
| kens2 | rayjj : I feel sure I've seen sopmething using Windows temp file the CreteTempFile API or somethign like that | 14:57.41 |
| chrisl | But Windows does have a "temp file" flag for opening files | 14:57.47 |
| Robin_Watts | henrys: I think you can do that. | 14:57.48 |
| | Using Windows specific calls. | 14:57.57 |
| kens2 | henrys, you don;t have to unlink the file, you just the use the OS-supported method to create a temporary file | 14:58.04 |
| henrys | Robin_Watts: I get a sharing violation upon the unlink | 14:58.16 |
| Robin_Watts | But the problem is that clist needed to be able to do that *and* to still be able to reopen it. | 14:58.20 |
| | henrys: Then you're not calling the windows specific calls. | 14:58.29 |
| paulgardiner | Does the cluster perform tests under MAC OS? | 14:58.32 |
| Robin_Watts | paulgardiner: Yes. On at least 1 node. | 14:58.44 |
| paulgardiner | My fix may have been failing only on MAC OS | 14:59.04 |
| henrys | Robin_Watts: I doubt you can as all the other scripting languages use a wrapper and finalize upon cleanup. | 14:59.11 |
| kens2 | henrys I don'tr see how that avoids leaving files behind on a crash | 14:59.35 |
| henrys | when implementing temp files, doesnât seem like theyâd miss that but maybe | 14:59.37 |
| chrisl | The last time we discussed this, there were three problem raised: 1) clist files, 2) we don't know how many other places now rely on "persistent temp files" and 3) it would mean changing an existing public interface which we don't do (apparently) | 14:59.56 |
| henrys | kens2: on a posix system the os clean them up | 14:59.57 |
| Robin_Watts | henrys: Is is true that windows will not let you create a file and then delete it while it's open using the standard posixish file creation/unlink calls | 14:59.58 |
| paulgardiner | I'd have quite liked to have finished this off, but it's just difficult to fit it in with the higher priority stuff | 15:00.03 |
| kens2 | henrys, yes and Windows does too, if you use the API to create a temporary file | 15:00.16 |
| | WHat you can't do is close a tmporary file, then reopen it. | 15:00.26 |
| rayjj | in base/gp_mswin.c we have: FILE_ATTRIBUTE_NORMAL /* | FILE_FLAG_DELETE_ON_CLOSE */, | 15:00.40 |
| henrys | kens2: that is not consistent with the python implementation which says it is only possible to do it on NT. but I havenât tried. | 15:01.37 |
| kens2 | Well, modern versions of WIndows started as NT.... | 15:01.58 |
| paulgardiner | rayjj: My patch alters that I believe | 15:02.04 |
| henrys | kens2: anyone is welcome to the bug ;-) | 15:02.21 |
| kens2 | At the moment I cna't find the API to do temporary files, but that's nothing new | 15:02.25 |
| marcosw | what happens if just never close temporary files? Keep them open and make the os deal with them when ghostscript quits? | 15:02.28 |
| rayjj | chrisl: the gp layer can be extended (added to) -- we do that all the time | 15:02.30 |
| chrisl | rayjj: but that won't solve it for the existing calls..... | 15:02.52 |
| rayjj | chrisl: so your idea of having a gp_open_transient_scratch_file is fine | 15:03.06 |
| chrisl | Right, okay | 15:03.23 |
| Robin_Watts | marcosw: The problem (for clist) is that it needs to write the file once, then close it and reopen it in a way that can be read multiple times. | 15:03.41 |
| | one for each rendering thread. | 15:03.50 |
| rayjj | chrisl: any devices which use gp_open_scratch_file can be fixed (pdfwrite and xpswrite) | 15:03.57 |
| henrys | the discussion in /usr/lib/python2.7/tempfile.py might be useful to whoever works on this but of they could have it wrong | 15:04.45 |
| rayjj | Robin_Watts: and for 'saved_pages' mode, it needs to be able to read it later. | 15:04.50 |
| henrys | s/but of/but of course/ | 15:05.11 |
| paulgardiner | Admittedly clist only, but I could probably finish my fix in two days. | 15:05.25 |
| marcosw | can't you open a file for reading if it's already open for writing? I'm pretty sure that's what makes "tail -f" useful. | 15:05.27 |
| Robin_Watts | rayjj: Right. So clist is an unusual case, and should be fixed in a clist specific way. And that's what paulgardiner has done/is doing. | 15:05.39 |
| henrys | tor8: you have a high priority easy project mujs docs. How is that coming? | 15:05.43 |
| chrisl | paulgardiner: we probably need a combination of your clist solution and a more general one | 15:05.55 |
| tor8 | henrys: there are docs on mujs.com | 15:06.18 |
| Robin_Watts | chrisl: I think it's more likely 2 separate solutions. | 15:06.22 |
| paulgardiner | I think my solution could be applied else where, but the problem is that you can no longer use plain FILE pointers | 15:06.35 |
| chrisl | Robin_Watts: I figured for the "ephemeral" temp files, Paul's code could call a new temp file API | 15:07.15 |
| paulgardiner | So we'd have to make everything that wanted to take advantage of the feature use GSFILE pointers | 15:07.23 |
| tor8 | henrys: some of it could use some fleshing out, and I still need to write a tutorial kind of thing | 15:07.34 |
| chrisl | paulgardiner: that's unlikely to happen :-( | 15:07.49 |
| henrys | tor8: yeah seem a bit light | 15:07.56 |
| paulgardiner | chrisl: yeah, I couldn't see a way that maintaine the use of FILEs | 15:08.47 |
| | Although it might be posible to use FILEs for external APIs and wrap them for internal APIs | 15:09.15 |
| henrys | rayjj: I guess changing the clist not to behave rather oddly to a naive outsider is not in play. | 15:09.44 |
| chrisl | paulgardiner: no - as I said before, the APIs should all have been using an abstraction, but too late now :-( | 15:09.45 |
| rayjj | henrys: I don't understand that | 15:10.21 |
| Robin_Watts | What the clist does with it's files is entirely natural. | 15:10.41 |
| henrys | rayjj: is there another way to implement the functionality wihout closing and reopening | 15:10.43 |
| | ? | 15:10.46 |
| Robin_Watts | It's just they aren't temp files in the purest sense of the term. | 15:10.56 |
| | henrys: yes, the way paulgardiner does it :) | 15:11.03 |
| henrys | temporary files | 15:11.05 |
| | it is not natural to close and reopen temporary files | 15:11.24 |
| paulgardiner | henrys: as robin says | 15:11.39 |
| Robin_Watts | Saved pages are not temporary files then. | 15:11.50 |
| chrisl | henrys: the problem is, we need an abstraction layer to allow platform independent, multi-threaded use of the FILE * objects | 15:12.19 |
| Robin_Watts | It all depends on your definition of temporary files. | 15:12.46 |
| | If you are defining temporary files to be "files that are deleted on close", then yes, closing and reopening them is unnatural. | 15:13.14 |
| marcosw | I have to run to uni. be back in an hour or so. | 15:13.29 |
| paulgardiner | chrisl: yes exactly. I thought that that was possible using dup but the internal pointers are shared so it doesn't play well multithreaded | 15:13.54 |
| Robin_Watts | If, however, you take your definition of temporary files to be "files that hold data whose lifespan is restricted to the lifespan of the calling process" then what clist does is perfectly natural. | 15:14.16 |
| henrys | Iâm using the POSIX understanding of temporary files - I donât have my own definition | 15:14.19 |
| Robin_Watts | Right. Then clist files are not posix temporary files. | 15:14.52 |
| rayjj | henrys: I can go ahead and add a gp_open_transient_scratch_file that does the unlink or adds the FILE_DELETE_ON_CLOSE | 15:14.54 |
| chrisl | paulgardiner: no, I stumbled on that before. IIRC, there are some *very* platform specific solutions, but they look like a pain | 15:15.12 |
| paulgardiner | chrisl: oh interesting | 15:15.31 |
| henrys | rayjj: from my read of the python code that will only work on NT but weâll give it a go. Maybe NT means everything after NT as kens2 suggests | 15:16.10 |
| kens2 | No, it looks like MS have withdrawn that API | 15:16.26 |
| | Current platform SDK doesn;t mention it | 15:16.37 |
| rayjj | henrys: FILE_DELETE_ON_CLOSE still is around I think | 15:16.56 |
| kens2 | Hmm, yes that's still htere | 15:17.35 |
| | But I thought that meant delete the file when its closed, not when the application crashes | 15:17.53 |
| chrisl | kens2: when the application crashes all the handles to the file a closed, so the file gets deleted | 15:18.19 |
| henrys | I donât think the windows closes files upon crashes | 15:18.20 |
| rayjj | kens2: the file is closed by the OS upon crash | 15:18.23 |
| kens2 | chrisl Bets ? :-) | 15:18.29 |
| Robin_Watts | When the application crashes, all files are closed. | 15:18.33 |
| henrys | weâre going to find out soon | 15:18.46 |
| chrisl | kens2: it's *supposed* to..... | 15:18.46 |
| Robin_Watts | occasionally windows gets confused and keeps a HANDLE open, but that's rare. | 15:19.02 |
| rayjj | I'd have to test that again, but I do recall trying that | 15:19.03 |
| kens2 | There are various threads (including msdn) telling you how temp files can be left laying around | 15:19.06 |
| chrisl | henrys: there can't be any other solution | 15:19.22 |
| Robin_Watts | certainly it would be a great improvement. | 15:19.23 |
| kens2 | But its better than nothing | 15:19.24 |
| rayjj | Robin_Watts: you are right. It is rare, and I've never had it be a problem for clist tempfiles | 15:19.41 |
| chrisl | Well, I supposed we could implement signal handlers which close and delete all temp files..... ick | 15:20.08 |
| rayjj | kens2: do they all mention ghostscript ;-) | 15:20.18 |
| Robin_Watts | chrisl: Except you can't trust signal handlers to be called. | 15:20.44 |
| kens2 | Nope..... | 15:20.45 |
| kens2 | backs out anyway, I don't weant the job.... | 15:21.04 |
| Robin_Watts | This is why other windows apps often run 2 processes. One to do the actual work, and one to tidy up if that one dies. | 15:21.18 |
| chrisl | Robin_Watts: no, that's true. I just don't see any other way to tackle the problem than having OS clean up | 15:21.31 |
| kens2 | If someone wants to do a new file API for temp files I'll modify pdfwrite to use it. | 15:21.39 |
| paulgardiner | rayjj: in case you do look into trying to finish off my patch, the trick I've used is, for some platforms, to provide alternative definitions for gp_open, gp_read, gp_close, gp_remove etc. so that gp_close doesn't actually close the file and gp_open makes a dup'd copy. Then read and write are done with fpread and fpwrite to avoid problems with threaded access to the read/write pointer. | 15:21.45 |
| | I replace FILE with a wrapped version IFILE so there is somewhere to keep our own read/write pointers. | 15:22.16 |
| | rayjj: one potential source of crashes is that repeated attempts to remove a single file may be problematic, so if clist can ever attempt to do so, we need to protect against it. (remove doesn't really remove any more, it just closes the already unlinked or DELETE_ON_CLOSE file) | 15:25.07 |
| Robin_Watts | paulgardiner: Can we have a flag in the IFILE that says "closed already" ? | 15:27.58 |
| rayjj | seems like nulling the pointers when we close would be enough of a "flag" condition | 15:28.44 |
| paulgardiner | There are more than one IFILE per virtual file. I think we need a flag in clist, or to blank the file name (which is actually an encoded file pointer | 15:29.09 |
| chrisl | paulgardiner: how about having another layer, so the IFILE contains an rcFILE * which is the FILE * plus a reference count? | 15:30.19 |
| paulgardiner | chrisl: possibly, although I've already had to mess with the insides of clist so another flag wouldn't hurt | 15:31.08 |
| chrisl | paulgardiner: I just thought a reference count might scale better | 15:31.34 |
| | and be more flexible | 15:32.05 |
| paulgardiner | chrisl: yeah, probably right | 15:32.35 |
| chrisl | rayjj: so, do you want to look at adding the new gp_ function? | 15:32.49 |
| rayjj | chrisl: yes. But I still think that xpswrite should work without that | 15:34.23 |
| chrisl | rayjj: it would be best - we may come across a system that *really* doesn't support this stuff | 15:35.30 |
| rayjj | henrys: your comment on bug 695373 says that you unlink after closing, but that doesn't seem to work | 15:35.54 |
| henrys | rayjj: I unlink after opening the temp file maybe I misspoke, in another meeting Iâll fix it later | 15:37.08 |
| rayjj | henrys: ahh.. right. On Windows trying to unlink a file that is still open will fail | 15:37.49 |
| mvrhel_laptop | rayjj: tried to ping you yesterday. the win_desktop branch in my mupdf repos has been updated if you want to try to build with that | 15:40.48 |
| | rayjj: are you there? | 15:44.43 |
| rayjj | mvrhel_laptop: git says I am up to date: 5ed2435 (HEAD, origin/win_desktop, win_desktop) Fix several issues in the project files. Also add missing App.config file. | 15:45.39 |
| mvrhel_laptop | rayjj: ok that should be correct | 15:46.03 |
| | rayjj: let me know how that goes for you | 15:46.13 |
| rayjj | mvrhel_laptop: but I still have those two errors I posted yesterday (missing mupdf/pdf-tools.h) | 15:46.14 |
| mvrhel_laptop | rayjj: hmm. ok I did not see those posted | 15:46.33 |
| rayjj | mvrhel_laptop: and Error303Resource file "Strings\en-US\Messages.resx" cannot be found. | 15:46.34 |
| mvrhel_laptop | let me spend a bit more time on it today then. I will do the clean check out and make sure it all works here | 15:47.09 |
| rayjj | mvrhel_laptop: it's at the top of today's logs | 15:47.10 |
| | mvrhel_laptop: there's a pastebin with my build output | 15:47.44 |
| mvrhel_laptop | rayjj: ok. sorry. did you have a list of things that you found that need to be fixed with gsview? | 15:48.12 |
| rayjj | mvrhel_laptop: I don't recall. I wasn't ready to open bugs. Mostly just irritating things that it doesn't do. Like let me select a page range for printing, or not paying attention to a page down | 15:49.30 |
| mvrhel_laptop | ok. those are the sort of things that I needed to know | 15:50.07 |
| | other than chrisl, no one had said anything | 15:50.22 |
| | and I fixed the things that he mentioned | 15:50.31 |
| rayjj | mvrhel_laptop: yeah, but those aren't things that are that important to have you spend time on probably | 15:50.44 |
| | mvrhel_laptop: but getting it so at least one other person can build ... | 15:51.02 |
| mvrhel_laptop | yes. that certainly needs to be fixed | 15:51.17 |
| | will get there today | 15:51.21 |
| rayjj | mvrhel_laptop: was pdf-tools.h something you added ? | 15:52.50 |
| mvrhel_laptop | no it is a header from mupdf | 15:54.58 |
| | but it is used as we use calls to mutool iirc | 15:55.28 |
| rayjj | mvrhel_laptop: I don't see it used in the master, and 'find' doesn't show it in the tree | 15:55.53 |
| | mvrhel_laptop: and it isn't used in the master platform/winrt/mupdfwinrt/muctx.h | 15:56.46 |
| mvrhel_laptop | hmm apparently you are correct | 15:56.57 |
| rayjj | (it only has fitz.h) | 15:57.04 |
| mvrhel_laptop | that needs to be added. | 15:57.10 |
| | sorry about that | 15:57.15 |
| | that needs to go in the main branch really | 15:57.28 |
| | but we can stick it here | 15:57.36 |
| | for now | 15:57.39 |
| rayjj | mvrhel_laptop: OK. Just wanted to make sure that my git was OK | 15:57.40 |
| mvrhel_laptop | yes. let me add it | 15:57.46 |
| | rayjj: ok header added | 16:01.29 |
| | rayjj: ok I did a clean check out | 16:05.55 |
| | let me make sure it all builds here | 16:06.01 |
| | and nothing more is missing, before you spend any more time | 16:06.13 |
| henrys | chrisl: back to one of your comment 4% should be discernible. | 16:06.47 |
| | If I saw 4% in the street Iâd bend over and pick it up ;-) | 16:07.18 |
| rayjj | mvrhel_laptop: I still have the Strings\en-US\Messages.resx | 16:07.25 |
| mvrhel_laptop | rayjj: hold on.... | 16:07.34 |
| rayjj | cannot be found | 16:07.37 |
| mvrhel_laptop | I am building now | 16:07.37 |
| | please | 16:07.42 |
| rayjj | mvrhel_laptop: note that I am trying this with VS2013 Express (the free version) It may be that I need to actually buy the real version, but the less I spend on MS s/w the better :-) | 16:10.20 |
| chrisl | henrys: I get more noise than that | 16:10.35 |
| mvrhel_laptop | rayjj: express should work. grabbing third party libs now then I will build and see if I get any issues | 16:10.50 |
| | brb | 16:10.57 |
| rayjj | chrisl: I get a lot of variation on windows, but even there 'time' cpu time is quite consitent | 16:11.26 |
| | consistent even | 16:11.41 |
| chrisl | henrys: I am wondering if we could modify the pcl code to "show" more than one glyph at a time - I bet we could speed things up if we could do that | 16:12.18 |
| rayjj | chrisl: pcl needs to know where to line wrap | 16:12.57 |
| henrys | chrisl: Iâve really tried that and it was so painful I just gave up I thijnk there are still hints of it in the code | 16:13.04 |
| kens2 | Its too hot here to think, I'm heading off for the night. Bye all | 16:13.28 |
| chrisl | Why was it painful? We'd still measure glyphs individually, buffer up to a certain number, or where the line wrap happens, then show | 16:13.57 |
| rayjj | chrisl: so getting the advance glyph by glyph isn't expensive ? | 16:14.55 |
| chrisl | rayjj: not compared to actually showing the glyphs, no | 16:15.11 |
| | rayjj: for showing text we're allocating, filling in, and destroying a text enumerator for *every* glyph | 16:16.39 |
| rayjj | bbiab... | 16:16.54 |
| chrisl | henrys: I am looking at some things we do in FAPI for every glyph which actually won't change for the life of the text enumerator, *but* eliminating those won't help PCL | 16:18.25 |
| | henrys: also, how commonly used is show_char_background()? | 16:21.24 |
| henrys | chrisl: only for odd rop cases | 16:24.47 |
| | rare | 16:24.51 |
| chrisl | henrys: okay, if it had been fairly common, there might have been a more efficient implementation | 16:25.30 |
| marcosw | my idea didn't work; opening an already open but unlinked file doesn't work. I think using dup() instead of fopen() would work, but I suspect that would require a substantial change to the code. | 16:30.56 |
| mvrhel_laptop | bbiab | 16:31.05 |
| chrisl | marcosw: dup() doesn't guarantee the file descriptors can be safely accessed from difference threads | 16:31.45 |
| | s/difference/different | 16:31.59 |
| marcosw | chrisl: right you are. | 16:33.35 |
| henrys | chrisl: last I looked the gsave/grestore per character (in pclâs case) was a bit heavy handed. Canât we make that more intelligent? | 16:36.00 |
| chrisl | henrys: no | 16:36.15 |
| Robin_Watts | chrisl: don't sugar coat it. Say what you mean. | 16:36.36 |
| henrys | ;-) | 16:36.55 |
| chrisl | Hmmm, I wonder....... | 16:37.37 |
| | henrys: actually, it *might* be viable because each glyph rendering is bounded by a gsave/grestore in the graphics library | 16:41.12 |
| henrys | I donât know, gsave on write to the graphics state might give a nice system wide boost. A lot of superfluous gsave and grestores are roaming around the code. | 16:41.43 |
| Robin_Watts | henrys: So gsave would set a flag, and only actually do anything when the first write happened? | 16:42.28 |
| henrys | Robin_Watts: that was my thought but my first thoughts about gs have about a 90% failure rate ... | 16:43.06 |
| Robin_Watts | gsave gsave gsave draw grestore draw grestore draw grestore | 16:43.43 |
| chrisl | I doubt that would help in this case | 16:44.02 |
| henrys | chrisl: I havenât looked at the font rendering performance in a long time I do recall that was an issue in the past. Certainly pushing more than one character at a time with pcl would help a lot | 16:46.01 |
| chrisl | We *do* change the graphics state during glyph rendering - what might be viable is that we explicitly store and then replace the things that change, thus avoiding the expense of a full gsave/grestore. That, of course, comes with its own risks...... | 16:46.26 |
| | henrys: it does look like rendering more than one glyph would be complicated, between the line wrapping and the BS code logic..... One possible "halfway" option would be to allow the enumerator to be reused - so we only create and fully populate one text enumerator for each buffer of characters, and just fiddle with the parts that change | 16:50.26 |
| | Hmmm, that might play badly with high level devices, though :-( | 16:53.38 |
| henrys | chrisl: Iâm not going to look at this more until I see numbers from marcosw. | 17:08.28 |
| marcosw | is working on the numbers⦠| 17:08.46 |
| henrys | marcosw: take your time ;-) | 17:09.01 |
| chrisl | henrys: fair enough. I'm going to finish for the day in a moment, anyway...... | 17:09.14 |
| marcosw | I always do :-) | 17:09.18 |
| rayjj | marcosw: are you doing anything to see how consistent the timings are ? | 17:09.22 |
| marcosw | rayjj: yes, I run the code 3 times, so I can put error bars on the plot. | 17:09.53 |
| rayjj | marcosw: cool | 17:10.00 |
| marcosw | I'll plot the min/'max/average, that should give us some confidence. Also I'll make sure the machine isn't doing anything else (i.e. I'll take it out the cluster pool). | 17:10.35 |
| rayjj | time for coffee. bbiab | 17:10.54 |
| henrys | marcosw: all that stat stuff for you PhD is being put to fine use! | 17:11.39 |
| marcosw | it is true that I have a much better understand of how to generate pretty graphs and other figures. | 17:12.22 |
| chrisl | With PCL shouldn't -dUseFastColor=true prevent *all* calls to LCMS? | 17:17.03 |
| henrys | chrisl: Iâd think so yes | 17:22.49 |
| chrisl | henrys: well, setting it I still see several LCMS2 calls in my profile | 17:23.15 |
| | henrys: I don't see the UseFastColor option getting sent to the device at all in PCL | 17:27.53 |
| henrys | chrisl: should be written at plmain.c:1116, no? | 17:33.28 |
| chrisl | henrys: I see the call to gs_putdeviceparams() but I'm not seeing it set in the device - at least, not yet..... | 17:34.14 |
| rayjj | it should be part of all devices since it is in gsdparam.c | 17:36.42 |
| | (get/put default_param) | 17:36.56 |
| henrys | chrisl: pcl argument processing is a ratâs nest maybe it doesnât get set. If you hit that line number in the debugger where the bool is set it should work, Iâd think | 17:37.43 |
| rayjj | chrisl: bp gx_default_put_usefastcolor | 17:38.26 |
| chrisl | Yes, I got there - for some reason my breakpoint didn't work in gx_default_put_params().... | 17:38.49 |
| | Hmm, my profile has some really weird things in it - I'm seeing calls listed from libtiff - but the command like specifies the "bit" device | 17:42.08 |
| henrys | chrisl: gprof? | 17:44.19 |
| chrisl | henrys: yeh, I think it's confused..... | 17:44.42 |
| henrys | I used pbmraw and didnât get anythink like that let me try bit | 17:45.05 |
| chrisl | henrys: no, it's fine - if I do the two profiles running the exes from the current directory, I see more sensible output. | 17:46.32 |
| | henrys: I'm really going to have to stop - I'm getting a headache. I think you're right, we should wait for marcosw to finish, and then use the results to decide which of us runs with it (if either). | 17:50.48 |
| Robin_Watts | Do we have a copy of the ETS paper? | 17:59.08 |
| marcosw | Robin_Watts: is it the one from 1999? | 18:03.40 |
| Robin_Watts | Sorry, no, they are asking for another one that I don't have/can't find. | 18:04.28 |
| marcosw | actually I found 3 on scholar.google.com, I'll upload them to casper (under ~marcos/screening) | 18:04.37 |
| henrys | Robin_Watts, marcosw the patent numbers are in the ets.c file and there is a algorithm description of course | 18:05.31 |
| | donât know about the paper | 18:05.36 |
| Robin_Watts | henrys: there is a copy of the main paper on both raph's site, and on ours (in chrisl's area) | 18:06.33 |
| | but this is a paper to which it refers. | 18:06.41 |
| marcosw | I uploaded the 3 papers authored by "RL Levien" that are relevant to screening; he has other papers but they deal with curves and/or fonts. | 18:09.38 |
| Robin_Watts | "Output dependent feedback in error diffusion" | 18:15.59 |
| malc | Robin_Watts: did my message made it through to you in pm? | 18:18.52 |
| marcosw | that might not be online. Google Scholar says it's been cited 102 times but doesn't provide a link to it. | 18:18.55 |
| | here's the complete reference: | 18:19.04 |
| | Levien, Raph. "Output dependent feedback in error diffusion halftoning." SPIE MILESTONE SERIES MS 154 (1999): 389-392. | 18:19.05 |
| Robin_Watts | malc: Yes. | 18:19.22 |
| | That makes sense, but tor8 is the guy for that | 18:19.41 |
| | Can you open a bug on bugs.ghostscript.com and attach it there please? I'm buried in non-MuPDF stuff at the mo. | 18:20.05 |
| malc | Robin_Watts: i haven't seen him here in quite a while | 18:20.12 |
| | sure | 18:20.18 |
| Robin_Watts | He's here, just quiet. | 18:20.20 |
| malc | erm.. and invisible | 18:20.46 |
| marcosw | Robin_Watts: it doesn't appear to be available online, here is the publisher URL for the book in which it appears: <http://spie.org/Publications/Book/327287?origin_id=x853> | 18:21.26 |
| | I can request a copy from the Uni science and engineering library (assuming they don't have it on the shelf, in which case I'll have to walk over there and photocopy it). | 18:22.12 |
| Robin_Watts | malc: he's not here currently, but he is generally here. just quiet. | 18:22.20 |
| | marcosw: That'd be great, if you could, please. | 18:22.31 |
| | Otherwise I could get it from the Bod, but that'd mean schleping down to oxford. | 18:22.53 |
| | No massive hurry! | 18:23.20 |
| malc | Robin_Watts: okay thanks | 18:23.20 |
| marcosw | Ironic that it's easier to get materials that are not available locally, instead of interlibray loans they email you scans but if it's one the shelf you have to walk to the library (obviously the latter is faster). | 18:23.53 |
| | I have to run; be back online later today. | 18:24.18 |
| Robin_Watts | Ta. | 18:24.22 |
| mvrhel_laptop | rayjj: ok you should be good to go now. both win32 and x64 solutions should build. | 18:44.27 |
| | several files were missing | 18:44.39 |
| | and there were a couple more project setting issues | 18:44.47 |
| | but all should be good now | 18:44.51 |
| | you will need to down load the extension for the installers if you want those to build | 18:45.23 |
| | let me add a readme for that | 18:45.34 |
| | rayjj: http://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d | 18:47.44 |
| | rayjj: please let me know if you have any more issues | 18:51.22 |
| rayjj | mvrhel_laptop: trying the build now... | 18:51.22 |
| | mvrhel_laptop: OK. Hurray! it builds | 18:52.26 |
| mvrhel_laptop | rayjj: good. I should have done a clean check out to begin with to fix all of this | 18:52.43 |
| | sorry it took so long. | 18:52.55 |
| rayjj | mvrhel_laptop: well, somebody had to be second :-) | 18:53.18 |
| | mvrhel_laptop: np on the delay -- I was just curious and did it when I got frustrated trying to track down other issues... | 18:53.50 |
| | which is what I should be doing :-) | 18:54.02 |
| mvrhel_laptop | ok. well it all needed to be done. I need to fix a few things I know. I may do a bit of work on it this week as a break from SOT charts if I start pulling out hair. | 18:54.34 |
| | so far SOT has not been too bad but I have been limited in what part of the code I am working in | 18:54.49 |
| | anyway back to the salt mine | 18:55.20 |
| rayjj | mvrhel_laptop: well, the installler thingies are free, but they only install if you have Visual Studio Professional (the dialog just says Visual Studio is required, but not installed on this computer :-( | 19:12.06 |
| | mvrhel_laptop: Guess I need to buy Pro eventually | 19:12.23 |
| | mvrhel_laptop: it runs, but I get the "MuPDF DLL not found 1" message | 19:14.16 |
| | do I have to "Install" in order to have it know how to find the DLL ? | 19:14.50 |
| Robin_Watts | rayjj: Try copying the DLL into the folder with the binary as a workaround? | 19:18.09 |
| rayjj | Robin_Watts: I have mupdfnet.dll in there | 19:19.13 |
| Robin_Watts | dunno then :( | 19:21.17 |
| rayjj | oh, I just noticed "load failed" for some of the sub projects (the Installers I got warnings on, but I also have it on some other projects) | 19:23.24 |
| | hmm... it makes a libmupdf.lib but not a libmupdf.dll | 19:23.56 |
| | OK, I see it as a dependency for the link of mupdfnet.dll so that should be OK | 19:26.22 |
| | I even get the same thing if I run it from msys with the cwd in platform/winrt/gsview/bin/Debug/ -- invoking it as gsview.exe The app starts, it just won't do anything | 19:32.57 |
| | Oh, I see. The default configuration is Win32, but I have to select Win64 and rebuild. Then it works | 19:39.24 |
| | ISTR, mvrhel mentioning that it is only for 64-bit | 19:39.53 |
| | Forward 1 day (to 2014/07/23)>>> | |
IRC Logs