IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2014/05/04)2014/05/05 
marcosw_ sebras: I'm going to reboot casper in a few minutes01: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 it07: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 guess07:57.23 
jo0nas he seems active on StackOverflow: https://stackoverflow.com/users/1306033/michael-slade08:02.23 
  He seems to be this guy on LinkedIn: https://www.linkedin.com/in/micksa08:02.47 
kens Tried LinkedIn08: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 it08:04.00 
kens We wanted to pay him the bounty, and I tried hard to contact him08:04.14 
  I didn't see him on SO, I'll try contacting him again that roue08:04.46 
  route*08:04.50 
jo0nas I understand - I don't imply foul play here08:04.55 
kens One reason for leaving the copyright message in place...08:05.33 
  But I will try again using SO08: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 code08:06.12 
jo0nas yes, I will try that08:07.33 
  we are finally close to being able to release new Ghostscript for Debian now - after a year stalling08: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 Debian08:10.12 
kens Oh, yes I guess that could be a problem08: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 here08: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. libtiff08:11.29 
  yes, the thread stuff!08:11.42 
kens Hmm, you'd have to talk to chrisl about that08:11.46 
jo0nas about libtrio, you mean?08:12.02 
kens Yes08:12.08 
jo0nas ok, thanks08:12.11 
kens We're vert pleased Marti agreed to do the memory improvement work08:12.22 
jo0nas we have it working now, but clutchy08:12.23 
chrisl Why do you need to take out libtrio?08:12.28 
jo0nas to link against system shared library instead08: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 website08: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 libraries08:14.04 
  right08:14.12 
chrisl So we're using trio exactly as intended and designed08:14.31 
jo0nas I know upstream is sloppy too - but Debian do care enough to do it properly08:14.41 
chrisl *We* are using trio properly08:14.56 
jo0nas fair enough if you don't want to change, then we just have to maintain our clutchy patch08:15.06 
chrisl There is no target in the trio makefiles to build anything other than a .a library08: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 over08: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 use08:16.33 
jo0nas ok08:16.40 
  zlib also had such "intended use" originally, I believe08: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 not08:17.31 
jo0nas I believe I saw a security bug a few days ago in libtrio08:17.40 
  yes, zlib has grown up08: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 code08:18.22 
  I hope you understand our choice of decoupling code08:18.37 
chrisl No, not really - it means you get untested packages08:18.53 
jo0nas ...and our interest in collaborating with you on that - even if upstream don't08: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 anymore08: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 release08:19.47 
jo0nas thanks, I'll do that08:20.30 
  kens: micksa is seen a month ago at StackExchange: https://music.stackexchange.com/users/2310/michael-slade08:23.01 
kens Hmm I was looking at SO....08:23.16 
jo0nas yes, that's what I found you before08: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/micksa08:23.56 
kens Yeah I'm no on Github08:24.25 
jo0nas perhaps this email address works: mslade@st.nepean.uws.edu.au08:25.08 
kens I'll try that as well, thanks08:25.25 
jo0nas whois for knobbits.org has a phone number (in Australia): +61.24722952508:26.26 
  ...and postal address as well08: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 door08: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 fails08:33.49 
  'recipient rejected - domain has no delivery address'08:34.09 
  So, I'm off for a swim08: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 library08:36.12 
chrisl When I had a poke around, I couldn't find changes to trio for *years* - that was another reason to use it08:40.55 
jo0nas nice09:08.11 
  I disagree that's a reason to not support system shared library when possible - and in Debian that is possible09:09.04 
  ...since 2 years09: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 perfect09:17.17 
  Debian is not the only way forward09: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 that09:18.24 
  ...and I extend that argument to it not only being possible in Debian but a practice for 2 years09:19.10 
chrisl In other words, Debian does things this way, and we should toe the line.....09:19.19 
jo0nas no no09: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 yet09:19.32 
jo0nas Debian does things this way, please consider supporting it - as you already nicely do for other libraries09: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 openjpeg209:21.19 
  (10:28:43) jonas: whois for knobbits.org has a phone number (in Australia): +61.24722952509: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/73865509: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 -lm09: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() produces09:47.00 
jo0nas oh09: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.patch09:47.50 
chrisl Well, clearly we can't use anything like that.......09:48.34 
jo0nas understood09:48.41 
  I didn't expect tht09:48.58 
  just thought perhaps that might be helpful in what you are trying to do now09: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 building09:50.12 
jo0nas right09: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/ceill09:52.24 
jo0nas sorry, I cannot help with programming09: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 help09:54.28 
jo0nas wish I could help out09:55.52 
jo0nas wish he could remember to talk in third tense when using /me on irc09: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 it10:13.25 
jo0nas thanks10:13.47 
tor8 Robin_Watts: ping.10:40.17 
  Robin_Watts: bug 694909 happens because the fix in commit 2f8c9375dc0624aff0bac7f5efe4dcbee78453a410:40.55 
  adds a conversion from the file JPX colorspace *into* a devicen/separation colorspace10:41.10 
  our color management only handles conversions *from* devicen/separation10: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 problem10:43.00 
  other than not trying such conversions. so I think we need to add a "can-be-destination-colorspace" check to load-jpx10: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 one11:16.26 
tor8 yes, and then you try to convert from RGB to DeviceN11:26.54 
  but that step fails on an assert11:26.59 
  there's a fix on tor/master for it which I think is reasonable enough11:27.08 
  given that there is no fail-safe way to convert into a DeviceN11:27.24 
  we might want to wrap the if (origcs->from_rgb) check into a convenience function11:27.49 
  but given its use in one location only, I'm not terribly bothered11: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 otherwise11: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 remember11:49.27 
tor8 which makes your commit rather conditional and I don't really see the value11: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, though11: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 lunch11:56.45 
Ziai guys have u seen jhabjan lately?12:23.21 
kens2 nope12:23.55 
henrys shouldn't have said anything about the holiday looks like everybody is here .13:29.55 
ighostxhub hello room14:00.57 
mcx5 ...14:02.35 
kens2 Morning Ray14:57.09 
ray_laptop hi, kens15:07.57 
kens2 Morning Michael15:44.07 
mvrhel_laptop morning kens215:50.58 
  brb. need to restart16:23.40 
kens2 goodnight all16: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 course16: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:5016:44.42 
  It was wet and cold though16: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 t16: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 congrats16:48.19 
mvrhel_laptop and she just barely made it.16:48.21 
  will do16: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/216: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 most16:50.19 
henrys mvrhel_laptop: probably sensible ;-)16:57.04 
mvrhel_laptop yes, things start to hurt beyond that16: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 running16:58.02 
mvrhel_laptop well, its the training that gets me16:58.20 
ray_laptop which is why I don't run16: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 fun16: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 69520517: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: yes17: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_rop17: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 defined17: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 though17: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 suppose17:27.46 
Robin_Watts OK, so it's commit: 13ceed2517:28.43 
  Add code for using run_rops for 8 and 24 bit targets too. Cluster testing shows17:28.52 
  that this gives the same results, but limited local testing suggests the setup17: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 spaghetti18: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 199818:48.36 
  now to see if my simple fix breaks anything18:49.26 
Robin_Watts Gah. I need Memento in Smart Office :(19:19.28 
 Forward 1 day (to 2014/05/06)>>> 
ghostscript.com
Search: