| | <<<Back 1 day (to 2011/07/26) | 2011/07/27 |
| henrys | Robin_Watts:is there an easy way to get a bmpcmp on something already committed? | 02:01.53 |
| | I can just use the local script I guess. | 02:02.42 |
| mvrhel2 | hmm I wonder if I have a broken build checked out | 04:31.36 |
| | ok. fetching appears to have fixed the issue | 04:35.07 |
| | good morning Robin_Watts | 06:02.07 |
| | henrys: cluster pushing my fix for the display device (and a rename of the device parameter to set and unset the use of Gray To K) | 06:07.07 |
| | ok. two nodes down. time for bed... | 06:16.04 |
| kens | Morning chrisl | 07:10.07 |
| chrisl | good morning kens | 07:12.06 |
| kens | I see henrys had to fix the build for me last night. | 07:12.17 |
| chrisl | Yep, I have had that a couple of times: some editors *really* don't like writing out tabs :-( | 07:12.49 |
| kens | The problem was that Git GUI wouldn't let me commit devs.mak with a tab in it, and make doesn't work if its spaces instead of a tab (!) | 07:12.49 |
| | My original commit had a tab :-( | 07:13.05 |
| chrisl | That's strange, I don't think I've had that problem - only trailing whitespace. | 07:13.47 |
| kens | It complained about a 'tab in indent'. | 07:14.03 |
| | I'm fairly sure Tor made those illegal | 07:14.21 |
| chrisl | Well, that would need changed! | 07:14.43 |
| kens | Its OK for C files :-) | 07:14.58 |
| | Next time I think I'll let you sort out the build...... | 07:15.14 |
| chrisl | Gee, thanks! | 07:15.52 |
| kens | Well, it took me about an hour to make the changes, and the rest of the day (and half the evening) to beat the build system and Git into submission. Only to fall into the tab problem. | 07:16.32 |
| | I will admit that's partly because gcc complained about my C constructs (VS didn't) and because I wanted the dependencies to work properly. | 07:17.48 |
| chrisl | I couldn't guarantee being any quicker! | 07:18.44 |
| kens | I'm sure you'd have got the make stuff done faster. | 07:18.57 |
| chrisl | possibly, it can be awfully counter intuitive, though | 07:20.22 |
| kens | But you mess with make more than me, so you're bound to be more familiar with it. | 07:20.48 |
| chrisl | True enough | 07:21.33 |
| kens | chrisl Ian just sent me this link: | 07:52.27 |
| | http://www.independent.co.uk/news/uk/home-news/exec-banned-from-soho-house-ndash-for-wearing-a-suit-2326578.html | 07:52.27 |
| chrisl | How very bizarre! | 07:55.13 |
| kens | Obviously you can only express your creativity by wearing the right uniform :-) | 08:04.39 |
| chrisl | He should turn up in a gimp outfit, see if they think that projects the "relaxed, casual" environment they want..... ;-) | 08:07.33 |
| kens | Hmm, or a furry ? :-) | 08:07.47 |
| chrisl | Fashion fascists are just annoying - I'd close the place....... | 08:09.45 |
| kens | Certainly one for the Groucho Marx 'I wouldn't join any club that would have me' :-) | 08:10.18 |
| | OK ray's fix for the semaphores does indeed fix the handle leaking problem for me. | 08:53.51 |
| chrisl | kens: Are we still leaking from elsewhere, then? | 08:55.02 |
| kens | Not as far as I can tell, no. | 08:55.13 |
| | The number of handles in the system (which is what Process Explorer actually measures) is stable throughout the run of the customer's application. | 08:55.51 |
| | Also 'handle.exe' says we aren't leaking either. | 08:56.05 |
| | THe handles in use remains constant at (IIRC) 5. | 08:56.18 |
| chrisl | Okay, so I should pull that into the 9.04 branch, then | 08:56.28 |
| kens | I guess so, yes, its quite a safe looking fix, three lines of code. | 08:56.49 |
| chrisl | I'll do that later, I've got squash training now. | 08:57.07 |
| kens | Just be careful not to get it mixed up with my Adobe Glyph List change, which got committed together | 08:57.10 |
| chrisl | The got pushed together, but still separate commits. | 08:57.53 |
| kens | Yes, they hav separate SHA numbers | 08:58.04 |
| | I had forgotten I'd applied Ray's patch, and Git GUI didn't show it to me. | 08:58.32 |
| | The patch ended up 'committed', whcih wasn't entirely what I expected. | 08:58.52 |
| chrisl | I think git apply makes a commit unless you tell it not to. | 08:59.04 |
| kens | Exactly | 08:59.11 |
| chrisl | Yep, fell over that one myself a couple of weeks ago! | 08:59.24 |
| | Right, off to squash...... | 08:59.37 |
| kens | Well it wasn't disastrous, and it was a learning experience (another one) | 08:59.45 |
| Robin_Watts | ooh, another funky xkcd graph. | 09:27.56 |
| | Seems clear that Wednesday is, in fact, Ladies night, and Church is best kept for sunday. | 09:30.18 |
| tor8 | oh bother, anyone else noticed the new google hosting for artifex.com changes today? | 12:17.18 |
| kens | Yes, I just got prompted to accept terms and conditions on login | 12:17.34 |
| tor8 | mmm, and then I got prompted to sign out of my private gmail account⦠it used to be they were separate logins, not anymore :( | 12:18.02 |
| | only one can be signed in at a time | 12:18.09 |
| kens | THat seems like a backward step | 12:18.20 |
| tor8 | indeed. grr. | 12:18.50 |
| kens | tor8 Robin_Watts is there some nice way to view hte history of a file in Git ? I knwo I can do git log -- filename, is there anything else ? | 13:05.54 |
| tor8 | git log filename is what I use. there's also git blame and "gitk filename". | 13:11.15 |
| Robin_Watts | I personally use gitweb. | 13:11.38 |
| kens | I guess I can live with log. I have to generate patches too, becaus eI need to see the code, and it keeps finding hits on the spacing changes. | 13:11.55 |
| tor8 | don't forget --follow to follow file renames | 13:11.58 |
| kens | So how do I use gitweb ? | 13:12.04 |
| Robin_Watts | Easiest way, is to go the dashboard, and click on a link. | 13:12.27 |
| kens | OK | 13:12.33 |
| kens | goes to try | 13:12.38 |
| Robin_Watts | That takes you to a commit. | 13:12.46 |
| kens | Yes | 13:12.55 |
| tor8 | kens: git log -w should ignore whitespace changes | 13:12.57 |
| Robin_Watts | Then at the top, pick 'tree', and navigate to a file. | 13:12.59 |
| | blame is the view I find most useful. | 13:13.15 |
| | but history may be what you want. | 13:13.33 |
| kens | Possibly, I know the blame is mine :-) | 13:14.03 |
| | history looks good | 13:14.24 |
| | <sigh> But no source :-( | 13:14.51 |
| | Ah, diif | 13:15.13 |
| | Damned customers. Wants a patch to undo code written over the space of months, up to 2 years ago. | 13:17.03 |
| chrisl | alexcher: I tested Bug 692309 and it is fixed by Ray's 10cd4a - "Fix for missing ICCProfilesDir during some device init. Move profiledir to gs_lib_ctx." | 15:02.25 |
| Robin_Watts | Need to talk to mvrhel2 about this SEGV. | 15:04.02 |
| alexcher | chrisl: grest | 15:07.07 |
| chrisl | alexcher: do you want me to close the bug? | 15:08.31 |
| alexcher | chrisl: yeas, please. | 15:10.05 |
| henrys | alexcher is the other bug critical? | 15:10.27 |
| alexcher | henrys; it is not a regression. | 15:11.25 |
| | henrys; gs uses too much memory for snooth shadings. | 15:12.01 |
| | henrys; my attempts to reclaim memory using --restore-- uncovered a bug in memory management. | 15:13.06 |
| kens | henrys thanks for fixing that make problem. Git GUI insisted I change the tab before it would let me commit the make file. :-( It was late and I hadn't realised it would cause a buld failure. | 15:13.11 |
| Robin_Watts | alexcher: But the bug is not that it's using too much memory, it's that it's SEGVing, right? | 15:13.23 |
| henrys | kens:np I am really surprised that doesn't happen more often if nmake allows spaces. | 15:14.31 |
| kens | henrys I didn't try it with nmake. Everything had tested out OK, so I went to commit, and Git GUI insisted I change the 'tab in indent' to spaces. | 15:15.05 |
| | Which I did, and because I was tireed, didn't think about it. | 15:15.19 |
| alexcher | Robin_Watts: yes, gs need to process low memory conditions correctly. This is a 3rd problem. | 15:15.43 |
| henrys | kens:well the windows build uses it we are still using the makefiles behind the scenes right? | 15:16.27 |
| kens | Absolutely, yes, but I didn't try a rebuild after making the change that Git GUI insisted on. | 15:16.50 |
| | I just assumed it would be OK, after all its just a white-space change...... | 15:17.08 |
| henrys | ahh | 15:17.14 |
| | kens:your customer is getting into "no land" | 15:18.01 |
| kens | henrys I'm thinking that too. | 15:18.13 |
| | One change isn't too bad, but these are several changes, done over the course of 2 years. | 15:18.33 |
| | I'm getting uncomfortable with the changes. | 15:18.47 |
| kens | just closed a 5 year old bug :-) | 15:20.56 |
| henrys | alexcher where is the segv? | 15:22.12 |
| | you could take a very long time to fix the low memory condition - somebody else should probably be looking at the SEGV | 15:22.49 |
| | right? | 15:22.57 |
| Robin_Watts | Does anyone know why gxclip.c calls gx_default_fill_path, rather than gx_forward_fill_path ? | 15:23.08 |
| henrys | or is it a language problem? | 15:23.10 |
| kens | henrys I've done what I *think* will address the customer's problems, I have put some serious caveats in the email. Do you want to look at it before I send it to them ? Its not as simple as a patch I'm afraid. | 15:23.36 |
| henrys | gxclip.c doesn't call anything ;-) | 15:23.43 |
| Robin_Watts | Does anyone know why the clipper device defined in gxclip.c uses gx_default_fill_path as a device proc, rather than gx_forward_fill_path ? | 15:24.20 |
| henrys | Robin_Watts:that is odd, did you check history? | 15:26.47 |
| Robin_Watts | not yet. will do. | 15:27.02 |
| | I had a thought about the CMAP stuff last night. Don't know if it's completely stupid or not. | 15:34.23 |
| | gs holds the CMAP stuff in ROM in one format. When it's required, "it executes it" to unpack it into memory, so it can use it. This means we take a hit in both ROM and RAM. | 15:35.04 |
| | Would it be possible for us to just keep the CMAPs in ROM in the most compact format we know about (like mupdf does), and have a special 'lookup value x in cmap y' operator ? | 15:36.16 |
| | We'd probably need a "lookup cmap number from name" operator too. | 15:36.59 |
| henrys | FWIW we are well below the customer's request now. | 15:37.28 |
| Robin_Watts | Sure, but less memory is always good. | 15:38.14 |
| henrys | you found the bug right? | 15:38.42 |
| Robin_Watts | no. | 15:39.16 |
| henrys | 692335 you were asking yesterday | 15:39.28 |
| Robin_Watts | This clip device stuff dates all the way back to SVN revision 25 when the file was added from new. | 15:39.43 |
| | There look to be lots of gx_defaults which I would have thought should all be gx_forwards. | 15:40.32 |
| | Do we have any history that dates back before SVN ? | 15:40.51 |
| henrys | you can find old tar.gz's on the web I've been meaning to collect them, someone else might have done so. | 15:41.32 |
| Robin_Watts | but we don't have a cvs repo or something from before SVN ? | 15:42.24 |
| chrisl | Robin_Watts: re. CMAPS: In your proposal, how would we handle a job that interrogates the contents of a CMap as a "normal" resource dictionary? | 15:42.36 |
| Robin_Watts | chrisl: Do we ever get that ? | 15:42.49 |
| chrisl | Yes | 15:42.59 |
| Robin_Watts | I understood that CMAPs were (mostly) only used for PDFs ? | 15:43.04 |
| chrisl | Nope | 15:43.10 |
| henrys | I think everything from cvs was captured in svn - before that we just exchanged tar balls back and forth. | 15:43.17 |
| Robin_Watts | henrys: right. | 15:43.33 |
| chrisl | Robin_Watts: Well, they are more widely used for PDF, but I've seen plenty of PS jobs that load CMaps and poke around inside. | 15:44.02 |
| kens | General heads up. I'll be out tomorrow, and am taking a week vacation starting on 3rd August through to the 10th August (including both). | 15:44.40 |
| Robin_Watts | kens: So you're here monday and tuesday next week ? | 15:45.15 |
| kens | Indeed. I'll be around for the Tuesday meeting | 15:45.33 |
| | Very modern looking hotel Miles has booked. | 15:45.48 |
| Robin_Watts | I'm off on the 8th for 2 weeks, so you won't see me for a while. Have a good one. | 15:45.59 |
| kens | You too :-) | 15:46.06 |
| Robin_Watts | chrisl: When you say "poke around inside", what do you mean? You mean they execute the CMAP file, then play with the datastructures created? Or they rely on the actual format of the file itself ? | 15:51.48 |
| chrisl | Robin_Watts: they rely on what pops out of a findresource being a Postscript dictionary which they can interrogate/copy/modify etc | 15:53.01 |
| Robin_Watts | chrisl: Right. | 15:53.29 |
| chrisl | Robin_Watts: So it doesn't stop us doing what you suggest, we just need to also need to create an appropriate PS dictionary from the internal representation. | 15:54.10 |
| Robin_Watts | So... we could keep the CMAPs in ROM in the most compact form we know about, and have the operators I described for the PDF interpreter to use, but we'd also need some magic to make findresource work. | 15:55.00 |
| kens | findresource absolutely has to work, or the magic CIDFON+CMAP won't work. | 15:55.41 |
| Robin_Watts | peeves disc is full, I think. | 15:55.42 |
| chrisl | Robin_Watts: yes. I'll admit it's not common (PS jobs usually have CMaps embedded) but, as I say, it's not unheard of for PS to use "built in" CMaps, and it would be bad to have something not work that previously did. | 15:56.40 |
| kens | Our 'substitute a TrueType font for a missing CIDFont' won't work unless the CMap can be found via findresource. | 15:57.45 |
| | OK I'm off, see you all on Friday :-) | 16:00.01 |
| mvrhel2 | is the build broken? | 16:00.02 |
| kens | Was, shouldn't be now. | 16:00.10 |
| mvrhel2 | I just did a clean cluster push that failed | 16:00.16 |
| Robin_Watts | mvrhel2: peeves disc is full, so cluster pushes have been failing. | 16:00.25 |
| | I just disabled peeves in the cluster. | 16:00.30 |
| mvrhel2 | oh | 16:00.33 |
| | ok that explains it | 16:00.37 |
| | so I should retry then? | 16:00.46 |
| Robin_Watts | Yes | 16:01.01 |
| | but I just got in in front of you, sorry. | 16:01.13 |
| mvrhel2 | oh | 16:01.20 |
| | trying to get this fix in for the display device | 16:01.26 |
| | ran the push last night to find that it failed with peeves timesouts | 16:01.49 |
| Robin_Watts | I'm testing a bug for 692368, the pattern clist transparency SEGV. | 16:02.18 |
| | It's a file rendering with banding. | 16:02.33 |
| | In one of the bands it tries to use a clist for a transparent pattern. | 16:03.00 |
| | and it's getting through to the tiling routines without the fill_trans_buffer being setup. | 16:03.18 |
| mvrhel2 | weird | 16:03.28 |
| Robin_Watts | Indeed, but I think I found out why. | 16:03.44 |
| | The "clipper" device that gets put on the device stack, calls gx_default_fill_path, not gx_forward_fill_path. | 16:04.17 |
| | So we don't go through pdf14_fill_path, hence we don't set up fill_trans_buffer. | 16:04.33 |
| henrys | alexcher:did you get my message? - there really is no language problem with this bug next step is to give it to Robin_Watts to look at the shading algorithm. | 16:04.43 |
| ray_laptop | I noticed that ken and Robin_Watts have vacation planned, so thought I'd remind everyone that I also will be on vacation from Aug 2nd and return on the 16th. I'll have internet part of the time, but none at all the 7th - 11th. | 16:14.40 |
| | I sent an email about it a while ago, but will send a reminder so everyone knows. | 16:15.23 |
| chrisl | Eek, so around the 5th of August is just a *great* time to have to do a release :-( | 16:15.28 |
| henrys | chrisl:what about getting it out early? | 16:16.08 |
| chrisl | henrys: I assume we want at least one release candidate, and we still have a blocker bug, I'm not even confident of the 5th right now! | 16:16.56 |
| henrys | mvrhel2 has a fix right? | 16:17.38 |
| mvrhel2 | I do | 16:17.49 |
| | waiting for the clusterpush to go through | 16:17.56 |
| chrisl | henrys: if mvrhel2 's fix is good, then I could do a release candidate tomorrow. | 16:18.26 |
| henrys | anything due tkamppeter? | 16:18.26 |
| mvrhel2 | I am hoping to wrap this up this morning as I am out this afternoon | 16:18.49 |
| | if I can't then it will have to be this evening | 16:18.56 |
| henrys | chrisl that would be good. | 16:19.19 |
| Robin_Watts | ray_laptop: Going anywhere nice? | 16:19.39 |
| | ray_laptop: Peeves disc is full. | 16:20.33 |
| | ray_laptop: Hence I've taken it out of the cluster. | 16:20.42 |
| ray_laptop | Robin_Watts: we are going to Florida (Orlando area) then a 4 day cruise to the Bahamas. My mom and dad are doing this for our whole family | 16:20.55 |
| | Robin_Watts: I'll look into it... | 16:21.03 |
| | 1.5Tb doesn't go as far as it used to :-( | 16:21.20 |
| Robin_Watts | ray_laptop: ooh, nice. | 16:21.31 |
| henrys | ray_laptop must like heat | 16:21.47 |
| mvrhel2 | chrisl: so you need to pull in the profile changes | 16:21.48 |
| chrisl | mvrhel2: will do | 16:22.14 |
| ray_laptop | actually peeves is 1Tb (3x500Gb in a RAID 5) | 16:22.26 |
| mvrhel2 | there is one for the CMYK profiles and one for the gray profiles | 16:22.27 |
| henrys | the cruise should be comfortable though | 16:22.31 |
| | I can't believe I picked Graph Expo year to vacation in Chicago. | 16:23.22 |
| chrisl | mvrhel2: which commit is the gray profile one? | 16:25.23 |
| henrys | Robin_Watts:I guess alexcher isn't around can you have a look at the shading issue? It seems odd evince seems to do okay with it. | 16:25.40 |
| Robin_Watts | henrys: I will do. | 16:26.23 |
| | I'm testing the minimal fix to gxclip.c now. | 16:26.33 |
| | Can anyone think of a reason why I shouldn't make ALL the gx_default_ calls go to gx_forward ones ? | 16:26.56 |
| mvrhel2 | chrisl: the most recent commit | 16:27.48 |
| chrisl | mvrhel2: ah, thanks! | 16:28.05 |
| henrys | Robin_Watts:I can't if this isn't a fix for the release I can. | 16:28.10 |
| Robin_Watts | henrys: Trying to parse that :) You'd prefer a minimal fix for the release? | 16:29.48 |
| | but a full fix after that ? | 16:29.58 |
| henrys | I don't think we should make that change in the release but it is fine for trunk. | 16:30.42 |
| ray_laptop | Robin_Watts: I'd think a minimal fix for the release would be best, then study the overall change later | 16:31.04 |
| Robin_Watts | Right. | 16:31.16 |
| ray_laptop | Robin_Watts: so to allow us to cherry-pick to the 904 branch, the minimal fix would have to be a separate commit. | 16:31.47 |
| Robin_Watts | Assuming the current clusterpush (the minimal fix) passes, I'll commit/push it, and chrisl can cherry pick it in. | 16:31.55 |
| henrys | I didn't think the default->forward change belonged in the release. | 16:32.06 |
| chrisl | henrys: the item that we didn't quite resolve for the release was the Windows Unicode issue: I'm concerned, given Ray's input, about changing the API without notice. | 16:32.27 |
| Robin_Watts | Then I'll do a clusterpush of the full default->forward change and if that passes, leave it on the trunk. | 16:32.29 |
| | henrys: Without the minimal default->forward change, we'll certainly be introducing SEGVs as a regression. | 16:33.07 |
| henrys | my vote now is to go with no unicode until sags is fully heard. | 16:33.55 |
| | Robin_Watts:oh I didn't realize that. | 16:34.30 |
| | I don't consider any change to the devices procedure table minimal ... | 16:34.59 |
| Robin_Watts | henrys: The pattern transparency clist stuff (new to 9.03 and 9.04) is what caused this to show up. | 16:34.59 |
| ray_laptop | henrys: I would be more comfortable with that for the release, then announce our intent to change the Windows default on the next release | 16:35.00 |
| chrisl | henrys: I take sags's point, but if we accept it fully, we cannot ever support UNICODE on Windows - we'd never get away with forcing wchar data through Postscript. | 16:35.19 |
| henrys | chrisl:well when sags presents his argument we'll have the discussion. | 16:35.55 |
| | he claimed to have a general solution that would work for all - but I don't see how that is possible. | 16:36.41 |
| Robin_Watts | chrisl: I think what sags is asking for is that on windows, we should make all the gsapi entrypoints that currently take a char *string, automatically utf8 encode those strings from extended ascii to utf8. | 16:37.21 |
| | and to also have unicode equivalents of those calls. | 16:37.31 |
| henrys | Robin_Watts:change the device procedure table in a forwarding device potentially effect every device in the system we need to test x11, display on and on. | 16:37.42 |
| | at least it should go through marcosw_ weekly test before release. | 16:37.59 |
| Robin_Watts | That way all existing windows code would continue to work. | 16:38.14 |
| chrisl | Robin_Watts: I'm really against the two APIs business, personally | 16:38.26 |
| Robin_Watts | Me too. | 16:38.34 |
| henrys | fine than you'll outvote sags but let's hear him out. | 16:38.52 |
| | and do this release without the change. | 16:39.15 |
| Robin_Watts | His argument is that our code has currently had the behaviour of "accepting strings in whatever the normal encoding for the platform is". | 16:39.18 |
| ray_laptop | well, if customers agree with you they may start switching over by rebuilding 9.04 (or using the with-unicode pre-built binary) | 16:39.36 |
| chrisl | Windows doesn't have a "normal" encoding, I'd argue. | 16:39.48 |
| Robin_Watts | and we'd be changing that to be "accepting strings in utf8 format everywhere". | 16:39.54 |
| | I'd personally be in favour of changing, but I can understand his argument. | 16:40.16 |
| ray_laptop | Robin_Watts: the important word in that is "changing" (in an incompatible way) | 16:40.27 |
| Robin_Watts | I think on balance, shipping with WINDOWS_NO_UNICODE and warning people is the smart way to go. | 16:40.44 |
| henrys | great | 16:40.58 |
| Robin_Watts | Then, when we get the inevitable no feedback, we can change the default for next time, and get lots of complaints. | 16:41.16 |
| ray_laptop | I think if we put the planned change of the default in the 9.04 (and Scott's newletter) then we can change the default on 9.05 | 16:41.17 |
| Robin_Watts | ray_laptop: Yeah. | 16:41.52 |
| chrisl | We can't really announce the change in this release if we are waiting to hear what sags has to say :-( | 16:41.57 |
| henrys | moving on to the so called "minimal change" what blocker does that fix? | 16:42.03 |
| ray_laptop | there should be 2 newsletters -- one right after 9.04 and another 3 mo later | 16:42.10 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=692368 | 16:42.16 |
| henrys | shit we do need that. | 16:42.45 |
| Robin_Watts | chrisl: We can announce it as an experimental feature, and encourage people to test it now. | 16:42.45 |
| | And we can state that if it tests out OK, we plan to change that to be the default, possibly as soon as 9.05 | 16:43.18 |
| ray_laptop | chrisl: we can announce the availability of Windows with UTF-8 and the plan to change in the next release w/o waiting for sags (IMHO) | 16:43.30 |
| Robin_Watts | That way we haven't committed to it, but we have stated our intent. | 16:43.55 |
| ray_laptop | and I think we should say that we will maintain the WINDOWS_NO_UNICODE indefinitely for those that need it | 16:44.06 |
| chrisl | Okay, I will do that. | 16:44.46 |
| henrys | anyone know how other programming languages developed with linux roots deall with this when going to windows, perl, python etc.? | 16:47.38 |
| ray_laptop | Robin_Watts: I've cleaned up space on peeves. The problem was /dev/sda1 I thought I had moved /tmp over, but I guess not. | 16:48.39 |
| Robin_Watts | ray_laptop: OK. peeves should be back in the cluster now (from the next job) | 16:49.22 |
| ray_laptop | most of it was left over gs_***** files from jobs that aborted | 16:49.54 |
| chrisl | henrys: this is more an API issue than a language issue - but I don't think we want to extend Postscript to understand wchars | 16:50.35 |
| ray_laptop | chrisl: that's what I understand as well | 16:50.55 |
| henrys | I am not talking about the language per se - perl and python have to read filenames and take options also. | 16:51.14 |
| tkamppeter | henrys, you mean a release candidate for 9.04 tomorrow? | 16:51.43 |
| ray_laptop | PS has it's 'symbol set' encoding that says how strings are encoded and filenames in PS are just passed through to the OS | 16:51.45 |
| henrys | maybe a simpler question - the original file that started all this was a postscript file in a directly with unicode characters - if that were a perl program would it work with windows perl. | 16:53.37 |
| | ? | 16:53.53 |
| Robin_Watts | henrys: "it was a postscript file in a directory with unicode chars in its name"? | 16:54.26 |
| | If perl was built with a wmain, rather than a main, yes. | 16:54.43 |
| | or was build with a WinMain and UNICODE defined. | 16:55.03 |
| | And indeed, ghostscript now copes because we have a wmain, so we get wchar's in, and I utf8 encode them before calling the core. | 16:56.26 |
| henrys | I am just trying to understand how the perl, python etc. folks resolved this. perl is normally distributed as a binary on windows what is the default. | 16:56.32 |
| | ? | 16:56.33 |
| Robin_Watts | There is no default. You either define UNICODE or you don't. | 16:57.02 |
| | I rather suspect they will define UNICODE though. | 16:57.21 |
| | The problem with gs is that we have this alternative set of entry points, gsapi. | 16:57.46 |
| henrys | I just thought it might be worthwhile to look at these languages, they have huge user bases on windows much larger than gs and have probably had more input, complaints from users than we are even considering. | 17:03.43 |
| Robin_Watts | We *could* define all new versions of the gsapi entrypoints. gsapi_blahANSI, gsapi_blahUNICODE, gsapi_blahUTF8 | 17:03.51 |
| | and then it would just be a matter of which one we made gsapi_blah point to. | 17:04.18 |
| chrisl | I suspect a better question would be "how do projects like Subversion and Git handle this stuff?": they have both a application and SDK elements, as we do. | 17:06.19 |
| Robin_Watts | Well, git does it by running under msys. | 17:06.45 |
| | so it's effectively under the same conditions as linux, I would imagine. | 17:07.01 |
| chrisl | Oh, cr*p, yes. Well, I was struggling to think of an example project that had both application and SDK aspects. | 17:07.51 |
| ray_laptop | Robin_Watts: we wouldn't need to clone all of the gsapi_ entry points with a UTF-8 variant (for Windows) just those few that take paths. the gsapi_run_string_continue doesn't change since that is sending data to the PS interpreter | 17:09.36 |
| henrys | another place to look is the adobe sdk for pdf? | 17:09.48 |
| | maybe we should just table this discussion until sags presents his discussion and solution. | 17:11.50 |
| tkamppeter | henrys, I have found another blocker now. I will report it now ... | 17:13.18 |
| henrys | ray_laptop:so it looks like it will be important for chrisl to know everything about doing a customer release before you go on vacatioin. | 17:14.31 |
| henrys | assumes the release is going to slip with tkamppeter last message. | 17:15.10 |
| Robin_Watts | FWIW: perl on windows doesn't seem to use UNICODE, and I can only see a main. | 17:15.24 |
| chrisl | henrys, ray_laptop: I think the only thing I'm missing is the commercial LICENSE file for ghostpdl, I *think* I have everything else I need. | 17:15.54 |
| ray_laptop | chrisl: I'll email the 'improved' script that has the two LICENSE data embedded... | 17:16.39 |
| chrisl | ray_laptop: super, thanks! | 17:16.50 |
| chrisl | thinks: ten year old Sun hardware is ssslllloooowwww :-( | 17:19.00 |
| tkamppeter | henrys, here we go: http://bugs.ghostscript.com/show_bug.cgi?id=692380 | 17:19.02 |
| henrys | tkamppeter:I really don't know I should have 692328 - I assume you want to test that in the cups pipeline right - I'm fine with the change itself. | 17:19.26 |
| Robin_Watts | tkamppeter: Bug 692380: has that ever worked ? | 17:20.19 |
| chrisl | Robin_Watts, tkamppeter: 8.71 give black boxes, too. | 17:21.07 |
| Robin_Watts | You say it fails in 9.01 and 9.04. It's only a blocker if it's previously worked and now it doesn't, right ? | 17:21.17 |
| tkamppeter | Robin_Watts, I have considered it blocker as a basic functionality does not work, then perhaps we should put it one level down. | 17:22.09 |
| Robin_Watts | tkamppeter: If it's never worked, then clearly people are no worse with the new release. Therefore it's shouldn't stop us releasing a new version. | 17:22.46 |
| | Having it work would clearly be nice though :) | 17:22.58 |
| tkamppeter | Robin_Watts, I do not know for how long this problem is there, the original bug report at Ubuntu is from today. | 17:23.05 |
| Robin_Watts | tkamppeter: chrisl reports it didn't work under 8.71 either, so that's a while ago. | 17:23.30 |
| henrys | tkamppeter:the title say when generating pdf - I guess they mean ps | 17:23.51 |
| Robin_Watts | henrys: It's a pdfwrite problem. | 17:24.36 |
| tkamppeter | henrys, the command line has z.ps as input and a.pdf as output. | 17:24.39 |
| | Robin_Watts, sorry, I picked the wrong component, I have corrected it now. | 17:25.33 |
| chrisl | Oh god, what a horrible file :-( | 17:25.34 |
| henrys | oh sorry I was looking at pdftops | 17:25.42 |
| chrisl | I'm sorry, but the cairo folk should be shot for files like this! | 17:26.18 |
| henrys | tkamppeter:what do you want to do about the "sed" issue. I think I've sed enough about at it ;-) | 17:26.20 |
| Robin_Watts | Damn. My simple gx_default -> gx_forward change causes significant cluster differences. I bet I need to write a new function :( | 17:26.52 |
| tkamppeter | bug 692329 has a patch, will it go into 9.04? | 17:27.47 |
| henrys | it is waiting for review from mvrhel2 and a test environment from marcosw_ | 17:28.54 |
| | I'll update the bug. | 17:28.58 |
| mvrhel2 | henrys: so my fix looks fine. I stumbled upon a bug in the gray to K where high level images were not getting converted properly. this commit will fix that too | 17:31.27 |
| chrisl | Hmmm, mkromfs.c doesn't build on Solaris/SPARC :-( | 17:34.10 |
| henrys | errand - be back in 20 minutes or so. | 17:34.43 |
| Robin_Watts | chrisl: What did I break? | 17:36.32 |
| chrisl | Robin_Watts: not sure yet...... | 17:37.37 |
| ray_laptop | chrisl: I don't see the gs904 branch -- any idea why not ? | 17:43.36 |
| | do I need to manually fetch branches or something ? | 17:44.06 |
| | git logg shows origin/904 | 17:44.39 |
| | git logg shows origin/gs904 | 17:44.42 |
| tkamppeter | Robin_Watts, yesterday you told that you wanted to work on a bug which I have talked about. Did you do so? | 17:44.56 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=692368 ? | 17:45.52 |
| | I'm looking at it now. | 17:45.59 |
| | I know what's going wrong, I just can't quite see how to solve it. | 17:46.15 |
| chrisl | ray_laptop: I don't know, try a git fetch? | 17:46.53 |
| Robin_Watts | henrys: ray_laptop: I think I actually need to write a proper device procedure for clip_fill_path. | 17:47.35 |
| | That is, when clip_fill_path is called, I need to repeatedly call the target fill path, but with its output restricted to each rectangle in the clip list in turn. | 17:48.32 |
| | And I can't immediately see how to do that. | 17:48.40 |
| | Any ideas? hints? | 17:48.51 |
| | Oh, I can probably make a new clipping path. | 17:49.54 |
| mvrhel2 | chrisl: so the most recent commit should be the blocker. I do need to update the docs still though and do a tiny bit of testing on a few things | 17:52.16 |
| chrisl | mvrhel2: I'll cherry-pick that commit now. | 17:53.24 |
| mvrhel2 | ok. I will try to get the docs finished up tonight | 17:54.29 |
| chrisl | Robin_Watts: this seems to be a bug in gcc 3.4.6 (maybe just on SPARC). It doesn't like: "(!psc->feof(psc->file))" but I have no idea why. | 18:01.25 |
| Robin_Watts | chrisl: Try (*psc->feof) ? | 18:02.02 |
| | (!(*psc->feof)(psc->file)) I mean. | 18:02.39 |
| tkamppeter | henrys, I have tried 692328. The script (CUPS filter) seems to be OK, building the expected GS command line, but GS chokes on usingf color management with the PXL driver. | 18:02.56 |
| | henrys, mvrhel2, this is the command line | 18:03.11 |
| chrisl | Robin_Watts: nope goes wrong differently - it also is fine with "psc->fgetc(psc->file)" | 18:03.48 |
| tkamppeter | gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=pxlcolor -sstdout=%stderr -r1200 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dMediaPosition=0 -dBitsPerPixel=8 -dDuplex=true -dTumble=false -sOUTPUTFILE=%stdout -c '<</.HWMargins[12 12 12 12] /Margins[0 0]>>setpagedevice' -f ~/ghostscript/testfiles/3-pages-test.pdf > y | 18:03.55 |
| | and it gives | 18:04.00 |
| | Unrecoverable error: rangecheck in .putdeviceprops | 18:04.14 |
| | sfopen: gs_parse_file_name failed. | 18:04.14 |
| | ./base/gsicc_manage.c:869: gsicc_open_search(): Could not find lab.icc | 18:04.14 |
| | | ./psi/zusparam.c:856: set_lab_icc(): cannot find default lab icc profile | 18:04.14 |
| Robin_Watts | chrisl: Try removing the ! then ? | 18:04.22 |
| tkamppeter | removing "-dBitsPerPixel=8" lets GS render without errors. | 18:04.47 |
| chrisl | I already did that, still fails: ./base/mkromfs.c:1389: error: syntax error before '(' token | 18:05.12 |
| | ./base/mkromfs.c:1389: error: syntax error before ')' token | 18:05.14 |
| | Robin_Watts: ^^ | 18:05.17 |
| mvrhel2 | great | 18:05.45 |
| tkamppeter | henrys, mvrhel2: ^^^^ | 18:05.49 |
| chrisl | tkamppeter: what happens without -dPARANOIDSAFER ? | 18:06.54 |
| Robin_Watts | is being called for food. | 18:06.55 |
| | sorry. | 18:06.58 |
| tkamppeter | chrisl, same error. | 18:08.02 |
| chrisl | tkamppeter: okay, just a thought. | 18:08.17 |
| tkamppeter | chrisl, henrys, mvrhel2, but I have found the following: "-dBitsPerPixel=8" works with "-sDEVICE=pxlmono". | 18:08.42 |
| henrys | so we're still having problems with finding icc profiles with compile inits 0 | 18:09.15 |
| | ? | 18:09.16 |
| tkamppeter | So this would mean that when a color printer is used (with cups/pxlcolor.ppd) then the option to switch between grayscale and color also needs to switch the device. Awkward. | 18:09.48 |
| | chrisl, henrys, mvrhel2: ^^ | 18:10.07 |
| henrys | I don't understand color printers use pxlcolor and mono pxlmono. | 18:11.42 |
| chrisl | tkamppeter: using your command line above, 8.71 gives me "Unrecoverable error: rangecheck in .putdeviceprops", too. | 18:18.23 |
| tkamppeter | henrys, it seems that pxlcolor is only capable of generating color and pxlmono only capable of generating Gray. BW printers print everything in gray, also when color is sent, color printer print how the stuff is sent. | 18:19.11 |
| | chrisl, henrys, mvrhel2, problem is solved, I have a simple patch for the filter now which switches the device if needed. | 18:19.59 |
| | A BW printer takes the output of pxlcolor and grayscales it. | 18:22.19 |
| henrys | yes you could use pxlcolor for BW printers but I think some operations will be more expensive. | 18:23.32 |
| tkamppeter | henrys, most probably slower as a 4 times bigger file needs to be converted down. | 18:24.17 |
| henrys | anyway let's focus on blockers and report other issues as enhancements or bugs as appropriate. | 18:25.16 |
| mvrhel2 | whew. | 18:25.48 |
| tkamppeter | henrys, this patch I will simply commit today, it is a simple bug fix. | 18:26.02 |
| henrys | tkamppeter:we're sort of in a hurry because a few people are going on vacation soon - best to bring problems to light before they leave. | 18:26.11 |
| | tkamppeter:okay | 18:26.25 |
| tkamppeter | henrys, the pstopxl script is OK now, I will commit it soon. If someone can help me in some hours if there is a commit problem, it is OK. | 18:29.14 |
| henrys | great | 18:30.38 |
| | tkamppeter:how are you liking git or do you not have to interact with it a lot? | 18:31.52 |
| tkamppeter | henrys, mvrhel2, now as the script is OK I would like if someone could check the patch of bug 692329 as the PXL files I get are huge and in many cases my printers simply run out of memory. | 18:31.54 |
| | henrys, I use git, but this is my first commit to GS, so I could get a "Permission denied" on git push. | 18:32.41 |
| | henrys, now you can do a nice DoS on network printers with the PXL drivers. | 18:33.39 |
| henrys | I think I could manage that with or without the patch ;-) | 18:35.10 |
| | the hope was marcos would set up a regression testbed for pxlcolor and mono I sent him email some time ago. | 18:36.16 |
| | we don't want to break a lot of stuff | 18:36.41 |
| | I'll send email again. | 18:37.00 |
| | mail sent, mvrhel2 can you check the patch again? | 18:40.01 |
| tkamppeter | henrys, I did the magic "git push" and get | 18:42.45 |
| | fatal: The remote end hung up unexpectedly | 18:42.53 |
| | henrys, what do I have to do? | 18:43.02 |
| henrys | are you using the http? | 18:43.28 |
| tkamppeter | henrys, I do not know, I have copied it from gs.com somewhere. | 18:44.46 |
| | henrys, how can I read out what I am using? | 18:44.59 |
| | henrys, and how can I switch, and to what? | 18:45.25 |
| henrys | git config -l - what does remote.orgin.url say? | 18:46.26 |
| chrisl | tkamppeter: can try pushing once again? I've had that "hung up unexpectedly" error about three times today. | 18:46.44 |
| tkamppeter | henrys, git://git.ghostscript.com/ghostpdl.git | 18:47.00 |
| | chrisl, tried again and still the error. | 18:47.25 |
| | chrisl, more three times and still the error. | 18:47.46 |
| henrys | the url is wrong | 18:47.56 |
| chrisl | Yep, your origin is for the read-only repos | 18:47.58 |
| tkamppeter | henrys, how to switch? | 18:48.11 |
| henrys | remote.origin.url=ghostscript.com:/home/git/ghostpdl.git | 18:48.16 |
| tkamppeter | which command does this switch? | 18:48.31 |
| henrys | I don't know how to switch - I would just reclone | 18:48.32 |
| | from the right place | 18:48.44 |
| Robin_Watts | remote.origin.url=till@ghostscript.com:/home/git/ghostpdl.git | 18:48.54 |
| | tkamppeter: Easiest way is to edit the .git/config file directly. | 18:49.35 |
| henrys | I wasn't sure if that was safe. | 18:50.01 |
| Robin_Watts | it is. | 18:50.04 |
| chrisl | Robin_Watts: the problem in mkromfs.c seems to be that the stoopid compiler can't tell the difference between the "feof" element in the structure, and the "feof" function. Changing the name seems to make it work. | 18:50.13 |
| Robin_Watts | call it eof ? | 18:50.29 |
| henrys | Robin_Watts:but we'd like to know if he can clone also so it makes sense to just set it up correctly from the start. | 18:50.41 |
| Robin_Watts | henrys: If he can push he can pull. | 18:51.15 |
| | but if he doesn't mind the bandwidth hit, go ahead and reclone. | 18:51.29 |
| chrisl | Robin_Watts: something like that. I was thinking we could rename all three of the function pointers, just in case. I'll look at it a bit more tomorrow, but I'm rapidly fading right now! | 18:51.33 |
| tkamppeter | Robin_Watts, great, thank you that's it, this edit is much quicker than a new download! | 18:51.35 |
| Robin_Watts | chrisl: I understand entirely. | 18:51.50 |
| chrisl | tkamppeter: you want that commit in 9.04 I take it? | 18:52.10 |
| tkamppeter | Robin_Watts, henrys: patch is up, I got the notification e-mail. | 18:52.24 |
| | chrisl, yes, I want to have it in 9.04. | 18:52.43 |
| chrisl | I'll pull it into the branch now, thanks! | 18:52.56 |
| tkamppeter | chrisl, is 9.04 already forked out? | 18:52.58 |
| chrisl | tkamppeter: yes, there's a gs904 branch in git | 18:53.11 |
| tkamppeter | chrisl, thanks, so I have to take snapshots now from there. | 18:55.11 |
| chrisl | tkamppeter: yes, and if you commit anything else you need in 9.04, can you prompt me on here, or by e-mail, and I will pull the change in to the branch? | 18:55.36 |
| tkamppeter | chrisl, OK, will do. | 18:56.11 |
| chrisl | great, thanks. | 18:56.19 |
| | Okay, I'm going to call it a day - g'nite all! | 18:56.36 |
| mvrhel2 | henrys: the patch looks good to me now | 19:00.18 |
| tkamppeter | mvrhel2, henrys, chrisl_away, I am trying the patch on real iron now ... | 19:01.04 |
| chrisl_away | Robin_Watts: I just remember the downloads aren't on Ix anymore, are they? Can you make the access details on the new site available, please? | 19:09.49 |
| Robin_Watts | chrisl_away: Yes, sure. | 19:16.08 |
| | chrisl_away: ~robin/DownloadsInformation.txt Same place as before. Already has the godaddy stuff in it. (Phew! Cos I couldn't remember it :) ) | 19:36.40 |
| henrys | tkamppeter:well the testing procedure is rather involved you have to use the pcl interpreter to look at the results. That is why I wanted marcos to set up something automated. | 19:56.54 |
| tkamppeter | henrys, now I have printed on printersm, see my last comment on bug 692329. It works and with the files being 10 times smaller it should be more reliable with repect of limited resources on the printers. | 19:59.58 |
| henrys | tkamppeter:your call if you want to go with it now put it in trunk and send an email to chrisl_away | 20:09.10 |
| tkamppeter | henrys, patch is in trunk, I will inform chrisl_away. | 20:22.54 |
| | henrys, chrisl_away has moved the patch into 9.04. | 20:47.09 |
| henrys | yes I saw that... | 20:48.15 |
| malc_ | Robin_Watts: hi, is 93701ab27b4d50f5d27da43f34d432e1963ce337 supposed to fix only 692354, but not 691629? | 20:48.58 |
| Robin_Watts | malc_: looking | 22:56.14 |
| malc_ | just in case.. it does not (here), then again maybe the underlying issue is different | 22:57.18 |
| Robin_Watts | malc_: It was not intended specifically to fix that. | 22:58.58 |
| malc_ | Robin_Watts: okay | 22:59.30 |
| Robin_Watts | The fix in 937 was to slightly expand images so there are no antialiased edges. | 23:00.02 |
| | If there are rounding issues, then there may still be gaps left. | 23:00.35 |
| | 1 pixel wide/high images are going to be prone to rounding issues. | 23:00.49 |
| | tkamppeter: I just pushed a commit that should fix bug 692368. | 23:14.26 |
| henrys | Robin_Watts:I don't see how alexcher's patch for 692352 helps if the shading algorithm uses too much memory it should be fixed we can't depend on save and restore or gc to fix it. | 23:15.41 |
| Robin_Watts | henrys: right. I've literally just pulled that bug up to read it. | 23:16.15 |
| | The way it reads to me is that garbage collection is broken somehow w.r.t. shadings. | 23:16.45 |
| | and save/restoring just makes it SEGV earlier (possibly because it's incorrectly throwing stuff away too early, hence using less memory). | 23:17.13 |
| henrys | you might want to try this one on mupdf too. | 23:17.35 |
| Robin_Watts | henrys: which aspect of this bug did you want me to look into? | 23:17.56 |
| | The amount of memory used by the shading algorithm? | 23:18.07 |
| | or the leaking/gc problems ? | 23:18.14 |
| | mupdf has a very different shading algorithm. | 23:18.57 |
| henrys | memory used by the shading algorithm | 23:18.58 |
| Robin_Watts | Right, that's what I was hoping :) | 23:19.06 |
| | I'll look at that tomorrow then. | 23:19.16 |
| henrys | if we had another language say svg that did shading without gc it should still work... | 23:19.56 |
| tkamppeter | Robin_Watts, thanks for the segfault fix. Will it go into 9.04? | 23:27.23 |
| Robin_Watts | tkamppeter: I believe it should. | 23:27.38 |
| | I'd like to get marcosw to check it with the weeklies though, cos it's a larger change than I'd hoped. | 23:28.10 |
| | but I guess he'll be testing the release candidate, so I'll get chrisl to pull it in tomorrow unless henrys or anyone else objects. | 23:28.57 |
| henrys | no objections here. | 23:31.39 |
| | going out for my run | 23:32.00 |
| | Forward 1 day (to 2011/07/28)>>> | |
IRC Logs