| | <<<Back 1 day (to 2012/09/18) | 2012/09/19 |
| Robin_Watts | Avast there, you scurvy lubbers! | 09:22.49 |
| kens | Ahoy matey | 09:23.02 |
| | talk liek a pirate day :-) | 09:23.08 |
| | Hmm, I wonder what Gemma is doing now.... | 09:26.03 |
| | "We found a bug of GhostScript of the version of Gs9.06(64_bit/32_bit) when we use in our application." | 09:26.23 |
| | What application is that then ? | 09:26.30 |
| sebras | paulgardiner: I just tested your testbuild of mupdf... I can still make it crash so that bug is not resolved. | 12:02.17 |
| | paulgardiner: what bugs were included in this version that is not already in 1.1? | 12:02.39 |
| paulgardiner | :-( Maybe I misunderstood the cause. | 12:02.50 |
| sebras | paulgardiner: I have a .pdf which takes a few seconds to render the first screen for. | 12:03.37 |
| | so I choose that file in the library-listing, letting it start to render the file. | 12:04.01 |
| | then I press the back button once. | 12:04.12 |
| | once I'm back at the library-listing I select the same file again. | 12:04.31 |
| | then I repeat this until it crashes. | 12:04.45 |
| | usually it takes 2 tried, sometimes it might take 4... | 12:05.05 |
| | s/tried/tries/ | 12:05.13 |
| paulgardiner | sebras: but the original method of making it crash still works too? | 12:05.27 |
| sebras | paulgardiner: original? hm... remind me..? | 12:05.57 |
| paulgardiner | madly dragging the page selector | 12:06.09 |
| sebras | paulgardiner: ah.. I'll try it. | 12:06.17 |
| | paulgardiner: btw... is the library-list updated if I download something while having mupdf started? | 12:09.27 |
| | paulgardiner: yes, I can still make it crash by clicking madly at the page selector. | 12:10.52 |
| | paulgardiner: http://goo.gl/FcjJt this pdf is particularly useful to test this at it takes a long time to render each page. | 12:11.18 |
| paulgardiner | Damn! I was pretty hopful to have cured that. | 12:11.22 |
| Robin_Watts | Did we put the version number in the app title? | 12:11.45 |
| sebras | paulgardiner: it took me 10-15 seconds to make mupdf force close... I'm an expert tester. ;) | 12:11.49 |
| | Robin_Watts: nope, not in this version. | 12:12.02 |
| | but we should. | 12:12.13 |
| paulgardiner | Strange. I'll give that file a try. I'm not managing to crash it by either means at the moment. | 12:13.34 |
| | I must raise a bug on adding the version - keep forgetting. | 12:14.08 |
| sebras | paulgardiner: probably it doesn't happen if you can't trigger enough simultaneous page renderings that use lots of memory and run out of memory... | 12:14.13 |
| paulgardiner | Yeah, but there aren't really simultaneous renders. It's more like a queue, and I thought this change had stopped it holding on to a bitmap for each render in the queue. | 12:15.28 |
| sebras | paulgardiner: http://bugs.ghostscript.com/show_bug.cgi?id=693344 | 12:16.14 |
| paulgardiner | thanks | 12:16.24 |
| sebras | paulgardiner: sure. | 12:16.35 |
| | paulgardiner: the only reason tor8 gets of lightly is because I don't have any ios-device. ;) | 12:18.11 |
| paulgardiner | sebras: that and it probably works anyway! :-) | 12:24.23 |
| | sebras: it's strange that the change has no effect. I could definitely see a reason for it running out of memory before, and not now. | 12:25.28 |
| | sebras: I'm not sure about new files appearing in the listing. The listing will be recreated each time the activity is started, but android may keep that activity going in the background while a doc is being viewed. | 12:29.49 |
| sebras | paulgardiner: right. | 12:34.49 |
| tor8 | paulgardiner: sebras: on iOS I resorted to reloading the file list every couple of seconds while the library view is visible | 12:38.20 |
| paulgardiner | tor8: yeah, I should probably do that. | 12:38.58 |
| tor8 | back in a while, time to upgrade to mountain lion... :/ | 12:39.15 |
| Robin_Watts | Gah. The Mountain Lion installer is *just* too big to fit on a single layer Blu-ray, and I don't have any double layer ones :( | 12:41.10 |
| | I'll use an SD card. | 12:41.29 |
| tor8 | Robin_Watts: I'm using a usb thumbdrive | 12:43.25 |
| sebras | paulgardiner: I mailed you a log from my phone crashing. | 12:46.15 |
| | paulgardiner: looks like it's related to mupdf not responding to input events.... | 12:46.26 |
| paulgardiner | sebras: hmmm, so might it now not be running out of memory, but rather just going unresponsive for too long? | 12:50.17 |
| | sebras: I wonder if that's what it was doing before. | 12:51.16 |
| sebras | paulgardiner: yeah, that's what I gather from briefly reading the log. look at it and see if you come to a differently conclusion. | 12:51.35 |
| | paulgardiner: could be. | 12:51.50 |
| paulgardiner | sebras: any chance you could try the previous version I uploaded (still there) to see if it crashes with the same reason? | 12:58.28 |
| | I can't remember why we previously thought it was running out of memory. Maybe that was just a guess. | 13:02.12 |
| sebras | paulgardiner: that might be the case. the previous version would be the first mail yesterday? | 13:35.34 |
| paulgardiner | Sorry no. One from a few weeks ago. I'll get the link | 13:36.14 |
| | http://intranet.glidos.net/~paul/MuPDF20120816.apk | 13:36.38 |
| sebras | paulgardiner: nope, that one fails due to out of memory: http://pastebin.com/jDPdjetc | 13:52.44 |
| paulgardiner | ah good. So I've fixed one problem. I guess I may have traded it for another, but hopefully not and the other problem was already present. | 13:54.10 |
| Robin_Watts | kens: Do you have a blu-ray reader ? | 13:54.47 |
| paulgardiner | sebras: Thanks for that. Really handy to know. At least my latest change is worth committing. | 13:54.47 |
| sebras | paulgardiner: sure thing. | 13:55.00 |
| kens | Robin_Watts : no, sorry | 14:11.30 |
| | At least, not yet. | 14:11.46 |
| | Unless possibly my daughter's laptop reads them just a moment | 14:12.05 |
| | Nope, only DVD I'm afraid | 14:13.13 |
| Robin_Watts | kens: No worries. DVD should be fine. | 14:13.58 |
| kens | OK well I have multiple devices to read DVD | 14:14.15 |
| chrisl | kens: check out the News "window": http://www.globalgraphics.com/ | 15:14.12 |
| kens | Oho! | 15:14.50 |
| chrisl | Interesting this bit, too: "More than 5 million copies of the Jaws RIP have shipped to users worldwide since 2000......." | 15:15.38 |
| kens | Well I gues htey can count royalties | 15:15.58 |
| chrisl | It's a higher number than I expected - I wonder how it compares with HQN | 15:16.36 |
| kens | I'd think 5 million is more or less right, correct magnitude anyway | 15:16.59 |
| chrisl | Well, it *must* be the first time Jaws has taken focus from HQN on the GG front web page | 15:19.59 |
| henrys | yeah I was reading the news page for 3.0 looks like onyx is happy sigh | 15:37.12 |
| kens | Moving them was always a big goal | 15:37.34 |
| | They have a lot of code there | 15:37.43 |
| Robin_Watts | helgrind just apitested tiger.eps clean. woo hoo! | 15:38.37 |
| henrys | kens, chrisl:seems to me if we are looking for folks to switch we'd be better off looking at harlequin customers. | 15:41.44 |
| kens | henrys Harlequin customers might be even harder ;-) | 15:42.01 |
| | They want a package, on the whole, not a toolkit | 15:42.15 |
| henrys | Yes but at least they are dissatisfied | 15:42.37 |
| kens | Good point | 15:42.55 |
| chrisl | OTOH, I reckon we can probably compete with (or beat) HQN on color now, and we definitely would on price...... | 15:43.11 |
| Robin_Watts | Yeah. Saves us the effort of making them dissatisfied ourselves :) | 15:43.17 |
| kens | No problem while Jim was at GG, many unhappy customers ;-) | 15:43.37 |
| Robin_Watts | henrys: Just about to launch into changing all the if_debug0m(char, mem, fmt, ....) calls to be if_debug0m(mem, char, fmt, ....) | 15:52.35 |
| | but before I do, it occurs to me that what they really mean is: | 15:52.54 |
| | if (gs_debug[char]) { dmprintf(mem, fmt, ....) } | 15:53.11 |
| | so there is an argument that the existing ordering is right. | 15:53.23 |
| henrys | I'm really okay either way and ray liked it that way I think. | 15:54.26 |
| Robin_Watts | OK. So I'm going to leave it as is then. Phew. | 15:54.39 |
| | Just tor8 will be annoyed - sorry. | 15:54.51 |
| tor8 | Robin_Watts: it's okay, I understand the reasoning | 15:55.49 |
| Robin_Watts | fab. | 15:56.21 |
| chrisl | henrys: so changing to 64 bit integer objects did cause ~35 QL test files to change/"fail". I reckon a little extra PS hackery in gs_cet.ps will work around all the problems - looking into that now. | 15:59.51 |
| Robin_Watts | chrisl: What did the cluster say about speed changes? | 16:00.24 |
| henrys | just cet stuff? | 16:00.27 |
| chrisl | henrys: yes, just cet changes. | 16:00.38 |
| Robin_Watts | 6 minutes faster. Nice :) | 16:01.01 |
| chrisl | Robin_Watts: cluster said faster, but not enough to be conclusive, reckon. *and* the nodes are all 64 bit | 16:01.22 |
| mvrhel | good morning | 16:01.31 |
| Robin_Watts | Morning mvrhel | 16:01.45 |
| chrisl | 'morning mvrhel | 16:01.48 |
| henrys | hi mvrhel | 16:01.50 |
| | chrisl:I've made a couple bountiable shelly may want to look in case you speak to him. I think he just searches for the keyword and doesn't need the bug numbers. | 16:25.36 |
| chrisl | henrys: Okay, I'll let him know. I was supposed to have dinner with him next week, but we've had to postpone it for a couple of weeks. | 16:26.38 |
| kens | OK time to go goodnight all | 16:31.17 |
| Robin_Watts | mvrhel: More stupid questions when you have a sec I'm afraid. | 17:14.42 |
| mvrhel | oops | 17:32.14 |
| | sorry Robin_Watts I missed your ping | 17:32.21 |
| | I had a question for you too | 17:32.24 |
| | one that I have asked a bunch of time | 17:32.31 |
| | I thought I wrote it down some pace | 17:32.42 |
| | place | 17:32.44 |
| | what is the syntax on the command line for turning on your new (or used to be new) debug options. e.g. the gs_debug_flag_icc | 17:33.37 |
| Robin_Watts | --debug=icc | 17:33.50 |
| mvrhel | thats right | 17:33.56 |
| Robin_Watts | Just --debug lists the available options. | 17:34.05 |
| mvrhel | ah ok | 17:34.11 |
| | is that in the documenation? | 17:34.17 |
| Robin_Watts | and you can do --debug=foo,bar,baz | 17:34.23 |
| | I think so. | 17:34.25 |
| mvrhel | ok | 17:34.30 |
| Robin_Watts | So, following on from the discussion yesterday where I said I'd like to pass the cms_context into the profile getting functions... | 17:35.14 |
| mvrhel | right | 17:35.27 |
| Robin_Watts | I figured that would be easy as I was bound to have the icc_manager pointer at that point, but alas, no. | 17:35.45 |
| mvrhel | that was my worry | 17:35.54 |
| | or one of my worries | 17:36.01 |
| Robin_Watts | So, I thought... I know, I'll put the cms_context pointer into cmm_profile_s | 17:37.13 |
| mvrhel | that sounds even messier with the clist | 17:37.33 |
| Robin_Watts | cos I've always got a cmm_profile_t when I call the get functions. | 17:37.45 |
| mvrhel | although the clist just stores the raw profile buffer data | 17:38.09 |
| | so that should be ok | 17:38.12 |
| Robin_Watts | BUT it looks like I don't always have the icc_manager pointer when I make cmm_profile_t's. | 17:38.29 |
| mvrhel | I hope our changes dont collide soon | 17:38.33 |
| Robin_Watts | In particular, there look to be some bits of code that make cmm_profile_t's that do so without reference to lcms etc. | 17:39.24 |
| | so I'm confused. | 17:39.29 |
| mvrhel | well certainly there are with respect to the non_cmm case | 17:39.49 |
| | which does not use lcms, but uses the same API | 17:40.04 |
| | where in particular are you running into issues? | 17:40.18 |
| Robin_Watts | Like gsicc_create_from_cal ? | 17:40.44 |
| mvrhel | oh | 17:40.58 |
| | yes | 17:41.00 |
| Robin_Watts | gs/base/gsciemap.c ? | 17:41.14 |
| mvrhel | hold on | 17:41.23 |
| Robin_Watts | Would it be neater to consider the idea of a cmm_profile_t holding a pointer to the icc_manager that it's created under rather than the cms_context itself? Is that even a sane thought? | 17:42.29 |
| mvrhel | well you could pass it into the cal function | 17:42.37 |
| | the manager that is | 17:42.46 |
| | the only call is from zicc.c | 17:42.56 |
| | which makes sense | 17:42.58 |
| | it is setting up an icc profile equivalent to the cal space | 17:43.15 |
| | Robin_Watts: I don't want a ptr to the manger in the profile | 17:43.39 |
| | please | 17:43.41 |
| | the profile is really a entity by itself | 17:43.53 |
| Robin_Watts | The profile is an entity by itself, but it's still tied to the particular instance of the underlying CMS, right? | 17:45.11 |
| mvrhel | Robin_Watts: I guess. we still have not seen a case where it is needed | 17:45.35 |
| Robin_Watts | I could back the context ptr stuff out entirely. | 17:46.08 |
| mvrhel | the thing is, the icc_manager is not tied to a particular cmm | 17:46.09 |
| | we actually have 2 cmm's in gs right now | 17:46.24 |
| | lcms and the non_cmm cmm | 17:46.33 |
| Robin_Watts | OK, but any given icc_manager is tied to one or other of them, right? | 17:46.58 |
| mvrhel | well I said that wrong | 17:47.07 |
| | the icc manager is simply a way to hold and make available default profiles | 17:47.40 |
| Robin_Watts | OK. | 17:47.52 |
| | Is there a better place for us to be holding the cms context ptr then? | 17:48.10 |
| | Should we maybe put that in the libctx ? | 17:48.18 |
| | That would mean we only gscms_create'd once when we startup, and destroy when we shut down. | 17:49.10 |
| mvrhel | if that is a location that is better suited for managing context pointers for multiple threads, then I would say yes. | 17:49.10 |
| Robin_Watts | It would mean that we only instantiated each cms once, regardless of how many threads we use. | 17:49.40 |
| | Every gs_memory_t contains a pointer to the libctx. | 17:50.29 |
| | Each thread gets its own gs_memory_t, but they all share the same libctx. | 17:50.52 |
| mvrhel | that seems a much more flexible solution to me. but, is there anything similiar in libctx now or are we simply stuffing globals in there? | 17:51.32 |
| Robin_Watts | libctx is exactly for stuffing globals in. | 17:52.08 |
| mvrhel | does this force any special requirments for the CMM in terms of how it manages different instances? | 17:52.10 |
| | i.e. does each thread need a new instance? | 17:52.29 |
| Robin_Watts | (If we use gsapi to produce multiple instances of ghostscript, then we DO get multiple libctx's) | 17:52.37 |
| mvrhel | ah ok | 17:52.43 |
| Robin_Watts | mvrhel: For numRenderingThreads stuff, we'd only have one libctx. | 17:52.58 |
| | and hence the cms would have to cope with a single instance being called from multiple threads. | 17:53.25 |
| mvrhel | ok. well right now that is fine as lcms is certainly not thread safe for that type of rendeirng | 17:53.27 |
| | and we have the lock outs in place to account for that | 17:53.40 |
| Robin_Watts | but if that's a problem, we can cover for it in the gscms wrappers for the particular cms, right? | 17:54.01 |
| | Wooah. Why is lcms not safe like that ? | 17:54.09 |
| mvrhel | because different threads can't access the same profile nor links | 17:54.24 |
| Robin_Watts | Right, but we make profiles/links and only use them within a single thread, right? | 17:54.55 |
| mvrhel | right that is ok | 17:55.02 |
| Robin_Watts | ok. | 17:55.06 |
| mvrhel | at one time, I wanted to share links across threads | 17:55.42 |
| Robin_Watts | OK, so moving to a libctx solution sounds nicer. | 17:55.42 |
| mvrhel | Robin_Watts: yes it does sound nicer to me | 17:56.00 |
| Robin_Watts | mvrhel: I can imagine that that would be better for memory etc (sharing links etc) | 17:56.00 |
| mvrhel | Robin_Watts: yes. I thought so | 17:56.26 |
| Robin_Watts | but I can also see why it makes life much harder for lcms. | 17:56.26 |
| mvrhel | yes | 17:56.30 |
| Robin_Watts | I get the feeling that the multi-threading stuff in lcms is rather untested. | 17:56.44 |
| mvrhel | I have the feeling that we are testing the limits of lcms | 17:57.04 |
| Robin_Watts | But at least I have a fixed version now that passes helgrind for tiger at least. | 17:57.29 |
| mvrhel | great | 17:57.37 |
| Robin_Watts | ok. I shall stop bothering you with stupid questions. For a while at least. Thanks! | 17:57.53 |
| mvrhel | not stupid questions. all good stuff | 17:58.21 |
| | things that will make the api much cleaner and useful | 17:58.35 |
| | back to deviceN profile fun for me | 17:59.08 |
| Robin_Watts | I hope so. | 17:59.12 |
| | :) | 17:59.16 |
| mvrhel | It is funny how what I thought was going to be easy and trivial has grown to be a bit of a headache | 17:59.57 |
| Robin_Watts | ain't that always the way. | 18:05.18 |
| cartman | Hi, can someone have a look at http://bugs.ghostscript.com/show_bug.cgi?id=693330 | 18:15.04 |
| Robin_Watts | cartman: It will get looked at, but I'm afraid that the developers are all a bit busy at the moment. | 18:17.27 |
| cartman | ok :) | 18:18.58 |
| Robin_Watts | It does seem odd that it needs quite that much memory though. | 18:22.39 |
| cartman | any idea on where to get "openjpeg-1.5.0-patched" ? | 18:22.43 |
| | yeah indeed, the page "looks" simple | 18:22.49 |
| Robin_Watts | Hmm. Huge shadings. | 18:23.03 |
| | That's probably why. | 18:24.14 |
| | cartman: It's part of mupdf-thirdparty.zip. | 18:24.28 |
| cartman | I don't really know what shading is | 18:24.29 |
| | Robin_Watts: thanks! | 18:24.34 |
| Robin_Watts | see mupdf.com/downloads | 18:24.37 |
| cartman | Robin_Watts: ah shading is the "shadow" in the gfx? | 18:29.12 |
| Robin_Watts | Don't know offhand. | 18:29.29 |
| | PDF shadings are for things like graduated fills. | 18:29.38 |
| | or mesh fills. | 18:29.43 |
| cartman | ok, the file looks a bit too shiny | 18:30.00 |
| Robin_Watts | mvrhel: That works out so much more nicely. Testing it now. | 19:43.20 |
| mvrhel | Robin_Watts Great | 21:10.18 |
| | ugh. this deviceN profile stuff just got even more involved in dealing with the equivalent cmyk values for the sep device output when we don't handle a particular color. the output may not obviously be cmyk in this case | 21:29.11 |
| | but that is hard coded right now to be that way | 21:29.43 |
| | need to think about this a bit. | 21:29.48 |
| | bbiab | 21:29.50 |
| Robin_Watts | So... pcl doesn't use the cms stuff ? | 23:04.53 |
| | hmm. does on my windows build, so why did the cluster test fail? | 23:30.10 |
| | Forward 1 day (to 2012/09/20)>>> | |
IRC Logs