| <<<Back 1 day (to 2014/05/04) | 2014/05/05 |
marcosw_ | sebras: I'm going to reboot casper in a few minutes | 01:06.25 |
jo0nas | what is license for base/ramfs.c? It is copyright Michael Slade but lacks explicit licensing, and http://bugs.ghostscript.com/show_bug.cgi?id=226943 doesn't indicate Michael has licensed it | 07:55.55 |
kens | We've been unable to contact him, I chose to leave the copyright information in, but assume that he has granted it as AGPL. I should probably change it I guess | 07:57.23 |
jo0nas | he seems active on StackOverflow: https://stackoverflow.com/users/1306033/michael-slade | 08:02.23 |
| He seems to be this guy on LinkedIn: https://www.linkedin.com/in/micksa | 08:02.47 |
kens | Tried LinkedIn | 08:02.58 |
jo0nas | seems to me that he reacted on a bounty, so not sure he is pleased the code is grabbed without him getting his reward for it | 08:04.00 |
kens | We wanted to pay him the bounty, and I tried hard to contact him | 08:04.14 |
| I didn't see him on SO, I'll try contacting him again that roue | 08:04.46 |
| route* | 08:04.50 |
jo0nas | I understand - I don't imply foul play here | 08:04.55 |
kens | One reason for leaving the copyright message in place... | 08:05.33 |
| But I will try again using SO | 08:05.50 |
jo0nas | just hesitant moving to 9.14 for Debian due to this :-/ | 08:05.53 |
| thanks! | 08:05.56 |
kens | You can always remove the ramfs code | 08:06.12 |
jo0nas | yes, I will try that | 08:07.33 |
| we are finally close to being able to release new Ghostscript for Debian now - after a year stalling | 08:08.20 |
kens | WHy so long ? | 08:08.36 |
jo0nas | we don't want code copies, and it took a long time for your improvements to lcms2 to enter Debian | 08:10.12 |
kens | Oh, yes I guess that could be a problem | 08:10.28 |
| wDid you get the new LCMS ? | 08:10.40 |
| With all the thread safety stuff ? | 08:10.57 |
kens | is hazy on the details here | 08:11.03 |
jo0nas | when that was ready, I noticed you'd introduced libtrio which was more tricky to rip out because you haven't implemented the flexible flag for that as you have for e.g. libtiff | 08:11.29 |
| yes, the thread stuff! | 08:11.42 |
kens | Hmm, you'd have to talk to chrisl about that | 08:11.46 |
jo0nas | about libtrio, you mean? | 08:12.02 |
kens | Yes | 08:12.08 |
jo0nas | ok, thanks | 08:12.11 |
kens | We're vert pleased Marti agreed to do the memory improvement work | 08:12.22 |
jo0nas | we have it working now, but clutchy | 08:12.23 |
chrisl | Why do you need to take out libtrio? | 08:12.28 |
jo0nas | to link against system shared library instead | 08:12.47 |
| same as for tiff, openjpeg, lcms2 zlib etc. | 08:13.11 |
kens | Hmm, I cant see any obvious way for me to contact Michael Slade via Stack Overflow. I guess I can try his website | 08:13.40 |
chrisl | "Trio is intended to be an integral part of another application, so we have not done anything to create a proper installation." | 08:13.41 |
jo0nas | would be nice if you'd implement a SHARE_TRIO the same as you've done for other libraries | 08:14.04 |
| right | 08:14.12 |
chrisl | So we're using trio exactly as intended and designed | 08:14.31 |
jo0nas | I know upstream is sloppy too - but Debian do care enough to do it properly | 08:14.41 |
chrisl | *We* are using trio properly | 08:14.56 |
jo0nas | fair enough if you don't want to change, then we just have to maintain our clutchy patch | 08:15.06 |
chrisl | There is no target in the trio makefiles to build anything other than a .a library | 08:15.33 |
jo0nas | right, because upstream don't see a need to maintain makefiles for that - they suggest downstreams (like you) to simply copy things over | 08:16.10 |
kens | Well the knobbits.org website is 'out of order', and I can't see any method for contacting a SO user, and trying to contact Michael via LinkedIn didn't work, so I'm back where I was before..... | 08:16.18 |
jo0nas | :-( | 08:16.28 |
chrisl | In fact, one of the reasons I chose trio was because of its intended use | 08:16.33 |
jo0nas | ok | 08:16.40 |
| zlib also had such "intended use" originally, I believe | 08:17.06 |
| ...then a security bug was found in that code, and all hell broke loose... | 08:17.24 |
chrisl | zlib now ships with targets to build shared libs, trio does not | 08:17.31 |
jo0nas | I believe I saw a security bug a few days ago in libtrio | 08:17.40 |
| yes, zlib has grown up | 08:17.55 |
chrisl | trio is tiny - it wastes resources forcing it to be a shared library...... | 08:18.18 |
jo0nas | I understand your choice of copying code | 08:18.22 |
| I hope you understand our choice of decoupling code | 08:18.37 |
chrisl | No, not really - it means you get untested packages | 08:18.53 |
jo0nas | ...and our interest in collaborating with you on that - even if upstream don't | 08:18.53 |
kens | Oh, Michael's most recent answer was April 17th 2012 as far as I can see, I guess he's not that active on SO anymore | 08:19.19 |
chrisl | jo0nas: if it's really that big a deal, open a bug, make sure it's the "build system" component, and I'll look at it for the next release | 08:19.47 |
jo0nas | thanks, I'll do that | 08:20.30 |
| kens: micksa is seen a month ago at StackExchange: https://music.stackexchange.com/users/2310/michael-slade | 08:23.01 |
kens | Hmm I was looking at SO.... | 08:23.16 |
jo0nas | yes, that's what I found you before | 08:23.42 |
kens | Anyway, I'm trying again with LinkedIn (if I can get it to co-operate with me) | 08:23.46 |
jo0nas | he is also at Github, but seemingly not active for a year: https://github.com/micksa | 08:23.56 |
kens | Yeah I'm no on Github | 08:24.25 |
jo0nas | perhaps this email address works: mslade@st.nepean.uws.edu.au | 08:25.08 |
kens | I'll try that as well, thanks | 08:25.25 |
jo0nas | whois for knobbits.org has a phone number (in Australia): +61.247229525 | 08:26.26 |
| ...and postal address as well | 08:26.46 |
kens | I wasn't really prepared to go quite that far to pay someone.... | 08:27.05 |
| I'd rather contact some friends and ask them to go knock on his door | 08:27.22 |
| (which is a bit creepy thinking about it) | 08:27.35 |
jo0nas | :-) | 08:28.08 |
kens | The mslade@st.nepean.uws.edu.au mail address fails | 08:33.49 |
| 'recipient rejected - domain has no delivery address' | 08:34.09 |
| So, I'm off for a swim | 08:34.27 |
jo0nas | enjoy :-) | 08:35.27 |
| there is no recent security issue with libtrio (that I know of) - I must've mistaken it for a different library | 08:36.12 |
chrisl | When I had a poke around, I couldn't find changes to trio for *years* - that was another reason to use it | 08:40.55 |
jo0nas | nice | 09:08.11 |
| I disagree that's a reason to not support system shared library when possible - and in Debian that is possible | 09:09.04 |
| ...since 2 years | 09:09.21 |
chrisl | I'm not sure Debian is the arbiter of all that's "right" | 09:09.59 |
jo0nas | I am sure Debian is *not* the arbiter of all that's "right" | 09:15.51 |
| you can end the conversation by talking in absolutes - but then we can also simply not have it in the first place :-) | 09:16.42 |
| Debian is not perfect | 09:17.17 |
| Debian is not the only way forward | 09:17.29 |
| I simply argued that in Debian it is possible for libtrio to be a system shared library, and I see a reason for then making use of that | 09:18.24 |
| ...and I extend that argument to it not only being possible in Debian but a practice for 2 years | 09:19.10 |
chrisl | In other words, Debian does things this way, and we should toe the line..... | 09:19.19 |
jo0nas | no no | 09:19.25 |
tor8 | jo0nas: while you're here, on a separate project, mupdf ... we use openjpeg2 but I still haven't seen that version appear in a debian repository yet | 09:19.32 |
jo0nas | Debian does things this way, please consider supporting it - as you already nicely do for other libraries | 09:19.56 |
jogux_mac | kens : re michael slade - the whois for knobbits.org appears to have a phone number... | 09:21.16 |
jo0nas | looking up status on openjpeg2 | 09:21.19 |
| (10:28:43) jonas: whois for knobbits.org has a phone number (in Australia): +61.247229525 | 09:21.36 |
| :-) | 09:21.41 |
jogux_mac | oh, sorry, I'm behind in the logs :-) | 09:21.57 |
jo0nas | jogux_mac: :-) | 09:22.05 |
| tor8: openjpeg2 seems likely to emerge in Debian within a month perhaps. It is tracked at https://bugs.debian.org/738655 | 09:27.20 |
chrisl | jo0nas: I can't seem to get the libtrio in Ubunto to work..... | 09:44.59 |
jo0nas | :-( | 09:45.20 |
chrisl | Gives me a bunch of linker errors on math functions, despite using -lm | 09:45.47 |
jo0nas | locates our current crude patch, in case that's any help... | 09:46.11 |
chrisl | jo0nas: this isn't Ghostscript, this is just an ickle test prog like AC_CHECK_LIB() produces | 09:47.00 |
jo0nas | oh | 09:47.27 |
chrisl | I wonder if there are macros..... | 09:47.43 |
jo0nas | We intend to use this for Ghostscript: http://anonscm.debian.org/gitweb/?p=printing/ghostscript.git;a=blob;f=debian/patches/2009_build_with_system_libtrio.patch | 09:47.50 |
chrisl | Well, clearly we can't use anything like that....... | 09:48.34 |
jo0nas | understood | 09:48.41 |
| I didn't expect tht | 09:48.58 |
| just thought perhaps that might be helpful in what you are trying to do now | 09:49.20 |
chrisl | It won't take long to do it "properly", but if I can't get a simple test case to link, I can't test Ghostcript building | 09:50.12 |
jo0nas | right | 09:50.32 |
| seems Ubuntu is using Debian libtrio package as-is (just recompiling, not behind or with additional patches applied) | 09:51.14 |
chrisl | Nevertheless, I don't understand how I'm getting link errors on thing like powl/fmodl/ceill | 09:52.24 |
jo0nas | sorry, I cannot help with programming | 09:52.41 |
jo0nas | tries get odyx to join here - he did the patch... | 09:53.32 |
chrisl | Oh, looks like they are c99 functions :-( | 09:53.47 |
| Nope, that doesn't help | 09:54.28 |
jo0nas | wish I could help out | 09:55.52 |
jo0nas | wish he could remember to talk in third tense when using /me on irc | 09:56.26 |
| odyx not responding - perhaps afk during working hours (european time) | 09:58.34 |
chrisl | So, that's confusing - linking gs to it libtrio doesn't error out.....ugh :-( | 10:01.54 |
| jo0nas: anyway, I'll look at sharing trio properly after I get a bug report about it | 10:13.25 |
jo0nas | thanks | 10:13.47 |
tor8 | Robin_Watts: ping. | 10:40.17 |
| Robin_Watts: bug 694909 happens because the fix in commit 2f8c9375dc0624aff0bac7f5efe4dcbee78453a4 | 10:40.55 |
| adds a conversion from the file JPX colorspace *into* a devicen/separation colorspace | 10:41.10 |
| our color management only handles conversions *from* devicen/separation | 10:41.21 |
| (and likewise we'd run into the same issue for indexed colorspaces) | 10:41.42 |
| and considering that there is only a transform from devicen into alternate tint, not the other way, I don't really see how we can solve that problem | 10:43.00 |
| other than not trying such conversions. so I think we need to add a "can-be-destination-colorspace" check to load-jpx | 10:43.42 |
Robin_Watts | looking. | 11:10.15 |
| So the JPX is claiming to be RGB (or something), but the PDF file tags it as being a devicen space? | 11:14.38 |
kens2 | 11aaaaaIIRC in that case then ytou use the JPX colour space and ignore the PDF one | 11:16.26 |
tor8 | yes, and then you try to convert from RGB to DeviceN | 11:26.54 |
| but that step fails on an assert | 11:26.59 |
| there's a fix on tor/master for it which I think is reasonable enough | 11:27.08 |
| given that there is no fail-safe way to convert into a DeviceN | 11:27.24 |
| we might want to wrap the if (origcs->from_rgb) check into a convenience function | 11:27.49 |
| but given its use in one location only, I'm not terribly bothered | 11:28.04 |
| kens2: the commit from Robin_Watts that I referenced explicitly does the opposite of what you said (presumably to fix some softmask colorspace issue) | 11:29.25 |
kens2 | I'm sure the spec says otherwise | 11:29.57 |
tor8 | reverting that commit would be my preference, but I'll leave the choice to Robin_Watts. he should more about the issue at hand, but he might have forgotten everything about it :) | 11:30.44 |
Robin_Watts | tor8: So the JPX says DeviceN, but the PDF file says RGB? | 11:45.16 |
| If your commit doesn't make 1439 - color softmask fails to draw jpx image.pdf look worse, then I have no problem with it. | 11:47.05 |
| yeah, my preference would, I think, be to just take your commit on and not revert anything. | 11:47.37 |
tor8 | Robin_Watts: no, the opposite. JPX says RGB, PDF says DeviceN. | 11:48.24 |
| your commit tries to turn that from RGB into DeviceN (in opposition of what kens says the spec should do) | 11:48.56 |
Robin_Watts | OK, that makes sense. | 11:49.09 |
tor8 | my commit makes that not happen if the PDF colorspace is DeviceN (since we can't convert into that) | 11:49.20 |
kens2 | I'm pretty sure the spec says the JPX takes precedence, its about the only place that does say that which is why I remember | 11:49.27 |
tor8 | which makes your commit rather conditional and I don't really see the value | 11:49.31 |
Robin_Watts | The top 4 commits all look goot to me. | 11:49.33 |
| tor8: Well, "1439 - color softmask fails to draw jpx image.pdf" is the torture test file here I think. | 11:50.29 |
tor8 | it still fails even with your commit, though | 11:52.45 |
Robin_Watts | yes, but without my commit it was worse. | 11:53.12 |
| it needs transfer functions to stand a chance of being utterly correct. | 11:53.26 |
tor8 | error: soft mask must be grayscale, we might be able to do the 'to-grayscale' conversion there instead of throwing? | 11:53.33 |
| agreed. it was worse. | 11:54.01 |
| I wonder if zeniko's transfer function patch will make it work. | 11:54.10 |
| I'll poke at that after lunch | 11:56.45 |
Ziai | guys have u seen jhabjan lately? | 12:23.21 |
kens2 | nope | 12:23.55 |
henrys | shouldn't have said anything about the holiday looks like everybody is here . | 13:29.55 |
ighostxhub | hello room | 14:00.57 |
mcx5 | ... | 14:02.35 |
kens2 | Morning Ray | 14:57.09 |
ray_laptop | hi, kens | 15:07.57 |
kens2 | Morning Michael | 15:44.07 |
mvrhel_laptop | morning kens2 | 15:50.58 |
| brb. need to restart | 16:23.40 |
kens2 | goodnight all | 16:37.47 |
henrys | mvrhel_laptop: how was the marathon - I saw the winning times were a bit slow, don't know if that's weather or just a difficult course | 16:44.09 |
mvrhel_laptop | henrys: stephanie was happy with her time. her goal on the half was to be under 2 hours and she was 1:59:50 | 16:44.42 |
| It was wet and cold though | 16:44.56 |
Robin_Watts | Congrats. | 16:45.49 |
| Woah, wait... | 16:46.21 |
| Her time to the half was just under 2 hours? Not "the time that she decided she wanted t | 16:47.07 |
henrys | mvrhel_laptop: that is a great time. | 16:47.27 |
Robin_Watts | Bah. I am confused. | 16:48.12 |
mvrhel_laptop | Robin_Watts: her goal was to be under 2 hours in the half. | 16:48.13 |
henrys | mvrhel_laptop: tell her I said congrats | 16:48.19 |
mvrhel_laptop | and she just barely made it. | 16:48.21 |
| will do | 16:48.22 |
Robin_Watts | So her first half took 1:59:50? How long did the second half take ? | 16:48.37 |
mvrhel_laptop | ah. Robin_Watts, this time she just ran the 1/2 | 16:48.52 |
Robin_Watts | Ah. I understand then. | 16:49.02 |
| She beat my only race half marathon time by 2 minutes then :) | 16:49.29 |
mvrhel_laptop | well you all beat me. I only run 5Ks at most | 16:50.19 |
henrys | mvrhel_laptop: probably sensible ;-) | 16:57.04 |
mvrhel_laptop | yes, things start to hurt beyond that | 16:57.22 |
ray_laptop | mvrhel_laptop: and that's just during the race. The next day (or week or month) is what gets me with running | 16:58.02 |
mvrhel_laptop | well, its the training that gets me | 16:58.20 |
ray_laptop | which is why I don't run | 16:58.24 |
| mvrhel_laptop: yeah, training is *really* boring. Not like tennis or something fun :-) | 16:59.20 |
| that's why I like tennis. training is playing (for the most part) | 16:59.48 |
| and even a ball machine can be fun | 16:59.58 |
mvrhel_laptop | right. | 17:00.08 |
ray_laptop | but running has advantages over tennis. Rarely do you have to wait for the track or road :-) | 17:00.55 |
| the cmd_put_path logic "skipping" logic is totally broken :-( I wonder why this never showed up before bug 695205 | 17:04.15 |
henrys | ray_laptop: I know showing up for that running group with all those 30 year old women in shorts, just bores me to tears ;-) | 17:05.02 |
| Robin_Watts: I did do some looking at performance issues for PCL with jeita files, there seems to be a case for speeding up xor between source and destination. I'd also like to split up the 24 and 8 bit output case. 8 bit output isn't going to get used in the PCL world. | 17:08.32 |
Robin_Watts | henrys: This is runrop stuff? | 17:09.00 |
henrys | Robin_Watts: yes | 17:09.09 |
| Robin_Watts: also I notice we are doing a lookup in the rop table per pixel, I don't know if we should depend on the compiler catching that. I know you are busy with other stuff, just bouncing this stuff off of you. | 17:11.48 |
Robin_Watts | How exactly do you want to separate the 8 and 24 bit ones? | 17:11.48 |
| The key thing is that we call 'rop_get_run_op' just once, but we call the returned function many times. | 17:12.20 |
henrys | the 8-bit destination stuff should be in another procedure entirely. | 17:12.36 |
Robin_Watts | That would mean having depth not be a param. | 17:12.55 |
| which would be a problem for gdevmr8n. | 17:13.41 |
henrys | Robin_Watts: maybe I'm reading the code wrong. rop_body_24 is inlined, right? | 17:14.05 |
Robin_Watts | Urm... where does PCL call the rop stuff from? | 17:14.20 |
henrys | Robin_Watts: what do you mean memory devices with 24 bit output would have a 24 bit output rop routine and 8 bit output devices would have another. | 17:15.19 |
Robin_Watts | Are you sure we're talking rop runs, rather than just rop's here ? | 17:15.42 |
| I can't see PCL calling rop runs anywhere. If you're calling just plain rops, then you will be MUCH slower. | 17:16.23 |
henrys | I'm looking at: mem_gray8_rgb24_strip_copy_rop | 17:16.35 |
Robin_Watts | with USE_RUN_ROP defined ? | 17:17.29 |
henrys | ah I see what you mean, no USE_RUN_ROP is not defined | 17:18.30 |
Robin_Watts | ah, well, expect slowness. | 17:18.49 |
| It looks to me like rop_body_24 is a macro. | 17:19.34 |
henrys | I don't see that either of the issues I brought up would be different with your code, but I'll try it. | 17:20.01 |
Robin_Watts | That checks for source or dest transparency, and then looks up rop_proc_table each time, and then calls the function, and then writes the function. | 17:20.19 |
| Which case are you currently going through? | 17:21.00 |
| Ah, right, COMPARE_AND_CONTRAST :) | 17:21.29 |
| Let me talk you through this. | 17:21.46 |
henrys | Robin_Watts: and if you expect this to be slow why haven't we pushed your changes through. I guess I forgot something about this. | 17:21.50 |
Robin_Watts | In the constant source & texture case... | 17:22.17 |
| we pass in the params to rop_get_run_op, and we get a function pointer back. | 17:22.45 |
henrys | I'm looking in my profile at line 647 can you give me your line. | 17:22.57 |
Robin_Watts | line 207. | 17:23.07 |
henrys | ? | 17:23.08 |
Robin_Watts | We set s and t to be constant. | 17:23.31 |
henrys | so I was 400 lines off in the same procedure ugh. | 17:23.40 |
Robin_Watts | Then (ignoring the COMPARE_AND_CONTRAST section) we make one call to the ropper function. | 17:24.04 |
| hence only 1 lookup, only 1 function call for a run of pixels, and the code in there can be as optimised as we like. | 17:24.50 |
henrys | Robin_Watts: I see so I should certainly profile with the USE_RUN_ROP, still confused why we didn't turn this on though | 17:25.57 |
Robin_Watts | me too. | 17:25.58 |
| I suspect that we found that for some files, (in particular those where "width" was very small), this ended up being slower. | 17:26.16 |
| possibly we should have an if (width < 4) { old code } else { new code } | 17:27.15 |
| and live with the bloat. | 17:27.16 |
henrys | with that width we could punt back to the default routine I suppose | 17:27.46 |
Robin_Watts | OK, so it's commit: 13ceed25 | 17:28.43 |
| Add code for using run_rops for 8 and 24 bit targets too. Cluster testing shows | 17:28.52 |
| that this gives the same results, but limited local testing suggests the setup | 17:28.54 |
| costs mean this isn't yet a win. Therefore leaving disabled for now. | 17:28.56 |
henrys | Robin_Watts: I have a bunch of stuff to do today but I'll profile more with the JEITA files tomorrow. I suspect they will benefit from the change based on profiling the old code. | 17:31.25 |
| which would warrant enabling it. | 17:31.43 |
Robin_Watts | henrys: I think the reason we (I) didn't enable this before was that I had a single test file, and I wasn't seeing a win. | 17:31.55 |
| henrys: If you find there are specific rops that are used commonly we can optimise those ones further. | 17:39.52 |
| Wow, I'm glad we got bug 695209 sorted :) | 18:07.59 |
ray_laptop | I now understand why the extra line with bug 695205 is rare. it has to be a closepath on a subpath when the moveto starting the subpath is the same as the endpoint of the last line not skipped in the previous subpath. This causes the current logic to skip the moveto, so the closepath goes to the start point of the previous path. | 18:09.11 |
| now to dive into the spaghetti | 18:10.51 |
| anybody have a code fork ? | 18:11.04 |
Robin_Watts | This is presumably clist pasta, rather than graphics rendering pasta ? | 18:14.48 |
ray_laptop | Robin_Watts: yes, it was the cmd_put_path clist pasta It wasn't that hard, to my amazement. I'm running a regression test now. | 18:45.12 |
Robin_Watts | ray_laptop: great! | 18:46.18 |
ray_laptop | WOW!! That bug has been in since the initial commit in 1998 | 18:48.36 |
| now to see if my simple fix breaks anything | 18:49.26 |
Robin_Watts | Gah. I need Memento in Smart Office :( | 19:19.28 |
| Forward 1 day (to 2014/05/06)>>> | |