| | <<<Back 1 day (to 2011/07/14) | 2011/07/15 |
| ray_droid | 64 bit Windows build is broken in 9.03 :-( | 03:19.02 |
| | I'm at the movies for the next 7 hrs, but i'll check when I get home. | 03:20.53 |
| cryptops1 | mupdf is create it's way faster than xpdf | 04:32.36 |
| kens | You're up early tor | 07:28.38 |
| tor8 | yeah... don't get too used to it :) | 07:29.27 |
| kens | :-) | 07:29.39 |
| tor8 | got far away relatives invading the house... no peace in the morning anymore | 07:29.54 |
| kens | Crap. VS 2008 crashes when it open my project. | 07:29.59 |
| chrisl | tor8: sure, your house, your rules! | 07:30.25 |
| tor8 | kyeongseob's cousins are visiting sweden. korean teenagers must have their morning starcraft fix :/ *yawn* | 07:31.42 |
| chrisl | feels old, having to resort to google to find out what starcraft is..... :-( | 07:33.13 |
| tor8 | hehe. did you know there's a tv channel dedicated to starcraft in korea? | 07:33.59 |
| chrisl | I find that slightly disturbing....... | 07:34.44 |
| kens | More than slightly. | 07:36.23 |
| | OK, if I disable rockscroll I cna open my project. | 07:36.44 |
| chrisl | Hmm, distiller doesn't seem to let you open and write to a file. | 07:37.06 |
| kens | Correct | 07:37.19 |
| | Security 'feature' | 07:37.24 |
| | Print it instead, it'll end up in the log | 07:37.43 |
| chrisl | I'll just use Jaws...... | 07:37.58 |
| kens | THat works too :-) | 07:38.06 |
| cryptopsy | someone suggested earlier i try mupdf, but i don't see a way to use it to delete individual pages from docs | 08:03.03 |
| kens | I read the logs, and it seemed to me Robin was suggesting using it to build a list of pages to deelte. But his suggestion required changing the MuPDF source for the viewer. I don't recall how he was suggesting deleting pages. | 08:07.21 |
| cryptopsy | ah okay | 08:07.39 |
| | xpdf allows me to use %f for the filename with their external command func | 08:08.01 |
| tor8 | kens, cryptopsy: pdfclean can rewrite a pdf with a list of pages to preserve | 08:08.30 |
| cryptopsy | it doesnt' say in the man page | 08:09.09 |
| kens | Probably that's what Robin was suggesting, I'm going on memory from readin ghe logs | 08:09.22 |
| cryptopsy | it doesnt' say in the man page of pdfclean it can do that | 08:10.42 |
| tor8 | the feature is still a bit experimental, it doesn't work all the time if you use the aggressive garbage collection flags | 08:10.49 |
| cryptopsy | how do i use this feature? | 08:11.27 |
| tor8 | that's why we don't mention it in the man page | 08:11.32 |
| | pdfclean -o out.pdf input.pdf 1-5,7,50-100 | 08:11.34 |
| cryptopsy | how can i mark pages in mupdf? | 08:11.47 |
| | do we have a channel? | 08:11.52 |
| | this is great because i no longer have to depend on pdftk written in java | 08:12.28 |
| tor8 | what robin suggested was hacking the mupdf viewer (apps/pdfapp.c) to add a key binding for marking and printing out the list of non-marked pages on stdout at exit | 08:12.38 |
| kens | Robin suggested adding a key to the MUPDF viewer which 'selected' or deselected' a page, and then emittting a list at the end of vioewing. | 08:12.41 |
| cryptopsy | tor8: would the community be interested in this? | 08:12.52 |
| tor8 | probably not, so don't spend too much time on it :) | 08:13.21 |
| | pdfapp_onkey() is the function that handles key input | 08:13.42 |
| cryptopsy | The MuPDF developers hang out on IRC in the #ghostscript channel on irc.freenode.net. | 08:16.42 |
| | whoops | 08:16.59 |
| tor8 | yes, that's right ;) | 08:18.03 |
| | Robin_Watts: linus is planning to add "generation numbers" to git commit objects in future versions of git. that should solve one of your pet peeves :) | 08:19.32 |
| kens | I hope he does it soon. | 08:19.48 |
| cryptopsy | do you happen to know a web browser in the style of mupdf (light), i just use it to display pages, but it must have tab | 08:23.11 |
| tor8 | cryptopsy: years ago I used "dillo", but that's not really an option with today's web. I use chrome, it has the most minimal and agreeable UI of the modern browsers IMO. | 08:25.57 |
| Robin_Watts | Morning all | 09:13.34 |
| kens | Morning Robin | 09:13.43 |
| Robin_Watts | Yes.I was suggesting using mupdf to get the list and pdfclean to extract pages. | 09:13.49 |
| kens | Its a sunny day here, how much power are you generating ? | 09:14.01 |
| Robin_Watts | Dunno. | 09:14.33 |
| kens | I'd have thought you'd have a controller wired up to a comuter :-) | 09:14.54 |
| Robin_Watts | I generated 18 or 19 units yesterday. | 09:14.58 |
| kens | No real time information ? :-( | 09:15.13 |
| Robin_Watts | To find out how much I'm actually generating at any given time, I need to go into the loft and look at the inverter. | 09:15.21 |
| | Then I can see all sorts of stuff. | 09:15.29 |
| kens | would prefer a WiFi unit to transmit it to me :-) | 09:15.44 |
| Robin_Watts | I think you can get such a thing, but that's more $$$. | 09:16.01 |
| kens | Oho, I see Ms Brooks has fallen on her sword :-) | 09:18.33 |
| Robin_Watts | not a moment too soon. | 09:22.18 |
| tor8 | kens, chrisl: in the build_char callback, is the ctm translation part supposed to be in the thousands range. the scaling looks correct, but the tx,ty part is around 5000. I'd have expected it to be zero... | 09:28.06 |
| kens | tx,ty might be bogus there, there are places where its ignored | 09:28.50 |
| chrisl | tor8: IIRC, you just ignore it. | 09:28.55 |
| tor8 | hm, but the build_char proc needs to build a path with moveto/lineto and then fill it... how does ignoring it work then? | 09:29.33 |
| | I'm trying to figure out why my "draw a rectangle instead" simple test case for fonts isn't working | 09:29.51 |
| | I'm not getting any marks at all :( | 09:29.58 |
| kens | I htink we don't care about the CTM translation, because the glyph description is in its own co-ordinate system ? | 09:30.54 |
| | We scale/rotate/shear etc, but we don't care about translation | 09:31.16 |
| | Don't forget, we are creating a bitmap for caching. | 09:31.31 |
| | usually | 09:31.36 |
| chrisl | ray_laptop: I fixed the Windows 64 bit build. | 09:45.20 |
| ray_laptop | chrisl: thanks. I hoped someone would while I was at the movies | 09:46.24 |
| | just got out of HP DH 2 | 09:46.34 |
| chrisl | ray_laptop: it was pretty trivial...... | 09:46.52 |
| ray_laptop | it's a quarter to 3 here | 09:46.55 |
| | my 12 year old kids liked it. | 09:47.12 |
| chrisl | ray_laptop: I meant the fix, but I'm not a fan on HP either ;-) | 09:47.38 |
| ray_laptop | chrisl: I'll send the script (works except for untested in 64-bit mode) | 09:48.08 |
| tor8 | kens: comparing with the values build_char proc gets for ghostxps, something is off. the tx,ty for gxps are coordinates on the page, not way off the page. probably something fishy with all the matrices :( | 09:48.15 |
| chrisl | ray_laptop: great, thanks - then I suggest you hit the sack! | 09:48.31 |
| kens | tor8 but gxps doesn't use FT. | 09:53.24 |
| tor8 | kens: I haven't even gotten that far yet :) just trying to get a pure gs_font struct working (xps uses gs_type1 and gs_type42 fonts) with the minimum set of callbacks required | 09:54.37 |
| kens | Oh, ok | 09:54.51 |
| | chrisl is probably better placed to help you with this now, but he's doign the release of course. | 09:55.14 |
| tor8 | xps has custom callbacks for build_char though, so I'm comparing the inputs | 09:55.24 |
| | I'll figure it out... eventually :) | 09:55.42 |
| | I may give up in disgust and procrastinate a few times first, though. | 09:56.05 |
| ray_laptop | chrisl: email with script sent. | 09:56.15 |
| kens | tor8 I could understand that... | 09:56.24 |
| chrisl | ray_laptop: got it, thanks! | 09:56.24 |
| tor8 | after all, I did get gslite working all those years ago... | 09:56.42 |
| ray_laptop | chrisl: don't try and run it until you look through it and adjust it to your liking. It'll probably take a few tries the first time. | 09:57.09 |
| chrisl | ray_laptop: okay, will do. | 09:57.21 |
| ray_laptop | chrisl: I forgot to mention one thing -- I can only build 64-bit with MSVC_VERSION 8, but I build 32-bit with MSVC_VER=9 | 09:57.52 |
| | chrisl: never got the compiler installed correctly for 64-bit with VS 9 | 09:58.22 |
| chrisl | ray_laptop: is that important? Can't I do both with 8? | 09:58.22 |
| ray_laptop | chrisl: sure | 09:58.30 |
| | just change the script | 09:58.40 |
| chrisl | Okay, cool | 09:58.46 |
| ray_laptop | g'nite... | 10:00.03 |
| kens | nigth ray | 10:00.09 |
| chrisl | tor8: the tx/ty values should be scaled with the rest of matrix, I think. | 10:00.23 |
| tor8 | yeah, it looks like my values are scaled by the font size twice. | 10:00.45 |
| | probably the advance widths I send to gs_process_text are wrong | 10:01.15 |
| chrisl | Oh, okay. Once I get the release done, I can look at what's actually happening in the FAPI code, if needed | 10:01.55 |
| Robin_Watts | We should be releasing with 8, anyway, IMHO. | 10:04.44 |
| | Anyone heard of Crystal RIP | 10:17.36 |
| chrisl | New one on me...... | 10:20.14 |
| kens | Crystal reports ? | 10:20.44 |
| | Any context ? | 10:21.06 |
| Robin_Watts | It's an open source RIP that uses ghostscript. | 10:21.33 |
| kens | Hmm, no never heard of it ;-) | 10:21.47 |
| | Not finding it with Google either | 10:22.10 |
| tor8 | kens: yay! I get black squares in the right places :) | 10:22.27 |
| | now to hook up freetype... | 10:22.32 |
| Robin_Watts | Me either. | 10:22.38 |
| kens | Great, excellent start :-) | 10:22.38 |
| | Robin_Watts : I do see a miling list for 'submitting Gghostscript bugs on Windows' which mentions a 'crystaldecisions.com' | 10:23.45 |
| | Which is a dead URL | 10:23.58 |
| Robin_Watts | kens: I'll ask the guy that contacted me mentioning it for a link. | 10:24.27 |
| kens | OK, sounds good | 10:24.38 |
| tor8 | kens: sweet, I have rendered text :) looks like shit, but that's what you get for not hinting with 72 dpi monobit rendering... | 10:50.48 |
| kens | Impressive though. | 10:51.06 |
| | Done very quickly too | 10:51.10 |
| tor8 | the font cache seems broken though... I'm getting random characters wrong after a while | 10:51.59 |
| | probably because I missed something vital when setting up the struct | 10:52.11 |
| kens | I'd have to guess its eomething like that, it normall yworks OK | 10:52.23 |
| tor8 | "Chapter 8: Interactive Features" -> "Chactee 1: Iateeactli e Featheef" | 10:53.22 |
| kens | Amusing, but gibberish :-( | 10:53.44 |
| ManDay | tor8: How is your program coming? | 11:32.10 |
| Robin_Watts | Well, my trip switch keeps going. I've disabled the solar system to see if that cures it :( | 13:05.34 |
| kens | makes you save electricity I guess :0 | 13:07.05 |
| Robin_Watts | Just had the solar panel guys calls back. They think it's because everything in my house goes through the one RCD. They are going to come and put a second board in just to take the solar stuff. | 13:11.37 |
| kens | Well, we have two because one wasn't enough. | 13:12.19 |
| | Cool tech: | 13:12.26 |
| | http://www.reuters.com/video/2011/07/14/flying-sphere-goes-where-man-fears-to-tr?videoId=217093066&videoChannel=6 | 13:12.26 |
| tor8 | kens: ow! looks like a pure gs_font won't work anywhere... gxccache casts to gs_font_base and accesses outside my malloced struct! | 13:23.02 |
| kens | Sorry, tor8 I'd have to read the code to see why. But its not uncommon in GS | 13:23.34 |
| tor8 | I'm just grumbling about crappy architecture. having a (pointless) base class and downcasting without testing whether it's safe... grrr. | 13:24.17 |
| kens | Like I said, not uncommon in GS ;-) | 13:24.34 |
| | Doens't mean I approve.... | 13:24.42 |
| tor8 | bites me every time... that's why the cache wasn't working anyway. | 13:25.38 |
| | it was looking at a UID field outside my struct | 13:25.56 |
| kens | Ah! Makes sense. | 13:25.57 |
| Robin_Watts | We should rearchitect to use something COM-like. | 13:27.22 |
| tor8 | better yet, stop using pseudo-OO everywhere... | 13:27.46 |
| Robin_Watts | But it'd be like moving a piece of furniture and watching all the cockroaches run for cover. | 13:27.55 |
| | chrisl: alive ? | 13:28.45 |
| | You may want to cherry pick 9be999c into 9.03 if it's not too late. | 13:29.30 |
| | That fixes item (3) in Freek Kempes mail. | 13:29.54 |
| chrisl | Robin_Watts: thanks. Might as well, I haven't resolved all the build problems with 9.03 yet :-( | 13:30.30 |
| tor8 | hmm, I wonder in which matrix the -rXXX dpi setting appears... | 13:31.11 |
| chrisl | tor8: for fapi we get it from the device: HWResolution | 13:32.53 |
| tor8 | chrisl: font unrelated :) I've just run into the problem of gs_setmatrix not doing quite what I expected | 13:33.31 |
| chrisl | tor8: yeh, but the resolution is stored in the device, so you can grab it from there. | 13:34.07 |
| tor8 | setting the .MediaSize device parameters sets the window size properly, but gs_setmatrix seems to overwrite the user->device matrix that embeds the resolution | 13:34.29 |
| | I'll just extract it at the beginning, probably safer | 13:34.51 |
| kens | pdfwrite uses the device HWResolution for this kind of thing. | 13:35.15 |
| chrisl | Robin_Watts: I've just been hacking (in a semi-blind panic!) in msvctail.mak. I've got it working, but I wondered if knew why the 64 bit genarch.exe has separate compile and link stages, whilst the 32 bit is done in a single step? | 13:53.48 |
| Robin_Watts | I have no idea at all. | 13:54.09 |
| chrisl | Okay, I guess it's not very important...... | 13:54.44 |
| Robin_Watts | Maybe they forked a while ago, and someone (like me) who couldn't do 64bit builds only updated one of them ? | 13:54.50 |
| chrisl | Possibly. I'll try changing it after I get done with this dratted release | 13:55.50 |
| henrys | I'll be out most of the morning today, chrisl I am not crazy about Friday releases because folks may not be here to deal with something bad happening but whatever you think is best. | 14:05.31 |
| Robin_Watts | henrys: If chrisl gets it finished today (which is by no means guaranteed, cos he's only had the release script for a few hours), then we can always send it out as a release candidate. | 14:06.41 |
| chrisl | henrys: given that I started this at about 8:30 this morning, it's now 3, and I'm not finished, there's no guarantees | 14:06.56 |
| Robin_Watts | The odds of them actually looking at it over the weekend are low, I would have thought. | 14:07.27 |
| | (Different if we were releasing to a US customer where they effectively have another day) | 14:07.53 |
| chrisl | I *had* hoped to get it out today as the "middle of the month", but it all went to hell...... | 14:08.16 |
| kens | On the plus side, you'll be ready for the real release ;-) | 14:08.40 |
| chrisl | True - but right now, I struggling to be positive about it! | 14:09.23 |
| kens | OK, Polish free user got rid of, back to consolidating text. | 14:10.49 |
| tor8 | henrys: you got any ideas for a name for the mupdf/ghostscript bridge? | 14:12.34 |
| Robin_Watts | mooscript. | 14:12.44 |
| tor8 | Robin_Watts: works for me :) | 14:13.13 |
| henrys | tor8:sounds like a discussion item for the meeting. | 14:14.47 |
| tor8 | henrys: I've got vectors and non-type3 text working for raster devices | 14:15.18 |
| henrys | great progress! | 14:15.56 |
| Robin_Watts | henrys: While michael was away, we tried to get timings for a planar device for some file or other for company R, right ? | 14:16.38 |
| | and we ran into problems... The file in question was lj4700_pcl5_color_AC8Z51CC.prn, right ? | 14:17.05 |
| henrys | yes, that is right | 14:18.23 |
| tor8 | I'll let chrisl and kens bang on getting fonts working with pdfwrite later :) | 14:18.25 |
| kens | If it works with GS it ought to be OK with pdfwrite I'd have thought | 14:18.44 |
| | Have you tried ? | 14:19.01 |
| tor8 | text makes it through as 72dpi bitmaps | 14:19.07 |
| kens | Oh :-( | 14:19.12 |
| tor8 | I would be surprised if it works at all :) | 14:19.24 |
| | s/would be/was/ | 14:19.32 |
| henrys | for pdfwrite just use "cat" ;-) | 14:19.40 |
| tor8 | there's something *really* funky going on with TextAlphaBits too | 14:20.05 |
| Robin_Watts | Ah, right. It was all-rops.pxl that I had problems with | 14:20.19 |
| kens | Well I'm going to have a lot to do in pdfwrite when you get finished anwya I expect. | 14:20.32 |
| henrys | Robin_Watts:I meant to create some simple rop examples so we can look at planar results with a file where is easy to change the rop and transparency - I'll probably do that this afternoon. | 14:28.55 |
| chrisl | So, now luratech build doesn't work on 64 bit Windows - I'm starting to get p*ssed off with this! | 14:29.20 |
| Robin_Watts | chrisl: If there is anything I can do to help, please say - but 64 bit windows I can't. | 14:30.26 |
| kens | Me neither I'm afraid | 14:30.42 |
| henrys | well I don't think we've tested that. luratech is very responsive to problems. | 14:30.51 |
| kens | Next PC will be 64-bit | 14:30.51 |
| Robin_Watts | henrys: It's OK. I was scratching my head trying to work out why I couldn't get it to crash with lj4700, and the answer was cos I'd fixed it. It was all-rops.pxl that had problems. | 14:31.18 |
| chrisl | henrys: I doubt they'd be quick enough to help with this release :-( | 14:31.33 |
| Robin_Watts | The main thing is that I now have an example where it goes wrong for when mvrhel2 arrives. | 14:31.33 |
| henrys | okay taking my nephew for a hike be back in a couple of hours. | 14:33.20 |
| kens | Enjoy | 14:34.25 |
| | Sorry 'Share and enjoy' | 14:34.41 |
| chrisl | henrys: I'm going to leave Luratech out of the binaries for this release (we'll still ship the source, though), and I'll try to get it sorted for 9.04. | 14:35.00 |
| | tkamppeter: I think I've fixed all the shared library problems, and I've upped the GS version number to 9.04. Let me know if you find more problems. | 14:40.18 |
| tkamppeter | chrisl, thanks, I will try it. | 14:42.03 |
| chrisl | *Finally* I have a 9.03 32 bit installer, 64 bit installer and a source archive. Need to quickly check something with Ray when he arrives, and I'll be ready. | 14:47.33 |
| kens | Great! | 14:48.14 |
| Robin_Watts | Does the 64bit luratech build work on unix ? | 14:48.46 |
| chrisl | Robin_Watts: yes, it does. There's a problem with the "inline" definition it's using on 64 bit Windows - inline/_inline/__inline or whatever | 14:49.37 |
| tor8 | kens, Robin_Watts: I assume the Type3_PCL and patt_trans_clist branches have been merged into master, am I correct? | 14:50.24 |
| Robin_Watts | tor8: patt_trans_clist, yes. | 14:50.39 |
| kens | I did the Type 3 long since tor8, but couldn't find a way to properly merge it at the master end. | 14:50.54 |
| | Please feel free to kill the branch if you like. | 14:51.08 |
| tor8 | I believe the git custom is to delete the branch once it's been merged | 14:51.12 |
| | just saw them now when I confirmed I had successfully pushed the mooscript branch | 14:51.27 |
| Robin_Watts | tor8: OK, all that does is to throw away the branch marker, right? The actual commits stay in the repo, because they are part of the history, yes ? | 14:52.03 |
| tor8 | yeah, it's just the ref that goes away | 14:52.16 |
| | "git push origin :patt_trans_clist" is the voodoo to delete a remote branch | 14:52.38 |
| Robin_Watts | If kens didn't merge in a way that includes appropriate parent pointer, we need to be careful not to lose history there. | 14:52.58 |
| kens | I think mine is fine. | 14:53.10 |
| tor8 | think of the command as pushing <nothing> to the branch | 14:53.20 |
| Robin_Watts | OK. If it wasn't fine, we could put in a dummy merge commit that leaves the master unchanged, but claims the branch as one of it's parents. | 14:53.50 |
| tkamppeter | chrisl, GS 9.04 builds now under Ubuntu Oneiric. Thanks for the fix. | 15:01.39 |
| chrisl | tkamppeter: phew, that's a relief! Thanks for testing it so quickly. | 15:04.02 |
| tkamppeter | chrisl, are there any new libraries included in the source tarball which were not included in 9.02? | 15:11.30 |
| chrisl | tkamppeter: None that are used. LCMS2 is there, but is currently very experimental, so don't worry about it. | 15:12.25 |
| tkamppeter | chrisl, thanks. Ubuntu is stll on liblcms1, so I leave that library in GS for the time being. | 15:14.59 |
| chrisl | tkamppeter: yes, the interface to lcms2 is *very* experimental | 15:15.30 |
| Robin_Watts | chrisl: Well, the interface works. The library itself has at least one problem that lcms1 doesn't. | 15:16.09 |
| tkamppeter | chrisl, can I remove the lcms2/ subdirectory from the source tree without loss of functionality in Ghostscript? | 15:26.31 |
| chrisl | tkamppeter: yes, it's not used at all unless you specifically ask for it to be used | 15:27.13 |
| tkamppeter | chrisl, OK. | 15:27.32 |
| | chrisl, Robin_Watts, who are copyright owners and what are the licenses of toolbin/color/icc_creator/effects/*.icc and iccprofiles/ps_cmyk.icc? | 15:34.31 |
| Robin_Watts | tkamppeter: I suspect that mvrhel2 generated them himself. | 15:35.01 |
| chrisl | tkamppeter: I think we are, but you should double check with mvrhel2 | 15:35.15 |
| Robin_Watts | so they are presumably the same as normal stuff. | 15:35.23 |
| tkamppeter | examples/transparency_example.ps? | 15:36.37 |
| | toolbin/color/*/*.icc? | 15:37.08 |
| chrisl | tkamppeter: you'll really have to check with mvrhel2, he committed that stuff | 15:38.17 |
| tkamppeter | chrisl, OK. | 15:43.07 |
| | mvrhel2, hi | 15:43.11 |
| mvrhel2 | hi tkamppeter | 15:43.18 |
| | reading logs... | 15:44.12 |
| tkamppeter | mvrhel2, There are some files in 9.04 where I need the copyright and license info of: toolbin/color/icc_creator/effects/*.icc, iccprofiles/ps_cmyk.icc, examples/transparency_example.ps, toolbin/color/*/*.icc, and generally files in toolbin/ | 15:45.14 |
| mvrhel2 | oh I created all of these and they should have same copyright and license as the other files in ghostscript | 15:47.13 |
| | this reminds me of one thing that I need to do which is to make my own versions of some standard profiles. I now have a way to do that very easily | 15:48.27 |
| tkamppeter | mvrhel2, thanks. | 15:49.08 |
| mvrhel2 | wait we have not tagged 9.04 yet have we? | 15:49.13 |
| tkamppeter | mvrhel2, the snapshot which I am using seems to build happily as 9.04. | 15:49.56 |
| mvrhel2 | oh ok | 15:50.03 |
| kens | mvrhel2 the current code is now flagged as 9.04 | 15:51.24 |
| mvrhel2 | yes. I understand | 15:51.33 |
| | overslept this morning. fighting this darn cold. off to grab breakfast | 15:54.08 |
| tkamppeter | I have built and installed 9.04 and stars.pdf gives 6 stars! | 15:54.28 |
| Robin_Watts | tkamppeter: Phew :) | 15:54.44 |
| tkamppeter | So after some small polishing it goes into Oneiric. | 15:55.20 |
| Robin_Watts | infinite loop freeing patterns. ick. | 16:25.08 |
| ray_laptop | morning, all | 16:28.10 |
| kens | Back early ray :-) | 16:28.20 |
| Robin_Watts | morning ray_laptop. | 16:28.30 |
| ray_laptop | chrisl: did you need to check sometihing with me ? | 16:28.41 |
| | chrisl: about the 9.03 release. | 16:29.58 |
| | what's this about 9.04 -- we haven't frozen thing already have we ?? | 16:30.23 |
| ray_laptop | must have slept too long, if so | 16:30.32 |
| kens | 9.04 pre-release | 16:30.34 |
| ray_laptop | chrisl: so we still have 64-bit luratech to sort out, right ? | 16:31.08 |
| chrisl | ray_laptop: yes, I'm dropping luratech from the 9.03 binaries (but the source will ship), we'll get it sorted for 9.04 | 16:37.24 |
| ray_laptop | chrisl: but I thought it automatically builds luratech if the directory was present -- or did you hobble the 64-bit build to avoid that ? | 16:38.37 |
| Robin_Watts | If we drop it from the binaries, we should drop it from the source too, IMHO. | 16:39.27 |
| | Otherwise they might rebuild and get something different - it's a potential source of confusion. | 16:40.00 |
| Robin_Watts | feels the pain as chrisl sticks pins into the voodoo doll. | 16:40.22 |
| chrisl | ray_laptop: it checks for the "ldf_jb2" and "lwf_jp2" directories under the gs directory (as per the documentation), so if we leave them under gs/luratech the build system will not try to use them. | 16:40.23 |
| ray_laptop | Robin_Watts: but most customers (including 850, AFAIK) build 32-bit and that works I think | 16:40.36 |
| | chrisl: so the commercial release script should have moved the ldf_jb2 and lwf_jp2 directories from luratech to the 'gs' level (after the export) | 16:41.59 |
| chrisl | ray_laptop: yes, that's right. | 16:42.17 |
| | So I've temporarily disabled the moving of the directories. | 16:42.48 |
| ray_laptop | chrisl: obviously, I hadn't noticed that it wasn't building luratech, but then, when I stopped yesterday evening, 64-bit didn't build at all due to the $(AUX) cock-uo | 16:43.00 |
| | chrisl: we wouldn't have to move them if we changed the path to 'luratech/ldf_jb2' (and same for jp2) as the defaults in the makefiles when 'luratech' was set | 16:44.22 |
| chrisl | ray_laptop: true *but* that's not what the documentation says, and customers who have been using it might be confused by a change in behaviour. | 16:45.13 |
| ray_laptop | and I like that better than having two, not well known, directories in the gs tree -- having them as subdirectories under luratech makes more sense to me | 16:45.14 |
| chrisl | ray_laptop: well, care to comment on why it wasn't done that way to start with? | 16:46.07 |
| ray_laptop | chrisl: anyone using it prior to 9.03 was doing it manually, so if it builds (in 9.04) automagically, they will be happy to avoid reading the docs | 16:46.13 |
| chrisl | ray_laptop: exactly, they won't read the docs, they'll copy the directories as they always have, and the build system will have to cope with both situations. | 16:47.13 |
| ray_laptop | chrisl: at the time, Ralph Giles did it. Our licensing position on the luratech wasn't clear (maybe only to Miles) and Ralph allowed for his jbig2dec to be used with luratech jp2 | 16:47.34 |
| | if they do it the way they used to, then they were manually editing the makefile for the path probably anyway (the ones I know wanted to keep the luratech stuff in a separate directory and just set the paths manually, not using the ldf_jb2 default path) | 16:48.57 |
| chrisl | Well, I can change it for 9.04 so they are both under luratech, once we get luratech building for all our standard builds. | 16:49.23 |
| ray_laptop | so what I am recommending is making the default path be luratech/ldf_jb2 instead of the naked ldf_jb2 | 16:49.30 |
| | chrisl: right | 16:49.39 |
| chrisl | ray_laptop: but the 9.03 release will have to wait until Monday, I've *really* had enough of it today - the 64 bit luratech problem was the last straw! | 16:50.44 |
| ray_laptop | chrisl: OK. We'll let marcosw be the king's messenger to cust 850. Maybe someone (Robin_Watts or I, or maybe even henrys) can get the 64-bit luratech build working. | 16:52.14 |
| | chrisl: just so I can see what problems you may have fixed in the script, can you send me yours. | 16:53.00 |
| tkamppeter | GS 9.04 is supposed to fix bug 691755, but the command line in the initial posting still takes ages for me. | 16:53.08 |
| chrisl | ray_laptop: I know what's wrong with the luratech build, it's a pretty trivial fix, I think, but I'm not keen on shipping luratech with modifications unless we *really* have to. | 16:53.52 |
| ray_laptop | chrisl: I assume such a crufty piece of work shouldn't go into the git repo, but if you want, we could put it in toolbin. Might be time to move the release related stuff in toolbin to a directory, too | 16:54.09 |
| Robin_Watts | tkamppeter: Define ages. | 16:54.26 |
| ray_laptop | chrisl: our luratech _is_ modified from the sources we get from them. Check the svn logs | 16:54.46 |
| Robin_Watts | ray_laptop: toolbin IS in the repo. | 16:54.50 |
| ray_laptop | Robin_Watts: I know | 16:55.05 |
| chrisl | ray_laptop: I didn't really *fix* anything in the script, I just modified the "cruft" to suit my setup. | 16:55.14 |
| ray_laptop | Robin_Watts: I meant move the release related scripts and helper files in toolbin to toolbin/release or something | 16:55.55 |
| Robin_Watts | right. I think that would be a good idea. | 16:56.07 |
| ray_laptop | chrisl: fine, then I don't need it | 16:56.15 |
| chrisl | ray_laptop: okay, I'll commit the change to our svn-private - it would be good to check with luratech if they know about/resolved the problem, though. | 16:56.17 |
| ray_laptop | chrisl: yes, I agree. | 16:56.32 |
| | chrisl: did you tag 9.03 ? | 16:57.04 |
| chrisl | ray_laptop: what I'll do, hopefully for 9.04, is make the script a bit more easily configurable, then it can go into the toolbin. | 16:57.11 |
| tkamppeter | Robin_Watts, after 6:30 min onn a 64-bit box on 100% CPU it has done one third of the page (stars.pdf). | 16:57.18 |
| chrisl | ray_laptop: yes, the tag is there - both ghostscript-9.03 and ghostpdl-9.03 tags exist. | 16:57.43 |
| ray_laptop | chrisl: great! | 16:57.56 |
| Robin_Watts | tkamppeter: OK, I'll reopen the bug and try and have a look. | 16:58.50 |
| ray_laptop | chrisl: the other issue is the customer LICENSE file. I wonder if we should keep that in svn-private, or if we can put it in the GPL repo as something like doc/LICENSE.Artifex.OEM.txt | 16:59.28 |
| Robin_Watts | tkamppeter: Can you confirm the problem happens with a non-cups device please? | 16:59.48 |
| ray_laptop | burying it there shouldn't confuse anyone, and the headers mention LICENSE | 16:59.55 |
| Robin_Watts | (Like perhaps the second command line given in the original bug report please) | 17:00.10 |
| | I'm not setup for cups here. | 17:00.18 |
| chrisl | ray_laptop: how about if I "hide" it in the script file, so that the script create the LICENSE file itself? | 17:00.28 |
| ray_laptop | chrisl: for ghostpdl, commercial release there is yet another (minor) couple of issues. GhostPDL has a different LICENSE file (and Artifex OEM variant), and it needs the Artifex commercial gs | 17:01.38 |
| | I had trouble with msys or git not letting me rename the directories | 17:01.58 |
| chrisl | ray_laptop: I don't need to worry about that for 9.03, do I? It can be Ghostscript only? | 17:02.38 |
| ray_laptop | chrisl: until cust 850 asks for it, we'll assume all they need is ghostscript | 17:03.07 |
| chrisl | good! :-) | 17:03.22 |
| ray_laptop | chrisl: BTW, thanks for fixing the 64-bit build. I'm going to try running the release script all the way through with the 9.03 tag... | 17:04.07 |
| chrisl | ray_laptop: from the sound of it the ghostpdl commercial changes are trivial enough to be done by hand, though. | 17:04.20 |
| ray_laptop | while I get my coffee | 17:04.26 |
| | chrisl: I just like having it scripted so I don't forget to do something | 17:04.50 |
| | (for instance I include the grep for GPL in the gs contents) | 17:05.20 |
| chrisl | ray_laptop: yeh, I know what you mean. I'll see about scripting the GhostPDL one, too, at some point..... | 17:06.02 |
| tkamppeter | Robin_Watts, the second line is also slow for me, so try this one for now. | 17:06.53 |
| Robin_Watts | thanks, will do. | 17:07.02 |
| ray_laptop | the only GPL file we ship is the afmdiff.awk | 17:07.13 |
| tkamppeter | Robin_Watts, still problems are with stars.pdf and also with the document.pdf of https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/668800. | 17:07.35 |
| ray_laptop | mooscript branch -- well at least it isn't 'oinkscript' | 17:07.39 |
| Robin_Watts | tkamppeter: It would be good to know if it's the same slowness as before, or whether the patt_trans_clist stuff has improved it, just not enough. | 17:08.02 |
| chrisl | ray_laptop: Yes, I noticed that (afmdiff.awk) in the 9.02 commercial release. | 17:08.03 |
| ray_laptop | chrisl: I see the patch for the luratech 64-bit -- thanks | 17:12.52 |
| tkamppeter | Robin_Watts, both sample files on bug 691755 are slow. I have even the feeling that they are slower than before. | 17:13.28 |
| chrisl | ray_laptop: told you it was trivial ;-) | 17:13.42 |
| Robin_Watts | tkamppeter: Hmm. That would be a shame :( | 17:14.20 |
| ray_laptop | chrisl: so that _should_ put us at a workable 9.03. What about I go ahead and do it today ??? | 17:14.24 |
| ray_laptop | doesn't want to usurp chrisl 's duties, but ... | 17:14.43 |
| chrisl | ray_laptop: if you like, that'd be great - it might just save my laptop from a flying lesson out the window! | 17:15.05 |
| ray_laptop | chrisl: OK. I'll do a release (I was going to anyway) and beat on it a bit, then check with henrys to see if he has any last minute objections to "throwing it over the transom" to cust 850 | 17:16.11 |
| chrisl | ray_laptop: the one thing I'm doing differently to your script is that I manually do a git archive on the tag, and then run the script in the expanded archive. I'll automate that bit before 9.04. | 17:16.47 |
| ray_laptop | chrisl: and I'll make luratech the default (by changing to script to move the directories after the export) | 17:16.49 |
| | chrisl: OK, that's cleaner (and will make it easier for the ghostpdl release that follows) | 17:17.39 |
| Robin_Watts | Right. Things are being put into the pattern cache as being one size, and are being taken account as another size. | 17:18.25 |
| ray_laptop | goes to read about git archive | 17:18.53 |
| Robin_Watts | So the 'how many bits in the pattern cache' figure gets out of whack, and it ends up in an infinite loop looking for things to bin. | 17:18.55 |
| ray_laptop | chrisl: can I just pipe the output of git archive to tar ? | 17:20.30 |
| chrisl | ray_laptop: yes. | 17:21.22 |
| | ray_laptop: git archive <git tag> | tar -x -C <your temp directory for release> | 17:22.34 |
| ray_laptop | chrisl: I would have thought: tar -Ctempdir -xf - | 17:24.23 |
| chrisl | ray_laptop: I just copied off some web site! | 17:25.02 |
| ray_laptop | chrisl: OK. Thanks. | 17:25.19 |
| chrisl | ray_laptop: this time I made the archive and copied it elsewhere, as I didn't want to run the script anywhere near my git repository. | 17:26.02 |
| tkamppeter | Robin_Watts, I am trying to render stars.pdf on another machine with 9.01 now but I have problems as gs produces more than 1.5 GB of temp files. | 17:26.41 |
| Robin_Watts | tkamppeter: Go to /dev/null maybe? It's time we care about, not space. | 17:27.17 |
| tkamppeter | Robin_Watts, for the resulting output file I have space. In /tmp I have only 1.5 GB. | 17:28.32 |
| Robin_Watts | Ah, clist stuff must be being written to disk. | 17:29.54 |
| | Who understands the pattern cache? ray_laptop ? mvrhel2 ? | 17:31.10 |
| | We calculate the number of bits used by a tile when it's inserted. We then calculate the number of bits used (again) when we remove it. | 17:31.44 |
| | Would it not be better (and less prone to accident) to record the number of bits used in the tile when we insert it? | 17:32.05 |
| | That way we don't have to recalculate it at the end, and our sums can't ever get screwed up, | 17:32.22 |
| ray_laptop | Robin_Watts: it should be that way, I agree. I don't have a problem with changing it to do that. The pre-calc (esitmate) is just so we free enough pattern-cache before allocating a buffer | 17:40.38 |
| | obviously for clist patterns, it's a very rough estimate | 17:41.02 |
| Robin_Watts | Right. The problem is we are estimating too large, then when we come to take out, we take out less, so the system becomes convinced that the cache is still full. | 17:41.28 |
| | I plan to use the original estimate at all times. | 17:41.59 |
| ray_laptop | previously, it would allocate a bitmap (maybe large) buffer and then free other patterns if we had exceeded the limit, leading to potentially 2 large patterns in the buffer | 17:42.03 |
| | Robin_Watts: I think it should have the ACTUAL clist sizes (after the clist is collected), NOT the estimate | 17:42.38 |
| Robin_Watts | Well, that would mean moving all the size calculation stuff that's currently in the free section to be in the alloc section. | 17:43.34 |
| | I'll look at that. | 17:43.37 |
| ray_laptop | some clists will be pretty small (if they are done with graphics instructions) but clist patterns made from images will be large | 17:43.39 |
| | Robin_Watts: the ensure_space can use the estimate for the 'needed', but it should use ACTUAL sizes from the cache as it frees patterns | 17:44.38 |
| Robin_Watts | ray_laptop: We *must* use the same value when we insert as when we remove. | 17:45.10 |
| | Anything else leads to inconsistencies and infinite loops. | 17:45.30 |
| chrisl | ray_laptop: I forgot there was another change needed for building luratech in msvc.mak :-( | 17:45.43 |
| ray_laptop | Robin_Watts: when we insert, yes, but the ensure_space is BEFORE we collect the clist/bitmap | 17:45.53 |
| Robin_Watts | Right. | 17:46.00 |
| | It's not clist values that are the problem, I think. | 17:46.35 |
| ray_laptop | chrisl: are you going to commit that change ? | 17:46.38 |
| chrisl | Yes, doing it now. | 17:46.47 |
| ray_laptop | chrisl: thanks. Going for coffee -- bbiab | 17:47.00 |
| tkamppeter | ray_laptop, Robin_Watts, chrisl: It is more or less the same performance onm stars.pdf, both 9.01 and 9.04, only that the latter makes all 6 stars visible. | 17:47.58 |
| Robin_Watts | tkamppeter: OK, thanks. Does -dNOINTERPOLATE help at all? | 17:48.36 |
| tkamppeter | Robin_Watts, trying ... | 17:49.26 |
| chrisl | tkamppeter: didn't you test this before? | 17:50.28 |
| Robin_Watts | I'm sure that this was tested and found to have been fixed. | 17:50.58 |
| tkamppeter | No, all tests of today are without -dNOINTERPOLATE. | 17:51.05 |
| Robin_Watts | Either that fix has fallen out since, or something else has happened. | 17:51.15 |
| | ISTR that stars wasn't exactly speedy, but it wasn't horrific either. | 17:51.35 |
| mvrhel2 | Robin_Watts: yes I thought the issue with that file was that we were generating huge transparency buffers where we were drawing only small objects within the pattern | 17:52.46 |
| | the bbox for the trans group was a full page | 17:53.05 |
| Robin_Watts | mvrhel2: yeah. | 17:53.12 |
| mvrhel2 | but we only drew a small star | 17:53.16 |
| Robin_Watts | Maybe because we now draw all 6 stars, the wins we got have balanced out. | 17:53.39 |
| mvrhel2 | yes. I think that was preventing us from even drawing iirc | 17:54.31 |
| | it sounds like you have a new issue now | 17:54.37 |
| | you or we | 17:54.42 |
| Robin_Watts | mvrhel2: I have just tried a quick hack to the pattern accumulator. | 17:55.08 |
| tkamppeter | Robin_Watts, my feeling is that we always have drawn all 6 stars, only that 5 of them got overpainted by something white (which perhaps was supposed to be transparent). | 17:55.08 |
| Robin_Watts | If the target is planar, it makes its buffers planar. | 17:55.41 |
| | That got me into trouble with the pattern cache and the sizes being wrong. | 17:55.55 |
| | but having patched that, it now seems to run to completion. | 17:56.07 |
| | Am about to look at the output to see if it's plausible. | 17:56.16 |
| chrisl | ray_laptop: I've updated the tag with the luratech build fix. You'll need to "git fetch" then "git checkout ghostscript-9.03" - the last commit listed should be "Set the defines needed to build luratech on WIN64" | 18:07.56 |
| | Thank heavens: 32 and 64 bit Windows binary installers, build with Luratech - I can't even summon the enthusiasm to be relieved.................... | 18:23.00 |
| | mvrhel2: ping? | 18:23.42 |
| Robin_Watts | mvrhel2: ping too. | 18:26.39 |
| chrisl | Oh well, at least I'm not alone in here :-) | 18:27.03 |
| Robin_Watts | mvrhel2: You wanted to discuss planar stuff. Can we do that soon, cos I can feel a weekend coming on. | 18:27.12 |
| | chrisl pinged first though, so... :) | 18:27.20 |
| chrisl | I'll be *very* quick. | 18:27.31 |
| Robin_Watts | I bet you say that to all the girls. | 18:27.51 |
| | :) | 18:28.05 |
| chrisl | Hah! Have you need reading the mail in my spam bin? | 18:28.24 |
| | Robin_Watts: actually, I meant to say: EasyTether (to tether to your phone via USB) claims to have OS/X drivers, as well as Linux and Windows | 18:30.56 |
| Robin_Watts | chrisl: right. | 18:31.24 |
| henrys | chrisl:is the 64 bit windows okay? | 18:31.38 |
| Robin_Watts | My phone has a 'portable wifi hotspot' thing built in which seems to work well. | 18:31.39 |
| mvrhel2 | oops sorry | 18:31.57 |
| | I stepped out for sec | 18:32.02 |
| chrisl | Robin_Watts: yeh, but it drains the battery quicker using wifi | 18:32.03 |
| mvrhel2 | back now | 18:32.04 |
| chrisl | henrys: it is now, *finally*! | 18:32.12 |
| henrys | great | 18:32.28 |
| mvrhel2 | chrisl: you wanted something? | 18:32.42 |
| henrys | chrisl:did you decide to do the release? I can read back if I should. | 18:32.57 |
| chrisl | mvrhel2: Shailesh asked me to prod you about whether you'd got his e-mails? He said if you were too busy right now, that's fine, but wanted to check they hadn't just been spam binned. | 18:33.08 |
| | henrys: Ray offered to do it, since it was getting late for me, after all the hassle. | 18:33.29 |
| mvrhel2 | ah. yes. I will get to those today and apologize for my tardiness | 18:33.40 |
| chrisl | mvrhel2: okay, cool. It's just gmail's over zealous filtering has stopped his mails getting to me a couple of times, which is why he's stuck to using my personal e-mail | 18:34.45 |
| | Robin_Watts: mvrhel2 is now all yours :-) | 18:35.14 |
| Robin_Watts | mvrhel2: Right. Planar stuff... | 18:35.37 |
| mvrhel2 | Robin_Watts: I am wrapped up right now trying to finish up this rendering intent stuff which is the final thing that I promised for the 9.04 release. I can stop now to talk about the planar stuff | 18:35.40 |
| henrys | chrisl:yes I'll respond didn't seem like an email to respond to when I read it. | 18:35.52 |
| Robin_Watts | mvrhel2: OK. I'm probably going to be stopping for the night within the next hour or so (unless I get stuck into something). | 18:36.23 |
| mvrhel2 | Robin_Watts: do we have a simple file that has the issue? | 18:36.29 |
| Robin_Watts | all-rops.pxl | 18:36.42 |
| chrisl | henrys: I'm hoping Ray reappears soon, I want to make sure he gets the updated ghostscript-9.03 tag (before I head off) | 18:36.48 |
| mvrhel2 | Robin_Watts: where is that file? | 18:36.55 |
| Robin_Watts | that's in tests_private/customer_files. | 18:37.02 |
| | tests_private/customer_tests/all_rops.pxl even | 18:37.31 |
| mvrhel2 | ok | 18:37.44 |
| Robin_Watts | If you try and do: | 18:38.07 |
| | main/debugobj/pcl6.exe -r600 -sDEVICE=plank -o out%d.ppm ../ghostpcl/tests_private/customer_tests/all_rops.pxl | 18:38.20 |
| | you'll see the problem. | 18:38.29 |
| mvrhel2 | ok. hold on let me grab my drive that has all the files on it. | 18:38.41 |
| Robin_Watts | Hmm. Need to juggle some files around to commit them. | 18:40.15 |
| mvrhel2 | hmm. ok I can't find my drive | 18:41.48 |
| | Robin_Watts: in any event, my concern is 2 things | 18:42.11 |
| | one is drawing into what we currently call the trans_buffer | 18:43.14 |
| | right now for the pdf14 case, that occurs by markfill_rect which draws appropriately | 18:43.48 |
| | we wont be doing that in this case | 18:43.58 |
| | Robin_Watts: and it is not clear to me how we draw in a planar manner into that buffer for the non transparency case | 18:44.47 |
| Robin_Watts | Right. | 18:45.15 |
| mvrhel2 | what we almost need is to have a memory buffer like what you have for the plank device | 18:45.17 |
| | and use your methods that you draw into that | 18:45.24 |
| Robin_Watts | This is going to be a very one sided conversation, I suspect as I have an almost complete ignorance of everything inside the pattern accumulator device. | 18:45.58 |
| mvrhel2 | ok. well right now it is pretty simple | 18:46.11 |
| | there are really 3 different member variables in the pattern accumulator structure for storing the pattern | 18:46.36 |
| Robin_Watts | When you said that the pattern accumulator "already used planar buffers if it detected it was going to the pdf14 device", I had hoped we could just hijack that test and make it be "if we're going to the pdf14 device or a planar device" | 18:47.04 |
| | but I'm now not so sure it's that simple. | 18:47.12 |
| | In pattern_accum_open at around line 490ish | 18:47.47 |
| mvrhel2 | tbits (and tmask) for non transparency buffer case, cdev (clist for large patterns) and ttrans which is for the case where we have transparency | 18:47.53 |
| Robin_Watts | Do we use ttrans with tbits ? | 18:48.45 |
| mvrhel2 | ttrans has baggage associated with being for the pdf14 device. No tbits and ttrans are never both used | 18:49.00 |
| | if the pattern has transparency then ttrans is used | 18:49.16 |
| Robin_Watts | OK. so ttrans represents all the planes? color(s) and alpha ? | 18:49.34 |
| mvrhel2 | otherwise tbit or cdev is used. If the trans pattern is large cdev may also be used | 18:49.39 |
| Robin_Watts | OK, well in the file I've been looking at, no transparency. | 18:50.13 |
| | So I tried a change... | 18:50.28 |
| | in pattern_accum_open around line 490. | 18:50.49 |
| | we create a memory device. | 18:51.02 |
| | before we open it, I check to see if target is planar. | 18:51.41 |
| | If it is, then I call gdev_mem_set_planar() which transforms the memory device into a planar one. | 18:52.06 |
| mvrhel2 | that should work | 18:52.22 |
| Robin_Watts | That seems to work in that it doesn't crash and it runs to completion. | 18:52.39 |
| mvrhel2 | ok. we probably need to use some different tiling methods though yes? | 18:52.55 |
| Robin_Watts | I'm not convinced the tiling out of the patterns works though. | 18:53.02 |
| | right. | 18:53.06 |
| mvrhel2 | yes. so I wonder if we can leverage the transparency planar tiling functions | 18:53.21 |
| Robin_Watts | But that sounds like it only accounts for 1 of the 3 cases. | 18:53.23 |
| mvrhel2 | ok. no we should be good with the other cases. | 18:53.38 |
| Robin_Watts | clist patterns, I can see that would work. | 18:54.18 |
| mvrhel2 | the trans case is a different animal and will just do its own thing. the halftone planar target is not seen until way later when the final group is popped to the target. by then the tiling was all done in the transparency code | 18:54.34 |
| | the plank device will never be tiled in by a transparency tile | 18:54.56 |
| Robin_Watts | OK. I only cope with PaintType == 1. | 18:55.27 |
| mvrhel2 | refresh my memory on type 1 and type 2 | 18:56.25 |
| Robin_Watts | Ha. I was just typing "what other painttypes are there?" | 18:56.42 |
| | Type 1 is colored, Type 2 is uncolored (he says, reading the comments) | 18:57.05 |
| chrisl | I need head out: if/when Ray reappears, can someone refer him to my post at 19:07, please? About getting the updated tag. | 18:57.30 |
| Robin_Watts | Ah, right, in PaintType 2, we only allocate a mask. | 18:58.12 |
| | And masks are 1 plane, hence implicitly planar. | 18:58.30 |
| | so we're fine for painttype 1 and 2. Let me just check whether there are more painttypes. | 18:58.55 |
| mvrhel2 | ok pattern type 2 are shadings | 18:59.03 |
| Robin_Watts | pattern type != painttype | 18:59.23 |
| mvrhel2 | ah | 19:00.18 |
| chrisl | Robin_Watts: only two painttypes | 19:00.32 |
| mvrhel2 | Paint tyoes 1 and 2. color and uncolored stencil | 19:00.49 |
| Robin_Watts | chrisl: Thanks. That was my memory too, but my memory isn't good. | 19:00.49 |
| mvrhel2 | so with type 2 we just need the mask | 19:01.07 |
| | type 1 we need tbits and the mask | 19:01.14 |
| | so we only need to worry about the case that you have done | 19:01.33 |
| Robin_Watts | OK, so we should be fine in all pattern creation cases. | 19:01.41 |
| | but we need to look at the pattern usage (tiling) stage. | 19:01.56 |
| mvrhel2 | yes | 19:01.59 |
| Robin_Watts | Any idea where that lives in the code ? | 19:03.31 |
| mvrhel2 | tile_by_steps_trans, gx_trans_pattern_fill_rect, | 19:04.11 |
| | in gxp1fill.c | 19:04.15 |
| | Robin_Watts: if may make more sense for you to look at the non-trans ones though | 19:05.09 |
| | and do you equivalent of strip_copy_rop | 19:05.19 |
| ray_laptop | chrisl_away: I saw your comment. | 19:05.25 |
| mvrhel2 | Robin_Watts: did you see if you were getting the correct output now with your change? | 19:05.47 |
| ray_laptop | chrisl_away: and I've incorporated your ideas into an improved script (git archive and using 'here' data for the LICENSE) | 19:06.06 |
| Robin_Watts | mvrhel2: I got distracted before I double checked, but it was looking a bit wrong. | 19:06.36 |
| mvrhel2 | ok | 19:06.51 |
| | Robin_Watts: well you have already done work in gxp1fill.c if I recall | 19:07.17 |
| Robin_Watts | mvrhel2: OK. I think I've got enough of an idea to keep bashing at this for the weekend. | 19:07.20 |
| henrys | I would like to get the language autoconf up to speed with ghostscript but I don't see anyway to do it without duplicating a lot of configure.ac, there doesn't seem to be a nice way to share this stuff. | 19:07.32 |
| Robin_Watts | Want to talk again on monday morning (your time) about this? | 19:07.35 |
| mvrhel2 | Robin_Watts: sounds good | 19:07.44 |
| | have a great weekend | 19:07.48 |
| Robin_Watts | Fab. You too. | 19:07.52 |
| henrys | mvrhel2:so is the all rops test completely wrong or are there just a few problems? | 19:08.38 |
| | have a good one Robin_Watts! | 19:09.13 |
| mvrhel2 | henrys: (Robin_Watts: correct me if I am wrong). I think we just have this issue with tiling patterns and I believe I have a polarity issue | 19:09.23 |
| Robin_Watts | I'm not going yet. | 19:09.27 |
| | henrys: In the current trunk it crashes. | 19:09.44 |
| | With my local changes it completes. | 19:09.54 |
| | I suspect the output of the tiled patterns are wrong. | 19:10.09 |
| mvrhel2 | Robin_Watts: maybe you should commit that even though it renders wrong. | 19:10.10 |
| Robin_Watts | mvrhel2: I will. | 19:10.29 |
| mvrhel2 | thanks | 19:10.33 |
| Robin_Watts | I need to test the pattern cache calculation fix first (running now) | 19:10.47 |
| | The cluster seems to be doing something odd. | 19:11.15 |
| ray_laptop | henrys: I've chatted with chrisl and he agreed that I would handle the 9.03 customer release (using a new improved script based on some ideas from chrisl's attempts the past day) | 19:11.46 |
| Robin_Watts | mvrhel2: When I ran the lj4700 file through the planar device I found I was getting different results to the non-planar device. | 19:12.26 |
| ray_laptop | henrys: I am doing the prep now, then will test the install/uninstall of 32 and 64 bit and some Windows smoke testing | 19:12.32 |
| Robin_Watts | even allowing for the polarity. | 19:12.37 |
| | When I investigated, I found that I was getting different results even with the non-planar device and banded/non-banded. | 19:13.11 |
| henrys | okay I said earlier I am not a big fan of a Friday release but whatever you think is best. | 19:13.15 |
| Robin_Watts | Changing the heights of the bands changed the differences too. | 19:13.28 |
| ray_laptop | henrys: well we can release on Saturday ;-) | 19:13.36 |
| Robin_Watts | We're only releasing to one customer, right? | 19:13.51 |
| henrys | meaning that I'd rather wait until Monday. | 19:13.53 |
| Robin_Watts | What are the odds they will actually be there to receive it over the weekend? | 19:14.06 |
| | On the other hand, they WILL be there monday morning european time. | 19:14.19 |
| mvrhel2 | Robin_Watts: ok. I will do some testing on that then. I have not compared non-planar/planar clist/nonclist and old ht/ new ht | 19:14.19 |
| | lunch time now. | 19:14.30 |
| | bbiab | 19:14.32 |
| Robin_Watts | So if you wait til monday morning ray time to release, that's another day they'll be waiting. | 19:14.38 |
| ray_laptop | henrys: np. I'll still go ahead and prepare the release (with luratech built in) and post it for anybody to play with. That way if it is OK, then chrisl can do the release his Monday AM | 19:15.18 |
| | which is closer to cust 850's TZ | 19:15.35 |
| Robin_Watts | Does the cluster look jammed to anyone else ? | 19:15.45 |
| ray_laptop | Robin_Watts: how long has it been waiting in that state ? | 19:16.24 |
| Robin_Watts | At least 5 minutes. | 19:16.40 |
| ray_laptop | I see an abort on miles (which tends to stay there) then waiting for x6 | 19:16.49 |
| Robin_Watts | me too. | 19:17.02 |
| | Time to SMS marcos. | 19:17.08 |
| | sent. | 19:18.30 |
| | He's looking. I'm going to walk the dogs. back in a bit. | 19:19.12 |
| ray_laptop | darn. latest and greatest 9.03 _still_ doesn't build luratech on 64-bit :-( | 19:45.21 |
| Robin_Watts | ray_laptop: Really? Same 'inline' problem, or different ? | 19:46.16 |
| ray_laptop | I'm seeing all of the asm errors | 19:46.35 |
| | all derive from: lwf_jp2\library\source\jp2_common.c(417) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture | 19:47.24 |
| | Robin_Watts: do you know -- is it different for the amd64 mode ? | 19:48.35 |
| Robin_Watts | I don't know. | 19:49.21 |
| | "Inline asm is not supported by Visual C++ on 64bit-machines" apparently. | 19:50.01 |
| | That's true as of VS2008. | 19:50.04 |
| tkamppeter | Robin_Watts, I have reopened bug 691755. And I have uploaded 9.04 to Oneiric anyway, to get more testing. | 19:50.25 |
| Robin_Watts | tkamppeter: Thanks. | 19:50.33 |
| ray_laptop | well, I'm using 2005, so it apparently is a problem there too | 19:50.47 |
| Robin_Watts | That'll be top of my list after this planar st | 19:50.51 |
| | uff. | 19:50.56 |
| chrisl_away | ray_laptop: I don't think that's the "latest and greatest", that's the error I got without the changes in msvc.mak | 19:51.06 |
| Robin_Watts | ray_laptop: Yeah, supposedly it wasn't even in VS2010. | 19:51.15 |
| | VS2010 Beta 1 at least. Dunno if it made it in the relase. | 19:51.28 |
| henrys | ray_laptop:I assume you are using win64 project file? | 19:52.29 |
| | lwf_jp2/library/win64 | 19:53.12 |
| ray_laptop | Robin_Watts: the build does not use the project file | 19:53.38 |
| chrisl | ray_laptop: if you look in msvc.mak, the luratech CFLAGS should have -DWIN64 in them for the WIN64 build | 19:54.43 |
| ray_laptop | chrisl: Hi. it doesn't. I'm looking at 9.03 and it has: | 19:57.03 |
| | !ifndef JBIG2_CFLAGS | 19:57.04 |
| | # required compiler flags | 19:57.06 |
| | JBIG2_CFLAGS=-DUSE_LDF_JB2 -DWIN32 | 19:57.08 |
| | !endif | 19:57.09 |
| chrisl | Well, that's not the latest, then. | 19:57.24 |
| ray_laptop | chrisl: I just did a git up :-( | 19:58.11 |
| Robin_Watts | http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=10fa3cdcae73e526d6279e5a70522d821d08469d | 19:58.56 |
| ray_laptop | and it says "current branch master is up to date." | 19:59.02 |
| Robin_Watts | or rather: | 19:59.31 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=gs/psi/msvc.mak;h=bbd8c212394ad467f27af49b03f96fcfda1713ad;hp=9ef97dc4caa41ff07d5f9171033488742ee2a75b;hb=2711662696407b82c2d382ae85567a5bd67f2037;hpb=673fae8b1154641fa2cf1f434fed484f930a5687 | 19:59.32 |
| | ray_laptop: Right. You're on master | 19:59.39 |
| | You want to be on ghostpdl-9.03 presumably? | 20:00.01 |
| ray_laptop | Robin_Watts: I did a git archive ghostscript-9.03 | 20:00.07 |
| chrisl | hmm, master should have that change, too. | 20:00.13 |
| Robin_Watts | Right, but git up only updates master. | 20:00.24 |
| | chrisl: It does. The first link I gave is for master. | 20:00.32 |
| | The second for ghostpdl-9.03 | 20:00.37 |
| chrisl | Yes, I meant Ray should see the change, even though he's on master. | 20:00.53 |
| ray_laptop | right. if I do a ghostscript-9.03 then I get the bad msvc.mak | 20:00.55 |
| | chrisl: I think the tag is wrong (or the branch didn't get that patch) | 20:01.23 |
| chrisl | ray_laptop: we need to force your git to update it's tags from casper - but I can't remember how. | 20:02.02 |
| ray_laptop | the tag I see is: 673fae8b1154641fa2cf1f434fed484f930a5687 | 20:02.30 |
| chrisl | The tag on casper is commit: 2711662696407b82c2d382ae85567a5bd67f2037 | 20:02.49 |
| Robin_Watts | git fetch works for me. | 20:03.04 |
| ray_laptop | This is rather stoopid of git | 20:03.12 |
| chrisl | ray_laptop: actually, it's my fault, I shouldn't have shared the tag until I was sure it was right :-( | 20:03.39 |
| ray_laptop | Robin_Watts: what do I do after git fetch ? | 20:04.01 |
| Robin_Watts | Well, you should hopefully see lines in the fetch like: | 20:04.23 |
| ray_laptop | git fetch didn't return anything | 20:04.36 |
| Robin_Watts | 5362c51..2711662 ghostpdl-9.03 -> origin/ghostpdl-9.03 | 20:04.36 |
| | 9be999c..10fa3cd master -> origin/master | 20:04.38 |
| | * [new branch] mooscript -> origin/mooscript | 20:04.40 |
| | * [new tag] ghostpdl-9.03 -> ghostpdl-9.03 | 20:04.41 |
| | * [new tag] ghostscript-9.03 -> ghostscript-9.03 | 20:04.43 |
| | Type: git name-rev 2711662 | 20:05.09 |
| ray_laptop | I had seen the new branch message earlier today when I did a pull --rebase | 20:05.12 |
| Robin_Watts | Hopefully you should get: 2711662 remotes/origin/ghostpdl-9.03 | 20:05.31 |
| ray_laptop | 2711662 remotes/origin/ghostpdl-9.03 | 20:05.37 |
| Robin_Watts | Right, so: git checkout ghostpdl-9.03 | 20:05.54 |
| chrisl | that's the branch, though | 20:06.19 |
| ray_laptop | Robin_Watts: but git rev-parse ghostscript-9.03 gives: 673fae8b1154641fa2cf1f434fed484f930a5687 and git rev-parse ghostpdl-9.03 gives: warning: refname 'ghostpdl-9.03' is ambiguous. | 20:07.09 |
| | 673fae8b1154641fa2cf1f434fed484f930a5687 | 20:07.11 |
| Robin_Watts | ray_laptop: What OS are you on here ? | 20:07.22 |
| ray_laptop | Windows | 20:07.27 |
| chrisl | ray_laptop: try "git fetch origin :refs/tags/ghostscript-9.03" | 20:07.45 |
| ray_laptop | git version 1.7.4 | 20:07.49 |
| Robin_Watts | git fetch --tags ? | 20:08.07 |
| ray_laptop | OK. that gave: | 20:08.28 |
| | From ghostscript.com:/home/git/ghostpdl | 20:08.33 |
| | - [tag update] -> ghostscript-9.03 | 20:08.34 |
| Robin_Watts | Ah. That sounds better. | 20:08.43 |
| | Being called for food, sorry. | 20:08.58 |
| ray_laptop | but git rev-parse ghostscript-9.03 now gives: 10fa3cdcae73e526d6279e5a70522d821d08469d | 20:09.08 |
| chrisl | ray_laptop: that's what rev-parse gives me, too. | 20:09.28 |
| ray_laptop | OK. I thought it was supposed to be 2711662 | 20:10.03 |
| chrisl | I think that's the hash for the tag object, rather than the tree being tagged | 20:10.15 |
| ray_laptop | too much SHA1 sh*t | 20:10.47 |
| chrisl | if you now do git checkout ghostscript-9.03 and have a look in msvc.mak for the luratech changes | 20:11.00 |
| ray_laptop | chrisl: so, did you sneak in a WINDOWS_NO_UNICODE change as well ??? | 20:12.46 |
| chrisl | ray_laptop: that was on Wednesday, I think. Should only be for VC7 | 20:13.18 |
| ray_laptop | suprising that didn't show up in my (only slightly out of date tag) ghostscript-9.03 | 20:14.05 |
| | OK. cleaning the directory and trying yet again ... | 20:14.21 |
| chrisl | Sorry about all this. This is why they say there are certain things you can change all you like on the local repos, but really don't once it's pushed upstream. | 20:15.24 |
| ray_laptop | I guess tags is one of those, but that's rather disappointing | 20:16.03 |
| chrisl | Well, it's why I want to get into the practice of letting things stablise on a branch, then tag, rather than moving the tag, which we shouldn't really do on any system! | 20:17.20 |
| | ray_laptop: the NO_UNICODE was the VC7 build failure that Alex stumbled over the other day. | 20:18.00 |
| | ray_laptop: I'm going to mosey downstairs and try to relax a bit, but I'll be keeping an eye on the logs for another hour or so - if you scream loud enough, I'll hear ;-) | 20:20.53 |
| ray_laptop | Hurray!! looks like it built BOTH 32 and 64 bit binaries and installer packages | 20:42.56 |
| chrisl | ray_laptop: that's a relief - I really am going to call it a night now! | 20:49.19 |
| ray_laptop | chrisl: well, the "install" had a problem -- gswin32c died while trying to do the cidfmap step (for CJK fonts) | 20:50.21 |
| | hmm... the 32-bit build aborts. The 64-bit build runs :-/ | 20:52.03 |
| chrisl_away | I definitely had the cidfmap stuff working for 9.02 :-( | 20:52.44 |
| ray_laptop | building for debug ... | 20:52.45 |
| | not just the cidfmap -- it dies just trying to start gswin32c | 20:53.05 |
| | chrisl_away: please leave -- I don't want you having nightmares about this ;-) | 20:54.05 |
| chrisl_away | Thanks, I'll leave it to you, then. Leave a message here or by e-mail if you need me to look at something. | 20:54.29 |
| ray_laptop | chrisl_away: sure. Have a good evening | 20:55.19 |
| | it's probably caused by git anyway ;-) | 20:55.51 |
| Robin_Watts | ray_laptop: The clist calculations for pattern size are the same at both ends. | 21:00.54 |
| | It's the non clist ones that differ. | 21:01.00 |
| ray_laptop | Robin_Watts: right. | 21:01.35 |
| | but strange. | 21:01.43 |
| ray_laptop | wonders if we should just drop support for 32-bit builds ;-) | 21:02.02 |
| Robin_Watts | Damn. My pattern cache size changes are causing timeouts. Must be some infinite loops. will look tomorrow. | 21:21.30 |
| ray_laptop | echoing Robin_Watts' sentiments. The 9.03 bomb seems to be related to WINDOWS_NO_UNICODE | 21:36.55 |
| | look above for my comment about chrisl sneaking that in | 21:37.33 |
| Robin_Watts | Interesting. Just got a reply about Crystal RIP. | 23:50.57 |
| | He says "FYI Crystal RIP is GPL but ATM we're only distributing it with the machine - no internet download currently". | 23:51.48 |
| | Assuming they are giving the source out with every machine they sell, I think that follows the GPL. | 23:52.10 |
| | Forward 1 day (to 2011/07/16)>>> | |
IRC Logs