| | <<<Back 1 day (to 2013/10/27) | 2013/10/28 |
| MedDev | I've built ghostscript from source, but when I try to view a ps file I get the error "Fontmap entry for Fontmap.local ends prematurely!" when I vim /etc/ghostscript/9.10/Fontmap.local all I see is an empty file :/ | 01:46.28 |
| | i tried using the --disable-fontconfig flag when i configure'd thinking maybe that was the problem, but still the same result. | 01:50.11 |
| | oh wait! got it! | 01:50.32 |
| ray_laptop | MedDev: Fontmap.local is not something that is normally part of a Ghostscript build, but this may be a result of a particular "biuild" | 05:12.41 |
| | MedDev: I recommend opening a bug at bugs.ghostscript.com and attach the command line and the the input file that gives the error. | 05:14.09 |
| MedDev | ray_laptop, i think it was a problem with the fedora package, i got it working just fine after i removed the ghostscript-fonts rpm | 05:15.11 |
| ray_laptop | MedDev: Great. Thanks for letting us know. | 05:18.17 |
| tor7 | http://jamesfriend.com.au/pce-js/ wow, that brings back the memories | 10:34.26 |
| kens | Good grief.... | 10:35.05 |
| ente | while we're going that way | 10:41.55 |
| | http://jsmachines.net/demos/pc/cga-win101/xt-cga-win101.xml | 10:42.00 |
| tor7 | Robin_Watts: so, what's your final verdict on the gary gibson book series? | 11:20.23 |
| paulgardiner | is currently engrossed by Wool. Excellent referral Robin_Watts | 11:24.08 |
| | Seems like Steinbeck, but SF. | 11:25.21 |
| chrisl | paulgardiner: I found Wool almost impossible to put down - seriously compelling...... Hmmm, faster paced than Steinbeck, I'd say | 11:26.09 |
| paulgardiner | Yeah, incredibly compelling. Little hints as to what is to come and then makes you wait. | 11:27.00 |
| | Really I'm not well read enough to be able to accurately liken another writer to Steinbeck (actually I think I've read only Of Mice and Men), but it was the insight into people's inner thoughts that reminded me of him. | 11:28.45 |
| chrisl | paulgardiner: actually, I think it's a good comparison: the way that Juliette clearly has great affection for and loyalty to where she lives, without being blinded to it's problems does remind me of Steinbeck's attitude to the US | 11:31.08 |
| tor7 | chrisl: I just read all of the laundry files books by stross | 11:34.30 |
| chrisl | tor7: also some of my favourites of recent years..... what did you think? | 11:35.01 |
| tor7 | I really enjoyed them! | 11:35.16 |
| chrisl | I wondered if they have been a bit "British"...... | 11:35.42 |
| tor7 | though I can't help but feel I missed a ton of references, by not having read enough of the stuff he's makin fun of | 11:36.01 |
| | chrisl: he uses a rather lot of odd bits of slang, but the built in dictionary in the kindle is very helpful! | 11:36.25 |
| kens | Bob Oliver Francis Howard = BOFH :-) | 11:36.54 |
| tor7 | jennifer morgue sure did remind of Ian Fleming's bond in places | 11:37.30 |
| kens | Its szupposed to | 11:37.41 |
| | the first 3 are writeen in conscious imitationof other writers | 11:37.51 |
| tor7 | kens: yeah, but then I missed the other two writers he's imitated altogether... | 11:38.05 |
| | the short story equiod was one of the better ones, you should definitely read that if you haven't already | 11:38.52 |
| kens | has hte whole lot | 11:39.25 |
| | The first authour was Len Deighton I think. THe third one I don't remember, bt it was hte authour of the Quiller Memorandum | 11:39.56 |
| chrisl | And apparently there is another Laundry book in the works | 11:40.03 |
| kens | Indeed :-) | 11:40.09 |
| tor7 | the next one should be out next year, IIRC | 11:40.38 |
| kens | Though I was hoping for another set after Iron Sunrise | 11:40.43 |
| tor7 | so now I'm wondering if you have any suggestions for what books of his I should go for next | 11:41.11 |
| | or is it just "all of them"? | 11:41.29 |
| kens | I wouldn't read teh merchant prince series, unless you really like world jumper series | 11:41.53 |
| | I enjoyed Iron Sunrise, and the one before it whose name I can currently remember, though its not as good | 11:42.31 |
| | Glasshouse is good if creepy | 11:42.38 |
| | accelerando is not bad, though it feels less polished than his other work I feel. As Chris was saying the other day "the rapture of the nerds" is less good, and very similar | 11:43.45 |
| tor7 | kens: Singularity Sky? | 11:45.41 |
| kens | Yes thats the one | 11:45.56 |
| chrisl | Accelerando feels to me like it was supposed to be twice the length, and was cut down..... | 11:46.13 |
| tor7 | chrisl: the opposite of hamilton's books then? ;) | 11:46.46 |
| kens | It started as a series of shorts, and I think that's the fragmented feel of it | 11:46.50 |
| chrisl | tor7: sort of, yeh. It felt slightly rushed in places, and then like stuff was skipped over in others - I thought it a *very* good story, though | 11:47.56 |
| | tor7: The Void series finally put me off Hamilton...... | 11:48.48 |
| tor7 | chrisl: I liked the "fantasy" bits of the void series, but as usual he can't write an series that doesn't end with "and then they lived happily ever after"... | 11:49.43 |
| chrisl | tor7: I don't mind the "happily ever after", but the whole resolution hinging on two (or more?) characters coincidentally doing things simultaneously was just too much | 11:51.23 |
| tor7 | I think a major issue with the void series is how everybody is immortal, if someone dies they can just get relifed. | 11:51.29 |
| | chrisl: what about the ending to the night's dawn trilogy then? that was also unplausible and rushed if I remember correctly. | 11:52.21 |
| chrisl | tor7: yep, but I don't write off an author for a bad ending.... but two really bad ones in row was a bit much! | 11:53.25 |
| tor7 | chrisl: I haven't read any of his standalone novels. wonder if they're as bad in the ending department. | 11:54.47 |
| chrisl | tor7: I read Fallen Dragon a while back - I seem to remember it was quite enjoyable. At least, I don't have a particular recollection of disliking it | 11:57.04 |
| Robin_Watts | tor7: Gary Gibson: Enjoyable enough. Not classics, but I'd read more. | 12:11.45 |
| | Fallen Dragon was ok - reminded me a lot of The Reality Dysfunction though. | 12:13.29 |
| | I like Neal Asher too, be interested to know what others think. | 12:13.55 |
| chrisl | Robin_Watts: is there a specific Asher book you'd suggest to start with? | 12:16.56 |
| Robin_Watts | chrisl: Urm... | 12:17.12 |
| | There is a continuing universe with his stuff, within which there are several 'series'. | 12:17.39 |
| | It probably makes sense to try to read them 'in order'. | 12:17.59 |
| | but figuring out what that order is is not trivial :) | 12:18.08 |
| chrisl | Looks like Gridlinked was first in the Polity universe | 12:19.04 |
| | Blimey, published by Tor...... :-) | 12:20.19 |
| Robin_Watts | Yeah. | 12:20.19 |
| | I have a shelf full of them here that people are welcome to borrow if you want. | 12:21.38 |
| tor7 | Robin_Watts: I'm going to add TIFF output support to mudraw (so we can more easily test CMYK output) unless you have any other suggestions | 13:50.58 |
| | PWG should work with CMYK as well? | 13:51.06 |
| Robin_Watts | tor7: PWG does CMYK. | 13:51.20 |
| | tor7: So does PAM. | 13:51.28 |
| | PAM would be the easiest to add. | 13:51.34 |
| | but having tiff output wouldn't be a bad thing. | 13:51.54 |
| tor7 | Robin_Watts: I have CMYK in PAM but I can't find anything that's willing to open the files | 13:51.57 |
| Robin_Watts | imagemagick convert. | 13:52.05 |
| tor7 | imagemagick throws an error :( | 13:52.08 |
| Robin_Watts | really? What TUPLTYPE are you using? | 13:52.22 |
| tor7 | CMYK and CMYK_ALPHA, but I can't really find any documentation for non-RGB and non-GRAYSCALE and non-BLACKANDWHITE tuple types | 13:52.53 |
| Robin_Watts | Can you put a file somewhere? | 13:52.55 |
| tor7 | Robin_Watts: http://ghostscript.com/~tor/stuff/out-cmyk.pam | 13:53.47 |
| Robin_Watts | I was using CMYK TUPLTYPEs for the ETS work. | 13:54.18 |
| | DEPTH 32 ? | 13:54.46 |
| tor7 | DEPTH is number of planes | 13:56.04 |
| Robin_Watts | P7 | 13:56.28 |
| | WIDTH 595 | 13:56.30 |
| | HEIGHT 842 | 13:56.31 |
| | DEPTH 4 | 13:56.33 |
| | MAXVAL 255 | 13:56.35 |
| | TUPLTYPE CMYK | 13:56.37 |
| | ENDHDR | 13:56.39 |
| | That worked for me for ETS. | 13:56.41 |
| | Maybe no comment ? | 13:56.48 |
| tor7 | ah! the comment was the problem indeed | 13:57.08 |
| Robin_Watts | Looks inverted to me, but that's easy enough to fix. | 13:57.33 |
| tor7 | right. so now my primary motivation for TIFF just went away :) | 13:59.30 |
| Robin_Watts | I bet :) | 13:59.49 |
| tor7 | Robin_Watts: I'm surprised it almost works out of the box! | 14:01.47 |
| Robin_Watts | AA should be OK. | 14:02.20 |
| | It's transparency where it'll all go cocked. | 14:02.27 |
| tor7 | black and white text seems to work perfectly, but colors are inverted | 14:02.28 |
| Robin_Watts | tor7: Are you inverting all the colors when writing to the PAM ? | 14:03.04 |
| tor7 | Robin_Watts: no, I'm dumping them raw | 14:03.22 |
| Robin_Watts | I daresay we're assuming additive spaces. | 14:03.41 |
| | Can't see why colors should be any different to K though offhand. | 14:04.08 |
| tor7 | Robin_Watts: our rendering code definitely is assuming additive color spaces, which is why I reckon it all goes inverted | 14:04.09 |
| Robin_Watts | When I fixed the file you sent me by removing the comment I found it was white on black. | 14:04.28 |
| | so K was inverted too. | 14:04.33 |
| tor7 | Robin_Watts: odd. the same file, without the comment, shows up normal with my "display" | 14:04.50 |
| | but "display" from imagemagick is not known for its correctness in all cases | 14:05.04 |
| Robin_Watts | tor7: Try converting to png and then displaying the png / | 14:05.40 |
| | ? | 14:05.41 |
| tor7 | Robin_Watts: yeah, then it's all inverted | 14:05.48 |
| Robin_Watts | OK. | 14:05.53 |
| tor7 | but other colors are now correct... | 14:06.05 |
| Robin_Watts | We could consider rendering to 1-C, 1-M, 1-Y, 1-K internally. | 14:06.21 |
| | Thus keeping only using additive spaces. | 14:06.34 |
| tor7 | Robin_Watts: hm, maybe I should add a cmyk mode to the mupdf viewer (like our grayscale mode) | 14:06.38 |
| Robin_Watts | I have this vague memory that that might simplify some of the blending functions. | 14:07.03 |
| tor7 | Robin_Watts: yeah, that's one thought. or a fz_device_additive_cmyk to keep the existing cmyk for images. | 14:07.24 |
| Robin_Watts | foods. | 14:09.38 |
| henrys | marcosw for the logs, with 694733 let's just do vmware automated testing for windows ⦠http://blogs.vmware.com/vipowershell/2012/06/be-efficient-virtualize-automate-your-test-environment.html, some poor soul will help with the scripting if it is difficult. | 14:25.42 |
| Robin_Watts | henrys: I sent the mail last night, but forgot to copy it to support. Presumably you got a copy though? | 14:44.57 |
| kens | I got a copy I thought | 14:45.09 |
| Robin_Watts | oh, yes, sorry. | 14:45.47 |
| | So I did copy support. I missed that when I looked for it this morning. | 14:46.04 |
| henrys | Robin_Watts: the email parses oddly in gmail though, I only get ellipses which I must click to see the message, normally the ellipses have to be clicked to see thread history and the current email displays | 14:50.25 |
| Robin_Watts | henrys: Hmm, odd. | 14:51.03 |
| | henrys: It might be to do with the character encoding being different from previous messages in the thread? | 15:08.44 |
| | Maybe I should resend it. I can take the opportunity to cut down the number of us that are directly copied on it. I'd imagine that most people would be perfectly happy to just get a single copy via support. | 15:09.34 |
| kens | yes please | 15:10.53 |
| henrys | gmail seems to magically get rid of duplicates for me, maybe it doesn't do that if you are just using it as a server. | 15:13.28 |
| Robin_Watts | Scott gets support. Does Miles? | 15:14.05 |
| henrys | no | 15:14.13 |
| tor7 | Sounds like the storm's arriving for real now... | 15:17.28 |
| henrys | Robin_Watts: you could also just request an ack ⦠saying some recipients reported strangeness with the mail or something to that effect. | 15:18.13 |
| Robin_Watts | henrys: Sent now; I copied the email, explained the reason and requested an ack. | 15:19.33 |
| tor7 | birds are flying backwards :) | 15:20.18 |
| | the poor things... | 15:20.28 |
| henrys | tor7:they do that all the time here.. 50 MPH winds are fairly common. | 15:20.57 |
| Robin_Watts | tor7: We had relatively little of the storm here. But the train company still hasn't managed to run trains to london yet today. | 15:21.11 |
| | I had to drive Helen to Oxford this morning so she could travel in from there. | 15:21.29 |
| tor7 | henrys: heh. not so common here though! | 15:21.31 |
| kens | We had the storm winds | 15:21.44 |
| | 90+ mph | 15:21.51 |
| tor7 | Robin_Watts: yeah. they just shut down all the train traffic now. | 15:22.00 |
| Robin_Watts | kens: Yeah, I think the further south you were, the worse it was. | 15:22.06 |
| henrys | tor7:wow so this is something extraordinary. | 15:22.33 |
| tor7 | henrys: yeah, the storm that hit england is coming this way this evening | 15:23.28 |
| kens | and picking up force as it crosses the North Sea | 15:23.51 |
| henrys | thought it wouldn't be warm enough for that hurricane like stuff. | 15:24.06 |
| kens | apparently the sea is warm | 15:24.26 |
| henrys | kens, Robin_Watts I guess you guys are far enough inland as not to be badly effected. | 15:28.43 |
| kens | bad neough here | 15:29.08 |
| Robin_Watts | henrys: I'm as far inland as you can get in the UK, pretty much (nowhere here is more than 72 miles from the sea). | 15:29.13 |
| | but there are lots of trees down/damage reported even in london. | 15:29.37 |
| kens | 2 dead in Ken | 15:30.28 |
| henrys | kens:did you sustain property damage? | 15:31.11 |
| kens | no, we're fine | 15:31.37 |
| Robin_Watts | suspects that should be 2 dead in Kent, rather than Ken becoming a hungry cannibal. | 15:32.13 |
| henrys | Robin_Watts: I alway forget how small the UK actually is⦠| 15:32.31 |
| kens | oops yes | 15:32.50 |
| tor7 | denmark just got a new wind record... 51 m/s | 15:33.25 |
| Robin_Watts | henrys: Did the resend appear 'properly' in gmail ? | 15:36.20 |
| henrys | it did | 15:36.43 |
| Robin_Watts | ray_laptop: Thanks for the feedback, but I'd sent the email by that point :( | 15:46.15 |
| ray_laptop | Robin_Watts: yeah, so I noticed. No problem, they were just very minor suggestions. Good email! | 15:47.59 |
| | I agree with getting them the email on their Monday AM was a good goal. | 15:50.25 |
| | mvrhel_laptop: Do you know if a value of 1 for #define ICC_CACHE_MAXLINKS will be OK ? I'm going to try a regression run, but if you can tell me it won't, then what is the smallest I should test ? | 16:07.06 |
| mvrhel_laptop | ray_laptop: I tested that out long ago and it worked, but I can't guarantee it still does | 16:07.53 |
| ray_laptop | mvrhel_laptop: OK. Well the customer is running 9.06, so I will test that. Thanks | 16:08.18 |
| mvrhel_laptop | ok | 16:08.22 |
| ray_laptop | The only painful part is uploading all of the modified sources :-( (11197 objects) | 16:10.08 |
| mvrhel_laptop | ray_laptop: why do you want to use such a small cache? I can't imagine it taking up that much space really | 16:12.37 |
| kens | Is this the customer questioning the large ICC profiles ? | 16:13.13 |
| mvrhel_laptop | even if they have a large profile, the link may not be that large | 16:13.28 |
| | if the link has to be recomputed over and over you are going slow things down | 16:13.51 |
| ray_laptop | sorry, kens. I was on a phone call. The customer is getting a VMerror and noticed that there were a large number of profiles allocated | 16:18.45 |
| kens | Its michael that's asking really, I was just curious if it was the same customer asking about profile sizes | 16:19.09 |
| mvrhel_laptop | hmm large profiles. I must have missed that one | 16:19.31 |
| ray_laptop | mvrhel_laptop: They didn't request such a small cache -- I just want to make sure that there is no lower bound. | 16:19.33 |
| kens | mvrhel_laptop : someone was sking if 500Kb was large for a profile | 16:19.57 |
| mvrhel_laptop | kens: where is this question | 16:20.01 |
| kens | I have profiles here up to 2.5Mb | 16:20.06 |
| mvrhel_laptop | right. | 16:20.12 |
| kens | mvrhel_laptop : you did reply I'm pretty sure | 16:20.23 |
| mvrhel_laptop | you can pack a bunch of crap in them if you want | 16:20.24 |
| ray_laptop | mv that was from 10/25 | 16:20.46 |
| kens | Subject was 'Question on ICC Profile Size' | 16:21.10 |
| ray_laptop | I don't see a reply from mvrhel_laptop | 16:21.14 |
| mvrhel_laptop | I am trying to find the email.... | 16:21.29 |
| kens | Well, we all know my memory is terrible, I possibly made that up | 16:21.33 |
| ray_laptop | I replied with the other part of their concern -- trying to print an error page after a VMerror | 16:21.44 |
| mvrhel_laptop | oh there it is | 16:21.45 |
| | it is likely that that profile has some special tags with gobs of measurement data etc | 16:23.53 |
| | to me, it seems odd that there would be multiple allocations though | 16:24.22 |
| | without freeing | 16:24.27 |
| kens | Fomr the propfiles I have here, 500K is in the upper 50% but by no means unusual | 16:24.29 |
| mvrhel_laptop | since the profiles are ref counted | 16:24.43 |
| | ray_laptop: do we have this same ATS file at them? | 16:26.44 |
| | AIX361DC_Save.pdf ? | 16:26.46 |
| ray_laptop | mvrhel_laptop: looking | 16:28.00 |
| | mvrhel_laptop: it's in the tests_private/pdf/PDF_1.7_ATS/ directory, but which version is the question. There are 5 files: AIX361DC_Writer.pdf AIX361DC_A_1B.pdf AIX361DC_MAC.pdf AIX361DC_X_3.pdf AIX361DC_Dist.pdf | 16:33.12 |
| mvrhel_laptop | AIX361DC_Save.pdf | 16:33.28 |
| | is the one that he has | 16:33.31 |
| | perhaps you can get that file from him, and I can take a look this week at it | 16:33.51 |
| ray_laptop | I missed it. So we do have the _Save version. | 16:34.33 |
| | too much noise from "find" the first time | 16:35.10 |
| mvrhel_laptop | oh. ok | 16:35.24 |
| | I will take a look at it today | 16:35.36 |
| ray_laptop | mvrhel_laptop: OK. Thanks. | 16:35.53 |
| mvrhel_laptop | want to wrap up something on mupdf first while it is still in my head | 16:35.57 |
| | ray_laptop: I sent him an email too | 16:36.06 |
| ray_laptop | mvrhel_laptop: OK. Thanks. | 16:36.15 |
| | mvrhel_laptop: my regression run didn't (run) | 16:38.58 |
| mvrhel_laptop | ray_laptop: ok if you want to open a bug for me to look at this that is fine | 16:40.20 |
| | that is the cache size limit | 16:40.35 |
| ray_laptop | mvrhel_laptop: I emailed him and told him we have the file and asked him to confirm the size is the same as what he has | 16:40.56 |
| | mvrhel_laptop: I didn't get an email, but the regression dashboard says: "An error occurred that prevented the local cluster run from finishing:" and then says that 3 machines had "timeoutFail: log file(s) too big:" | 16:42.31 |
| | I'm going to bump it up a bit and see if it will run. | 16:42.52 |
| mvrhel_laptop | this file has a lot of transparency | 16:43.04 |
| | with icc color spaces | 16:43.11 |
| | I suspect the transparency size is a bigger issue than the icc profiles | 16:43.31 |
| ray_laptop | mvrhel_laptop: recall that they always use transparency, but force -dBandHeight=128 | 16:44.09 |
| mvrhel_laptop | in one area it has 5 different transparency groups overlapping along with deviceN mesh shading | 16:44.27 |
| ray_laptop | s/always use transparency/always use clist/ | 16:44.34 |
| | oh, joy. Sounds like a real killer | 16:44.59 |
| mvrhel_laptop | ray_laptop; well that would explain all the allocations | 16:45.00 |
| ray_laptop | what explains all the allocations ? | 16:45.17 |
| mvrhel_laptop | with every transparency group / band it is going to allocate a new ICC profile | 16:45.29 |
| | and then it should destroy them when the band is done | 16:45.56 |
| ray_laptop | Really ? Why? The ICC profiles are stored in the clist and don't need to be kept in memory once we form the link, right ? | 16:46.26 |
| mvrhel_laptop | perhaps we could look into reducing the size of the profile before it goes in the clist | 16:46.26 |
| | ray_laptop: the transparency group needs the profile | 16:46.47 |
| ray_laptop | mvrhel_laptop: Oh, you mean by trimming out the part we don't need | 16:46.49 |
| mvrhel_laptop | that is its color space | 16:46.54 |
| | and the device color space at that time | 16:47.02 |
| | the group is active | 16:47.06 |
| ray_laptop | mvrhel_laptop: all the cms is done with the link, right ? | 16:47.11 |
| mvrhel_laptop | you absolutely need the profile | 16:47.13 |
| | how do I know what is going to get drawn in the group? | 16:47.24 |
| | I could pick 100 different source profiles to draw in the group | 16:47.37 |
| ray_laptop | you need the profile in order to generate the link, but you don't need the profile do you ? | 16:47.39 |
| mvrhel_laptop | so I need the groups color space | 16:47.41 |
| | yes, but the links are not generated until needed | 16:47.58 |
| ray_laptop | right, but you can get the profile you need from the clist, right ? | 16:48.19 |
| | keeping the group's profile around wouldn't be too bad, but the others ? | 16:48.53 |
| mvrhel_laptop | ray_laptop: what others? | 16:49.08 |
| ray_laptop | the for the current color | 16:49.35 |
| mvrhel_laptop | those are not kept around | 16:49.52 |
| | well, the current color yes | 16:50.00 |
| | but once done, it is released | 16:50.10 |
| | i.e. once a new color is set | 16:50.16 |
| | but that is only for images | 16:50.22 |
| | well that is not true hold on | 16:50.44 |
| ray_laptop | once the link is generated, the profile could be released, right ? | 16:50.48 |
| | or the rc decremented | 16:51.13 |
| mvrhel_laptop | ray_laptop: let me look over the file before I say anymore. I am not convinced that the ICC profiles are the real issue with this file | 16:52.02 |
| | he said the he sees a lot of allocations for the profile. | 16:52.29 |
| | 1) not sure what he means by alot | 16:52.44 |
| | 2) I would expect to see an allocation in each band for each group color space | 16:53.09 |
| | But as we move to a new band those should be released clearly | 16:53.30 |
| | If I have 5 groups in a band which are not nested groups, we will end up doing 5 allocations | 16:54.20 |
| | that is what I am seeing in the file just looking at it in AR | 16:54.39 |
| ray_laptop | mvrhel_laptop: I only see two ICCBased colorspaces: obj 24 and 327 | 16:55.55 |
| mvrhel_laptop | ray_laptop: that may be. but if I have 5 groups not nested, we will end up doing an allocation for the group each time | 16:56.36 |
| | when one group goes away we have a new one | 16:56.49 |
| ray_laptop | I suspect that you are right. I doubt the ICC profiles are the culprit. Go ahead and work on something else, and I'll have a look | 16:56.53 |
| mvrhel_laptop | ray_laptop: ok. if you do want me to jump back in, that is fine | 16:57.28 |
| ray_laptop | mvrhel_laptop: sorry to distract you from the mupdf work | 16:57.52 |
| mvrhel_laptop | ray_laptop: not a distraction. if you want me to help I can, I drag you into plenty of my issues. I do think reducing the size of the iccprofile into the clist would be a worthwhile task . I will open an ehancement bug with this file for me to look into doing | 16:59.41 |
| | ray_laptop: do you think that would be a good idea? we can start with chopping out the private tags | 17:00.12 |
| ray_laptop | I'm trying 9.06 with 50 (the original). At 3, 7 machines came back with that same message | 17:00.15 |
| mvrhel_laptop | ray_laptop: :( | 17:00.44 |
| | sounds like I will need to figure out what is going on with that | 17:00.53 |
| henrys | Robin_Watts: actually I had to bump ray_laptop's 801 contact privately to finally get a response. I hope it goes better with this message. | 17:01.24 |
| ray_laptop | mvrhel_laptop: I think trimming the junk out of an ICC profile is a good idea, and not just clist mode. Can we just throw stuff away when reading the ICC profile into memory ? | 17:02.05 |
| mvrhel_laptop | ray_laptop: that would be an even better place to do it | 17:02.23 |
| | It would not be too hard. Just throwing stuff out and fixing the tag table | 17:02.47 |
| ray_laptop | mvrhel_laptop: OK. | 17:02.53 |
| Robin_Watts | mvrhel_laptop: Maybe that should be something that lcms2 can do. | 17:02.54 |
| ray_laptop | Is that where the ICC profile is read ? | 17:03.17 |
| mvrhel_laptop | Robin_Watts: I don't think we want the dependent upon the cmm | 17:03.20 |
| | ray_laptop: no | 17:03.27 |
| ray_laptop | mvrhel_laptop: true. | 17:03.31 |
| mvrhel_laptop | s/the/that/ | 17:03.40 |
| Robin_Watts | mvrhel_laptop: Urm... Surely the idea of having separate CMMs is so that ALL knowledge of the particular formats in use is in the CMM? | 17:04.05 |
| ray_laptop | Robin_Watts: but we want to be CMS agnostic, right ? | 17:04.38 |
| mvrhel_laptop | Robin_Watts: the idea is that you can easily use different CMMs with GS. If we can do something that helps GS regardless of the CMM then we should do that | 17:04.54 |
| ray_laptop | and if we want to munge profiles, we can't rely on the CMS to do it the way we want | 17:05.08 |
| mvrhel_laptop | right | 17:05.25 |
| Robin_Watts | We have GS, and we have the CMM in use, and we have a layer of glue between the two. | 17:05.36 |
| | GS should call something like "load_stripped_profile" | 17:05.52 |
| | If the CMM provides it, then the glue can just call direct into the CMM to do it. | 17:06.35 |
| | If not, the glue layer can do it itself. | 17:06.49 |
| ray_laptop | if we want to always do it, why should it be in every version of the glue logic | 17:06.56 |
| mvrhel_laptop | Robin_Watts: I want control over this myself | 17:07.05 |
| | and I don't know of a single CMM that does it | 17:07.29 |
| ray_laptop | Robin_Watts: It's unlikely that a CMS will do it, and do it the way we want. We know what we need and don't need from the profile | 17:07.30 |
| Robin_Watts | but it really feels like a bad design decision to me for both gs and the CMM to both have to understand a format in all cases. | 17:07.35 |
| mvrhel_laptop | Robin_Watts: we already do | 17:07.44 |
| | I generate ICC profile from PS color spaces | 17:07.51 |
| ray_laptop | Robin_Watts: well, it is a standard | 17:07.55 |
| mvrhel_laptop | V4 and soon V2 | 17:07.55 |
| | creating a profile and doing a CMM are order of magnitude different profiles | 17:08.46 |
| | different problems | 17:08.51 |
| | i.e. profile manipulation is easy | 17:09.03 |
| | creating a CMM that works decent is hard | 17:09.26 |
| ray_laptop | is glad I'm not the only one picking the wrong word this morning ;-) | 17:09.31 |
| mvrhel_laptop | :) | 17:09.41 |
| ray_laptop | OK. Even "stock" 9.06 won't run the regression :-( | 17:10.36 |
| | I'm going back to head and test it with a small cache (1) | 17:10.55 |
| mvrhel_laptop | ray_laptop: so it is not the ICC cache size that was causing the crash? | 17:11.00 |
| Robin_Watts | Ok, I'm getting plausible looking graphics out of my new 801 device. | 17:11.00 |
| mvrhel_laptop | Robin_Watts: nice | 17:11.06 |
| henrys | Robin_Watts: wow that was fast | 17:11.13 |
| ray_laptop | mvrhel_laptop: Not a crash -- machines reporting timeoutFail: log file(s) too big | 17:11.21 |
| Robin_Watts | Now i need to hook the put_params stuff back in. | 17:11.25 |
| mvrhel_laptop | ok | 17:11.28 |
| Robin_Watts | Currently I'm just using the C stuff. | 17:11.30 |
| | or rather, I'm using C versions of the SSE routines that I wrote. | 17:11.43 |
| henrys | Robin_Watts: so you reworded all their sse stuff in c? | 17:11.52 |
| Robin_Watts | I am using C versions (that I wrote) of their SSE. | 17:11.58 |
| | henrys: Yes. | 17:12.05 |
| ray_laptop | Robin_Watts: oh, you went ahead and wrote the C as well ? | 17:12.05 |
| Robin_Watts | The C is trivial. | 17:12.15 |
| henrys | Robin_Watts: very nice. | 17:12.18 |
| ray_laptop | henrys: their SSE stuff had C comments in it | 17:12.27 |
| Robin_Watts | Once I get the put_params/get_params stuff in, I'll have a look at their SSE. | 17:12.42 |
| henrys | It would be interesting to profile before sse'ing | 17:12.42 |
| ray_laptop | They don't have very much SSE | 17:12.48 |
| Robin_Watts | No, the SSE bits are small (and yet, still not optimal :) ) | 17:13.12 |
| ray_laptop | Robin_Watts: if you want me to test performance on my slow laptop, let me know. I can't really profile there, however | 17:13.49 |
| Robin_Watts | henrys: The C is not written for efficiency- it's written to give exactly the same results and to be clear. | 17:13.54 |
| | ray_laptop: I'm not outputting in the same format as them yet, just as PGMs. | 17:14.29 |
| ray_laptop | Robin_Watts: right. So when the SSE doesn't work "out of the box" it's easier to compare intermediate results :-) | 17:14.44 |
| Robin_Watts | ray_laptop: Indeed. | 17:14.54 |
| henrys | once again I have to step out for a "showing" this is getting very annoying. | 17:14.58 |
| Robin_Watts | Also, this gets me going without having the alignment/padding stuff from ray. | 17:15.17 |
| ray_laptop | henrys: you have to leave while they show it ? | 17:15.19 |
| Robin_Watts | henrys: Can you not just hide in the cellar? :) | 17:15.31 |
| ray_laptop | I always stayed around while it was being shown | 17:15.59 |
| henrys | I guess my realtor figures I'm a bit much ;-) | 17:16.10 |
| ray_laptop | :-) | 17:16.17 |
| kens | night all | 17:33.43 |
| ray_laptop | darn. I was in wrong branch when I clusterpushed | 17:47.07 |
| | miles is down and miles is in Mexico (miles the CPU is down). Does someone have to go into his office to fix it ? | 18:07.29 |
| henrys | I don't see miles on the day 4 results? | 18:35.33 |
| Robin_Watts | day 4 results aren't up yet? | 18:36.18 |
| | He's number 74 on the Day 3 accumulated times (on which the order of running on day 4 is based) | 18:37.08 |
| henrys | Robin_Watts: well I downloaded the pdf 4-resultados.pdf | 18:37.41 |
| | be back in 5 minutes returning home. | 18:38.23 |
| ray_laptop | finally. With MAXLINKS set to 3, I was able to finish a regression run. Still got 95 timeouts.Trying 5 to see how performance compares. Who knew we would need so many ? (probably mvrhel did :-) ) | 18:41.36 |
| Robin_Watts | 1 for greyscale to device, 1 for rgb to device, 1 for cmyk to device? | 18:42.10 |
| mvrhel_laptop | ray_laptop: shows you how expensive it is to generate links | 18:42.22 |
| | Robin_Watts: depends upon what profiles (or PS colors spaces) are in the document | 18:42.51 |
| Robin_Watts | mvrhel_laptop: Right, but my point is that 3 doesn't seem unreasonable. | 18:43.27 |
| mvrhel_laptop | lots of different rgb, cmyk, and gray types | 18:43.29 |
| | for most files yes | 18:43.45 |
| | the link cache is pretty small in terms of its memory usage though | 18:44.18 |
| | not really something that we need to worry about in my opinion | 18:44.30 |
| Robin_Watts | A dumb PDF file that doesn't define any colorspaces of it's own, and just uses rg, k, and g to set colors would get by with 3 links, right? | 18:44.48 |
| mvrhel_laptop | the thing is that it is expensive to compute links | 18:44.54 |
| Robin_Watts | (checking my understanding here, rather than anything else) | 18:44.58 |
| mvrhel_laptop | Robin_Watts: perhaps. depends on what else is in the file in terms of transparency | 18:45.18 |
| Robin_Watts | no transparency. | 18:45.26 |
| mvrhel_laptop | in the no transparency case with just Device source spaces then yes 3 links at most | 18:45.51 |
| Robin_Watts | ok, so my understanding is not way off :) | 18:46.01 |
| ray_laptop | mvrhel_laptop: and with transparency, we need more because we form RGB (not device colorspace) ? | 18:48.39 |
| | or whatever the blend colorspace is ? | 18:48.51 |
| mvrhel_laptop | right. you could have all the combinations of from and to | 18:49.14 |
| Robin_Watts | henrys: I'm looking here for the results: http://www.lacarrerapanamericana.com.mx/index.php/resultados | 18:49.25 |
| henrys | Robin_Watts: yes and I downloaded resultado Final dia 4 | 18:51.03 |
| ray_laptop | Robin_Watts: none of the links for Day 4 show "live" for me. Only "TOTAL ACUMULADO AL DÃA 3" is a valid link | 18:51.08 |
| Robin_Watts | ray_laptop: Me too. I have no idea how henrys can have downloaded anything from something that isn't a link. | 18:51.35 |
| ray_laptop | henrys: what's your secret ? | 18:51.48 |
| Robin_Watts | I tried downloading day 3 and changing the URL, but that failed to work as a time machine either. | 18:52.17 |
| | AIUI, today is Day 4, and so the races won't have been run yet. | 18:52.32 |
| ray_laptop | I tried manually: http://www.lacarrerapanamericana.com.mx/images/contenidos/documentos/resultados/2013/resultado-final-dia-4.pdf and got 404 | 18:52.52 |
| henrys | yes now I can't reach it. | 18:52.53 |
| Robin_Watts | The wormhole collapsed :( | 18:53.11 |
| ray_laptop | henrys: it'll be interesting when day 4 is posted again, whether it matches the one you downloaded :-) | 18:53.59 |
| henrys | no it won't the title in the pdf says 2012 | 18:54.20 |
| ray_laptop | maybe somebody paid to get a better time and they had to pull it off for adjustment ;-) | 18:54.42 |
| | this is MX, after all. | 18:55.19 |
| henrys | they should gps the cars. | 18:55.42 |
| ray_laptop | henrys: yeah, and also have helmet cams they can uplink for us to watch | 18:57.04 |
| Robin_Watts | I thought that the cars were GPS'd? | 18:57.23 |
| | Certainly one year there was a GPS page you could look at, and I was confused by the fact that Miles was showing as being in the middle of a town for about 6 days. | 18:58.07 |
| | Then I twigged that was a garage, and his car had broken... | 18:58.18 |
| ray_laptop | I saw a pretty cool bluetooth camera that hooks over the ear and looks like a bluetooth headset | 18:58.22 |
| Robin_Watts | http://app.rallysafe.com.au/Event/PublicView/54 | 19:01.26 |
| | Miles doesn't seem to be listed though :( | 19:05.28 |
| ray_laptop | Well, with 5 links, the it went from 95 timeouts to 45 and the overall time went from 24 down to 22 hours (gs) vs. 17 for the reference. | 19:10.49 |
| | one more, then I'll let Len know what a reasonable number might be, although they ALWAYS blend in RGB space, iirc (I know that's the case with 8.71) so transparency may not factor in as much | 19:12.38 |
| | oops. Sorry, chrisl. Do you want me to abort mine ?-- it's just for timing, nothing urgent | 19:13.33 |
| | oh, well. It runs in about 17 minutes or so. Going to lunch. | 19:17.36 |
| Robin_Watts | ray_laptop: Can I safely set defaults in the device in the device open call? | 19:20.16 |
| | Or is that too late for get_params/put_params ? | 19:20.26 |
| ray_laptop | Robin_Watts: yes, It's allowed to have defaults set in 'open', but put_params / get_params fo get called before open | 19:24.45 |
| Robin_Watts | ray_laptop: OK. 801 seem to be fiddling with the graphics state (to add page zooming) in their custom operators. | 19:25.54 |
| ray_laptop | It's better to set defaults in the device prototype initial values, or set 'not set yet' values that put/get can recognize and put in the real defaultd | 19:25.59 |
| Robin_Watts | ray_laptop: OK, ta. | 19:26.12 |
| ray_laptop | generally get will be called first (if it's the -sDEVICE device) in order to get the names of the parameters, then it replaces the values that are in systemdict and 'puts' that | 19:27.28 |
| | that's how it figures out which params are valid for a device and why there has to be a 'get' for every param | 19:28.33 |
| | even if the values are logically just write-only. A lot of device implementors trip over that, thinking, I really don't need to ever 'get' this since it is a private param that nobody needs to know about | 19:29.46 |
| | bbiaw | 19:30.50 |
| chrisl | ray_laptop: (for when you return) no problem, I just went to get some food, too, so it hasn't really held me up...... | 19:32.01 |
| ray_laptop | oh, great. With 9 links, the run didn't complete. Some systems claim too many timeouts | 19:32.20 |
| | chrisl: OK, thanks | 19:32.27 |
| chrisl | And mine compile failed <sigh>....... | 19:33.20 |
| | last minute quick edit always bites me in the a$$! | 19:34.07 |
| | henrys: here? | 19:51.49 |
| henrys | yes | 19:52.03 |
| chrisl | I've got a fix for Norbert's bug, but it would benefit from your review..... http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=c186880d | 19:52.38 |
| | It wasn't (only) down the issue he identified | 19:53.07 |
| henrys | chrisl:wow really? okay... | 19:56.45 |
| chrisl | henrys: it's basically the same issue Robin found in libpng a few weeks ago | 19:57.17 |
| henrys | not to say that sort of construct isn't going to screw us eternally but I'm surprised of the requirement. | 19:57.18 |
| chrisl | henrys: Yeh, it does seem *way* OTT, but apparently is so. Are you "happy" with the solution? | 19:58.13 |
| henrys | chrisl: yes I'm elated | 19:58.30 |
| chrisl | Great, I'll push that, then | 19:58.47 |
| | Thanks! | 19:58.56 |
| | henrys: actually the "hpgl call failed" errors still occur, but I consider that a different bug - although the output seems okay. | 20:04.13 |
| henrys | chrisl: it would be unusual for that to happen and there not be something wrong. | 20:05.15 |
| chrisl | henrys: I agree, it's just the bug is about a crash, which is fixed, I'd rather track the errors under a different bug number | 20:06.11 |
| henrys | assign it back to me and I'll look at those. | 20:06.16 |
| chrisl | Done | 20:09.15 |
| mvrhel_laptop | bbiaw | 20:09.53 |
| chrisl | henrys: actually, all the debug builds give those "hpgl call failed" errors, so it seems "correct" - do you still want to look into those, or will I just close the bug? | 20:44.06 |
| ray_laptop | chrisl: do we need to add something to genarch (or autoconf) to help us with jmpbuf alignment on various platforms ? | 20:45.26 |
| chrisl | ray_laptop: I thought about it, but that's probably going to be hard to do, since it's quite hard to test for require alignments in a reliable way | 20:47.20 |
| | Also, so far, I've only found reference to it for Windows, and not for other platforms - maybe Unices are less fussy..... | 20:49.36 |
| ray_laptop | chrisl: if we can test repeatedly (which involves being able to catch the error if it is wrong) we can start with PTR aligment and increase by 2x each time. | 20:49.40 |
| | chrisl: or maybe start with 8x PTR aligment, and loop down until PTR alignment doesn't fail. The last value written was the one that didn't bomb | 20:50.41 |
| | that way we can do it in genarch.c | 20:51.27 |
| chrisl | ray_laptop: it would mean having a signal handler in genarch | 20:51.37 |
| | ray_laptop: also, I'm not sure what we'd do with the information once we had it - the allocators won't know a (part of a) particular block of memory is a jmp_buf | 20:53.26 |
| ray_laptop | chrisl: not if we pass the test we write #undef for the previous value, then write the successful #define | 20:53.34 |
| chrisl | ray_laptop: but the executable doing writing (genarch) has just segv'ed | 20:54.17 |
| ray_laptop | chrisl: at least jmpbuf code can use it, or we can use that for all allocations | 20:54.28 |
| | chrisl: that's why we start with a LARGE value and go down by a factor of 2 | 20:54.57 |
| chrisl | ray_laptop: using it for all allocations won't help if, as in this case, the jmp_buf is in the middle of a structure | 20:55.14 |
| ray_laptop | so when it segv's we don't care. We have the last value that worked | 20:55.18 |
| | yeah. I see that would not work | 20:55.55 |
| chrisl | ray_laptop: Robin's investigations seem to support that this is a Windows only problem, too | 20:57.49 |
| ray_laptop | was just about to ask marcosw. Whose machine is 'i7' and why is it so FAST ? | 20:57.55 |
| | oh, he's back | 20:58.05 |
| | chrisl: yes. I consider it a bug in the RTL that they use SSE instructions that require alignment. | 20:58.46 |
| chrisl | ray_laptop: I think we're all agreed that's a bit of a mess. | 21:00.12 |
| ray_laptop | i7 is more than twice as fast doing regression tests compared to peeves and peeves is an i7 with an SSD for the system and a RAID-5 3-disk array that gets 2x the I/O net of a single drive | 21:00.53 |
| | Forward 1 day (to 2013/10/29)>>> | |
IRC Logs