| | <<<Back 1 day (to 2013/03/22) | 2013/03/23 |
| Robin_Watts | marcosw: You here? | 00:19.18 |
| marcosw | Robin_Watts: yup. | 00:21.09 |
| Robin_Watts | I've been looking into some mupdf indetermisms on the cluster. | 00:21.29 |
| | it seems that xeon and macpro in particular give slightly different fp results. | 00:21.43 |
| marcosw | I read a bit of the discussion. | 00:22.13 |
| Robin_Watts | I've tracked down one place where it happens. It seems that: a+(b-a)*x can evaluate to different things in different places. | 00:22.17 |
| | but it basically seems to be how the compiler optimises stuff - probably the order of operations etc. | 00:22.35 |
| | I guess gs must use less fp :( | 00:22.58 |
| | I'm not sure I see any easy route around this. | 00:23.20 |
| marcosw | we could eliminate the two macpros from the cluster when running mupdf regressions. they run so quickly it's not going to matter much. | 00:28.02 |
| Robin_Watts | Is xeon a macpro? | 00:28.15 |
| marcosw | yes. | 00:28.31 |
| Robin_Watts | That would, I think give us consistency at least. | 00:28.38 |
| marcosw | I though the the differences were the 32 vs 64 bit binaries. | 00:29.06 |
| | but that was just a guess... | 00:29.24 |
| Robin_Watts | When I was thinking about adding a windows cluster node, I pondered about having the clients send a set of capabilities. | 00:29.41 |
| | and then having the cluster take note of those capabilities. | 00:29.55 |
| | but it never got further than idle thought. | 00:30.12 |
| | I've worked around one of the FP differences, but there is still at least one more in the same page of the same file. | 00:30.54 |
| marcosw | that's one solution, I think it's easier to just maintain a file on casper that lists the capabilities of each machine. E.g. some nodes can't do 32 bit compiles, others don't run valgrind, ... | 00:31.30 |
| Robin_Watts | and when I found another one in freetype, I just gave up - I can't see us bending freetype to make it work. | 00:31.32 |
| marcosw | if there is an issue with free type why doesn't it affect GHostscript? | 00:32.08 |
| Robin_Watts | marcosw: The advantage of having the nodes send the capabilities is that they can autodetect some of them (so if the version of gcc changes, or valgrind gets installed etc). | 00:32.11 |
| | marcosw: I don't know. | 00:32.22 |
| | Possibly gs extracts outlines and scales them itself? | 00:32.34 |
| | wheras freetype gets bitmaps back? | 00:32.42 |
| | s/freetype/mupdf/ | 00:32.51 |
| marcosw | right, I didn't realize that gs and mu were that different in how they call free type. | 00:33.23 |
| Robin_Watts | There are definite differences - I don't claim to be an expert on them, as tor has done all that. | 00:34.04 |
| marcosw | the problem with having each nodes declare the capabilities is that we don't want some nodes running some tests even if they have the capability, i.e. Henry's MacPro has valgrind installed on it but he said not to use it. I'm not sure why, perhaps it's an old version. So we have to have an exception list. Also I don't see how we'd have the machines decide if they were capable of correctly performing floating point :-) | 00:36.39 |
| Robin_Watts | marcosw: We'd key on the version of gcc, I suspect. | 00:40.23 |
| | One capability could be "IS_ALLOWED_TO_RUN_MUPDF_TESTS" | 00:40.49 |
| | hence no exception list required. | 00:41.08 |
| marcosw | I'm still not sure why the mac's wouldn't report "IS_ALLOWED_TO_RUN_MUPDF_TESTS". They run the tests just fine, it's the other nodes that are wrong :-) | 00:43.07 |
| | okay, i've put macpro and xeon into the exclude list for mupdf and mujstest. It should work for clusterpush and commit tests (I've obviously only tested the clusterpush case). | 00:57.48 |
| | Robin_Watts: ^^^ | 00:57.53 |
| henrys | hi mvrhel_laptop | 14:53.21 |
| | my nephew is just getting ready to compete: http://www.coderedrobotics.com/webcast/West-Michigan-FIRST-Robotics-District-Competition/ | 14:55.30 |
| atmos4 | hi | 15:15.42 |
| | I've got a pdf file that is insanely slow to process on the server, taking more than 60 minutes to extract 15 pages to jpeg, while locally it takes only 30 seconds. The server was running debian squeeze gs 8.71 but has since been upgraded to the latest build from unstable (9.05-7). Local version is 9.06 on Mac OS X. | 15:18.16 |
| | Still the problem persist on the server, so how can I debug what exactly is causing the slowdown? | 15:18.36 |
| | I know that debian replaces most of the built-in shared libraries with system provided copies, so that could be a problem. | 15:19.18 |
| | the pdf contains just images in 16-bit/channel. | 15:19.36 |
| | hmm, just downloaded a linux binary and it's fast | 15:26.02 |
| | guess I'll try building the debian package with 9.07 | 15:26.21 |
| mvrhel_laptop | morning henrys | 15:51.20 |
| | cool | 15:51.35 |
| henrys | he's won 2 matches so far | 15:51.50 |
| mvrhel_laptop | they are having a competition here in seattle this weekend | 15:51.57 |
| | that looks like fun | 15:52.09 |
| henrys | atmos4:without admin access to the server I am not sure how to debug cups | 16:04.06 |
| atmos4 | henrys: why cups? | 16:04.34 |
| henrys | atmos4:oh I thought it was a print system | 16:04.42 |
| | what does the server do? | 16:04.48 |
| atmos4 | no it's extracting jpegs from a pdf | 16:04.54 |
| henrys | our software does not extract jpegs it renders pdf to jpeg and other formats. | 16:05.33 |
| atmos4 | yeah, but you get the point =) | 16:06.08 |
| henrys | do you have the command line option gs is using on the server/ | 16:06.48 |
| | ? | 16:06.50 |
| atmos4 | normally it splits the pdf to single pages, but for now I'm trying the simplest case | 16:06.52 |
| | gs -dNOPAUSE -sDEVICE=jpeg -sOutputFile="tmp/page-%d.jpg" slow.pdf -c quit | 16:07.28 |
| | that's the command I'm testing with that is enough to reproduce the behaviour | 16:08.08 |
| henrys | if you change the device to ppmraw is the slowdown apparent? | 16:16.06 |
| atmos4 | henrys: yes, that makes no difference | 16:21.14 |
| | if I run strace I just see endless read/lseek with a constant blocksize of 8k | 16:22.54 |
| henrys | yup that is what I was going to suggest next or maybe oprofile | 16:23.41 |
| atmos4 | henrys: I could send you a link to the problematic file | 16:28.50 |
| henrys | atmos4:only happens with that file? | 16:29.49 |
| atmos4 | that's the one I copied when the background queue was choking on it | 16:30.29 |
| | but it happened a day before aswell, so I guess it was neither the first nor will it be the last problematic file | 16:30.55 |
| | the app allows users to uplaod pdfs files, which will then be split into single pages in a background queue, which also creates thumbnails | 16:31.34 |
| henrys | atmos4:what app is this? | 16:31.53 |
| atmos4 | oh it's a web application that handles processing of orders for a customer | 16:32.32 |
| henrys | atmos4:which one? | 16:33.19 |
| atmos4 | oh, it's custom built for our customer, it's built on top of ruby on rails, but you'll need a login to access it | 16:34.09 |
| | it uses a combination of direct gs and graphicsmagick calls to do the processing and does that in a background queue, so the frontend doesn't block | 16:35.16 |
| | given that they are working with contractors all over the country, we don't have control over the format or app that generates the pdfs | 16:37.13 |
| henrys | atmos4:this is all beginning to sound a little commercial to me. You could pursue a support contract with scott.sackett@artifex.com and then we can help you. | 16:38.48 |
| atmos4 | henrys: oh it is definitly commercial | 16:39.19 |
| | I was just looking for some general debugging guidelines | 16:39.49 |
| | I know that I can solve it by using some newer build of ghostscript, but I was interested to find out what's actually triggering the problem | 16:40.34 |
| henrys | We've switched to the Affero GPL license as long as you comply with that, yes. | 16:42.24 |
| | maybe some weird library did you "ldd" each gs? | 16:44.44 |
| atmos4 | henrys: given that I'm calling the gs binary and not modifying it's source I wouldn't know how the license would affect me | 16:45.06 |
| Robin_Watts | atmos4: You're fine then. | 16:45.40 |
| henrys | atmos4:you said you were calling it "directly" and I wasn't sure what that meant. but yes you are fine | 16:46.15 |
| atmos4 | henrys: directly as in not through graphicsmagick | 16:46.32 |
| | becuase graphcism,agickl/imagemagick do some very inefficient thinks when working with pdfs | 16:46.53 |
| | things | 16:46.56 |
| Robin_Watts | Frankly though, it still sounds like you're making money out of it; being a 'good citizen' and taking a support contract out would help to "put something back" as it were. | 16:47.24 |
| henrys | atmos4:nonetheless you are a commercial operation and we'd prefer you get a support contract if you want us to help you. | 16:47.33 |
| atmos4 | I usually contribute back by providing patches/pull requests for new features or bugfixes | 16:48.16 |
| | so I consider myself a good citizen when it comes to working with open source software | 16:48.30 |
| | I do realize that I have no right whatsoever on getting support | 16:48.51 |
| henrys | mvhrel_laptop:my nephew made it to the next level, I am still trying to sort out the scoring and rules | 16:49.20 |
| | or mvrhel_laptop even. | 16:52.34 |
| mvrhel_laptop | cool | 16:53.31 |
| henrys | we're supposed to get 14" of snow here, close to 8 now. | 16:58.46 |
| atmos4 | henrys: where are you located? | 16:59.46 |
| henrys | colorado | 16:59.57 |
| Robin_Watts | We have 6 inches here. | 17:00.13 |
| henrys | Robin_Watts: that's odd this time of year, no? | 17:00.35 |
| atmos4 | I'd be happy if it finally stopped snowing and the spring would begin =) | 17:01.15 |
| henrys | atmos4:where are you? | 17:01.37 |
| atmos4 | germany | 17:01.43 |
| Robin_Watts | henrys: yeah, late for us. | 17:01.47 |
| | atmos4: Ah. I'm in the UK. | 17:02.11 |
| atmos4 | there's usually enough snow to be annoying and too little to be fun =) | 17:02.24 |
| | hmm, I wish debians package format was as lightweight as homebrew on the mac. I wonder why they have thee sets of checksums of all the files | 17:03.49 |
| | even with crc32 it should be impossible to have a mismatch, but they have sha1, sha256 and md5 | 17:04.11 |
| | in homebrew all you need to do for a new version is change the source url and update the checksums | 17:05.39 |
| | maybe update the version number if it uses some crazy format | 17:06.08 |
| | Robin_Watts: do you still have snow in the UK? wheather can't be much warmer than here unless you're at the coast | 17:07.59 |
| chrisl_away | atmos4: just a thought: does the problem file have JPX encoded image date in it? | 17:25.36 |
| atmos4 | chrisl_away: what's the quickest way to find that out? | 17:26.48 |
| chrisl_away | atmos4: maybe grep it for JPX - let me check..... | 17:27.31 |
| atmos4 | I have acrobat if that helps | 17:27.46 |
| chrisl_away | Reader or Pro? | 17:28.07 |
| atmos4 | pro | 17:28.12 |
| chrisl_away | okay, the examples I've got here, I can just grep for "JPX" | 17:28.31 |
| atmos4 | I'll check that | 17:28.42 |
| | yes, it has JPX images | 17:29.06 |
| | ran strings example.pdf |grep -i jpx | 17:29.17 |
| henrys | chrisl_away:jasper vs openjpeg? | 17:29.44 |
| chrisl_away | henrys: that's what I'm thinking | 17:29.52 |
| atmos4 | that could be the case | 17:29.59 |
| henrys | ldd would say | 17:30.02 |
| atmos4 | debian uses an ancient version of libjasper | 17:30.08 |
| chrisl_away | there are only ancient versions of libjasper...... | 17:30.25 |
| | It hasn't been maintained in quite a long time | 17:30.38 |
| atmos4 | and I know that they rip out the version that comes with gs | 17:30.40 |
| | libjasper.so.1 => /usr/lib/libjasper.so.1 | 17:31.16 |
| | it's version 1.9 | 17:31.35 |
| chrisl_away | gs now ships with OpenJPEG because JasPer was massively slow, used *huge* amounts of memory, and had some nasty security problems - I'd lay money that's where the problem is | 17:31.38 |
| atmos4 | chrisl_away: thank's I'll try to modify the deb package to build with openjpeg instead | 17:32.05 |
| chrisl_away | atmos4: you can't use libopenjpeg on the debian system - we had to patch the API to get what we needed out of it | 17:32.43 |
| | atmos4: you should just build with the gs packaged openjpeg | 17:33.09 |
| atmos4 | chrisl_away: hmm, doesn't gs come with it's own version? | 17:33.12 |
| chrisl_away | atmos4: see above :-) | 17:33.20 |
| atmos4 | ah ok =) | 17:33.33 |
| | sorry | 17:33.36 |
| chrisl_away | atmos4: what I meant was: don't try to link with the libopenjpeg that debian ships | 17:33.57 |
| atmos4 | on squeeze that would have been ancient anyways | 17:34.14 |
| | I know why we build our newer servers on ubuntu server instead | 17:35.05 |
| chrisl_away | atmos4: I think ubuntu has the same issue - they insist on shared libs (rather than the ones we ship), so they fall back to Jasper, still | 17:35.52 |
| | atmos4: FWIW, Jasper 1.900.1 is the latest release, and that came out in 2007...... | 17:36.51 |
| atmos4 | given that most packages are based on the debian ones that's no big surprise | 17:37.21 |
| chrisl_away | atmos4: it can be a support pain for us..... | 17:37.48 |
| atmos4 | yea, I can see that | 17:38.03 |
| | I remember when I set up solr on a server tow weeks ago, and it came with v1.4 | 17:38.47 |
| | where at 4.2 currently | 17:38.54 |
| | I ended up just dumping the newest release into /opt | 17:39.14 |
| | which is fine with java apps, cause they have very little dependencies | 17:39.39 |
| chrisl_away | By their nature, that should be true! | 17:40.26 |
| atmos4 | but most of the time I go with the distribution provided apps, cause it can quickly turn into admin hell, if you use custom built binaries all over the place | 17:40.33 |
| | besided the fact that you loose distribution provided security fixes | 17:41.10 |
| chrisl_away | That is true - the new OpenJPEG 2.x, we think, has all the APIs in place for us, unfortunately, it has other problems. If we/they can get those resolved, we might end up being able to use a released OpenJPEG library. | 17:42.27 |
| atmos4 | just checked, the current ubuntu server gs is also built against jasper | 17:42.36 |
| chrisl_away | Yep, so I see :-( | 17:43.35 |
| atmos4 | that however means that I can just rebuilt the package for ubuntu if I run into problems | 17:43.46 |
| chrisl_away | I guess the thing is, JPX is still a *very* rare beast, so there isn't much impetus to sort this out | 17:44.33 |
| atmos4 | not rare enough to not cause trouble =) | 17:45.08 |
| | I think I had another problem with gs once and it turned out to also be causes by jasper | 17:45.32 |
| chrisl_away | Jasper is, and always has been, a mess. But, to be frank, JPEG2000 is also a huge, over-complicated disaster - hence the lack of widespread adoption | 17:46.33 |
| | anyway, good luck with the build - I hope I haven't sent you down a blind alley. I now intend to be, as my nick suggests, "away"........ | 17:47.36 |
| atmos4 | hmm, recent ubuntu does NOT remove openjpg | 17:48.27 |
| | Version: 9.06~dfsg~20120803-0ubuntu1 changelog | 17:48.41 |
| | New source tarball repackaging | 17:48.49 |
| | - Do not remove libopenjpeg | 17:48.50 |
| | guess I'll grab that source package | 17:49.03 |
| henrys | Robin_Watts:do you use a heart rate monitor running? | 17:49.28 |
| atmos4 | chrisl_away: tahnks, have fun! | 17:49.46 |
| | now rebuilding ghostscript (9.07~dfsg2-0ubuntu2) for squeeze, looks very promising | 17:54.38 |
| | ah, shiny new japer free gs =) | 18:13.57 |
| | that did the trick | 18:14.03 |
| | thank you guys! | 18:14.19 |
| Robin_Watts | henrys: Yes, a garmin one with the Forerunner 310XT/ | 19:09.56 |
| | atmos4: I'm as far from the coast as it's possible to be in the UK :) | 19:10.58 |
| atmos4 | :-) | 19:11.41 |
| | btw. anyone has tried a build on osx with 9.07? I'm getting a strange undefined symbol error, 9.06 builds fine | 19:13.00 |
| | it can't find _cmsPluginTHR in obj/gsicc_lcms2.o | 19:13.52 |
| | oops figured that one out | 19:19.55 |
| | I was toying with lubjpeg-turbo and there was a lib that was still linked against it | 19:20.28 |
| | or not, but I guess it's because it's trying to build against system lcms2 | 19:34.46 |
| | yepp, switching to the builtin lcms2 fixed the build | 19:40.41 |
| | Forward 1 day (to 2013/03/24)>>> | |
IRC Logs