| | <<<Back 1 day (to 2012/10/03) | 2012/10/04 |
| Robin_Watts | So is the wrong memory being put into that ? | 00:00.06 |
| | Are you using a proper debug build or a release build with -g ? | 00:00.21 |
| rayjj | Robin_Watts: a regular debug build | 00:00.56 |
| Robin_Watts | ok. | 00:01.11 |
| rayjj | Robin_Watts: it looks like the icc_link_cache is being set up with the wrong memory | 00:01.22 |
| Robin_Watts | I have to go to bed now. falling asleep. I'll check logs in case you turn up with anything. | 00:01.32 |
| | Well, that'd be nice if true, cos it might be a simple fix. | 00:01.42 |
| rayjj | Robin_Watts: OK, or, I'll post it on the bug (like I said I was going to) | 00:02.22 |
| | Robin_Watts: g'nite. | 00:02.34 |
| | trying a change to gxclthrd.c:673 to make it: ncdev->icc_cache_cl = gsicc_cache_new(thread->memory); | 00:04.28 |
| | (instead of crdev->memory) | 00:04.42 |
| | still seeing the 'not idle' message, but time for dinner and have a meeting at the school tonight | 00:11.19 |
| Robin_Watts | sounds like progress, maybe. | 00:12.06 |
| rayjj | well, it ran quite a bit longer, (21 pages) but then got a SEGV. | 00:12.55 |
| | nope, not enough -- still flaky | 00:18.34 |
| | I think I know what's going on, but not why Robin's change should make it any worse. | 00:56.40 |
| mvrhel_laptop | stupid postscript test file. 12-07D.PS had a very weird color rendering going on for page 3, which only renders when you include the -dJOBSERVER on the command line. turns out that the null device gets introduced briefly with some various commands which result in the links in the link cache getting altered with respect to their formatting due to the null device having 1 component | 05:52.24 |
| | then when we return to rendering to the ppmraw device which has three components things are not quite right | 05:53.03 |
| | I may have a simple fix for this | 05:57.37 |
| | ok that makes a nice progression | 06:17.25 |
| | and on that note, I am calling it a night | 06:26.18 |
| sebras | tor8: just 1.5h earlier and you would have beaten kens today! :) | 08:16.31 |
| kens | Lol.... | 08:16.51 |
| tor8 | damn! shouldn't have gone back to sleep when I woke up at 8 am :) | 08:16.57 |
| sebras | tor8: nope. :) | 08:17.07 |
| kens | Hehe, I was already here at 8am | 08:17.12 |
| | Well, 8am my time... | 08:17.20 |
| tor8 | :D | 08:17.24 |
| | sebras: so did you get time to check out the gtk+ viewer yesterday? | 08:17.42 |
| kens | Only chirsl usually beats me in, or our colonial cousins by dint of not going to bed. | 08:17.57 |
| sebras | tor8: yep, there's something for you in the logs... | 08:17.58 |
| | kens: that's just unfair! on the other hand, you probably work while they eventually _do_ sleep. | 08:18.28 |
| tor8 | sebras: yes, the flickering is annoying. I have a few ideas that may be worth trying. like resizing the underlying widget and letting gtk+ rescale with blur until the new render is ready | 08:20.17 |
| sebras | tor8: ah, yes! I forgot what I was complaining about. :) | 08:20.54 |
| | sounds like a good approach to me. | 08:21.02 |
| tor8 | if gtk+ supports it, that is | 08:21.25 |
| | but there are more important lower hanging fruit to implement first | 08:21.37 |
| sebras | sure, this was just my first impression. | 08:21.54 |
| | no segfaults and no other odd behavious. | 08:23.03 |
| tor8 | palatable ui design? | 08:23.17 |
| sebras | didn't try chinese input though. I guess I should do that tonight. :) | 08:23.20 |
| tor8 | try chinese search too, not just input! | 08:23.48 |
| sebras | tor8: it's ok, but I'm pining for .mupdfrc and a right click menu that allows me to run in paged mode instead of continuous. :) | 08:23.50 |
| | tor8: of course. | 08:23.58 |
| tor8 | sebras with pgup and pgdown or b/space it behaves like paged mode | 08:24.16 |
| sebras | not, when the entire page doesn't fit in the window. | 08:24.41 |
| tor8 | just need a 'shrinkwrap' button to set the window height to perfect | 08:24.44 |
| sebras | exactlyl. | 08:24.51 |
| sebras | inherited kens keyboard. | 08:25.01 |
| tor8 | sebras: try it again, then. those keys page by an exact page | 08:25.09 |
| kens | will be getting a new keyboard soon, same old typist though.... | 08:25.26 |
| tor8 | space/b to the beginning of the next page, pgup/down by one page's height | 08:25.36 |
| sebras | tor8: ah, ok I see what you mean now, I actually never tried space/b because I didn't think that was implemented (didn't look at all the code, sorry) | 08:26.16 |
| Chumbawamba | I have some pdfs that have alot of unused images and other useless objects. Is there a way to sanitize these pdf's with Ghostscript? | 08:48.07 |
| kens | If they are truly unused you can try running them to the pdfwrite device | 08:48.30 |
| | However, you should note that this *completely* interprets the PDF to graphics primitives, and builds a new PDF which has no relationsjip other than appearance, with teh original. Metadata may well not be preserved. | 08:49.26 |
| Chumbawamba | Thats fine :) | 08:56.56 |
| sebras | Chumbawamba: I can't help you with gs, but I'm curious how you ended up with a document that doesn't actually use all images? | 09:02.19 |
| | Chumbawamba: that's suggests to me that the generator of the pdf is broken somehow, so if this is a common generator it would be useful to know about it. :) | 09:03.00 |
| chrisl | sebras: some PDF editing apps don't actually remove objects when you "delete" them from the page - Acrobat does that depending on how you save the edited file. | 09:04.06 |
| sebras | chrisl: I guess I shouldn't be surprised that even Acrobat has this problem.... | 09:06.51 |
| chrisl | sebras: Usually, with Acrobat, if you edit and "save", it will leave unused objects in the output. If you do "save as" it will remove them | 09:08.01 |
| sebras | chrisl: ok, then we are _not_ surprised by Chumbwamba's file. :) | 09:10.53 |
| kens | Very little surprises me with Acrobat these days... | 09:11.16 |
| chrisl | sebras: certainly not! We've seen *much* worse results from manipulating PDFs | 09:11.59 |
| kens | Also some Adobe applications (eg Illustrator) preserve the entire original application file in the PDF as comments.... | 09:12.44 |
| chrisl | kens: ahem, remember "Jaws" PDFEditor? Acrobat isn't the worst offender in *this* case! | 09:12.52 |
| kens | Yes true, though applying the Jaws label was a really *bad* decision IMO | 09:13.22 |
| sebras | kens: I wonder why they do that. the undo-function would be redundant after saving the file... | 09:14.27 |
| kens | Quite so.... | 09:14.36 |
| | But logic is not applied well in the case of Acrobat (or other PDF editors) | 09:15.22 |
| chrisl | Or even PDF! | 09:15.34 |
| Chumbawamba | sebras: I had a pdf with alot of images. I removed everything but the text from it. With some pdf's the images are still referenced somehow. I use PdfTron for that btw. | 09:16.03 |
| | Thank you kens, my pdf got from 72MB to 2MB :D | 09:16.42 |
| kens | You are welcome... | 09:16.52 |
| sebras | Chumbawamba: thanks for the info. :) | 09:17.55 |
| chrisl | So, have we gained some indeterminisms in psdcmyk, then? | 09:56.49 |
| kens | I think so, yes, I hasd some yesterday | 09:57.44 |
| chrisl | That's okay then - a change in pcl shouldn't really cause differences in PDF and PS jobs! | 09:58.19 |
| kens | My change was in pdfwreite.... | 09:58.44 |
| chrisl | Okay, clearly an indeterminism, then | 09:59.36 |
| | begone foul global! | 10:00.38 |
| Robin_Watts | http://io9.com/5947852/this-is-a-hexaflexagon-its-about-to-blow-your-mind | 11:45.02 |
| claudiu__ | Hello | 12:14.02 |
| | is there any way to set the page width for when converting a pdf to image (png) ? | 12:14.19 |
| kens | -sPAPERSIZE= and -dFIXEDMEDIA | 12:15.02 |
| claudiu__ | thank you :) kens | 12:15.35 |
| kens | also -dPDFFitPage | 12:17.30 |
| claudiu__ | kens: is there any way to set the width and let ghostscript calculate the height ? | 12:27.18 |
| | this is the current script: https://gist.github.com/776fa06a11d66cc5d007. Would like for all the png files to be 2000xapropiate_height. | 12:27.47 |
| kens | You want the pagesize to be set from the JPEg, or what >? | 12:28.30 |
| saper | changing resolution? | 12:28.31 |
| kens | Err, forget I said that... | 12:29.02 |
| claudiu__ | I want to give a pdf file and generate all the pages as png files with width 2000px | 12:29.19 |
| kens | And height ? | 12:29.28 |
| claudiu__ | the height should be appropriate for the page format. | 12:29.51 |
| kens | define 'appropriate' | 12:29.58 |
| Robin_Watts | claudiu__: mudraw -o out%d.png -w2000 in.pdf :) | 12:30.14 |
| claudiu__ | by appropriate I mean ghostscript to figure it out. so that it does not cut the image. | 12:30.44 |
| saper | probably 'proportional' | 12:32.01 |
| claudiu__ | yep :) | 12:32.07 |
| kens | GS won't do that. You can write a PostScript program to do it, but its not trivial | 12:32.22 |
| Robin_Watts | Or, you could use mupdf. | 12:32.41 |
| chrisl | claudiu__: there's Postscript "utility" file that ships with Ghostscript called pdf_info.ps which (amongst other things) dumps the media box(es). You could use that to get the page dimensions, and calculate the page size you want. | 12:42.08 |
| claudiu__ | thank you :) | 12:42.34 |
| chrisl | It will means doing the calculations yourself, but it makes it easier to get the information you need to do that | 12:43.19 |
| kens | Or, as Robin says, just use MuPDF | 12:44.51 |
| claudiu__ | thank you. Trying now with MuPDF | 12:49.39 |
| Robin_Watts | Morning ray_laptop | 13:54.08 |
| | I tried the thing I had in mind this morning; for each block, store the gs_memory_t pointer that was used to allocate it. | 13:54.46 |
| | Then check on a free/realloc that the same mem * is being used. | 13:55.21 |
| | That test ran cleanly. | 13:55.28 |
| | I think you're right that it should be gsicc_cache_new(thread->memory); | 13:57.32 |
| ray_laptop | Robin_Watts: I think the correct allocators are being used to free (the same as for the alloc), but the thread->memory AND the lack of thread safety in the underlying (PCL only) chunk memory is more serious | 14:00.04 |
| Robin_Watts | Right. A lack of underlying thread safety would be a major problem. | 14:00.27 |
| ray_laptop | Robin_Watts: note that with PS we use the GC base memory that is always thread safe. | 14:00.42 |
| Robin_Watts | What does the main thread do while the rendering threads are running ? | 14:00.51 |
| | i.e is the problem that something in the main thread is footling with memory while the rendering threads run? | 14:01.46 |
| ray_laptop | Robin_Watts: convert the bitmaps to output format. This _usually_ doesn't include allocation actions, but the 'get_bits_rect_mt' _does_ allocate a buf_device for each band | 14:01.48 |
| | Robin_Watts: exactly. The line in gxclthrd.c I mention in the bug comment | 14:02.21 |
| Robin_Watts | or is the problem that when the rendering threads chunk managers end up falling back to the underlying allocator that that isn't thread safe? | 14:02.27 |
| | So, can we wrap the main threads allocator to make it threadsafe? | 14:02.59 |
| ray_laptop | while the threads lock amongst each other, the main thread doesn't use the thread safe allocator | 14:03.21 |
| Robin_Watts | Right, so the wrapping done for the render threads has some sort of locking in there? | 14:03.55 |
| | My reading of the comment in the code suggested to me that the wrapped threads just assumed that the underlying allocator was already thread safe. | 14:04.28 |
| | /* Every thread will have a 'chunk allocator' to reduce the interaction | 14:04.54 |
| | * with the 'base' allocator which has 'mutex' (locking) protection. | 14:04.56 |
| | * This improves performance of the threads. | 14:04.58 |
| | That implied to me that the render threads managers had no locking at all - just that when they needed memory for new chunks they'd fall back to the underlying one that DID have such protection. | 14:05.33 |
| | And you're now saying that it doesn't. | 14:05.40 |
| | Morning mvrhel_laptop | 14:13.22 |
| | Did you get your bug sorted? | 14:13.35 |
| ray_laptop | Robin_Watts: sorry -- I am busy with the kids still. | 14:14.39 |
| Robin_Watts | ray_laptop: No worries. | 14:14.47 |
| ray_laptop | The threads are OK. It is the main thread that is the problem. As long as the devices don't do allocations, we can fix the clist stuff to use the mem->thread_safe_memory | 14:15.30 |
| | but I don't think we should assume that. | 14:15.39 |
| kens | pdfwrite does lots of allocation | 14:16.00 |
| | and we want it to use clist for transparency flattening | 14:16.26 |
| Robin_Watts | ray_laptop: Sorry, humour me here. | 14:17.47 |
| | Let's suppose our base level allocator is A. That's not thread safe in PCL. | 14:18.10 |
| | Damn. Start again. | 14:18.19 |
| | Our base level malloc allocator is A. That's thread safe. | 14:18.31 |
| | PCL wraps that with a chunk allocator, call it B. | 14:18.42 |
| | This is NOT thread safe. | 14:18.45 |
| | For each thread we make a new chunk allocator with B as it's underlying allocator. Call those C1, C2, C3 etc. | 14:19.23 |
| | Once C1, C2, C3 have chunks to work in, they are fine, but it's getting those chunks that interests me. | 14:20.19 |
| | When C1 first starts up (or when its chunk is full) it has to call down to B to get a new chunk. | 14:20.56 |
| | What makes that threadsafe if B is not. | 14:21.12 |
| | ? | 14:21.15 |
| | Is there a wrapper layer that's in use that I've missed somewhere? | 14:21.31 |
| ray_laptop | Robin_Watts: first, every allocator also has a "thread_safe_memory' allocator member, so the chunk allocator provides this, call is B.ts | 14:23.23 |
| Robin_Watts | Hmm ok, slightly different terminology here. | 14:24.08 |
| ray_laptop | The rendering threads us B.ts as their base allocator. This allows most of the Cn allocations to not need to lock. | 14:24.25 |
| Robin_Watts | OK. | 14:24.38 |
| | And B.ts is what? a wrapped version of B ? | 14:24.48 |
| ray_laptop | The B.ts has B as its base allocator (it B.ts is B with a locking wrapper) | 14:24.54 |
| Robin_Watts | Gotcha. | 14:25.00 |
| | OK, that makes sense then. | 14:25.04 |
| | So the problem is that the main thread is calling B not B.ts | 14:25.11 |
| ray_laptop | the problem is when a thread needs to get a block from B.ts, that uses B after ensuring exclusive access | 14:25.48 |
| Robin_Watts | but any calls direct to B don't bother getting exclusive access and hence can collide with those that think they are safe coming from B.ts | 14:26.27 |
| ray_laptop | Robin_Watts: correct. both a thread (via B.ts) AND the main thread use B | 14:26.33 |
| Robin_Watts | Yeah, I follow now. | 14:26.42 |
| ray_laptop | Robin_Watts: OK. | 14:26.46 |
| Robin_Watts | So... can we persuade the main thread to use B.ts instead of B ? | 14:26.55 |
| ray_laptop | Robin_Watts: we can fix it within the clist logic, but devices ... | 14:27.59 |
| Robin_Watts | Can we not wrap B as a threadsafe version early enough ? | 14:28.24 |
| | i.e. would it hurt us a lot to always make B threadsafe when we create it? | 14:29.01 |
| ray_laptop | Robin_Watts: thus my idea of having a 'use_lock' mode on B (and maybe get rid of thread_safe_memory) that the clist controls, invisibly to the device. | 14:29.22 |
| Robin_Watts | Ah, I see. | 14:29.47 |
| ray_laptop | Robin_Watts: yes, it would be painful to always have B use a lock. | 14:30.09 |
| Robin_Watts | So on a call to B, B would check B.use_lock and take a lock if required. | 14:30.23 |
| ray_laptop | Things like paths use LOTS of allocate/free actions and locking on each of these would kill us | 14:30.47 |
| | Robin_Watts: that's the proposal. | 14:31.10 |
| | unless someone thinks of a safe, clever, and not to kloodgy way around the potential pitfall of a device using alloc/free while rendering | 14:32.11 |
| Robin_Watts | It seems reasonable. I'd have to see the interface for setting/unsetting the use_lock flag before I had a strong opinion on how clean a solution it is :) | 14:32.21 |
| | Maybe rather than a use_lock, we should have a 'thread_use_count'. | 14:33.02 |
| | When we wrap the allocator, we increment that. When we destroy an allocator that wraps it, we decrement it. | 14:33.25 |
| ray_laptop | Robin_Watts: we could either use a new method, or just a new element to the gs_memory_t struct | 14:33.26 |
| Robin_Watts | And so we need to lock if thread_use_count > 1. | 14:33.43 |
| | That way it's not something 'secret' that the clist calls. | 14:34.26 |
| | It's the act of wrapping an allocator for a thread that triggers it. | 14:34.45 |
| ray_laptop | so, we'd have to lock around increment/decrement of the thread_use_count in case a child thread spawns another thread ;-) | 14:35.11 |
| Robin_Watts | Yes. | 14:35.26 |
| ray_laptop | Robin_Watts: I was kidding. | 14:35.33 |
| Robin_Watts | but that's an infrequent occurrence. | 14:35.37 |
| ray_laptop | right, I don't kid often ;-) | 14:36.23 |
| Robin_Watts | :) | 14:36.39 |
| ray_laptop | we could get rid of the locking wrapper and the thread_safe_memory as long as all allocators that are not thread_safe implement the thread_use_count | 14:38.17 |
| | which gets rid of one extra layer in the calli stack on most PS chunk actions (gsmalloc). | 14:39.10 |
| chrisl | Won't that incur a penalty? Avoiding locking for frequent, small malloc/free sequencies in each thread can be quite a big win | 14:41.20 |
| ray_laptop | chrisl: that's what the chunk allocator in each thread is for | 14:42.32 |
| chrisl | Ah, then I misunderstood your suggestion - just ignore me....... | 14:43.04 |
| ray_laptop | the chunk allocator only uses the base allocator with the mutex lock for new chunks | 14:43.23 |
| Robin_Watts | chrisl: The idea is that we make it so that every allocator keeps track of the number of threads that might be calling it. | 14:43.25 |
| chrisl | Hmm, sounds like a bit of a minefield, to me | 14:43.47 |
| Robin_Watts | Every allocator then only takes locks etc, if that number is > 1 | 14:43.54 |
| ray_laptop | any thread that wants to (such as the rendering threads) use their own chunk allocator | 14:44.07 |
| Robin_Watts | chrisl: It's like everything else - a tradeoff. Each allocator gets slightly more complex, to give a simpler interface overall. | 14:44.46 |
| ray_laptop | so an accessor method that does the 'adjust_thread_use_count' (with a +/- arg) would allow the allocator to use the lock around the increment/decrement | 14:45.41 |
| | in this case it isn't simplicity, but rather performance that is the goal. | 14:46.05 |
| chrisl | What currently sets up the allocator(s) for a given thread? Is it done automatically on thread creation, or is it done explicitly by the creator? | 14:46.36 |
| ray_laptop | chrisl: gxclthrd.c takes care of it in setup_render_threads | 14:47.05 |
| | it spawns the threads, each with their own chunk allocator | 14:47.34 |
| Robin_Watts | The code that makes a thread, first makes a new chunk allocator based on the underlying thread safe allocator, then that pointer is passed into the new thread creation function. | 14:47.58 |
| ray_laptop | Robin_Watts: right, except in the proposed approach, there wouldn't be a thread safe allocator, but rather the chunk's base allocator will be made thread safe by bumping the thread_use_count | 14:49.10 |
| Robin_Watts | right. | 14:49.22 |
| chrisl | My concern is that future uses of threads might not know to increment the counter in the allocator | 14:49.23 |
| ray_laptop | chrisl: just one more 'invariant' to keep track of in multi-threading with GS. Probably a comment in gp_sync.h would suffice | 14:50.39 |
| chrisl | ray_laptop: given that we already have a platform independent API for handling threads, could we not pass the mem pointer in there, and have that increment the counter - maybe make things a little simpler, instead of a little more complex? | 14:52.17 |
| Robin_Watts | chrisl: The problem, I think is that we pass in the chunk allocator that we've already made to the thread creation function. | 14:53.18 |
| | so it's not that the thread count on that that needs updating, but rather the thread count on the underlying allocator. | 14:54.04 |
| ray_laptop | chrisl: if the thread is spawned with a private chunk allocator (as the clist does) then the allocator that needs the thread_use_count bumped is the base allocator of the chunk allocator, not the one that the thread uses | 14:54.11 |
| | Robin_Watts typed a bit faster | 14:54.33 |
| | but AFAICT we were both saying the same thing | 14:54.58 |
| Robin_Watts | What we could do is have a function that: makes a chunk allocator from the underyling one, increment the thread count on the underlying one, then call the platform independent thread creation. | 14:55.07 |
| chrisl | Okay, more complicated it is, then...... | 14:55.22 |
| ray_laptop | I have to take the kids to school. bbiaw | 14:55.26 |
| Robin_Watts | So that would be the function that all new threading code would call. | 14:55.31 |
| ray_laptop | Robin_Watts: since this looks like something in the gxclthrd.c, I assume you don't mind me fixing it. | 14:56.04 |
| Robin_Watts | ray_laptop: No, not at all. | 14:56.13 |
| ray_laptop | I'll send out a patch for review before committing | 14:56.18 |
| Robin_Watts | I've satisfied myself that it's nothing in the gsicc_lcms2 layer., so I'm quite happy to hand it off :) | 14:57.23 |
| mvrhel_laptop | good morning | 15:08.41 |
| | Robin_Watts: I started my computer earlier but then eating breakfast etc.... | 15:09.03 |
| Robin_Watts | mvrhel_laptop: No worries. It sounds like ray has a handle on the problem and a solution. | 15:09.27 |
| mvrhel_laptop | great | 15:09.33 |
| | so there were not any issues in the color stuff then | 15:09.55 |
| Robin_Watts | It's nothing specific to lcms2, I think we just tickled it by the fact that we now do allocation/deallocation properly. | 15:09.57 |
| | You said yesterday that LCMS wasn't thread safe. | 15:10.18 |
| | or at least, that's why you didn't share the link cache between threads. | 15:10.41 |
| mvrhel_laptop | I meant that you cant share links and profiles amongst threads | 15:10.45 |
| Robin_Watts | right. I can't think of a reason why not any more - except for the fact that the allocator/deallocators might mismatch. | 15:11.29 |
| mvrhel_laptop | well because one thread is changing a link or profile while another is using it | 15:11.57 |
| | that is what I found when I dug into the issue in lcms 1.8 | 15:12.22 |
| Robin_Watts | Oh, do we 'change' them? I thought they were created, used, and then destroyed? | 15:12.30 |
| mvrhel_laptop | unless Marti fixed this bad things will happen | 15:12.34 |
| | not us | 15:12.36 |
| | Marti | 15:12.38 |
| | destroyed? | 15:12.49 |
| | no we cache the links | 15:12.53 |
| | and the profiles are around for a long time | 15:13.02 |
| | hanging out in color spaces or devices | 15:13.11 |
| Robin_Watts | sorry, I meant "put into the cache, and then finally destroyed when we destroyed them". | 15:13.13 |
| | But I see what you mean. | 15:13.24 |
| | And no, I don't believe there have been changes in that regard. | 15:13.34 |
| | So let's back quietly away from that one :) | 15:13.48 |
| mvrhel_laptop | sounds good | 15:13.53 |
| | ok. back to more stuff for customer 330. just did one giant commit for them | 15:14.12 |
| | I wish they would answer my emails though | 15:14.20 |
| | that is how I got Miles involved to begin with | 15:14.32 |
| chrisl | mvrhel_laptop: if they haven't been giving you feedback you need to proceed, you shouldn't be pressured about getting it done urgently...... | 15:16.17 |
| henrys | wow how many android viewers are there based on mupdf? I found quite a few. | 15:22.04 |
| Robin_Watts | henrys: All of them :) | 15:23.57 |
| henrys | it's impressive but really not great news. To have such command of a marketplace and to be making little money from it suggests there is not money to be had. | 15:29.46 |
| mvrhel_laptop | chrisl: yes. good point | 15:31.15 |
| chrisl | mvrhel_laptop: it's just not worth getting stressed about | 15:34.46 |
| mvrhel_laptop | henrys: you there? | 15:37.55 |
| henrys | yes | 15:38.04 |
| mvrhel_laptop | Do you know Andy who sent the detailed email from customer 330? | 15:38.40 |
| | henrys: I wonder if I should include him in the questions that I had | 15:39.16 |
| | It says he is a "solutions manager" | 15:39.49 |
| henrys | I don't know him but I can't think it would hurt to include him. | 15:40.42 |
| mvrhel_laptop | ok | 15:41.43 |
| kens | I see those psdcmyk files are showing diffs again with Michael's change :-( | 15:50.24 |
| Robin_Watts | I am investigating a segv in psdcmyk at the moment. | 15:52.27 |
| kens | Could be related I guess | 15:52.41 |
| Robin_Watts | an image_info block is being used in clist playback after it's freed. | 15:52.50 |
| kens | I gues if it gets reused that could cause the indeterminism | 15:53.51 |
| | happens at 72 dpi though | 15:54.24 |
| | as well as 300 | 15:54.28 |
| chrisl | Could be pattern clists, I suppose | 15:54.54 |
| | There's certainly no point doing anything more until Robin_Watts has finished with the seg fault | 15:55.56 |
| mvrhel_laptop | what going on? | 15:56.44 |
| kens | indeterminisms mvrhel | 15:57.14 |
| mvrhel_laptop | from one of my commits? never.... | 15:57.37 |
| | likely an issue with a rendering parameter that is now used and not getting properly set | 15:58.37 |
| henrys | Robin_Watts,tor8:having trouble with mupdf on nexus? What document do you know opens? | 15:58.39 |
| mvrhel_laptop | based upon the changes that I just did | 15:58.48 |
| Robin_Watts | pdf_reference17.pdf | 15:58.50 |
| chrisl | mvrhel_laptop: we're not sure where they started, kens noticed them yesterday, I noticed today, and the same files hve popped up showing differences in your latest commit run. | 15:58.54 |
| Robin_Watts | My SEGV predates michaels changes. | 15:59.12 |
| mvrhel_laptop | well one of the files that I fixed had a problem from way back | 15:59.17 |
| kens | Its not Michale's changes | 15:59.31 |
| ray_laptop | Robin_Watts: so, now that you understand what I think is the problem (it _definitely_ IS a problem), can you think of why your patch would have made it so much worse ? Did it change the allocations used by the cms, for example ? | 15:59.44 |
| mvrhel_laptop | 12-07D.PS was not rendering correctly and now is | 15:59.51 |
| Robin_Watts | ray_laptop: Absolutely. | 16:00.03 |
| | Previously all lcms' allocations went to malloc/free. | 16:00.16 |
| | Now they go to gs_alloc_bytes etc. | 16:00.26 |
| chrisl | mvrhel_laptop: the list of spurious psdcmyk diffs: http://pastebin.com/JamNXnQA | 16:00.49 |
| | All in PDF or PS jobs, when the change I was testing was in PCL/PXL...... | 16:01.13 |
| ray_laptop | Robin_Watts: OK. That makes sense. previously they didn't interact with PCL's base chunk allocator at all (allocator B) | 16:01.13 |
| Robin_Watts | right. | 16:01.20 |
| ray_laptop | that is allocator B not B) | 16:01.36 |
| mvrhel_laptop | ok. chrisl. I am going to keep pushing on this one thing for customer 330 now. Then I will look at these with valgrind to track down the issue | 16:01.45 |
| henrys | nope nothing seems to be working just grabbed the apk from mupdf.com/downloads | 16:02.03 |
| ray_laptop | chatzilla changes B followed by ) into a smiley with sunglasses :-( | 16:02.11 |
| chrisl | mvrhel_laptop: Or leave it to marcosw to try to track down where the indeterminisms happened...... | 16:02.45 |
| mvrhel_laptop | well there is that option, but it is likely that it came from my change | 16:03.07 |
| | since I introduced new parameters that affect the color and may not be getting initialized properly in some odd case | 16:03.38 |
| | I thought I found them all but we all know how it goes | 16:03.52 |
| chrisl | Fair enough.... it just that minor panic of "I didn't change anything around there......" when I saw them earlier | 16:04.32 |
| mvrhel_laptop | and we have been there before too :) | 16:04.52 |
| chrisl | Okay, I'm off for a squash match... | 16:06.49 |
| henrys | Robin_Watts, tor8:the default pdf viewer is fine. | 16:07.19 |
| Robin_Watts | henrys: How are you running it? | 16:07.56 |
| henrys | I'm selecting a pdf file then it asks me if I want to use mupdf or the default viewer. | 16:08.39 |
| Robin_Watts | And when you say mupdf, what happens? | 16:08.50 |
| henrys | Unable to open document | 16:09.19 |
| Robin_Watts | OK, so what happens if you run mupdf direct? | 16:09.30 |
| | Presumably "Unable to open document" is an android error, rather than one obviously from the mupdf app itself? | 16:10.02 |
| henrys | that seems to work. | 16:10.11 |
| Robin_Watts | OK. mupdf should list the documents in /Downloads (or /sdcard/Downloads, I forget) | 16:10.39 |
| | So you should see a list of documents there that you can select from? | 16:10.56 |
| henrys | but that's not okay ... I have no way to make mupdf the default viewer when I select a mupdf file, I hope that's a bug. | 16:11.05 |
| | not mupdf file a pdf file. | 16:11.16 |
| Robin_Watts | Right. | 16:11.25 |
| | Android provides an "Intent" system where we state what types we can open. | 16:11.42 |
| | as set in android/AndroidManifest.xml | 16:12.41 |
| | I have no idea why it wouldn't be working for you. | 16:12.49 |
| | Do you have android dev tools set up on your machine? | 16:13.17 |
| | What version of Android? | 16:13.35 |
| henrys | I do not I can set it up later | 16:13.41 |
| Robin_Watts | Let me just check here. Jelly Bean downloaded to my asus yesterday. | 16:14.04 |
| henrys | 4.1.1 | 16:14.04 |
| Robin_Watts | works fine for me :( | 16:14.49 |
| henrys | this should be okay demo wise, so it prompts you if you want to make mupdf the default or just once? | 16:15.12 |
| Robin_Watts | it does. | 16:15.24 |
| | and I say "just once" (for now) | 16:15.29 |
| henrys | for both "just once" and "default" I get unable to open and a dismiss button. | 16:16.32 |
| Robin_Watts | henrys: I'd like to see what "adb logcat" says when you have the tablet attached. | 16:17.04 |
| | We'll hopefully see some messages about why it failed to work. | 16:17.28 |
| henrys | Okay well I'll have to get that all set up on the mac. | 16:20.04 |
| henrys | was hoping not to become an android developer today... | 16:22.46 |
| | so I need the android sdk for the mac first | 16:25.08 |
| Robin_Watts | yeah, follow the instructions in mupdf/android/ReadMe.txt | 16:25.25 |
| henrys | will do. you left coffee out of instructions | 16:25.53 |
| Robin_Watts | Hmm. That should be in step 15 :) | 16:26.51 |
| kens | thinks every other step probably | 16:27.15 |
| | Time for me to be off, goodnight all | 16:45.34 |
| henrys | still installing ... | 16:48.06 |
| ray_laptop | mvrhel: henrys: alexcher: does anyone have any suggestions re: changing all allocators to make them optionally use a mutex when 'thread_use_count' > 1. This gets rid of the locking wrapper and 'thread_safe_memory' pointer and allows clients to switch on and off use of the mutex. | 16:50.43 |
| | I assume that chrisl, kens, and Robin_Watts have already weighed in. | 16:51.10 |
| mvrhel_laptop | ray_laptop: this sounds reasonable to me | 16:51.42 |
| ray_laptop | BTW, do we want a function added to 'reset' the thread_use_count, or at least to read it ? | 16:52.05 |
| | mvrhel: thanks | 16:52.43 |
| henrys | I am okay with it. Although I haven't read the bug carefully enough to understand the details of the pcl crashes. | 16:53.35 |
| ray_laptop | just to bring anyone up to speed, the issue is described in bug 693361 | 16:53.37 |
| | and in the logs above. Robin_Watts suggested using increment/decrement of a thread_use_count rather than a simple set/reset 'use_lock' which is slightly more complex, but may have advantages | 16:55.03 |
| | so one question remaining, other than 'elegance' or planning for something we don't really need (yet), should I do it the more complex way, or the simple way ? | 16:56.06 |
| | Robin_Watts: that is something I'd like your input on -- what did you have in mind that might need the thread_use_count vs. the use_lock | 16:56.52 |
| henrys | what exactly do you mean by "primary chunk allocator" - heap allocator? | 16:57.42 |
| ray_laptop | henrys: PCL uses a chunk allocator on top of the heap allocator as it's commonly used allocator | 16:58.23 |
| henrys | okay so you are talking about gsmchunk.c | 16:58.55 |
| ray_laptop | gs (PS/PDF only) use the GC allocator (ialloc) which does the chunking. | 16:59.08 |
| Robin_Watts | ray_laptop: I like hiding complexity under interfaces. | 17:00.19 |
| | partly cos I have a crap memory. | 17:00.26 |
| ray_laptop | neither the GC nor the chunk allocator is inherently thread safe (nor is gsmalloc heap allocator) but we always wrap the gsmalloc in a locking wrapper | 17:00.29 |
| | Robin_Watts: well set/reset use_lock is hardly more complex than adjust_thread_use_count( +/- ) | 17:01.20 |
| | or simply set_lock( true/false) | 17:01.54 |
| Robin_Watts | No, but I could believe that once you wrap it up nicely, the interface for adjust_thread_use_count is nicer. | 17:02.06 |
| | Specifically because callers don't need to get involved in the "Am I the last threaded user of this?" decision. | 17:02.34 |
| ray_laptop | Robin_Watts: 'nicer' or 'more elegant', true, but can you envision why we would ever need it ? | 17:02.39 |
| Robin_Watts | nicer and more elegant are both worth striving for. | 17:03.04 |
| | if only someone had pointed this out earlier in the development of gs :) | 17:03.18 |
| | The only excuse for ignoring "nicer and more elegant" is when they would excessively complex or slow. | 17:03.49 |
| ray_laptop | Robin_Watts: well, it does expose the potential for killing a thread (or having a thread shut down) without decrementing the use count, thus leaving us using the mutex (and only noticing if teh performance is crap) | 17:03.58 |
| Robin_Watts | Right, but if that happens, it's probably a sign that we got the interface wrong. | 17:04.38 |
| | Honestly, I'd be happy either way - it's you that has to maintain the code. | 17:04.54 |
| | My personal preference would be for the counted version (as it hides a decision from the caller), but having made my case, I'll leave it to the poor guy that has to implement it (i.e. you). | 17:05.34 |
| ray_laptop | Robin_Watts: but it's relatively hard to detect (maybe subtle performance that sometimes is serious) vs. a crash if it gets reset when it shouldn't which is actually not that hard to track down | 17:05.47 |
| | e.g. the chunk allocator has an 'in_use' flag in debug mode that led me right to the problem | 17:06.16 |
| Robin_Watts | ray_laptop: Well, when we destroy an allocator, we should assert that the count is zero. | 17:06.28 |
| | So it should be obvious on shutdown if something is miscounting. | 17:06.42 |
| ray_laptop | Robin_Watts: right, I thought of that, so that may suffice. | 17:06.52 |
| henrys | I'm also good with ray_laptop's decision but uncomfortable something else isn't awry here, why are we just seeing this now? | 17:07.04 |
| ray_laptop | henrys: we are seeing it now because Robin_Watts changed the cms to use the thread's allocator. | 17:07.36 |
| Robin_Watts | henrys: My change moved a lot of allocations/deallocations from malloc/free to gs_alloc_bytes. | 17:07.48 |
| | hence lots more scope for threaded contention. | 17:08.02 |
| ray_laptop | henrys: and the cms tends to need new chunks more often than 'normal' rendering, so it is more likely to encounter the race | 17:08.22 |
| | the race being where the main thread allocates while the rendering thread needs a new chunk | 17:09.04 |
| | and this only happens with PCL when NumRenderingThreads > 0 (which is not tested on every cluster run) | 17:10.06 |
| henrys | yes but I've run into pcl jobs that really hit the allocator, I would think the number of allocations from cms added would pale in comparison, but maybe I'm wrong. | 17:10.10 |
| ray_laptop | henrys: this can only occur when rendering the page, so PCL parsing is immune | 17:10.51 |
| | henrys: and the allocations from within the threads themselves all use the mutex before accessing the base chunk allocator, so they are 'safe'. | 17:11.54 |
| henrys | oh okay right than that would make more sense. | 17:12.26 |
| ray_laptop | it's only when the main thread is doing an allocate/free while a thread gets a new chunk that there is an issue. | 17:12.54 |
| | a lot of the 'normal' allocation pattern for rendering a clist just thrashes alloc/free within a chunk the thread already 'owns' so the base allocator isn't used that much (which is why each thread has a chunk alllocator in the first place) | 17:14.09 |
| | BTW, I think we should have an image of a burglar along the bottom of the website that goes to a page of known 'parasites' or those that we consider are violating the GPL ;-) | 17:16.57 |
| | i.e., a 'cheaters' page | 17:17.15 |
| | Robin_Watts: on the new website, can't Miles make the changes (as he will be doing with the new CMS) to 'practice' before going live ? | 17:19.15 |
| Robin_Watts | ray_laptop: Yes. I just sent him account details for the CMS. | 17:19.44 |
| | so he can log in and make the changes. | 17:19.50 |
| | I had (wrongly) thought that the site structure would be edited one way, and press releases another, but it's all done the same way, so it makes sense for him to do it. | 17:20.20 |
| ray_laptop | Robin_Watts: OK, ignore the email I had sent. Thanks. (you are much more valuable editing code) | 17:20.52 |
| | I have to run something over to the school. I'll check back on the logs before diving in to hacking up the allocators (again). | 17:21.50 |
| henrys | Robin_Watts:I'm watching Helen play at musickecompanye | 17:26.35 |
| Robin_Watts | henrys: Ah, the shiny new videos. Have we hit triple figured views yet? :) | 17:27.12 |
| | not yet :) | 17:27.40 |
| | I've been threatened with severe bodily trauma if I give you the link to our unedited galapagos pictures. | 17:28.27 |
| | I can try to produce a set with our fatter ex-selves removed :) | 17:29.31 |
| henrys | love to see them but don't get yourself in trouble. | 17:32.40 |
| | Helen takes golden oldies to a new level, the 16th century. | 17:33.21 |
| mvrhel_laptop | ok. my spot color replacement mixing for DeviceN colors is working pretty well | 17:40.18 |
| Robin_Watts | Hmm. | 17:43.01 |
| | I have a stream *s, where s->memory is nicely defined. | 17:43.11 |
| | And s->state->memory = NULL. | 17:43.18 |
| | Is that a bug? | 17:43.25 |
| mvrhel_laptop | bbiaw | 17:45.22 |
| | ah a response from customer 330 | 17:46.18 |
| Robin_Watts | ray_laptop: gxclread.c line 810: s_init_state((stream_state *)&rs, &s_band_read_template, (gs_memory_t *)0); <- Why the 0 memory pointer? | 17:51.33 |
| | So this SEGV is another crap in the clist problem, I think. | 18:12.50 |
| ray_laptop | Robin_Watts: having a look at that... | 18:17.38 |
| | Robin_Watts: that line dates back to 2000 from Peter. | 18:21.17 |
| Robin_Watts | Possibly at that point there wasn't a memory pointer to put into it. | 18:21.36 |
| | BUT... | 18:21.38 |
| ray_laptop | that's a BIG "BUT" | 18:22.25 |
| Robin_Watts | (it had to hold your attention while I looked up the rest :) ) | 18:22.53 |
| | in s_band_read_process we call: process_interrupts(st->memory), where we kind of assume that it's not NULL. | 18:23.18 |
| ray_laptop | Robin_Watts: so, why is this a problem ? Related to being able to do debug prints or something ? | 18:23.20 |
| Robin_Watts | And also my debug printing relies on it being non NULL in the same function. | 18:23.32 |
| | It's entirely possible that I added both those requirements in the course of various commits though :) | 18:23.53 |
| | So unless you can think of a good reason not to, I'm going to change it to mem rather than 0. | 18:24.28 |
| ray_laptop | Robin_Watts: sure, go ahead. It makes sense (and "NULL" doesn't) | 18:26.00 |
| | Robin_Watts: are you also going to clean up the gp_check_interrupts so that 'mem' cannot be NULL (that may help spot things) | 18:26.37 |
| Robin_Watts | I might later. | 18:26.55 |
| ray_laptop | there are hacks in there now that violate multi-threaded usage | 18:27.14 |
| Robin_Watts | At the moment this is just a distraction from the SEGV due to to clist corruption I'm looking at. | 18:27.18 |
| ray_laptop | Robin_Watts: single threaded rendering, I presume | 18:27.43 |
| Robin_Watts | yes. | 18:27.56 |
| | ray_laptop: Are there? | 18:27.58 |
| ray_laptop | Robin_Watts: yes, look at gp_mspol.c and gp_macpoll.c (they may be moribund) | 18:28.43 |
| Robin_Watts | if (mem == NULL) right. | 18:28.57 |
| | I'll change that to #ifndef GS_THREADSAFE | 18:29.07 |
| ray_laptop | Robin_Watts: ping me (SMS) if you want advice on looking at the clist corruption. I've worked on several of those | 18:32.02 |
| | (assuming that I don't respond here) | 18:32.24 |
| Robin_Watts | ray_laptop: If I can't sort it by the time I go tonight, I'll update the bug and mention it here. | 18:32.53 |
| radistao | ray_laptop: hi. Your advice really helped me to locale text in PDF page at the center | 18:36.22 |
| | ray_laptop: i did this: clippath pathbbox 2 index add 2 div /PctrY exch def 2 index add 2 div /PctrX exch def pop pop %page center /Arial-Bold 120 selectfont .5 setgray (Sample) dup stringwidth pop 2 div PctrX exch sub PctrY moveto show | 18:36.37 |
| Robin_Watts | radistao: Nice one. Now you're a postscript hacker :) | 18:37.18 |
| radistao | but, only one notice, you you can help: if i rotate Sample text at least on 10 degrees - it moves left and now not in center | 18:37.34 |
| | how to processs this? | 18:37.45 |
| Robin_Watts | radistao: You are positioning the bottom left hand corner of the text. | 18:38.30 |
| | If you're rotating it, you therefore need to adjust how much you move from the specified centre point. | 18:39.02 |
| | For an angle of 0, you move (-stringwidth/2, 0) right? | 18:39.54 |
| radistao | on which point PS rotates text? Left bottom? middle? | 18:40.06 |
| | correct | 18:40.20 |
| Robin_Watts | For an angle of alpha you move (-stringwidth/2 * sin(alpha), -stringwidth/2 * cos(alpha)) | 18:40.35 |
| | (make sure alpha is in radians/degrees as appropriate) | 18:40.56 |
| ray_laptop | radistao: you want to 'moveto' the center of the page, then rotate by the desired angle, THEN moveto backwards in (the transformed) X by 1/2 the stringwidth | 18:41.05 |
| radistao | Robin_Watts: degrees | 18:42.40 |
| ray_laptop | radistao: /Arial-Bold 120 selectfont PctxX PctrY moveto __angle___ rotate (Sample) dup stringwidth pop 2 div neg 0 moveto show | 18:42.45 |
| | radistao: by moving to the center of the page, then rotating, it makes the subsequent 'moveto' work in the rotated coordinate system | 18:43.53 |
| | radistao: note that the PS 'rotate' operator works in degrees (as you probably knew) | 18:46.28 |
| | radistao: oops. that should be PctxX PctrY translate __angle___ rotate (translate sets the center for the rotation, not moveto) | 18:47.58 |
| | I'll try it just to make sure :-) | 18:48.23 |
| radistao | i've tried | 18:48.53 |
| | error | 18:48.56 |
| | but damn PS - -it makes absolutely unredable error logs | 18:49.28 |
| | stdout: Error: /undefined stdout: in --.endpage-- stdout: Operand stack: 0 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %s stdout: topped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- -- stdout: nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1809 0 3 %op | 18:49.50 |
| Robin_Watts | ray_laptop: OK. This seems to be a fault with fill_trapezoid. | 18:50.07 |
| | The first fill_trap that gets written into the file is read back as a fill_trap, but everything afterwards is honked up. | 18:50.36 |
| ray_laptop | radistao: no, you just have to know how to read (that particular format) | 18:50.53 |
| | radistao: BTW, I had a typo. When I tested, this worked: | 18:52.43 |
| | clippath pathbbox 2 index add 2 div /PctrY exch def 2 index add 2 div /PctrX exch def pop pop | 18:52.45 |
| | /Arial-Bold 120 selectfont PctrX PctrY translate 30 rotate (Sample) dup stringwidth | 18:52.47 |
| | pop 2 div neg 0 moveto show | 18:52.48 |
| | Robin_Watts: its usually a colorspace issue. | 18:53.19 |
| Robin_Watts | I'm sure. This is psdcmyk, so it'll be something to do with the planar nature. | 18:53.43 |
| ray_laptop | Robin_Watts: is it a linear color trapeziod, or (i.e. what "options" bits) | 18:56.12 |
| radistao | sorry, guys, i switched off my PC accidentally | 18:57.35 |
| ray_laptop | radistao: check the logs | 18:58.14 |
| | radistao: I posted an actually tested, working PS snippet | 18:58.37 |
| radistao | you mean chat log? how to do this? | 18:58.47 |
| | i see http://ghostscript.com/irclogs/20121004.html | 18:59.15 |
| ray_laptop | radistao: duh? it says in the channel topic. http://ghostscript.com/irclogs/current.html (that's always the most recent) | 18:59.39 |
| | radistao: but the URL with the date is good enough (for today) | 19:01.05 |
| | phone call ... | 19:02.43 |
| radistao | cool, really works great! | 19:06.10 |
| Robin_Watts | ray_laptop: It looks like it's a constant color trap from a mesh decomposition. | 19:07.58 |
| | no, scratch that. | 19:09.00 |
| | I think my breakpoint didn't catch the first one. | 19:09.10 |
| slestak_work | hey guys. I am getting warnings from my barracuda from ghostscript.com | 19:09.41 |
| | just started in teh past 24-48 hours | 19:09.50 |
| | The link you are accessing has been blocked by the Barracuda Web Filter because it contains spyware. The name of the spyware is: Spyware.Exploit.Misc.MU.ghostscript.com | 19:10.03 |
| mvrhel_laptop | ok so those indeterminisms are irritating. I will see if I can figure out what is going on | 19:11.42 |
| Robin_Watts | mvrhel_laptop: They are with psdcmyk, right? | 19:12.35 |
| mvrhel_laptop | yes | 19:12.42 |
| Robin_Watts | It may be the issue I'm looking at. | 19:12.42 |
| mvrhel_laptop | oh ok good | 19:12.46 |
| | then I will continue on my next issue for customer 330 | 19:12.55 |
| Robin_Watts | I'm seeing it as a SEGV, but it might manifest differently. | 19:13.07 |
| | I wouldn't let it distract you for now. | 19:13.17 |
| mvrhel_laptop | ok. | 19:13.24 |
| slestak_work | you can specify more than one -sDEVICE in ghostscript? I cannot access the docs right now. | 19:22.34 |
| Robin_Watts | slestak_work: One at a time. | 19:22.44 |
| slestak_work | ok, tyvm. I thought I read somewhere you could do multiple | 19:23.01 |
| Robin_Watts | If you specify a second, the first is lost. | 19:23.04 |
| | So you can change devices between pages/files etc. | 19:23.16 |
| henrys | with the last commit there should now be 0 gcc warnings in pxl and pcl, let see how long that lasts. | 19:39.26 |
| | back to the android business | 19:39.55 |
| nonane | hi | 19:49.21 |
| ghostbot | moin moin | 19:49.21 |
| nonane | are any MuPDF developers hanging around here? | 19:49.45 |
| | Wanted to know if MuPDF can convert XPS to PDF | 19:50.24 |
| henrys | Robin_Watts:logcat sent | 20:15.23 |
| Robin_Watts | noname: Not currently. | 20:19.25 |
| | Though I have some code that is the start of that functionality. | 20:19.47 |
| | Ahahaha. I see the problem. | 20:21.20 |
| | mvrhel: You here? | 20:21.27 |
| | mvrhel_laptop: or you for that matter. | 20:22.03 |
| | henrys: ok. is it possible that the directory you have the document you are trying to open in is unreadable? | 20:24.02 |
| | Or it is that we are refusing to open it because it doesn't have a .pdf on the end? | 20:24.45 |
| | or is there a space in the document name ? | 20:26.06 |
| | What's the name of the file you are trying to open? | 20:26.17 |
| | The very first entrypoint we get called with is MuPDFActivity.openFile(String path); | 20:28.43 |
| | and we do: System.out.println("Trying to open "+path); | 20:28.59 |
| | which is coming out as I/System.out( 1655): Trying to open /all_downloads/150 | 20:29.12 |
| | I'm betting the file you are trying to open is something like: "150 ways to leave your lover.pdf" | 20:29.39 |
| nonane | Thanks Robin | 20:30.32 |
| Robin_Watts | nonane: The relevant commits are probably available online if you fancy extending the code. | 20:32.38 |
| henrys | Robin_Watts:all I did was download adobe pdf documentation from adobe's web site (using chrome). Went to downloads and tried to open the pdf's | 20:37.05 |
| Robin_Watts | and did the name have a space in it ? | 20:37.47 |
| henrys | I'll check hang on. | 20:38.41 |
| | no spaces I can do a shell ls and see the files from adb | 20:40.09 |
| Robin_Watts | mvrhel_laptop: For the logs: It seems we are writing a fill_trapezoid in, and as part of that, we write color data. It writes num_components worth of color data (which at writing time is 14). | 20:40.13 |
| | At reading time, there is a pdf14 device on the stack, and so we try to read 17 colors. | 20:40.37 |
| | henrys: What was the filename ? | 20:40.49 |
| henrys` | ./adb shell ls storage/sdcard0/Download | 20:42.18 |
| | PDF32000_2008.pdf | 20:42.18 |
| | adobe_supplement_iso32000-1.pdf | 20:42.18 |
| | adobe_supplement_iso32000.pdf | 20:42.18 |
| | adobe_supplement_iso32000_1.pdf | 20:42.21 |
| | mupdf-1.1-android-1.apk | 20:42.24 |
| | mupdf-1.1-android.apk | 20:42.26 |
| Robin_Watts | So... why is mupdf being invoked with path = "/all_downloads/150" ? | 20:43.20 |
| henrys` | I don't know, I don't see any such directory on the file system. | 20:45.34 |
| Robin_Watts | I wonder if it's a workaround for an old SDK bug, or something stupid. | 20:46.13 |
| | Or whether it's a virtual path or something. | 20:46.25 |
| | ./adb shell ls /all_downloads/ doesn't give anything then ? | 20:47.58 |
| henrys` | no such file or directory | 20:48.16 |
| Robin_Watts | Ah... | 20:48.47 |
| henrys` | I did a recursive ls and searched everythign no luck | 20:48.51 |
| Robin_Watts | open the apk and edit the AndroidManifest.xml | 20:49.20 |
| | <!-- Allows an app to access all downloads in the system via the /all_downloads/ URIs. The | 20:49.33 |
| | protection level could be relaxed in the future to support third-party download | 20:49.35 |
| | managers. --> | 20:49.37 |
| | <permission android:name="android.permission.ACCESS_ALL_DOWNLOADS" | 20:49.39 |
| | android:label="@string/permlab_accessAllDownloads" | 20:49.40 |
| | android:description="@string/permdesc_accessAllDownloads" | 20:49.42 |
| | android:protectionLevel="signature"/> | 20:49.44 |
| | and add that in. | 20:50.40 |
| slestak_work | Robin_Watts: this example from the ghostpdl docs is what I was thinking of when I was trying to output to txtwrite and tiffg3 in one run | 20:50.48 |
| | pcl6 -r72 -sDEVICE=x11mono mypcl.pcl -r100 -sDEVICE=x11 mypcl.pcl | 20:50.50 |
| | the docs also say "This demonstrates on-the-ï¬y device switching." | 20:51.09 |
| Robin_Watts | Right. That displays mypcl.pcl to a 72dpi x11mono device. | 20:51.23 |
| | Then it displays mypcl.pcl to a 100dpi x11 device. | 20:51.36 |
| | Note that mypcl.pcl is given twice on the command line. | 20:51.57 |
| slestak_work | it says in http://www.artifex.com/downloads/doc/ghostpcl.pdf that it "Render a pcl ï¬le at 72dpi on the monochrome X11 device, then render the same ï¬le at 100 dpi on color X11 | 20:52.07 |
| | device." | 20:52.07 |
| Robin_Watts | Right. | 20:52.14 |
| | It's only the same file because the same file is given twice on the command line. | 20:52.31 |
| slestak_work | oh yeah, mypcl.pcl is there twice | 20:52.42 |
| Robin_Watts | henrys: If you look here: | 20:54.20 |
| | https://bitbucket.org/bigxie/android_packages_providers_downloadprovider/src/ab43bb48fd41/AndroidManifest.xml | 20:54.25 |
| | You can see various bits of gubbins to do with path-permission for /all_downloads | 20:54.42 |
| | We need to shoehorn the relevant bits into our AndroidManifest.xml I think. | 20:54.58 |
| henrys` | can I simply unzip this and zip it back up again | 20:55.47 |
| Robin_Watts | an apk is just a zip file. | 20:55.56 |
| henrys` | okay | 20:56.00 |
| Robin_Watts | I believe you can unzip, edit the Manifest and rezip without it getting annoyed. | 20:56.16 |
| henrys` | that's what I'm trying | 20:56.33 |
| Robin_Watts | Annoyingly I can't find any docs on this. | 20:56.34 |
| | Right, so it looks like it's <uses-permission...> lines you need. | 20:57.33 |
| | specifically the one for android.permission.ACCESS_ALL_DOWNLOADS | 20:57.48 |
| | But... you might find that you can't do it without using a signed apk. | 20:58.06 |
| henrys` | something is quite screwy here - | 20:58.42 |
| | file AndroidManifest.xml | 20:58.44 |
| | AndroidManifest.xml: DBase 3 data file (5596 records) | 20:58.44 |
| | all binary data. | 20:58.51 |
| Robin_Watts | oh, maybe they encode it as part of the build process. | 20:59.14 |
| | Are you set up to rebuild yet? :) | 20:59.26 |
| henrys` | Robin_Watts:I just installed platform tools. Actually I didn't even use what I installed I just ran everything out of the download and it seemed to work. | 21:00.42 |
| | it seems like one of you A team droid developers should take this one over ;-) | 21:01.58 |
| Robin_Watts | Right, but how can I test my changes? | 21:02.44 |
| henrys` | Robin_Watts:why don't you put up a good guess I'll test it, if it fails I'll get give development a go. | 21:04.17 |
| Robin_Watts | OK. I'll have a go tomorrow. | 21:05.18 |
| henrys` | okay | 21:05.49 |
| Robin_Watts | Maybe if I update the tools I can get the same behaviour out of the emulator. | 21:05.56 |
| | It's odd that my tablet likes it. | 21:06.10 |
| | have you turned on "install unsigned apps" ? | 21:06.26 |
| | I fear that in order for us to make this work, we need to get a proper key to sign things, which means being a proper developer. | 21:07.49 |
| | And last time I tried that, I ran into problems with google insisting on combining my personal google account with the company one. | 21:08.12 |
| henrys` | Robin_Watts:well mupdf is installed, where is that? | 21:08.14 |
| Robin_Watts | One of the settings options. | 21:08.23 |
| | Security: Device Administration | 21:09.06 |
| | Unknown sources: Allow uinstallation of apps from unknown sources | 21:09.20 |
| henrys` | yes it is enabled | 21:09.57 |
| henrys | if I have some extra time today I'll set up a dev env, I need to do it eventually anyway. I just have some other stuff I wanted to get cleared today. | 21:15.14 |
| Robin_Watts | Sure. | 21:15.24 |
| | I don't think this is something we can trivially get fixed before the show, because I'm sure it's going to involve getting a developer key from google, and to do that we need to sort the bloody dev account out. | 21:15.57 |
| | ISTR that I tried before I went on holiday, and didn't have time to sort it properly. Very annoying. | 21:16.19 |
| henrys` | I was hoping google would be a little less intense than apple on this front but it doesn't look much better. | 21:17.28 |
| Robin_Watts | They insisted on linking the accounts together because I'd used the same card or something. | 21:18.35 |
| | and then I could not find any way of unlinking them. | 21:18.52 |
| | Anyway, afk for a bit. | 21:19.16 |
| sebras | Robin_Watts: ASCII octal 0150 == 'h'... what if the remainder of the string is 0164 0164 0160 072 057 057..? it's a long shot idea, but just something I noticed. | 21:24.57 |
| | Robin_Watts: I'm not really sure how these things work. :) | 21:25.19 |
| | Forward 1 day (to 2012/10/05)>>> | |
IRC Logs