| | <<<Back 1 day (to 2012/07/30) | 2012/07/31 |
| kens | marcosw are you really there ? | 07:25.33 |
| marcosw | morning kens | 07:25.41 |
| kens | is astonished | 07:25.51 |
| | marcosw I'm trying to find some seg faults | 07:26.02 |
| | But I'm not sure how to read the logs | 07:26.11 |
| | From the cluster run I get : | 07:26.34 |
| | tests_private/comparefiles/109-01.ps.pdf.pkmraw.300.0 fathoms Seg_Fault | 07:26.34 |
| | Does that mean the machine the job was run on was fathoms ? | 07:26.48 |
| marcosw | Yes. Is this from a clusterpush or a git regression run? The logs are in different places. | 07:27.19 |
| kens | A local run, not from a Git commit | 07:27.36 |
| | Actually that was the wrong line.... | 07:28.45 |
| marcosw | then you'd look in /home/regression/cluster/users/ken/fathoms.log on casper | 07:28.58 |
| kens | I meant this one: | 07:29.01 |
| | tests_private/ps/ps3cet/09-01.PS.pdf.ppmraw.300.0 fathoms Seg_Fault | 07:29.01 |
| | From teh logs I see: | 07:29.39 |
| | ===tests_private__ps__ps3cet__09-01.PS.pdf.ppmraw.300.0=== | 07:29.39 |
| | gs pdfwrite | 07:29.39 |
| | ./gs/bin/gs -sOutputFile=./temp/tests_private__ps__ps3cet__09-01.PS.pdf.ppmraw.300.0.pdf -sDEVICE=pdfwrite -r300 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -dClusterJob -dJOBSERVER %rom%Resource/Init/gs_cet.ps - < ./tests_private/ps/ps3cet/09-01.PS | 07:29.39 |
| | Is that correct ? | 07:30.01 |
| | THe entry ends with : | 07:30.21 |
| | Command terminated by signal 11 | 07:30.21 |
| | 0.24 0.03 0:00.65 42% | 07:30.21 |
| | return: 139 | 07:30.21 |
| | I'm just trying to replicate the fault so I can see what's going on. The file runs OK for me here locally :( | 07:30.49 |
| marcosw | yes. that's all correct. Let me try it on my machine to see if I can reproduce it. | 07:32.55 |
| kens | OK thanks, I'll try it again here with that commend line (or at least one like it) | 07:33.12 |
| | marcosw you'll need to use the code in my user area of course.... | 07:35.07 |
| marcosw | Just tried your build on my i7 and it seg faults, so it's not limited to fathoms. | 07:35.17 |
| kens | Can't say I'm surprised. | 07:35.29 |
| | Can you try a real simple case ? Just -sDEVICE=pdfwrtite -sOutputFile=something please ? | 07:36.01 |
| | I may have to go to one of the cluster machiens to run this | 07:36.16 |
| | The strange thing is all the code ought to be dependent on a new flag being set, so it *should* do nothing.... | 07:36.42 |
| kens | fires up VMWare | 07:37.32 |
| marcosw | I'm happy to simplify the command line, but you can log into peeves and try it yourself. | 07:37.43 |
| | I think this command should work from anybody's account: | 07:37.53 |
| | /home/marcos/cluster/users/ken/ghostpdl/gs/bin/gs -sOutputFile=/tmp/tests_private__ps__ps3cet__09-01.PS.pdf.ppmraw.300.0.pdf -sDEVICE=pdfwrite -r300 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -dClusterJob -dJOBSERVER %rom%Resource/Init/gs_cet.ps - < /home/marcos/cluster/tests_private/ps/ps3cet/09-01.PS | 07:37.54 |
| kens | Yes, that works for me locally (or as close as I can get on WIndows) | 07:38.10 |
| | I'm just starting VMWare to see if I can reproduce it there | 07:38.24 |
| | remote debugging on a cluster machine is a last resort ;-) | 07:38.38 |
| marcosw | you and I are very different, my idea of a last resort is starting VMWare to run windows :-) | 07:39.24 |
| kens | It just depends what you are used to | 07:39.41 |
| marcosw | btw, .../bin/gs -sDEVICE=pdfwrite -o temp.pdf 09-01.PS also seg faults | 07:41.08 |
| kens | OK that's great marcosw thanks, much easier to type :-) | 07:41.24 |
| | Hmm, just told VMWare to copy my ghostpdl directory from Windows to Linux, its up to 600 MB and still counting.... | 07:42.14 |
| chrisl | kens: if you want me to take a look at the crash, let me know.... | 08:12.53 |
| kens | chrisl, thanks, I'm trying to sort out my LInux ghostpdl checkout at the moment, its been a while since I last used it..... | 08:13.46 |
| | I'm sure it'll be something obvious when I find it | 08:14.37 |
| chrisl | It so often is..... | 08:15.09 |
| kens | OK look slike Git is working now :-) | 08:15.33 |
| | I shoul dbe OK to just run configure ? | 08:15.59 |
| chrisl | no, use autogen.sh | 08:16.14 |
| kens | Ah, OK | 08:16.20 |
| | Hmm git complaining about a load of untracked files :( | 08:18.28 |
| chrisl | Do you have untracked files you need to keep? | 08:18.47 |
| kens | No | 08:18.51 |
| chrisl | git clean -x -d -f | 08:19.02 |
| kens | Hmm, well its done something :-) | 08:19.22 |
| | aha, that's better thanks | 08:19.49 |
| | Just going to build a master before I bring my code over from the PC | 08:20.17 |
| chrisl | It's a rune that I use often...... | 08:20.17 |
| kens | chrisl dumb question time.... | 09:00.41 |
| | 'make' from the ghostpdl directory makes PCL, XPS, SVG and language switch for me, but not GS, am I missing something ? | 09:01.02 |
| chrisl | That's correct | 09:01.18 |
| kens | AH, OK so I need to switch to gs for the gs build ? | 09:01.36 |
| chrisl | Yes, *and* make sure you run the autogen.sh in the gs directory | 09:02.01 |
| kens | Just doign that now :) | 09:02.07 |
| chrisl | FWIW, there's no reason we couldn't have the toplevel build gs, too..... | 09:02.57 |
| kens | To me it makes more sense, but its pretty minor | 09:03.09 |
| chrisl | It's because gs is "standalone" | 09:03.46 |
| kens | I figured that | 09:03.53 |
| | Windows, of course, is different.... | 09:04.07 |
| chrisl | Is it? | 09:04.20 |
| kens | Well, the VS project is | 09:04.29 |
| chrisl | That really has nothing to do with the makefiles, though | 09:04.47 |
| kens | And I don't think we have a top-level makefile that builds alll the non-gs builds, but I might be mistaken about that | 09:04.48 |
| | I always just build them individually when I want tehm | 09:05.02 |
| chrisl | No, for the nmake builds, each product needs build individually | 09:05.21 |
| kens | Right, so it is different :-) | 09:05.38 |
| | Anyway, all very minor | 09:06.05 |
| chrisl | Yeh, I should probably get the two at least consistent - at some point | 09:06.37 |
| kens | I'm not sure its worth it, there can't be many people jumping back and forth like me | 09:06.53 |
| chrisl | Only a very few developers, that's really why it's never come up as an issue. | 09:07.51 |
| kens | Indeed. I'm amused by the latest build one, using autotools on WIndows :-O | 09:08.17 |
| chrisl | Yeh, hence my reply on the other bug - "important", hah! | 09:08.53 |
| kens | :-) | 09:08.58 |
| | Well, my code on my 32-bit Linux VMWare doesn't seg fault | 09:21.31 |
| | So presumably its a 64-bit Linux-specific problem | 09:21.41 |
| | remote debugging time :-( | 09:21.57 |
| chrisl | Did you try the -Z@ option? | 09:27.07 |
| Robin_Watts | Have you got it set so you can use ddd on the cluster node and open the xwindows on your local machine? | 09:27.23 |
| kens | Give me a few more minutes :-) I can reproduce the crash on peeves | 09:27.27 |
| | I should be able to use ddd but I need a debug version | 09:27.47 |
| | Hmmmm | 09:28.17 |
| | I probably can't build a debug version in /home/marcos.... | 09:28.30 |
| chrisl | I wouldn't have thought you could build anything in there | 09:29.01 |
| kens | Nope, can't. permission denied | 09:29.10 |
| kens | copies the sources from one to the other | 09:30.43 |
| | Excellent a debug build doesn't seg fault :-( | 09:35.46 |
| Robin_Watts | make XCFLAGS="-g" ? | 09:36.11 |
| kens | Oddly a non-debug build is not crashing either...... | 09:36.30 |
| | But I may have forgotten to build that one so I'm doing it now, just in case | 09:36.48 |
| | Hmm, interesting. I get a warning in gdevtsep.c about memset used with constant zero length parameter 'this could be due to transposed parameters' | 09:39.39 |
| | OK local non-debug gs does seg afult, that's something | 09:40.21 |
| | aha, and so does the debug build now, goood | 09:40.56 |
| | time for ddd | 09:41.06 |
| | Oh, seems like I can't do this on peeves. | 09:42.26 |
| | chrisl could I impose on you to try this for me ? | 09:42.45 |
| chrisl | Does peeves have ddd installed? | 09:42.52 |
| kens | Well the error is 'Cna't open display' so I guess so | 09:43.08 |
| chrisl | You need to use ssh -X ....... to get the X routing | 09:43.40 |
| kens | Oh, ok will try that | 09:43.53 |
| chrisl | But if you send me a patch, I'll take a look..... | 09:44.10 |
| Robin_Watts | kens: yes, that warning is my fault. | 09:44.15 |
| kens | chrisl, I'll plod on if I can get ddd to work, its a large diff | 09:44.35 |
| | Ah, that looks better chrisl thanks. No window yet but it hasn't thrown a woobly either | 09:45.51 |
| chrisl | It'll take a while to draw the window over the connection | 09:46.20 |
| kens | Yeah I know, it takes a relly long time as I recall | 09:46.35 |
| | But goes reasonably quickly once its up and going | 09:46.59 |
| Robin_Watts | Did you use -C ? | 09:47.34 |
| kens | No, what does that do ? | 09:47.43 |
| Robin_Watts | compression | 09:47.46 |
| chrisl | it should be quicker than it is, but ddd isn't terribly smart about how it (re)-draws the window | 09:47.49 |
| kens | Robin_Watts : well, maybe I'll try that if I have to restart it :-) | 09:48.13 |
| chrisl | I didn't find the compression helped noticably - ymmv | 09:49.05 |
| kens | Since it takes ages to start up I don't want to kill it unless I need to. Still thnking to itself.... | 09:49.36 |
| | Oooh, a windopw :-) | 09:49.44 |
| Robin_Watts | What do you set DISPLAY to? | 09:49.48 |
| kens | Whatever it already is, no changes | 09:50.01 |
| Robin_Watts | (I've done this before, but not with cluster nodes. It's something I should investigate.) | 09:50.08 |
| | Right, thanks. | 09:50.13 |
| | just wondering if there will be a problem with more than one of us doing this at a time. | 09:50.49 |
| chrisl | Robin_Watts: using the -X option sets DISPLAY correctly for the ssh routing on the current session | 09:51.00 |
| kens | I don't *think* that shoudld be a problem | 09:51.07 |
| chrisl | DISPLAY is per login, not system wide | 09:51.23 |
| Robin_Watts | chrisl: right. | 09:51.33 |
| kens | I'm using the debug binary in my user area, and I think X is capable of dealing with the windows OK | 09:51.36 |
| Robin_Watts | kens: I was worried that the ssh agent might take over the 'standard' X ports. | 09:51.53 |
| kens | I don't *think* it does that | 09:52.04 |
| chrisl | Hmmm, it sort of does, but only for the current X session, which should be specific to the login | 09:52.47 |
| kens | Someone remind me how to set the program arguments for ddd ? | 09:55.34 |
| chrisl | Porgram->Run brings up a window you can put the arguments in there | 09:56.10 |
| kens | THat's the puppy, thanks | 09:56.31 |
| | Ah, I see, the array I'm collecting file offsets in isn't large enough | 09:59.47 |
| | OK I think that should fix it, lets see what happens with a clusterpush | 10:03.47 |
| | Rats, Robin's commit will be in front of me...... | 10:06.18 |
| Robin_Watts | sorry. | 10:12.06 |
| kens | No problem | 10:12.11 |
| | Took me a while to shut down my VM, so my clusterpush took a long time to get fired off | 10:12.40 |
| | Running 2 Vms at once really eats the memory up and the system runs very slowly | 10:13.02 |
| | You're already at 30% :-) | 10:13.15 |
| chrisl | You need more memory! | 10:13.24 |
| kens | I know, I know :-( | 10:13.32 |
| | THe system is 5 years old now.... | 10:13.41 |
| | I know I need to upgrade, but I hate shifting to a new one. | 10:14.14 |
| | chrisl I was looking at GG shares on euronext, the graph can now go back as far as 2002. Share value is down 94.8% since then.... | 10:15.16 |
| | And that wasn't een their highest point | 10:15.24 |
| chrisl | Crikey, that's pretty dire! What were they at back in 2002? | 10:16.09 |
| kens | Umm 20 euros or there about | 10:16.24 |
| | let me check | 10:16.31 |
| | maybe 22 or 23 | 10:17.01 |
| | The high point IIRC was about 40 | 10:17.08 |
| chrisl | bbiaw | 10:47.22 |
| kens | Ah good that's all my seg faults gone, that's a relief | 10:55.56 |
| | Now to update to HEAD and try a proper test. | 10:56.53 |
| henrys | Doing an internet speed test with 10 base T ethernet cable hooked to the router I get 20 Mbs same router wireless connection 5 Mbs. Is that what other see, wireless bottlenecking the connection? | 14:52.22 |
| kens | yes | 14:52.38 |
| henrys | the "link speed" for the wireless card says 20 Mbs but I've never seen anything close to that. | 14:54.47 |
| | 5 of a meeting, but this should go quick. | 14:55.35 |
| Robin_Watts | Urm... 10base T - the top speed you should get out of that (even theoretically) is 10Mbits/s | 14:56.19 |
| | Are you sure it's not a 100baseT router? That would be much more common these days. | 14:56.46 |
| | (In fact, modern stuff might well be 1000baseT (gigabit ethernet)). | 14:57.11 |
| henrys | Robin_Watts:yes sorry | 14:57.12 |
| Robin_Watts | OK. In that case your ethernet values sound sensible. | 14:57.24 |
| | And it doesn't surprise me that the wifi is slower. | 14:57.35 |
| henrys | the difference between cable and wireless doesn't surprise me, it would be nice if the wireless folks could keep up with typical home speeds for internet. | 14:58.20 |
| Robin_Watts | henrys: The problem with the wifi band is that it's heavily used; lots of equipment produces interference in that region of the spectrum. | 14:59.10 |
| | and the channels overlap, so even if you think you're in an unused channel, other networks +/- 2 can interfere with you. | 14:59.43 |
| | (actually, it's worse than that. If you're on channel n, then you actually use n-2 to n+2. So someone on n-4 will interfere with some of your transmission, some of the time. | 15:00.39 |
| | And if you have any 'b' devices on your 'g' network at all, you drop back to 'b' speeds (I think!) | 15:01.03 |
| henrys | I understand the issues - but 9 out of 10 cable customers in my area are paying for premium speeds which they can't access. Nobody uses cables anymore. | 15:01.05 |
| | yes my router does that. But I tested with g | 15:01.30 |
| Robin_Watts | Well, I use cables :) | 15:01.52 |
| henrys | anyway the meeting ... tor is out this week. | 15:02.21 |
| Robin_Watts | If you want to avoid cables, use the power networking stuff. | 15:02.22 |
| henrys | Robin_Watts:is that available now? | 15:02.39 |
| Robin_Watts | It's been available for years over here. | 15:02.50 |
| | I set my parents in law up with it to connect their new telly to the router. Works perfectly. | 15:03.12 |
| | I have nothing for the meeting. I've been buried in gs. | 15:03.51 |
| paulgardiner | I have a little more info on submission | 15:04.54 |
| henrys | paulgardiner:did you have anything last week you were off? I saw the status report do we want to discuss that stuff in more detail? | 15:05.12 |
| paulgardiner | Just got some results from beggining of this week. It seems that Chrome doesn't support submission at all. | 15:06.27 |
| henrys | do you know of a real website that is using submission in the real world? | 15:06.35 |
| | paulgardiner:then we should probably just skip it entirely for now. | 15:07.04 |
| paulgardiner | I don't. We have test files that look to be from such sites | 15:07.10 |
| | i.e. We have files that have submit buttons. | 15:07.49 |
| Robin_Watts | http://www.docstoc.com http://www.scribd.com | 15:08.03 |
| | http://slideshare.net | 15:08.13 |
| | http://www.poposhare.com/ | 15:08.28 |
| | In fact... http://forums.digitalpoint.com/showthread.php?t=1946135 | 15:08.42 |
| paulgardiner | How did you find those so quickly? | 15:09.56 |
| Robin_Watts | I googled for "PDF submission site list" | 15:10.19 |
| paulgardiner | Ah. Sneaky! :-) | 15:10.36 |
| Robin_Watts | However, I'm confused as to whether they really are what I expected them to be. | 15:10.55 |
| henrys | I went to several of these and it isn't obvious ... | 15:11.07 |
| paulgardiner | Yeah, it may be that it is possible to submit a pdf, rather than use pdf for the submission | 15:11.31 |
| Robin_Watts | I think those are sites where you submit your PDFs and they host them etc. | 15:11.43 |
| | yeah. | 15:11.44 |
| henrys | Robin_Watts:you'll just have to wait until Google can read our IRC channel and apply context to your query. | 15:12.42 |
| paulgardiner | henrys: as you say, maybe we should not bother with it for now, although I don't think it would actually be quite easy to add some support for simple cases. | 15:12.47 |
| | s/don't// :-) | 15:13.08 |
| Robin_Watts | henrys: http://xkcd.com/1085/ | 15:13.16 |
| henrys | paulgardiner:that does sound reasonable. | 15:13.24 |
| paulgardiner | I also had trouble with submissions that use FDF in both directions when using Firefox, although it worked fine in IE. | 15:14.34 |
| | where the reply is in FDF I mean, and the reply updates the form. Worked a few times in Firefox, but then mysteriously stopped working. But IE was fine. | 15:15.47 |
| Robin_Watts | So, if we're putting this submission stuff on the back burner, are there any major areas we should fix before we do a release ? | 15:16.11 |
| | We need to merge forms -> trunk, and I was really hoping that tor would do that as it would let him do an overall code review as it goes. | 15:17.10 |
| paulgardiner | Possibly: we support list boxes and comboboxes only in the library at the moment, not yet in the apps. | 15:17.18 |
| henrys | we need 2 4 and 6 from the status report at least, yes? | 15:17.30 |
| | 6 seems being bare minimum for something even alpha. | 15:18.21 |
| Robin_Watts | Most people fill put forms and then print them rather than save them? But maybe as we don't have a print option yet 2 would be good :) | 15:18.33 |
| henrys | s/being// | 15:18.33 |
| Robin_Watts | s/2/6/ | 15:18.42 |
| | 2 is an extra thing to help the apps, right? | 15:19.08 |
| paulgardiner | 4 and 6 seem more important than 2 to me. | 15:19.09 |
| | Robin_Watts: yes, plus it could reject what comes from the app. | 15:19.48 |
| Robin_Watts | (i.e. it'll all work without 2, it just means that people will be able to enter illegal things until they hit 'return' for the data to go back from the native widget into the document, when it'll be sanitised before turning it into an appearance stream. | 15:20.03 |
| henrys | 4 and 6 and then an alpha release/announcment? | 15:20.03 |
| paulgardiner | There are two parts to it: what is done on each key press and what is done on leaving the field. | 15:20.32 |
| Robin_Watts | ok. There is enough support with pdf_write.c that a first attempt at 6 shouldn't be too bad, right? | 15:21.10 |
| | It wouldn't surprise me if there were things we need to fix in there, but we should be in a position to give it a go, I hope. | 15:21.49 |
| paulgardiner | Not sure how to progress with 4. We need to target a platform. | 15:22.19 |
| | I'm guessing we don't want to put too much work into the current windows app when the new one is on the way. | 15:22.45 |
| henrys | I don't have much use experience with pdf forms but regular html/php stuff I'll frequently print to a pdf (distiller) to save results. Simply saving usually screws something up. | 15:23.13 |
| Robin_Watts | paulgardiner: Is there a platform that you'd feel happy to try with combo boxes on? | 15:23.51 |
| paulgardiner | Robin_Watts: yeah, I'm hoping that pdf_write.c should have most of what we need for 6 | 15:23.53 |
| Robin_Watts | (I mean, is it something that will go into the android app easily? Or would a hack for the current windows app be easier?) | 15:24.19 |
| | At the moment, the linux app resorts to the console window to get input for text fields, right? | 15:24.49 |
| paulgardiner | Probably a hack to the current windows app would be easier than Android. Did Tor say that we couldn't use v8 on Android? | 15:25.26 |
| Robin_Watts | We could do combo boxes the same in that. When you click on a combo box, print the list of options numbered 1)... 2) ... 3) ... and then input a number for which one to select ? | 15:25.28 |
| | tor raised that possible idea. I couldn't find anything to confirm/deny it either way on googling. | 15:26.05 |
| | I find it hard to believe that we can't use it. | 15:26.24 |
| | as the purpose of there being ARM support in v8 is for android, I believe. | 15:26.48 |
| paulgardiner | I was surprised that it wasn't in some way part of Android. | 15:27.21 |
| Robin_Watts | I thought it was part of the android browser. | 15:27.37 |
| | but it may not be accessible to other android apps directly. | 15:27.52 |
| paulgardiner | Do browsers tend to have their own engines? | 15:27.58 |
| henrys | paulgardiner:guesstimate on 6? I'm going to be preparing the Artifex newsletter and I'd like to say something about the alpha release time wise? | 15:28.38 |
| Robin_Watts | AIUI, yes. | 15:28.43 |
| paulgardiner | I wondered about a trick where you wrap your javascript in html and get the browser to execute it for you. Not sure it's possible though. | 15:28.52 |
| Robin_Watts | browsers and their engines tend to be tightly coupled. (I..e you can't replace the engine without rebuilding the browser) | 15:29.25 |
| paulgardiner | henrys: 6 might be a week if we are lucky and pdf_write doesn't fight back. | 15:30.29 |
| | henrys: on the other hand, I guess there could be problems lurking we'll find only when we start on it. | 15:30.58 |
| Robin_Watts | If there are problems with pdf_write, I'm on holiday in 2 weeks time. | 15:31.13 |
| | (I'm on holiday in 2 weeks time regardless of problems actually, but I was the last one in pdf_write...) | 15:31.36 |
| paulgardiner | Sounds like it would be good to tackle 6 asap | 15:32.09 |
| henrys | I might say something like October in the newsletter for early adopters willing to fool with git. Okay? | 15:32.34 |
| Robin_Watts | I reckon it would be good thing to try. Either it will 'just work', or it'll fail horribly and you can get on with 4 while I try and fix it | 15:32.39 |
| | henrys: I thought the plan was to try to merge forms -> master before the next mupdf release? | 15:33.28 |
| | Are you proposing we delay the mupdf release til october? Or that we don't do the merge ? | 15:33.50 |
| paulgardiner | henrys: sounds as reasonable as any date, but it's very hard to predict what customers will consider sufficient coverage of features. | 15:33.53 |
| henrys | Robin_Watts:neither. | 15:34.19 |
| | I didn't think merging was really a newsletter topic. | 15:34.35 |
| Robin_Watts | So we merge, and release the merged version - but don't mention in the release notes that there is forms support ? | 15:34.55 |
| paulgardiner | henrys: on the other hand, the sooner we have people moaning about things that are lacking, the better we can prioritise. | 15:35.00 |
| henrys | I hope we do a mupdf release on schedule. | 15:35.22 |
| Robin_Watts | Well, if we don't merge before the release, then I think a mupdf release is a trivial thing to do. | 15:35.50 |
| | If we aren't going to mention forms stuff in the mupdf release, then delaying the merge until afterwards gives us more time. | 15:36.31 |
| henrys | the really rosy scenario was to have an alpha by this release but that didn't happen. | 15:36.43 |
| | so I sort of lean towards delaying the merge since we don't have something we are willing to call alpha. | 15:37.29 |
| Robin_Watts | OK, that seems best to me. | 15:37.41 |
| | That gives us more freedom to rejig interfaces on merging to ensure the API is consistent. | 15:38.06 |
| henrys | okay agreed. | 15:38.21 |
| paulgardiner | okay | 15:38.48 |
| henrys | when did tor8 plan the mupdf release? | 15:38.50 |
| Robin_Watts | Pass. I'd imagine as soon as he gets back. | 15:39.58 |
| henrys | I hope he does it plenty of time before your vacation. | 15:40.04 |
| | anyway I guess we are good until next week. paulgardiner, as usual, if you need anything ... holler. | 15:42.42 |
| paulgardiner | henrys: ok thanks | 15:42.59 |
| ray_laptop | kens: I saw earlier in the logs a comment about needing to copy stuff onto the HD in your VMware instance. My VMware needs to be upgraded to run on this laptop, but I used to just mount the host disk filesystem and not have to xfer files | 15:51.16 |
| kens | ray_laptop : yes but that's even slower than copying it :=-) | 15:51.36 |
| ray_laptop | mounting is slower than copying ? | 15:51.52 |
| | it was 'instant' | 15:52.01 |
| kens | Reading each source file is yes | 15:52.04 |
| Robin_Watts | header files get reread multiple times during compilation as opposed to just once if copied. | 15:52.28 |
| kens | I have the folder mounted, that's how I was copying | 15:52.29 |
| ray_laptop | I did this so I didn't have to copy the test files, but I had a local tree for the VM (on its native disk) | 15:52.57 |
| | kens: I didn't compile on a mounted fs | 15:53.48 |
| kens | ray_laptop : the compilation was done to finish on a 'local' disk, but the source files were on a mounted volume. Copying the files is faster than compiling them while still resident on the mounted volume | 15:54.37 |
| ray_laptop | kens: I was just surprised that you had to copy 600Mb | 15:55.19 |
| kens | So was I! | 15:55.28 |
| | But it includes all the obj and other binaries | 15:55.43 |
| | So I stopped doing that :-) | 15:55.52 |
| henrys | kens:I imagine if you set "GENDIR" to something local it would go fairly quickly but I haven't tried it. | 15:57.32 |
| ray_laptop | kens: right -- debugobj on my gs alone is 382Mb | 15:57.51 |
| kens | henrys compilation with sources on a mounted drive seems to be slower than copying the sources to a local volume, that's all I'm saying :-) | 15:58.13 |
| ray_laptop | kens: yes, that makes sense. I wasn't doing that either | 15:58.35 |
| | kens: I found it faster to have a separate tree that I just updated, however | 15:59.10 |
| chrisl | The quickest solution is a git repos on the VM local drive, and then copy a patch from the host to the VM | 15:59.20 |
| henrys | kens:yes but it convenenient to not copy so I thought maybe if you only read from the mounted drive and wrote objects and exe's local it would be a better solution for you. | 15:59.49 |
| kens | And indeed once I remembered that I *did* have a Git repository on teh VM, that's exactly what I did | 15:59.50 |
| henrys | anyway the meeting | 16:00.21 |
| mvrhel | good morning | 16:00.28 |
| chrisl | The other solution is a personal repos on casper, and push your changes to that, and pull them to the VM (or vice versa...) | 16:00.38 |
| henrys | chrisl do you need help putting together release notes or can you cobble stuff together based on the logs? | 16:00.49 |
| ray_laptop | morning, all | 16:00.50 |
| chrisl | henrys: I've pulled together some stuff from the changelog, good enough for the rc | 16:01.21 |
| henrys | chrisl:okay I will write something more elaborate for the newsletter but based on what you have, so if other folks want something included speak up! | 16:02.20 |
| | all ^^^ | 16:02.23 |
| mvrhel | chrisl: do you have something in there about the planar changes to the sep devices? | 16:02.38 |
| kens | I sent some stuff to chrisl, should I mail it to you too henrys ? | 16:02.43 |
| ray_laptop | one thing I think we want to feature in the release notes is the support color separations with better performance and eliminate previous limitations, particularly with transparency | 16:02.44 |
| mvrhel | right | 16:02.55 |
| chrisl | mvrhel: yes - I put it as "support for large numbers of separations improved" | 16:03.26 |
| henrys | kens:if chrisl's release notes aren't adequate send me something. | 16:03.33 |
| kens | chrisl put it all in the release notes, just wondered if yo uneeded it as well. I'll let you pick it out from there | 16:04.02 |
| ray_laptop | chrisl: and performance for separations with transparency is improve | 16:04.09 |
| | improved | 16:04.18 |
| mvrhel | yes. I would add that too please | 16:04.23 |
| alexcher | The upcoming release has the lowest number of SEGVs. | 16:04.27 |
| mvrhel | we don't want to advertise that there are segvs.... | 16:04.54 |
| henrys | alexcher that is not something to brag about. | 16:04.56 |
| ray_laptop | a more positive way is to say that many persistent SEGV conditions have been fixed | 16:05.05 |
| mvrhel | yes | 16:05.09 |
| chrisl | ray_laptop: the rc archives are already created, I'll add the performance for the next round..... | 16:05.15 |
| ray_laptop | chrisl: huh ? | 16:05.31 |
| henrys | I don't want to say "SEGV" at all. | 16:05.44 |
| ray_laptop | are you saying the release notes are 'frozen' ? | 16:05.48 |
| | chrisl: or just for this rc ? | 16:06.07 |
| chrisl | ray_laptop: just for rc 1 | 16:06.16 |
| ray_laptop | chrisl: OK. thnaks | 16:06.24 |
| chrisl | hopes we'll only have one release candidate this time! | 16:06.36 |
| mvrhel | ray_laptop: did your fix for the rect_fill_hl_color get in? | 16:07.28 |
| ray_laptop | chrisl: well, if I fixed my silly mistake, and I don't have the mess of regressions, I'd really like to get the fixes to the confused hl_color calls in | 16:07.33 |
| henrys | who is the customer and why can't they take a patch? | 16:08.19 |
| ray_laptop | mvrhel: no -- I had ALSO confused when I had int and when fixed, so there was a place where I used fixed2int instead of int2fixed :-( | 16:08.27 |
| henrys | very late for that kind of change. | 16:08.31 |
| ray_laptop | I'm re-running that now | 16:08.37 |
| | henrys: I can always go ahead and commit and we can decide whether or not to cherry pick it later | 16:09.16 |
| mvrhel | right | 16:09.25 |
| ray_laptop | frankly, I'm surprised that we don't have problems with the current code | 16:09.42 |
| chrisl | ray_laptop: at this stage, unless there's a regression (or high priority customer) involved, I'm not keen getting into a "just one more change" cycle | 16:09.55 |
| | FWIW, here's what I cobbled together for the release notes in RC1: http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=gs/doc/History9.htm;hb=gs906 | 16:10.28 |
| ray_laptop | but it seems that the confusion was screwed up in enough places that it sort of worked | 16:10.36 |
| henrys | let's just get this thing out as close to rc1 as possible. | 16:10.41 |
| Robin_Watts | If we're trumpeting "more separations supported", it would be nice if it actually worked though. | 16:10.44 |
| ray_laptop | Robin_Watts: it doesn't work ? | 16:10.56 |
| Robin_Watts | ray_laptop: I thought that without your fix there were cases where it didn't ? | 16:11.12 |
| ray_laptop | other than bug 693234 ??? | 16:11.18 |
| | Robin_Watts: I don't (yet) know where it doesn't work. If the regression run (that is in progress now) shows some progressions ... | 16:12.05 |
| Robin_Watts | ray_laptop: OK. I'm clearly confused. | 16:12.24 |
| mvrhel | I dont know where it does not work either | 16:12.27 |
| | it is certainly better than it was 6 months ago | 16:12.55 |
| Robin_Watts | You're doing a fix for 'hl_color' stuff, right? Presumably if you're fixing something you have at least one case where it doesn't work. | 16:12.56 |
| ray_laptop | Robin_Watts: the problem with the code is that several uses of fill_rectangle_hl_color passed gs_int_rect type coordinates instead of gs_fixed_rect | 16:13.22 |
| Robin_Watts | ray_laptop: And we have files where that makes a difference? | 16:13.41 |
| ray_laptop | Robin_Watts: the usages that mvrhel added to support devn color used int coords and I think work. gs_rectfill used fixed as did pdfwrite and fillpage | 16:14.54 |
| | Robin_Watts: so that's why I was saying I'm surprised that it worked | 16:15.19 |
| mvrhel | Robin_Watts: I don't believe there are any files that show any issues | 16:15.46 |
| henrys | alexcher:I also wanted to ask about your 3 bug aging entries - they look sticky and Robin_Watts' problem is blocking on one of them. Do you have status on the bugs? | 16:15.47 |
| alexcher | henrys: some of the bugs depend on the large object support. I'll post the comments. | 16:17.37 |
| Robin_Watts | bug 693115 is the blocker for me. Any progress on that ? | 16:18.47 |
| henrys | kens:do you think it would be worthwhile to have marcos do an output size comparison on pdf. I really don't want to shoot down this customer and have them come back and say there is some or "across the board" problem. Even if they are "no support" | 16:18.48 |
| ray_laptop | OK. My regression run showed '1 ps2write difference' comparefiles/Bug692129.pdf | 16:18.49 |
| kens | henrys I'd be very happy to see an output size comparison | 16:19.00 |
| | But I think that generally we are good, I see many people using GS to 'shrink' PDF files | 16:19.27 |
| henrys | marcosw:do you think that is something which would fall in your domain? | 16:19.44 |
| ray_laptop | kens: yeah -- we leave out a lot of the junk that Adobe puts in ;-) | 16:19.54 |
| henrys | kesn:that is what I expect too. | 16:20.05 |
| kens | Note that since we do not support PDF 1.5 yet, compressed xref and object streams can get more size reduction than we can match | 16:20.14 |
| alexcher | I'm working on 693115. I'm trying to set the mask as soon as it is introduced but so fae it doesn't work. | 16:20.24 |
| henrys | alexcher:I guess fixing Robin_Watts problem should be priority as it will allow another problem to be fixed. | 16:21.05 |
| alexcher | OK | 16:21.19 |
| Robin_Watts | alexcher: Yeah, the pdf interpreter code looked strange enough that it didn't look trivial :( | 16:21.54 |
| henrys | chrisl:notes look great should make the newsletter an easy "derivative" work. | 16:21.59 |
| Robin_Watts | Hmm. Pushing the max components up to 64 can make some of the 'unbanded' tests under the cluster become 'banded' ones. | 16:22.56 |
| chrisl | henrys: that's goodm thanks - it wouldn't surprise me if I'd missed a couple more notable things, though. | 16:23.03 |
| Robin_Watts | chrisl: Did you mention the windows scrollbars? :) | 16:23.17 |
| henrys | chrisl:I'll go through the logs, too? | 16:23.21 |
| | s/\?// | 16:23.34 |
| alexcher | The notes don't explain what downscaler does. | 16:23.35 |
| chrisl | Robin_Watts: I try to ignore Windows as much as possible..... | 16:23.51 |
| Robin_Watts | chrisl: "functionailty" | 16:24.08 |
| chrisl | alexcher: it's existing functionality - I'll see about a link to the existing docs for it | 16:24.43 |
| | Robin_Watts: thanks | 16:24.50 |
| Robin_Watts | Also, you're missing a . on that line. | 16:25.00 |
| mvrhel | where are you all looking at the notes? | 16:27.25 |
| henrys | almost 1/2 hour - anything else for the meeting? | 16:27.37 |
| Robin_Watts | marcosw: The cluster stuff currently sets -dMaxBitmap=30000000 for unbanded files. | 16:27.37 |
| kens | mvrhel see earlier in irc | 16:27.51 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=gs/doc/History9.htm;hb=gs906 | 16:27.59 |
| henrys | mvrhel:chrisl said http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=gs/doc/History9.htm;hb=gs906 | 16:28.03 |
| mvrhel | ok thanks | 16:28.17 |
| Robin_Watts | With 64 components, that's not enough at 72dpi (72*72*13*8 = 38MB). Can we make that -dMaxBitmap larger, please? | 16:28.36 |
| mvrhel | link for the ICC color parameters is brokien | 16:28.56 |
| chrisl | mvrhel: it won't work because it's in git, it will work when it's pulled into a "normal" directory | 16:29.28 |
| mvrhel | ah ok | 16:29.33 |
| | the tiffsep write up is nice | 16:29.41 |
| chrisl | I mostly guessed! | 16:29.51 |
| ray_laptop | Robin_Watts: there are some files that are large enough (PageSize) at 300 dpi that even now always use banding mode with -dMaxBitmap=300000000 | 16:30.26 |
| mvrhel | yeah! 8.71 is no longer supported | 16:30.30 |
| kens | Finally | 16:30.39 |
| henrys | we are at the 1/2 hour so if anyone needs to go | 16:30.44 |
| ray_laptop | Robin_Watts: we discussed it a long time ago and it's unlikely enough that anyone would go larger that we decided not to worry about it (why test it if no one will use it) | 16:31.23 |
| Robin_Watts | ray_laptop: Indeed. But with 64 components we hit it at 72dpi too. | 16:31.27 |
| | I'd like -dMaxBitmap=40000000 | 16:31.47 |
| ray_laptop | why not 1G ? | 16:31.59 |
| Robin_Watts | Legal = 8.5*14, (the biggest paper size of that ilk) | 16:32.28 |
| | which at 64bit 72dpi will just fit into 40000000 | 16:32.39 |
| | ray_laptop: Higher would be fine. I wondered if marcosw had chosen 30000000 carefully to allow multiple jobs to run without causing swapping on cluster nodes. | 16:33.17 |
| henrys | so chrisl at this point can we commit and you'll cherry pick or do you want to hold the freeze a bit more? | 16:33.45 |
| ray_laptop | Robin_Watts: does each cluster just runs one job at a time from its list ? | 16:34.16 |
| chrisl | henrys: everyone is free to commit to master, no probs | 16:34.19 |
| Robin_Watts | ray_laptop: No. It runs several in parallel, AIUI. | 16:34.32 |
| kens | OK I have to go now, g'night all | 16:34.35 |
| henrys | chrisl:thanks | 16:34.46 |
| Robin_Watts | Night kens. | 16:34.48 |
| henrys | bye kens | 16:34.53 |
| | marcosw:are you here? | 16:35.10 |
| ray_laptop | Robin_Watts: oh, that's right. It starts about 8 jobs at once I think | 16:35.42 |
| henrys | alexcher:so go ahead with the large object change. It will be interesting to see if anyone can break something with that. | 16:36.05 |
| alexcher | henrys: OK | 16:36.18 |
| chrisl | Robin_Watts: does the "downscaler" addition to tiffsep also include the error diffusion halftoning capability? | 16:37.11 |
| Robin_Watts | Yes. | 16:37.19 |
| | The downscaler encapsulates the error diffusion etc. | 16:37.35 |
| chrisl | Yes, I didn't know if you'd included the options in the tiffsep device, or were going to roll it into tiffsep1 | 16:38.02 |
| Robin_Watts | Oh, the downscaler can now do 'funky' ratios too. I wonder if I updated the docs for that. | 16:38.03 |
| ray_laptop | chrisl: the tiffsep1 uses the 'standard' halftoning method -- whatever is set, so by using threshold array it provides for ordered dither or stochastic (BN) mask dither, but probably faster than error diffusion | 16:40.17 |
| Robin_Watts | No, I didn't update the docs. | 16:41.14 |
| chrisl | ray_laptop: Yes, but now we have "tiffsep1" which produces halftoned output, and "tiffsep" which optionally produces a different halftoned output - that could be considered confusing. | 16:41.21 |
| Robin_Watts | I'll update the docs to cover 34 and 32 now. | 16:41.30 |
| marcosw | henrys: sorry I missed the meeting, had a meeting with my advisor but am here now. | 16:41.31 |
| ray_laptop | chrisl: tiffsep downscale produces error diffusion ONLY AIUI | 16:42.02 |
| marcosw | 30000000 came out of the old nightly regression code. Which I think was written by Jack Moffitt. | 16:42.27 |
| chrisl | ray_laptop: it's still 1bpp halftoned output..... | 16:42.30 |
| ray_laptop | chrisl: correct. | 16:42.44 |
| chrisl | ray_laptop: basically, I'm wondering if we shouldn't aim to have just one tiffsep device, which optionally produces contone, halftone, error diffused halftone etc..... | 16:43.39 |
| ray_laptop | chrisl: but error diffusion may not be what is desired (or it may be preferred) -- so we have both. | 16:43.41 |
| | chrisl: yes, that makes sense -- we just have to mash it together (but not for this release) | 16:44.17 |
| marcosw | ray_laptop: btw, your last fix for the multi-threaded psdcmyk issues fixed all the problem. | 16:44.41 |
| ray_laptop | chrisl: but clarifying the doc for this release would be good | 16:44.53 |
| | marcosw: thanks | 16:45.06 |
| chrisl | ray_laptop: which doc? | 16:45.24 |
| ray_laptop | chrisl: doc/Devices.htm | 16:46.33 |
| | I'll add the note on the halftoning for 1bpp tiffsep and tiffsep1 and you can decide if you want to cherry pick it | 16:47.27 |
| Robin_Watts | ray_laptop: I'm editing that file at the moment. | 16:47.40 |
| henrys | marcosw:we wanted to do a comparison of adobe distiller against gs output size wise - I think distiller can be set up to do batch stuff can't it? | 16:47.53 |
| chrisl | ray_laptop: I quite happy cherry-picking any documentation changes right up to when I create the final release archive..... | 16:48.26 |
| marcosw | I believe you can just drag and drop PostScript files onto Distiller and it will generate PDF files. The big question is what settings to use; the most significant one being image downsampling. | 16:50.18 |
| ray_laptop | Robin_Watts: I was editing it, too | 16:50.21 |
| Robin_Watts | ok. merge race then! | 16:50.40 |
| ray_laptop | Robin_Watts: I'll send you what I was going to add to tiffsep1 (which you probably were not going to touch) | 16:51.02 |
| henrys | marcosw:is the distiller default different than ours? | 16:52.25 |
| Robin_Watts | ray_laptop: OK. I was dealing with the 32 and 34 ratios, not the halftoning, so merging should be easy. | 16:53.26 |
| mvrhel | bbiab | 16:53.52 |
| ray_laptop | Robin_Watts: diff sent | 16:54.04 |
| marcosw | henrys: color and grayscale images >225 dpi are down sampled to 150 dpi and monochrome images >1800 dpi are downscaled to 1200 dpi. So no, our defaults are 72 and 300 dpi, we do agree on the ColorImageDownsampleThreshold of 1.5 (presuming that means what I think it does). | 16:58.38 |
| Robin_Watts | ray_laptop: http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=5876c67ba54ca41499fe4e595d140afa5d0c6120 | 16:58.58 |
| ray_laptop | Robin_Watts: the main 'gotcha' with pulling using threshold array based halftoning in tiff downscaling is the need to grab the order to convert to threshold array using a fill_path proc | 16:59.25 |
| marcosw | looks like our eBook settting might be closest to the distiller Standard setting. Though monochrome images are still only 300. | 17:00.06 |
| | Finally, the default PDF version is 1.5 with Acrobat and 1.4 with Ghostscript, but I'm not sure if that is significant (does alexcher want to chime in with what changed in the PDF spec between those two versions?). | 17:01.09 |
| Robin_Watts | marcosw: That is significant. | 17:01.23 |
| ray_laptop | Robin_Watts: I can use ' safely (I noticed you used " ) | 17:01.29 |
| Robin_Watts | 1.5 introduced compressed streams. | 17:01.30 |
| ray_laptop | we don't support writing PDF 1.5 yet | 17:01.55 |
| Robin_Watts | Files that use 1.5 *will* be smaller. | 17:02.12 |
| ray_laptop | i.e., compressed object streams and xrefs | 17:02.22 |
| henrys | marcosw:I think the best thing to do is have kens send you a command line - delegate! | 17:02.27 |
| Robin_Watts | But we should be testing Acrobat doing 1.5 versus us doing 1.4. | 17:02.35 |
| | We want to compare "Acrobats best" versus "Our best" (with the same quality settings) | 17:03.07 |
| ray_laptop | Robin_Watts: the diff looks fine. Go ahead. | 17:03.14 |
| Robin_Watts | marcosw: So do you have any objections to me upping the 30000000 to 4000000 ? | 17:04.00 |
| ray_laptop | Robin_Watts: as long as it is 400000000 | 17:04.49 |
| | ;-) | 17:04.54 |
| marcosw | Robin_Watts: no, I think that's fine. I should probably update the nightly and weekly regressions as well, no point in having too many different differences. | 17:04.59 |
| Robin_Watts | ok, I've updated the cluster code. | 17:05.42 |
| henrys | it will be interesting to see the benefit of 1.5 compression. | 17:08.21 |
| marcosw | Adobe has odd ideas of what distiller presets generate what PDF versions, standard is 1.5, High Quality Print is 1.4, Oversized Pages is 1.6, etc. | 17:09.38 |
| | henrys: BTW, distiller still has "Watched folders". We added that ability to Image Alchemy about 20 years ago but no one ever used it (or maybe everyone did and no one ever reported any bugs). | 17:12.27 |
| Robin_Watts | We had "Watched Folders" in FastSpool+. Seems like a standard solution. | 17:13.12 |
| | ray_laptop: How can I force something to be banded, and yet to use just one band for the entire page? | 17:15.59 |
| ray_laptop | Robin_Watts: you can set the BufferSize big enough with -dMaxBitmap=0, or set the -dBandHeight= big enough for the entire page | 17:27.00 |
| | oops -dBufferSpace | 17:27.18 |
| | are there any common scaling suffixes other than k, K, m, M, g, G ??? | 17:28.03 |
| | that would be useful to have in -d____=nnnn args ? | 17:29.29 |
| chrisl | Got to go...... bye all | 17:31.22 |
| Robin_Watts | So setting -dBandHeight forces banding? | 17:31.30 |
| ray_laptop | bye, chrisl | 17:31.32 |
| marcosw | ray_laptop: t and T, might has well plan ahead :-) | 17:31.40 |
| ray_laptop | Robin_Watts: no, unfortumately. -dMaxBitmap does | 17:31.49 |
| Robin_Watts | But if I set MaxBitmap low, I can still set BandHeight higher than would actually fit into the MaxBitmap ? | 17:32.18 |
| ray_laptop | Robin_Watts: yes. -dMaxBitmap=0 -dBandHeight=3100 works fine | 17:32.53 |
| | Robin_Watts: it's more efficient to open if you use -dBufferSpace=____ (big enough for the page) becuase otherwise it tries to use the default BufferSpace, then if that isn't big enough, doubles and tries again till it gets a buffer large enough | 17:34.10 |
| | marcosw: tera is too large for a 32-bit int, right ? | 17:35.14 |
| marcosw | someday an int will be 64 bits⦠| 17:37.27 |
| ray_laptop | marcosw: not in PS | 17:37.50 |
| | marcosw: we tried that and too many CET's had problems, iirc | 17:38.18 |
| marcosw | PostScript Language Level 4 is just around the corner⦠| 17:38.32 |
| Robin_Watts | ok, changing the 30000000 to 40000000 in the cluster produces 24 diffs (+3 pdfwrite, + 1 ps2write) | 17:46.40 |
| ray_laptop | Robin_Watts: pdfwrite and ps2write ??? | 17:48.33 |
| | marcosw: with all of the private extensions, gs is already 3.5 | 17:48.58 |
| Robin_Watts | ray_laptop: I suspect indeterminisms. | 17:50.37 |
| | but actually, given we render the files after we write them (2 invocations of gs), it's possible they are genuine. | 17:51.24 |
| ray_laptop | Robin_Watts: oh, right -- the -dMaxBitmap=___ changed for the rendering stage as well, right ? | 17:52.15 |
| | although WHY we test ps2write and pdfwrite for banding/no banding doesn't make sense to me | 17:52.52 |
| | since we're trying to verify the pdfwrite and ps2write devices | 17:53.21 |
| Robin_Watts | ray_laptop: I'm not sure we do. | 17:55.35 |
| | So, they probably aren't genuine :) | 17:55.46 |
| | or they might be intended to be unbanded, but were previously banded due to extreme size? | 17:56.14 |
| | I'm going to take the dogs for a walk. | 17:56.40 |
| | I have a file here that in banded mode is getting corrupt data to an image. | 17:56.58 |
| | I can see the data going into the hl_color call in the unbanded and banded files, and it's different. | 17:57.21 |
| | so presumably something is screwing it up in clist reading/writing. | 17:57.34 |
| ray_laptop | Robin_Watts: looking at the log, we set the -dMaxBitmap ONLY for the second step (rendering). | 17:57.56 |
| Robin_Watts | Yes. And I doubt we test both banded and unbanded at that point. | 17:58.50 |
| | bbs | 17:59.06 |
| ray_laptop | marcosw: it looks like we set the -r for pdfwrite which is NOT the usually customer usage. With ps2write, it is more common to set -r to match the printer target, but pdf's are almost always the default (-r720) in the common usage | 17:59.21 |
| | Robin_Watts: it looks like we don't test banded, although with the -dMaxBitmap larger, some files that used to be banded will no longer be | 18:00.10 |
| marcosw | We used to not set -r with pdfwrite but added that option at one point. I don't recall why, but kens probably recalls (or I could search my email and/or the IRC archive). | 18:01.33 |
| ray_laptop | marcosw: I just wanted to mention it since -r with pdfwrite is NOT very common in the real world. | 18:10.51 |
| specialforest | Hi to all | 19:09.04 |
| | Is there any of commiters of a mupdf library? | 19:09.11 |
| Robin_Watts | specialforest: MuPDF developers are here, yes. | 19:10.32 |
| specialforest | There is a missing include <sys/types.h> in file fitz/memento.h for size_t type | 19:11.47 |
| | It would be great if someone adds it ^) | 19:12.24 |
| Robin_Watts | specialforest: What platform are you compiling on? | 19:13.01 |
| specialforest | android | 19:13.10 |
| Robin_Watts | My android build works just fine. | 19:13.31 |
| | I have to be careful about which header I include. | 19:16.26 |
| | on msvc size_t is defined by stddef.h, not sys/types.h | 19:17.15 |
| | I am more tempted to #include <string.h> | 19:18.03 |
| | as that is guaranteed to define size_t and will work everywhere. Would that do for you? | 19:18.24 |
| specialforest | Okay | 19:22.04 |
| | It | 19:23.26 |
| | It's rather interesting how msvc works, when compiling C-code, because in C++ size_t is a builin type | 19:25.17 |
| Robin_Watts | let us not discuss the in(s)anity of C++ here :) | 19:26.01 |
| specialforest | BTW msvc has sys/types.h header, but size_t is not defined neither there nor in stddef.h | 19:26.33 |
| | OK :) | 19:26.39 |
| Robin_Watts | which version of MSVC? Too many different compilers out there, and we have to work with 'em all. | 19:26.53 |
| | string.h is the safest bet I reckon. | 19:26.59 |
| specialforest | no doubt | 19:27.48 |
| ray_laptop | Robin_Watts: how do I revert unstaged changes (is there a simpler way than git stash ; git stash drop; ) ? | 19:32.56 |
| Robin_Watts | ray_laptop: It's git, there will be many ways of doing it. Let me think. | 19:33.40 |
| ray_laptop | Robin_Watts: I thought reset, but that doesn't allow paths | 19:34.11 |
| Robin_Watts | git checkout file will revert a single file. | 19:34.30 |
| ray_laptop | well, if Ive committed the changes I actually wanted (with git add ... ; git commit; ) then git reset --hard might do it, right ? | 19:34.50 |
| Robin_Watts | IF you're prepared to blow away anything in the index, yes. | 19:35.08 |
| | git reset --hard is what I most often use, but it's a sharp tool. | 19:35.40 |
| ray_laptop | Robin_Watts: git co master ____ worked for me | 19:35.47 |
| | thanks. | 19:35.58 |
| Robin_Watts | git stash ; git stash drop is actually nicer, cos it keeps a reference in the history that you can get back to if there is an accident. | 19:36.16 |
| ray_laptop | I rarely need it, but the stoopid ghostscript.vcproj always gets modifed | 19:36.30 |
| | I'm going to commit my changes that add support for the suffixes with -d____=#### | 19:37.36 |
| | the only handy thing I didn't add support for was -d____=.5g (you have to use 512m) | 19:39.23 |
| Robin_Watts | cool. | 19:39.44 |
| ray_laptop | I think there is a long standing enhancement for that. | 19:40.02 |
| ray_laptop | goes to look | 19:40.06 |
| | well, if there was a bug, we must have closed it | 19:46.30 |
| | bbiaw | 19:51.22 |
| henrys | FWIW henrysx6 has filled up /tmp again with gs temporary files. | 20:15.35 |
| Robin_Watts | mvrhel: ping? | 20:29.28 |
| | If mvrhel arrives, I've just opened bug 693240 for him. | 20:45.03 |
| | If he has questions, tell him to text me, as I'm heading afk for a bit. | 20:45.23 |
| sebras | Robin_Watts: didn't know of git stash drop, thanks for the tip! | 20:50.52 |
| marcosw | henrys: sorry about that, the cron job that clears out /tmp every 24 hours wasn't installed on henrysx6. It is now so shouldn't happen again. | 21:47.05 |
| | Did we discuss better handling of tmp files at the last staff meeting? I thought we had a solution that worked on at least Linux. | 21:47.41 |
| mvrhel | Robin_Watts I am here now | 22:28.46 |
| | afk? | 22:29.07 |
| henrys | mvrhel:robin_watts made a bug for you I'm - away from keyboard | 22:38.24 |
| | afk | 22:38.39 |
| Robin_Watts | mvrhel: ping? | 22:54.20 |
| mvrhel | Robin_Watts: | 23:06.40 |
| | I am here now | 23:07.06 |
| | this sounds like the bug that I had just fixed that was the issue with the gray to K | 23:07.33 |
| | but obviously not | 23:07.52 |
| Robin_Watts | it does sound similar. | 23:10.02 |
| | It is a graytoK case, I believe. | 23:10.16 |
| | There may well be another problem with the same cutdown file; of the 15 images, 9 of them are black. But 3 definitely change between banded and unbanded. | 23:11.07 |
| mvrhel | ok. thanks for chopping it down | 23:11.59 |
| Robin_Watts | no worries. | 23:12.03 |
| | I'll move onto the next problem in the max_comps=64 stuff. | 23:12.25 |
| mvrhel | this happens with or without 64 Robin_Watts ? | 23:13.09 |
| Robin_Watts | without. | 23:14.48 |
| | and with. | 23:14.51 |
| mvrhel | ok | 23:14.55 |
| Robin_Watts | I spotted it with the 64 stuff, but it was because going to 64 made it a banded file rather than an unbanded one. | 23:15.13 |
| | but it's the banded/unbanded change that triggers it, and it happens irrespective of the component max. | 23:15.45 |
| | Actually... if you search in the file for "RJW" you'll see a comment just before the 5 lines that do the different tests. | 23:20.02 |
| | and commenting out different tests changes the end result (if you miss out the first 4, the remaining line is *always* black, for both banded and unbanded). | 23:20.35 |
| | Dunno if that's helpful or not. | 23:20.41 |
| mvrhel | it is | 23:25.16 |
| | thanks Robin_Watts | 23:25.19 |
| | Forward 1 day (to 2012/08/01)>>> | |
IRC Logs