| | <<<Back 1 day (to 2014/09/01) | 2014/09/02 |
| kens | chrisl I can't seem to make this font cache work with non-gc memory :-( I get a crash in gc_validate_object from gs_vmreclaim, at the end of the job..... | 08:01.01 |
| chrisl | kens: Hmm, that's weird. Even though the font directory has the gc stuff in it, I thought it would only come into effect if allocated in gc memory.... | 08:04.01 |
| kens | I'm very unsure. It works fine in PCL of course, no GC..... | 08:04.21 |
| | In GS we allocate the 'dir' in stable memory and the ccache in noin_gc_memory. I'mkk giving that a try, but it means adding GC tracking for the pointer into the pdfwrite structure | 08:05.07 |
| | The 'dir' pointer that is, of course | 08:05.36 |
| chrisl | That should be easy enough, but still rather a pain :-( | 08:05.53 |
| kens | Yeah, and no guarantgee it'll work beyond 'monkey see, monkey do' | 08:06.08 |
| | Ah, and that crashes while freeing the font cache.... Oh, probably because I have teh memory pointer wrong now, oops | 08:06.58 |
| | Well, I have a 34 page file working now, time for a cluster test I guess. | 08:14.23 |
| chrisl | kens: it's not immediately clear to me why it doesn't work in non-gc memory - I can take a look in a while if you like...... | 08:17.03 |
| kens | Let me see how this goes, I'd *much* prefer to do this in non-GC memory, but at least if this works I can pass you something working to look at and poke. | 08:17.47 |
| | Having said that, I see that we do GC pointer tracking of the font_dir in GS, and I'm certainly not doign that properly, so I suspect this will fail. | 08:26.11 |
| chrisl | I thought you were adding the pointer to the gc stuff for pdfwrite? | 08:27.18 |
| kens | Just for the font_dir itself, I'm not certain that the full GC tracking gets done | 08:27.39 |
| | I'll let you know in a minute, the test just finished | 08:28.10 |
| chrisl | That should be taken care of by the declarations for the font_dir structure | 08:28.26 |
| kens | 'SHould be' :-) | 08:28.36 |
| | I know it ought to work, but I have zero confidence in this stuff | 08:28.49 |
| | Yep, still *lots* of seg faults | 08:29.14 |
| | Fewer than before though | 08:29.27 |
| | Down to 187 now | 08:29.40 |
| chrisl | Are all the fonts being freed before the cache? | 08:30.39 |
| kens | They 'should' be, as I free the cache at the end of pdf_close | 08:31.02 |
| | But we all know how good pdfwrite is at memory management | 08:31.16 |
| chrisl | This is the kind of situation where sane reference counting would be helpful! | 08:31.50 |
| kens | OK the Altona file crashes before I free the cache. In copied_type1_SEAC_DATA | 08:31.53 |
| | chrisl, yes :-( | 08:32.04 |
| | Seems pfont->dir->global_glyph_code is NULL and the code doesn't check for that | 08:32.35 |
| | I admit I have no idea what that is..... | 08:33.02 |
| chrisl | Ah, was about to ask! | 08:33.11 |
| kens | Seems to be a function pointer | 08:33.37 |
| | It gets set to zfont_global_glyph_code in zfont.c | 08:34.09 |
| | Where its a staic, lovely..... | 08:34.42 |
| chrisl | So, you probably need to pull the value of that from the "real" font cache - which should exist when pdfwrite is initialised | 08:35.05 |
| kens | Yeah, I think that's the only solution | 08:35.21 |
| | I also need to update ccache.mark_glyph going by the code in there | 08:35.38 |
| kens | heads off to do that.... | 08:35.57 |
| chrisl | Remember that only gs sets the font_dir entry in the graphics lib context, so you'll have to check that before using it | 08:36.29 |
| kens | I'm asssuming at the moment that the PCL interpreter doesn't set these, and they aren't used for PCL fonts. | 08:37.18 |
| chrisl | I would suspect not. | 08:38.12 |
| kens | rebuild.... | 08:40.09 |
| | OK well that solves the altona file, guess I'll just do another push and see how many more are left | 08:41.41 |
| | And check out the PCL implementation while it runs | 08:41.54 |
| | Ah, I see you beat me to it with a trio fix :-) | 08:45.53 |
| chrisl | Oh, sorry, I thought you'd already pushed your test | 08:46.16 |
| kens | Doens't matter, I need to go check that this works with PCL now, so I've plenty to do | 08:46.34 |
| | I also think the PCL implementation of the font cache needs to change, it explicitly uses non-gc memory and I think it ought to use the stored memory pointers when freeing the memory instead, so there's no chance of confusion. | 08:47.27 |
| | But I'll probably put that one to Henry ratehr than doing it myself | 08:47.48 |
| chrisl | You are probably right *but* in practice it is almost certainly benign: PCL is (or should be) consistent in the allocator it uses everywhere | 08:48.34 |
| | kens: that complaint about ps2write emitting "huge Postscript output" - I did find something interesting in the acroread output (which I'm not inclined to mention on the bug thread at the moment)...... | 08:49.40 |
| kens | It absolutely is, but I htink it would save confusion if it 'properly' used the stored memory pointer. I need to revamp my own use (because I simply copied the PCL free code) so that it uses the correct memory pointers. It does right now but if I change hte type I have to alter the free code too, and I shouldn't need to.... | 08:49.58 |
| | OK put it to me privately ? | 08:50.13 |
| | I *did* look at it..... | 08:50.27 |
| chrisl | private chat or e-mail? | 08:50.33 |
| kens | Either is fine | 08:50.39 |
| chrisl | You may already know it..... | 08:50.48 |
| kens | :-) | 08:50.52 |
| | OK so with PCL the gs_lib_ctx pointer to font_dir is NULL, so I can indeed use this to check and copy the (PostScript) required members from it | 08:55.40 |
| chrisl | Yes, which is one of the reason I think the way PCL uses the cache is contrary to the intended use | 08:56.49 |
| kens | I'm inclined to agree. A 'dummy' font dir would work if placed there of course, but that is also somewhat contrary to expected use I would say. And teh passthrough PCL ugliness makes it pretty well impossible to use it 'properly', as we would still end up throwing the cache away before pdfwrite gets to see it. | 08:58.12 |
| chrisl | To handle the pcl passthrough case "properly" would have meant a hefty overhaul of the cache machinery - much quicker just to hack it :-( | 08:59.39 |
| kens | Indeed.... :-(( | 08:59.53 |
| Robin_Watts_ | tor8: (For the logs) 1 more commit on robin/master. Looking at yours now. | 09:12.39 |
| | I've pushed yours. | 09:35.52 |
| tor8 | Robin_Watts_: LGTM. | 10:08.53 |
| Robin_Watts_ | Ta. | 10:09.00 |
| tor8 | Robin_Watts_: zero differences with the strtod change, that's reassuring :) | 10:09.52 |
| | haven't measured the performance impact though | 10:10.30 |
| Robin_Watts_ | fz_snprintf makes a huge difference though. | 10:21.28 |
| tor8 | Robin_Watts_: where? | 10:33.47 |
| Robin_Watts_ | http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=7e274313904e46cd3cf3f476ceb888ca687d1969&project=mujstest | 11:55.43 |
| | tor8: mujstest | 11:55.49 |
| | tor8: git revert that commit then clusterpush mujstest and then bmpcmp to do a visual compare? | 11:56.45 |
| tor8 | Robin_Watts_: yeah, I'll look into it | 11:56.55 |
| | do you use pdf_print_token in mujstest? | 11:59.40 |
| Robin_Watts_ | off the top of my head, I have no idea. | 12:02.34 |
| tor8 | because that's really the only place that was affected by the snprintf commit | 12:02.50 |
| Robin_Watts_ | Probably in the forms stuff, it's used to generate AP streams? | 12:02.56 |
| | That synthesis uses the pdf_device I think. | 12:03.29 |
| tor8 | that, and pdfclean's pretty printing of numbers | 12:03.31 |
| | which are both more accurate now | 12:03.50 |
| Robin_Watts_ | so they are probably many many subpixel differences. | 12:04.09 |
| | Your bmpcmp should confirm that and we can ignore it then. | 12:04.25 |
| tor8 | Robin_Watts_: I can't get the bmpcmp to start... | 12:24.35 |
| Robin_Watts_ | If you look at your report, there were no differences. | 12:25.14 |
| | just 48 errors | 12:25.20 |
| | hence bmpcmp won't start as it has no files to check. | 12:25.37 |
| tor8 | right. I was looking at the wrong report. | 12:27.06 |
| Robin_Watts_ | as to why.... no idea. | 12:27.20 |
| | Maybe git checkout back rather than git revert and retest? | 12:28.24 |
| tor8 | and that's made me even more confused | 12:28.26 |
| | Robin_Watts_: I don't think that's going to work... "The following 629 regression file(s) had differences but matched at least once in the previous 25 runs" | 12:41.50 |
| Robin_Watts_ | ass. | 12:42.17 |
| | You may need to resort to running a random sampling of them locally. | 12:42.30 |
| | btw, I cocked up when I pushed last night, and pushed a load of commits I shouldn't have. | 12:42.56 |
| | I then did a force push to put it right (30 seconds later). | 12:43.07 |
| | I then noticed that the cluster hadn't been testing mupdf for a few days because (presumably) you'd done a force push then as well. | 12:43.32 |
| | When we do a force push, I need to prod the cluster to get it working again. | 12:43.44 |
| tor8 | yeah, I think I had to do a force push last week as well due to a slip-up | 12:44.07 |
| | pushed from the wrong branch :( | 12:44.13 |
| | how do you prod the cluster then? might be handy to know. | 12:44.24 |
| Robin_Watts_ | tor8: ~regression/cluster/mupdf is the git repo that the clustermaster pulls into | 12:44.59 |
| | It pulls into incoming_master, and then stuff gets transferred to master as the jobs are queued for testing. | 12:45.38 |
| | hence you need to reset incoming_master and master as appropriate. | 12:45.49 |
| | and you mustn't leave it checked out in incoming_master, as if you do, the fetch fails. | 12:46.13 |
| tor8 | right. | 12:47.53 |
| | reset master and incoming_master and leave HEAD pointing to master | 12:48.20 |
| Robin_Watts_ | yeah. | 12:51.21 |
| | I should put that on the twiki or something. | 12:51.31 |
| tor8 | Robin_Watts_: hm, looking at the scan-build warnings I wonder if there's a way to teach it about fz_rethrow | 12:59.43 |
| henrys | chrisl, kens the other thing I thought of was not to free the cache for high level devices. That might be simplest and solve norbert's issue. That change would seem less of an upheaval. Thoughts? | 14:04.22 |
| kens | henrys it would work, but would leave the cache(s) behind so memory leaking. Isn't it better to fix the leaks ? | 14:04.54 |
| henrys | kens: it would leak for high level devices only which leak like seives anyway last I looked. | 14:05.27 |
| kens | Well pdfwrite doesn't leak, I spent a lot of time sorting that out. | 14:05.47 |
| henrys | with PCL it doesn't? There is nothing that depends on GC in pdfwrite? | 14:06.09 |
| chrisl | henrys: I don't think piling an even worse hack on top of a hack is a good idea | 14:06.25 |
| kens | I spent *lots* of tim explicitly freeing everything in pdfwrite, for a number of reasons. I won't say absolutely that nothing ever leaks, but it shouldn't | 14:06.43 |
| | One reason is for the '%d' output format, another was for PCL. | 14:07.08 |
| henrys | kens, chrisl okay let's go with what you've got | 14:07.09 |
| kens | If you are happy with teh patch I can commit it. | 14:07.20 |
| | It passes cluster testing without problems. | 14:07.37 |
| henrys | kens: I'm good | 14:07.52 |
| kens | OK give me a few minutes to squirrel away what I'm doing, and I'll pull the code fro my stash | 14:08.17 |
| tor8 | Robin_Watts_: the differences I've looked at manually look very much to be subpixel differences | 14:08.26 |
| Robin_Watts_ | tor8: cool, then we shouldn't worry about it. | 14:08.47 |
| | tor8: Random thought... could we have a hint that says "stop running now"? | 14:09.37 |
| | We could short circuit the entire interpretation that way. | 14:10.16 |
| tor8 | it should be easy to add, but we'd need to take care to pop all the graphics stack operations | 14:10.17 |
| Robin_Watts_ | The draw device has cleanup code for that, but it wouldn't be used for the draw device. | 14:10.42 |
| | All devices should cope with being told to abort early, right? | 14:11.30 |
| tor8 | yeah, but I think some might depend on the open elements being closed | 14:11.49 |
| | I don't remember when FZ_MAINTAIN_CONTAINER_STACK was introduced | 14:12.24 |
| Robin_Watts_ | That was to allow some logic that we thought would be common to several devices to be moved out into the null device layer, I think. | 14:13.38 |
| tor8 | as long as the early-abortion from the interpreter is patched up by the null device to maintain the various stack states, which I think it does already but I'm not 100% confident | 14:13.44 |
| | then we should be fine | 14:13.48 |
| | in the xps interpreter we'd just stop iterating over children in the xml and drop back up the stack closing elements as we go | 14:14.24 |
| | and I reckon the same would hold for pdf recursion through XObjects | 14:14.45 |
| | we already handle hitting EOF early in pdf so actually, I think you can just ignore my ramblings and add the flag and code to bail out of the interpreter as if we hit EOF in the pdf interpreter | 14:15.41 |
| | maybe toss a fz_warn that we were aborted | 14:15.56 |
| rayjj | Hi, all | 14:18.08 |
| Robin_Watts_ | Morning rayjj | 14:18.19 |
| rayjj | I have to leave at 7:30 -- anything for me this AM ? | 14:18.30 |
| henrys | rayjj: company C status? | 14:18.45 |
| rayjj | I'll be back, but it's my youngest's first day of school and he wants me to take him | 14:19.08 |
| henrys | rayjj: that's a big day! | 14:19.34 |
| rayjj | henrys: I requested some docs from them -- they're available in a web site, but the docs are password protected PDF's :-( | 14:19.52 |
| | so actually, I requested the password. | 14:20.09 |
| | I did fire up the M board, and other than the baud rate for the debug port being incorrect in the docs, it works (it said 115200, but it was actually 38400) | 14:21.04 |
| | working in linux will be a *LOT* simpler | 14:21.29 |
| henrys | is the M linux? | 14:21.48 |
| rayjj | I also registered with company M for their "extranet" -- waiting for them to get back to me with the auth code | 14:22.19 |
| | henrys: yes, M is linux :-) | 14:22.29 |
| | the company C board is ThreadX :-( | 14:22.52 |
| | and the expected "flow" of stuff through their system is arcane | 14:23.58 |
| | OK, my son wants to go... bbiaw | 14:24.11 |
| henrys | rayjj: unfortunately I think C is a bit more important. | 14:24.15 |
| | bye | 14:24.20 |
| | meeting in 5 minutes | 14:26.01 |
| marcosw | I like how rayjj and mvrhel_laptop leave just as the meeting starts... | 14:30.06 |
| mvrhel_laptop | hey. I just had a network goof here | 14:30.34 |
| henrys | marcosw: ray is missing this one. | 14:30.39 |
| mvrhel_laptop | although it is the first day of school here too. I will need to head out for a few minutes around 8pm to see them off | 14:30.59 |
| marcosw | henrys: I was joking, I saw that he's taking his kid to school. | 14:31.20 |
| | school started last week for my kids | 14:31.36 |
| Robin_Watts_ | You're all doing it wrong. Boarding school. Ship 'em off once aged 7 and see 'em again when they are 18. | 14:32.01 |
| marcosw | my daughter is a senior in high school, so college next year :-( | 14:32.16 |
| kens | Melanie starts university in < 3 weeks now.... | 14:32.42 |
| Robin_Watts_ | How is Stella coping with that? | 14:32.56 |
| kens | RIght now ? Happy to see the back of her :-) | 14:33.12 |
| marcosw | kens: which uni is she going to? | 14:33.15 |
| kens | Might change in a few weeks | 14:33.18 |
| henrys | I ddn't have anything beyond what's on the agenda for this meeting. Does anyone else have anything. I believe fredross-perry had some questions for tor8 but he might have solved those problems already. | 14:33.28 |
| kens | marcosw : UCL (University Colege London) | 14:33.32 |
| fredross-perry | I had a build-related issue, but thatâs solved. | 14:33.56 |
| chrisl | We are fast approaching release time - I'd like to do a release candidate early next week. Unless there are objections | 14:34.24 |
| Robin_Watts_ | fredross-perry: If you ever have a question, and we're not here, just ask the question and leave the window open. We check the logs and will reply when we return. | 14:34.35 |
| henrys | mvrhel_laptop: are you giving fredross-perry some feedback as he goes along here? (review) | 14:34.49 |
| fredross-perry | ok, groovy. | 14:34.50 |
| Robin_Watts_ | fredross-perry: Presumably you're happy using git? Do you have git repo somewhere? | 14:35.13 |
| mvrhel_laptop | henrys: I can do that. Is there a place that I can look over the this fredross-perry/? | 14:35.18 |
| fredross-perry | Iâm happy for anyone to take a look. http://github.com/fredrossperry/mupdf.git | 14:35.23 |
| Robin_Watts_ | Either we can give you an account on casper, or you... ah, github, great. | 14:35.30 |
| mvrhel_laptop | ok great. | 14:35.31 |
| henrys | mvrhel_laptop: or other mupdfers can weigh in on the work | 14:35.34 |
| | kens: what is going on with pdfwrite color management? Can we get this off the agenda soon? | 14:36.11 |
| mvrhel_laptop | that should be done I would think | 14:36.26 |
| fredross-perry | I havenât touched mupdf itself. Just been using whatâs in pdfapp.{c,h} | 14:36.33 |
| kens | henrys there is still work to do, I have a bug open to remind me what needs doing. Its not going to get done soon though. You can remove it form teh agenda any time | 14:36.43 |
| henrys | kens: I'm going to remove the high level device memory ownership entry since you are about to fix that. | 14:36.48 |
| mvrhel_laptop | fredross-perry: did you build and run the gsview that I made for windows? | 14:36.57 |
| kens | I think I already did, if that'ts the Norbert bug | 14:37.01 |
| mvrhel_laptop | we will want to interface to ghostscript also at some point | 14:37.19 |
| fredross-perry | yes I did, just to get a sense of how that versionâs UI works. | 14:37.20 |
| henrys | kens: which bug I'll add it to the entry before I remove it for archiving? | 14:37.27 |
| kens | 695017 is the one I just closed | 14:37.42 |
| | pcfont_do_reset() leaks memory | 14:37.56 |
| fredross-perry | I have a basic Qt app into which I am adding everything necessary to make it work similarly to gsview. | 14:38.20 |
| henrys | kens: no which bug is not going to be fixed for a long time. | 14:38.29 |
| | ? | 14:38.30 |
| kens | Oh the colour management in pdfwrite, just a moment | 14:38.41 |
| mvrhel_laptop | fredross-perry: ok. If you do see something that should be different in the windows gsview UI, please let me know | 14:38.49 |
| kens | henrys Bug #695302 | 14:38.58 |
| fredross-perry | I am also adding menu bar items to match the keystroke-driven commands, putting About and Help where theyâre expected, that wort of thing. | 14:40.11 |
| | *sort* | 14:40.44 |
| marcosw | chrisl: there is a build issue with 'make uproduct' but I can't find the bug number at the moment. do you recall the problem? | 14:40.48 |
| henrys | kens, chrisl I'm wondering if you shouldn't be helping ray out with projects. he is a bit backed up. the tmp file stuff would be great to get in for example. | 14:41.06 |
| chrisl | marcosw: so? It's not supported any more | 14:41.12 |
| | henrys: then something else gets shuffled away | 14:41.36 |
| kens | henrys, its not obvious what I could help Ray with. | 14:41.37 |
| marcosw | chrisl: http://bugs.ghostscript.com/show_bug.cgi?id=695220 | 14:41.38 |
| kens | and as chrisl says, then I will be dropping something else | 14:41.53 |
| | Liek the colour management, which is already on hold because I'm too busy to finish it | 14:42.09 |
| marcosw | chrisl: okay, I'll stop testing it. Could we take the uproduct target out of the makefile? | 14:42.44 |
| fredross-perry | Iâve noticed that when printing to a high-res printer (like 1200 dpi), rendering each page takes a bit of time. I put in a progress/cancel thingy. Concerned? | 14:42.53 |
| chrisl | marcosw: I'll do that, yeh | 14:42.58 |
| henrys | okay I didn't realize you were fully occupied with customer or agreed upon projects. | 14:43.08 |
| marcosw | and probably the documentation (not sure if it's (still) documented). | 14:43.21 |
| kens | I'd hoped to get back to the form matrix problem from the customer before the release, but that's looking doubtful | 14:43.44 |
| chrisl | marcosw: I'll check the docs, too | 14:43.45 |
| henrys | kens: but I was thinking of you pushing along the /tmp file stuff, it seems like that will never go away. | 14:44.13 |
| marcosw | grep doesn't find any mention of uproduct other than in the Makefile. | 14:44.22 |
| kens | henrys, I don't think I'm a good person to deal with that, I have no idea what's going on there | 14:44.35 |
| Robin_Watts_ | fredross-perry: Are you rendering in bands or to a whole page? | 14:44.37 |
| mvrhel_laptop | fredross-perry: how are you doing the printing in the code? | 14:44.41 |
| | yes | 14:44.44 |
| henrys | kens: fair enough | 14:44.48 |
| | anything else meeting wise? | 14:46.27 |
| kens | Nope | 14:46.40 |
| Robin_Watts_ | The mupdf customer with greyscale/color detection... | 14:46.54 |
| | I hope they should be happy with the latest version now. | 14:47.04 |
| mvrhel_laptop | nothing from me. I would like to fix up a couple minor things in the windows gsview and get it thrown up on the gsview.com website at some point | 14:47.08 |
| kens | Ah, Mr Binks | 14:47.09 |
| fredross-perry | Calling pdfapp_showpage at the printerâs resolution. Then pushing the produced image data to some Qt objects to move to the printer. | 14:47.09 |
| marcosw | henrys: I think we are good for a release candidate as far as the open bugs are concerned, no blockers (afaik). | 14:47.17 |
| Robin_Watts_ | fredross-perry: Wooah! | 14:47.32 |
| | You're building the Qt app on top of pdfapp? | 14:47.47 |
| fredross-perry | Yes, that seemed the simplest thing to do, since pdfapp encapsulates a good deal of necessary logic. | 14:48.19 |
| Robin_Watts_ | tor8: How do we feel about that? | 14:48.25 |
| marcosw | Did anyone notice any issues with casper after the 12.04 -> 14.04 update (other than the git issue that tor8 found and fixed)? I assume there were no major problems, since I didn't get any panicky emails. | 14:48.55 |
| Robin_Watts_ | My impression was that pdfapp is not powerful enough to allow you to do all the stuff that gsview does. | 14:48.57 |
| henrys | marcosw: okay chrisl do you have a sense when you want to release? | 14:49.14 |
| Robin_Watts_ | marcosw: The twiki config was broken. I fixed it. | 14:49.14 |
| kens | marcosw casper seems fine to me | 14:49.28 |
| tor8 | fredross-perry: pdfapp is not a good example to look at, in fact it's terrible! :) | 14:49.33 |
| henrys | mvrhel_laptop: so you won't be around for skype? | 14:49.45 |
| chrisl | henrys: see above...... at 15:34...... | 14:49.46 |
| Robin_Watts_ | marcosw: It was broken cos the new version of apache didn't ignore an error any more. | 14:49.50 |
| tor8 | fredross-perry: also, please use lowercase path names (or my OCD will rename everything for you) | 14:49.51 |
| mvrhel_laptop | henrys: I might be out for the first 15 mintues of the skype meeting | 14:50.02 |
| | have to go out and take a couple pictures | 14:50.09 |
| | etc | 14:50.10 |
| henrys | chrisl: sorry missed it completely. | 14:50.25 |
| Robin_Watts_ | tor8: fredross-perry is not just using pdfapp as an example - he's actually building the app using it. That seems very wrong to me. | 14:50.31 |
| henrys | no objection here chrisl | 14:51.09 |
| tor8 | yeah. I would very much advise against that. the pdfapp stuff is a hodge podge of cruft accumulated to work specifically for the x11 and win32 viewers that's never been designed to be good for general use | 14:51.10 |
| Robin_Watts_ | chrisl: You want to release at 15:34? :) | 14:51.17 |
| tor8 | there are some useful bits in there, but they should really be pulled out and into the real mupdf api | 14:51.51 |
| chrisl | Robin_Watts_: I tried, but was too late...... | 14:52.08 |
| Robin_Watts_ | You've got another chance tomorrow. | 14:52.31 |
| chrisl | Robin_Watts_: I'll try and manage it at 15:34 next Monday..... | 14:52.58 |
| marcosw | Robin_Watts_: thanks for finding and fixing it, I'll add the twiki to my things to test next time I do an update. | 14:53.48 |
| Robin_Watts_ | marcosw: It was my fault it was broken, so seems only fair :) | 14:54.32 |
| mvrhel_laptop | fredross-perry: that is why I was asking about the current gsview app. I wonder if rewritting the c# stuff in c++ makes some sense for you | 14:55.03 |
| fredross-perry | Sorry about confusion re: gsview. My task as I understood it was to âportâ the WIndows viewer, which I thought was the one in platform/win32, which uses pdfapp. | 14:56.29 |
| mvrhel_laptop | it really should not be too bad. some of the hairier stuff in there had to deal with the boundary between managed and unmanaged code. You would not have any of those issues and we could strip out a lot that deals with the ui. You could just use my API to mupdf | 14:56.36 |
| | gsview is the c# app | 14:56.56 |
| Robin_Watts_ | fredross-perry: No. The desire is for you to port the "new" windows viewer, which is gsview. | 14:56.57 |
| fredross-perry | where is that API found? thanks. | 14:57.06 |
| Robin_Watts_ | gsview is in platform/winrt, I believe. | 14:57.45 |
| mvrhel_laptop | fredross-perry: yes. on the windows_desktop branch. | 14:58.03 |
| | fredross-perry: are you available this morning. | 14:58.15 |
| fredross-perry | yes | 14:58.24 |
| Robin_Watts_ | mvrhel_laptop: Can we merge windows_desktop down to master now? | 14:58.25 |
| mvrhel_laptop | maybe we can go through that code real quick this morning | 14:58.25 |
| | Robin_Watts_: we can do that | 14:58.34 |
| Robin_Watts_ | would be good to do before the release. | 14:58.42 |
| mvrhel_laptop | rayjj had me fix a bunch of issues | 14:58.44 |
| | and I think it is ready to merge | 14:58.55 |
| Robin_Watts_ | cool. | 14:59.02 |
| mvrhel_laptop | I will try to do that today | 14:59.18 |
| Robin_Watts_ | gsview isn't strictly winrt though, is it? | 15:00.13 |
| mvrhel_laptop | fredross-perry: lets talk on the phone at 10:30am if that works for you. I have a double kid send of this morning (one now and one at 10am) | 15:00.14 |
| | send off | 15:00.22 |
| | Robin_Watts_: gsview is not winRT at all | 15:00.34 |
| fredross-perry | ok, sounds good. | 15:00.42 |
| mvrhel_laptop | it does share some of the same code though | 15:00.48 |
| | so I don't know how best to organize that | 15:00.59 |
| Robin_Watts_ | so can we rename the dir? platform/windows maybe? | 15:01.11 |
| mvrhel_laptop | platform wise | 15:01.11 |
| | that would be good | 15:01.17 |
| Robin_Watts_ | tor8 may have a better idea for a name. | 15:01.27 |
| mvrhel_laptop | brilliant idea :) | 15:01.28 |
| | since under windows you have windows, winRT, winphone8 | 15:01.47 |
| | oh | 15:02.00 |
| | one thing though | 15:02.02 |
| | you will need vs2013 for this | 15:02.13 |
| | i know how you dislike that Robin_Watts_ | 15:02.27 |
| fredross-perry | Right now I have platform/Qt, which I hope can build mac/linux/windows desktop, for starters. | 15:02.28 |
| mvrhel_laptop | have to go now | 15:02.47 |
| | bbiab | 15:02.49 |
| Robin_Watts_ | mvrhel_laptop: I dislike requiring newer VS than we actually need to, but AIUI, the winrt stuff really won't build on anything earlier, right? | 15:03.03 |
| | fredross-perry: Sorry, we should have been clearer about this from the start. | 15:03.39 |
| | platform/qt sounds an ideal place. | 15:03.47 |
| | but you don't want to be calling pdfapp, you want to be calling the stuff that pdfapp calls. | 15:04.03 |
| kens | Robin_Watts_ : Mr Binks is back for you again :-) | 15:04.28 |
| Robin_Watts_ | Possibly you could copy pdfapp into your app and refactor it, but you might get better results working from a clean slate. | 15:04.55 |
| fredross-perry | It could be that simple. | 15:04.58 |
| | It would help if folks who know can say what parts of pdfapp are bad, so I can avoid. | 15:05.38 |
| | Iâm going to jump out now. mvrhel_laptop, call me at 10:30 Pacific, 415-518-9729 | 15:06.43 |
| Robin_Watts_ | fredross-perry: The guy to talk to... bah. was about to point him at tor8. | 15:07.10 |
| henrys | fredross-perry: this might be largely my fault - I thought you would be looking a michael's new gsview code in the branch we talked about and just port windows stuff to QT | 15:07.26 |
| Robin_Watts_ | mvrhel_laptop: (when you get back) when you speak to fred, encourage him to come on here and talk to us. | 15:07.45 |
| henrys | probably wasn't clear. | 15:07.46 |
| tor8 | Robin_Watts_: platform/qt and platform/windows sound good to me | 15:08.46 |
| | platform/dotnet? | 15:08.52 |
| henrys | I'm not really sure how/if fred is going to get regular review off on github. It just seems it would be simpler to give him an account and a personal repo. | 15:08.58 |
| Robin_Watts_ | tor8: urgh. mupdf doesn't build. the dtoa.c file dies because we don't have NAN defined. | 15:09.23 |
| tor8 | henrys: from our point of view, it doesn't matter where his personal repo lives as long as it's a fork from our git repo | 15:09.27 |
| | Robin_Watts_: ah, I might've forgotten to copy that bit from jsi.h | 15:09.58 |
| | #ifndef NAN #define NAN (INFINITY-INFINITY) | 15:10.07 |
| | the NAN define is a c99-ism | 15:10.18 |
| henrys | tor8: that may be but obviously we aren't reviewing... | 15:10.27 |
| tor8 | #define INFINITY (DBL_MAX+DBL_MAX) #define NAN (INFINITY-INFINITY) | 15:10.40 |
| | henrys: I wasn't even aware he'd set it up (or that fredross-perry was the person we've asked to write the Qt viewer) | 15:11.13 |
| | but once we know, we can add it to our list of remotes and see what happens there just as easily as on casper | 15:11.35 |
| henrys | tor8: I don't care how we do it. Just want to get fred some regular review. | 15:12.10 |
| tor8 | I already have 10 remote repositories I'm pulling from on my machine | 15:12.18 |
| henrys | so we don't go astray again | 15:12.23 |
| tor8 | one more won't break it | 15:12.27 |
| henrys | tor8: great. | 15:12.47 |
| tor8 | henrys: what does break it though, is that he didn't fork the mupdf git, he just created a new repository and copied in the code | 15:13.45 |
| | that can be fixed, but we'll need his presence here | 15:14.17 |
| henrys | tor8: I'll tell him. | 15:15.11 |
| Robin_Watts_ | tor8: fix commit on robin/master then. | 15:19.22 |
| tor8 | Robin_Watts_: LGTM | 15:20.06 |
| Robin_Watts_ | tor8: One possible way to fix the fredperry-ross git issues; clone mupdf on github, cherry-pick his commits, put them back on github, then tell him to fork that and continue from there. | 15:58.13 |
| | marcosw, kens: re the support mail about tiff stuff. AIUI, the thing is that gs 9.05 would have been writing broken tiff files (for files with compression at least) | 16:02.02 |
| | zeniko: Hey. | 16:02.13 |
| kens | Umm, which mail is this ? | 16:02.27 |
| zeniko | Robin_Watts: good evening | 16:02.28 |
| Robin_Watts_ | At least now, we're properly telling people. | 16:02.43 |
| zeniko | Robin_Watts_: tor8: I'd have two more commits on zeniko/mupdf for the impending(?) release | 16:03.03 |
| kens | Oh, difference in behaviour ? | 16:03.06 |
| Robin_Watts_ | kens: yeah. | 16:03.14 |
| kens | was leaving that one for Marcos | 16:03.18 |
| Robin_Watts_ | yeah, I figured. ISTR it was chrisl that actually added the error. | 16:03.45 |
| kens | Maybe they aren't using compression (which would be dumb) | 16:03.46 |
| chrisl | They say it's using g3 compression | 16:04.05 |
| kens | So they do (just read it) | 16:04.13 |
| Robin_Watts_ | some tiff readers probably won't care, cos they may not look at the indexes and might just walk the file looking for chunks. | 16:04.15 |
| | and if all the data is in a single chunk the index may even be right. | 16:04.57 |
| | cos you can predict where the first chunk will be, but not where subsequent ones will be. | 16:05.32 |
| chrisl | I actually can't remember if I special cased the non-compressed case...... | 16:05.52 |
| kens | anyone know who owns the tiffsep device ? | 16:07.58 |
| | Or I suppose this could be a colour issue, overprinting spot colours. | 16:08.25 |
| chrisl | tiffsep.dev: ray and henry | 16:08.46 |
| kens | I'll assign it to Ray then I guess. | 16:08.59 |
| | OK night all | 16:10.39 |
| rayjj | on gsview, is that going to be AGPL or something different (AFPL?) | 16:14.48 |
| rayjj | reviews the logs from the meeting | 16:15.03 |
| | I have "scheduled" power outages between 8am and 2pm today, so things might be up and down. | 16:28.45 |
| Robin_Watts_ | tor8: Urgh. an abort device hint ain't gonna fly. Would make the pdf_process code horrible. | 16:42.42 |
| | I wonder about a specific exception. | 16:42.49 |
| rayjj | Robin_Watts_: when rendering pages in a viewer, and the page is still being rendered when you need to go to a new "view" (page or zoom), how do you stop the page in process in order to free up CPU+RAM for the new view (or do you) ? | 16:46.51 |
| Robin_Watts_ | rayjj: When you interpret a page in MuPDF you can pass in a cookie. | 16:47.31 |
| | The cookie is a pointer to a structure, in which we have various fields. | 16:47.51 |
| | One of these fields is 'abort'. | 16:47.59 |
| rayjj | so, why doesn't this work for mudraw -T ? | 16:48.13 |
| Robin_Watts_ | If the caller decides that it doesn't need the interpretation, it can set the 'abort' field in the cookie. | 16:48.30 |
| | The interpreter will notice that between processing operators and will then bale out. | 16:48.47 |
| | The cookie is not available to the device. | 16:49.00 |
| | i.e. the device can't set the cookie. | 16:49.06 |
| tor8 | Robin_Watts_: let me think about it. can we discuss it tomorrow? I've got sebras here and just started on the epub stuff. | 16:49.10 |
| Robin_Watts_ | tor8: No worries. | 16:49.20 |
| | I'll do some experiments here between SOT compiles :) | 16:49.30 |
| rayjj | but the device can feed back "hints" or something ? | 16:49.32 |
| Robin_Watts_ | The device has access to hints, yes. | 16:49.49 |
| | but those are more typically used for callers to set and the device to read. | 16:50.13 |
| | We are abusing that slightly here by having the device set the hint that says "we don't care about images". | 16:50.43 |
| rayjj | sounds like the machinery is there to abort page interepretation -- just not the plumbing | 16:50.59 |
| Robin_Watts_ | The plumbing to use that would be horrible. | 16:51.16 |
| rayjj | plumbing often smells bad ;-) | 16:51.42 |
| Robin_Watts_ | because of the abstracted nature of how we process operators. | 16:51.47 |
| | Not all operators get processed through a device. | 16:51.55 |
| | Or rather, sometimes we can process a page without it going to a device (like when we are doing textual processing on the operator streams) | 16:52.53 |
| rayjj | Robin_Watts_: true, but those that don't probably aren't the ones that chew up much time | 16:52.59 |
| Robin_Watts_ | to do this using hints, we'd need to change every single operator handling function (for the run device processor at least) | 16:53.38 |
| | Using an exception seems much nicer, cos that jumps straight out using our usual exception handling routines. | 16:54.08 |
| | plumbing via hyperspace :) | 16:54.17 |
| rayjj | aka longjump ? | 16:55.26 |
| Robin_Watts_ | yeah. | 16:55.32 |
| | I dunno if you've seen it, but we have fz_try/fz_always/fz_catch clauses in mupdf, together with fz_throw() etc. | 16:56.04 |
| | Makes error handling a lot neater. | 16:56.12 |
| | They are implemented in terms of setjmp/longjmp, but the complexity is (largely) hidden from the user. | 16:56.48 |
| rayjj | oops, problem at home -- something glitched when power came back on -- bbiab (I hope) | 16:56.58 |
| | Robin_Watts_: yes, I've seen the try/catch stuff, and recall the discussions on the implementation design | 16:57.30 |
| | Robin_Watts_: sure is a *LOT* simpler than gs's approach of having every function have to check for code<0 and return | 16:58.29 |
| Robin_Watts_ | rayjj: Explicit error passing in C basically throws away the ability of the language to return values from functions. | 16:58.59 |
| rayjj | I recall going through some code that had bunches of cases missing and adding it. | 16:59.00 |
| | bbiab | 17:00.14 |
| mvrhel_laptop | ok. just had a hour + call with fredrossperry. I have him going in the right direction in terms of what interface/code to use | 18:45.30 |
| | I think it will not be too hard and his work will not have been thus far | 18:45.56 |
| | work will not have been wasted thus far | 18:46.08 |
| | essentially he will be hooking into the c++ interface that I have | 18:46.36 |
| | instead of working with pdfapp | 18:46.47 |
| | tor8, Robin_Watts_ he is going to ask you guys at some point about git and getting his repos up properly | 18:47.15 |
| Robin_Watts_ | cool. | 18:47.37 |
| mvrhel_laptop | Robin_Watts_: I will work on getting the win_desktop branch merged in | 18:47.38 |
| | so should we just rename winrt to windows? | 18:47.49 |
| | then we will have windows and win32 | 18:47.54 |
| Robin_Watts_ | That seems reasonable. | 18:48.01 |
| mvrhel_laptop | ok. | 18:48.05 |
| | grabbing lunch | 19:27.58 |
| | Forward 1 day (to 2014/09/03)>>> | |
IRC Logs