| <<<Back 1 day (to 2013/01/22) | 2013/01/23 |
Robin_Watts | https://play.google.com/store/apps/details?id=com.artifex.mupdfdemo&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5hcnRpZmV4Lm11cGRmZGVtbyJd | 10:20.32 |
paulgardiner | Lovely | 10:27.28 |
sebras | Robin_Watts: how come that the developers page does not link to mupdf.com..? | 10:40.31 |
Robin_Watts | Does now :) | 10:41.29 |
| Might take a few hours to show up. | 10:41.44 |
sebras | ah. :) | 10:41.53 |
tor8 | Robin_Watts: argh! now I finally figured out why the tinting on the file picker icons didn't work... | 11:37.56 |
| setBackgroundResource() should be setImageResource()... | 11:38.10 |
Robin_Watts | tor8: Ah. | 11:38.54 |
tor8 | Robin_Watts: also, the lack of a path to where the navigation is is driving me nuts... | 11:39.16 |
Robin_Watts | Well, if you fix the icons we can rebuild and reupload, and I can test the auto update thing with Helens phone :) | 11:39.21 |
tor8 | Robin_Watts: I want to experiment more with the icons | 11:39.36 |
| I'm not entirely happy with some of them | 11:39.44 |
| maybe we should make a list of all icons we can think of that we'll want to use | 11:40.38 |
| thinking ahead of the features for annotation that are in development | 11:40.48 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=75643c9a1353b77b59e4c3006298a5feac81e33a | 11:53.45 |
| Fixes various files. I've just been through the bmpcmp. | 11:53.57 |
tor8 | Robin_Watts: fz_transform_vector for transforming points that are used as vectors (i.e. ignore the translation)? | 12:08.58 |
Robin_Watts | tor8: could do, I guess. | 12:11.24 |
| Would that be useful anywhere else? | 12:12.09 |
tor8 | Robin_Watts: probably not | 12:17.47 |
Robin_Watts | If it was used in more than one place then that function would be more clearly a win. | 12:19.30 |
| Woo Hoo! I have smart advance working with pretty scrolling effects within a page. | 12:22.47 |
| Need to sort the advance to next page thing now. | 12:22.59 |
kens | network kicking time | 14:06.27 |
tor8 | Robin_Watts: http://ghostscript.com/~tor/stuff/mupdf-debug-batch.apk yet another set of icons | 15:51.50 |
| rather fat and rounded, but it turned out nicer than I would have expected | 15:52.04 |
paulgardiner | Yeah, I quite like those | 15:55.12 |
tor8 | paulgardiner: the set is a bit more complete than the old "iconic" set as well | 15:55.38 |
| if it ends up missing things, it'll be harder to find ones that match though... given how much character it has | 15:56.10 |
Robin_Watts | I'm up to my ears in this smart motion stuff. | 15:57.47 |
| It looks really promising, I just can't get the moving back a page to work. | 15:57.57 |
| tor8: Ugh. I hate the directory icon, | 16:24.26 |
| All the others seem nice though. | 16:25.20 |
| http://ghostscript.com/~robin/MuPDF-debug.apk | 16:26.25 |
| tor8, paulgardiner: That has a first version of smart motion implemented. Let me know what you think. | 16:26.45 |
paulgardiner | Like it. Seems to work fine. | 16:30.19 |
Robin_Watts | Morning henrys | 16:42.20 |
henrys | howdy Robin_Watts | 16:42.37 |
Robin_Watts | tor8: Oh! fz_transform_vector already exists! | 16:47.22 |
tor8 | Robin_Watts: ahem. I didn't know that! | 16:47.53 |
Robin_Watts | I'll update the review :) | 16:48.11 |
henrys | chrisl:we seem to generating tiff configuration files somewhere other than the build "gendir", I didn't track it down, I noticed in when trying to build a windows system in a shared directory after a unix build. I did clean and even blew away the "gendir" | 16:54.10 |
| chrisl:not a big deal but if it is something easily fixed great. | 16:54.31 |
tor8 | Robin_Watts: I would prefer a different name for "p2", like "dp" or something more diff/delta-ish. other than that it looks good. | 16:54.35 |
| Robin_Watts: I used 'dir' in a few other places | 16:55.02 |
chrisl | henrys: I mentioned that a *long* time ago. Problem: gendir doesn't exist during configure - also, when I checked it before, the libtiff configure script didn't work from a different directory | 16:55.59 |
mvrhel_laptop | good morning | 16:56.15 |
Robin_Watts | Morning michael. | 16:56.30 |
| tor8: p2 => dir done | 16:57.05 |
mvrhel_laptop | cool. I will try the download on the nexus when I get back home (at coffee shop now) | 16:57.19 |
tor8 | Robin_Watts: push away! | 16:57.40 |
Robin_Watts | ta. | 16:57.44 |
henrys | chrisl:ah okay | 16:57.46 |
tor8 | Robin_Watts: paulgardiner: two quick android related reviews on tor/icons | 16:58.00 |
chrisl | henrys: I did think we could do something like create a "tiff-config" directory - *if* the tiff configure works now | 16:58.57 |
Robin_Watts | tor8: Urm... so if I'm in /mnt/sdcard/Download, the file picker will have "/mnt/sdcard/Download" where it used to have .. ? | 16:59.30 |
kens | OK off for pizzagoodnight all | 16:59.40 |
Robin_Watts | night kens | 16:59.44 |
tor8 | Robin_Watts: yeah. feel free to improve it. | 16:59.46 |
| Robin_Watts: but it has the "up" arrow there so it made sort of sense | 16:59.56 |
henrys | chrisl:does it make sense to have gendir created by configure? | 17:00.01 |
Robin_Watts | tor8: it would be nicer if it said "[/mnt/sdcard]" and the title bar said: "MuPDF 1.1: Download" | 17:00.52 |
| or maybe we could just make it say "/mnt/sdcard/Download/.." ? | 17:01.12 |
chrisl | henrys: "gendir" differs depending on the type of build you do, we don't know what it will be at configure time - release, debug, etc | 17:01.15 |
tor8 | Robin_Watts: or "[ Up one level ]" and the title had the path? | 17:01.19 |
henrys | chrisl:as it is now everything but tiff generates to gendir right? | 17:01.20 |
Robin_Watts | tor8: That would be nicest. | 17:01.51 |
chrisl | henrys: IIRC, tiff is the only other configure script we run, now | 17:01.54 |
henrys | chrisl:yeah I was thinking of pushing all those options up to configure | 17:02.03 |
Robin_Watts | I'm not sure how to set the title programmatically though. | 17:02.11 |
henrys | I suppose that would be a big change. | 17:02.22 |
tor8 | Robin_Watts: that feels like a horrible hack though... | 17:02.32 |
Robin_Watts | Does it? That feels correct to me. | 17:02.51 |
| (The title saying "MuPDF 1.1: path" and .. being "[Up one level]") | 17:03.25 |
tor8 | I mean abusing the title like that. But it's the best idea so far. | 17:03.46 |
henrys | chrisl:but it would simplify the makefiles quite a bit. | 17:04.00 |
Robin_Watts | wooah. henrys, you want to configure between release and debug builds? | 17:04.33 |
chrisl | henrys: well, I like not having to re-configure for the different builds. | 17:04.41 |
Robin_Watts | No way, dude. | 17:04.43 |
tor8 | Robin_Watts: the bounce back when trying to swipe to flip pages is really annoying! | 17:05.47 |
henrys | chrisl:okay fair enough | 17:06.22 |
chrisl | Also, not being funny, but the way it used to "work" that stuff was done in both configure and makefiles. We discussed it a couple of years ago, and all agreed to handling it in the makefiles - and we've devoted a fair amount of time to getting all working nicely. | 17:06.25 |
tor8 | but I guess that's the android gesture recognizer not being as good as apple's | 17:06.26 |
Robin_Watts | tor8: dunno. | 17:07.11 |
| I think Paul took the decision that any 'fling' stops at page boundaries. | 17:07.25 |
| The alternative is to let the fling continue, and then to reset from where it stops. | 17:07.41 |
| That would make swiping easier. | 17:07.50 |
| But it may have issues with how many pages we have loaded at a time or something. | 17:08.12 |
paulgardiner | It's the scroller that made that decision really. We could have used OverScroller but it's not in v8 | 17:08.55 |
| I guess we could fake it or make it conditional | 17:09.30 |
Robin_Watts | Well, we could use OverScoller if it's present, and the current one otherwise ? | 17:09.31 |
| The question is, do we make left/right do what up/down do now ? | 17:10.03 |
paulgardiner | For chinese text in rows? :-) | 17:11.44 |
chrisl | henrys: is there somewhere "central" where we can grab the contributor agreement? | 17:11.58 |
henrys | chrisl:oh did we not put that up yet I've ticked it off my todo list | 17:12.54 |
| nothing back from URW BTW... | 17:13.18 |
| yes | 17:13.20 |
paulgardiner | If you had zoomed in to lose the margins, then it would move hard right before a page change which would be detrimental | 17:13.22 |
henrys | s/yes/yet | 17:13.25 |
Robin_Watts | paulgardiner: No. It only moves right if it can fit a whole new column in. | 17:13.49 |
chrisl | henrys: I've never even seen the agreement..... I don't know it Robin did the bugzilla hackery for it at some point | 17:14.04 |
paulgardiner | oh ok | 17:14.10 |
Robin_Watts | chrisl: I did not. | 17:14.22 |
henrys | I'll send it to tech | 17:14.46 |
chrisl | Cool thanks. | 17:14.56 |
| And I'll update the interested users about the URW thing...... | 17:15.24 |
henrys | done | 17:16.16 |
chrisl | Thanks | 17:17.53 |
Robin_Watts | tor8: I have a version working here with the title etc. Will upload an apk in a sec. | 17:20.49 |
chrisl | henrys: so, in new(er) libtiff we're using now, the configure script works okay from a different directory, so I think it would be good to change things around to use a "config" directory, or similar. | 17:23.59 |
henrys | chrisl:that would make it easier for shared directory builds. | 17:26.46 |
chrisl | henrys: I'll put it on my todo list..... I would certainly prefer it to work that way | 17:27.28 |
henrys | although I bet there is a simple way to get rid of extra files using git. - remove everything not under source control. | 17:28.19 |
Robin_Watts | git clean | 17:28.26 |
| tor8, paulgardiner: http://ghostscript.com/~robin/MuPDF-debug.apk | 17:29.03 |
| Observe the file picker. | 17:29.12 |
chrisl | henrys: or with extreme prejudice: git clean -x -f -d | 17:29.45 |
Robin_Watts | git alias nuke="git clean -x -f -d" :) | 17:30.27 |
chrisl | I prefer not to make something that extreme too easy! | 17:31.05 |
henrys | indeed I know I'll eventually lose an added file once I start the git clean habit | 17:32.56 |
| not added in the git sense | 17:33.37 |
| but something I want in the directory. | 17:33.45 |
chrisl | My most common one is losing a cut-down test file to git clean - but then, I also lose them to "make clean" since we started obliterating the obj and bin dirs for that. | 17:34.31 |
ray_laptop | alexcher: I'm glad you were able to duplicate bug 693496. Cust 532 would like an estimate for when it will be fixed. | 17:34.41 |
chrisl | ray_laptop: have you got a sec to talk about something related to the GC problem I'm looking at (Bug 693571)? | 17:37.22 |
ray_laptop | chrisl: sure. | 17:40.17 |
chrisl | ray_laptop: cool. So, in the gs_ref_memory_t structure we've got the chunk list (cfirst), the current chunk (pcc) in the list and the "active" chunk (cc) | 17:42.04 |
| Now "cc" is "in-line" with the gs_ref_memory_t structure, so we end up copying the contents of the chunk into and out of that and the chunk list | 17:43.39 |
| alloc_close_chunk() and alloc_open_chunk() do that copying. | 17:44.32 |
ray_laptop | ok, following so far | 17:44.47 |
chrisl | So, what I'm wondering is: do we really need the "cc", can't we just use "pcc" and ditch all the copying? | 17:45.19 |
ray_laptop | chrisl: then where will the current chunk be ? Just allocated on it's own ? | 17:46.07 |
chrisl | ray_laptop: it already is allocated, and held in the chunk list, what's in cc is a copy | 17:47.02 |
ray_laptop | chrisl: OK, right. But how does not copying to 'cc' cure the problem ? | 17:47.43 |
chrisl | ray_laptop: the issue in this bug is that we get into garbage collection with a chunk that hasn't been "closed" since the last "free" operation, hence the pointers in the chunk in the chunk list do not match the pointers in the cc structure | 17:49.35 |
| So, the chunk validator tries to validate memory that has actually been freed | 17:50.39 |
| I have a fix for that, but it strikes me as pointless doing the copying back and forth when we could simply use the chunk in the chunk list directly (via the pcc pointer) | 17:52.21 |
ray_laptop | chrisl: but the start of a GC calls alloc_close_chunk before it does the GC | 17:53.22 |
| ireclaim.c line 125 | 17:53.50 |
| chrisl: so how can we get into garbage collection with a chunk that hasn't been "closed" since the last "free" | 17:55.20 |
chrisl | ray_laptop: we only close the current chunk in the "top" allocator....... | 17:56.12 |
| ray_laptop: the problem is when we do a save: we can use the allocator *after* it has been "saved", and that can leave it in an "unstable" state | 17:56.29 |
ray_laptop | chrisl: so you are seeing a 'free' in a chunk that isn't an 'inner_chunk' ? | 18:05.20 |
chrisl | ray_laptop: err, is it an inner_chunk? During a save operation, we can free memory using "mem->saved.state", and that leaves us in the unstable state | 18:07.39 |
| ray_laptop: (now that my debugger is talking to me again!), this is happening in alloc_save_state() | 18:15.12 |
| If we're past the first save level, we call save_set_new() passing in the *previous* generation of allocator. That can eventually call drop_redundant_changes() which can free memory in an allocator whose current chunk has already been alloc_close_chunk()'ed | 18:18.15 |
| Hmm, the cluster seems to be throwing a fit again :-( | 18:21.09 |
ray_laptop | chrisl: All of the 'save' stuff is something I've never (as far as I can recall) dug into, but I thought that 'changes' were all supposed to be allocated in the chunks after the save, so how can there be a change from an outer chunk being freed by drop_redundant_changes ?? | 18:27.57 |
chrisl | ray_laptop: changes are allocated after the save - once we've "saved" an allocator, though, we try to get rid of any pointless "changes", and that's where this problem arises. | 18:30.17 |
| ray_laptop: so, if you put a breakpoint in alloc_save_state(), and skip to the first non-global save (the third call, for me)....... | 18:32.10 |
| At that point lmem->save_level == 2 | 18:33.04 |
ray_laptop | chrisl: I need to fire up the debugger with the problem file. Just a mo... | 18:33.31 |
| oh, great. It's rebuilding about eveerything :-( | 18:36.25 |
chrisl | Okay, that'll give time to go grab a drink - back in a sec | 18:37.05 |
ray_laptop | chrisl: OK. It's the 4th bp for me, but I'm there | 18:38.58 |
| That's the first call with global == 0 | 18:39.23 |
chrisl | Right, cool. So it calls alloc_save_space() which closes the current chunk, "saves" the allocator etc.... | 18:40.12 |
| And the "saved" allocator is moved into lsave->saved | 18:40.50 |
| Oops, sorry: lsave->state is the "saved" allocator | 18:41.36 |
| So, then, further down, we call save_set_new() passing in the "saved" allocator from lsave->state | 18:43.38 |
ray_laptop | chrisl: OK. right | 18:43.54 |
chrisl | Then we call save_set_new_changes() | 18:44.13 |
| And in there, we *may* call drop_redundant_changes(), which can free memory in that allocator | 18:44.46 |
ray_laptop | chrisl: OK. This time it didn't do the drop_redundant call | 18:45.28 |
chrisl | No it doesn't do it every time, but it illustrates that we can end up freeing memory in an allocator that is not expected to be used at that stage. | 18:46.24 |
| ray_laptop: for me, it will call drop_redundant_changes() on the fifteenth call to alloc_save_state() | 18:47.43 |
ray_laptop | chrisl: I have a bp in drop_redundant_changes and I get an exception BEFORE it is ever called. But that seems to be because I have -Zu set | 18:48.39 |
chrisl | ray_laptop: there is an issue with the memory pointer not being set for one of the printf calls - I have a fix for that, too | 18:49.27 |
ray_laptop | the last thing it printed was: [u]GC finalizing stream 0x299ead0 | 18:49.32 |
| chrisl: OK. I'll turn that off for now | 18:49.54 |
mvrhel_laptop | yeah. I have the UI swiping working now in my mupdf windows metro app | 18:52.31 |
| have to step out for bit to get wifes computer at the fedex store. somehow they missed me 3 days in row | 18:53.09 |
Robin_Watts | mvrhel_laptop: Nice. | 18:55.48 |
ray_laptop | chrisl: OK, so I see it freeing some changes. A 'real' then a 'string', a 'name', ... | 18:59.47 |
chrisl | ray_laptop: so it's freeing in an already "saved" allocator, which is not expected | 19:00.18 |
| hence the problem: the call to alloc_close_chunk() when we start gc only applies to the "top" allocator | 19:01.06 |
ray_laptop | chrisl: so this must happen ALL the time. Why only a failure with this file ? | 19:07.36 |
chrisl | ray_laptop: Well, not only this file, but with -Z@ - it may well be happening all the time, but if we don't zap the memory, we'll not see a problem | 19:08.51 |
ray_laptop | there is a comment in i_free_object about not overwriting contents if something is from an older save level. | 19:10.26 |
chrisl | We can't know it's an earlier save level, because we explicitly use the previous allocator instance..... | 19:11.25 |
| Also, the memory being freed must be at the bottom of the chunk, so we have to move the cbot pointer | 19:11.57 |
ray_laptop | chrisl: so is the problem in chunk_locate_ptr not returning the correct bool ? | 19:12.10 |
chrisl | ray_laptop: no, the problem is after we've freed memory (which uses the mem->cc chunk) we never apply those changes to mem->pcc (the chunk in the chunk list). The gc code only ever uses the chunks in chunk list | 19:13.39 |
ray_laptop | chrisl: OK, I see. So it is using (writing to 'cc') for a chunk that has not been 'opened' and doesn't get 'closed' | 19:15.22 |
chrisl | ray_laptop: yes. So my fix is to add an open/close around the drop_redundant_changes() call | 19:15.58 |
ray_laptop | chrisl: but different 'changes' might be in different chunks | 19:17.24 |
chrisl | ray_laptop: doesn't the allocator handle that possibility? | 19:18.14 |
| ray_laptop: if the memory is not in the current chunk, the allocator should close the current chunk, and open the appropriate chunk | 19:19.16 |
ray_laptop | chrisl: I'm looking at i_free_object to see how (or if) it does that, but it isn't obvious. It seems like it should be done by 'chunk_locate_ptr' | 19:21.28 |
chrisl | ray_laptop: well, it can't expect the caller to know what chunk a block of memory was allocated in | 19:22.23 |
ray_laptop | chrisl: right. OK, so it scans to find the chunk. The while ((cld.cp = cld.memory->clast), !chunk_locate_ptr(ptr, &cld) | 19:24.55 |
| but I don't see where it sets the 'cc' (that it later uses) | 19:27.33 |
chrisl | ray_laptop: I think if the memory we're freeing is not in the current chunk, we write the changes straight back to the chunk from the list - no need to open and close | 19:27.36 |
| In fact, most of the time, we don't even change the chunk, we just "tag" the memory as free with pp->o_type = &st_free | 19:29.09 |
ray_laptop | chrisl: I see it setting 'cld.cp' (and sometimes it sets that to &imem->cc) | 19:29.54 |
| but isave.c line 854 just starts using imem->cc (as if the chunk is opened) | 19:31.03 |
chrisl | isave.c? | 19:31.57 |
ray_laptop | chrisl: sorry, gsalloc.c | 19:33.18 |
chrisl | ray_laptop: It does assume the chunk is open, yes. Opening and closing on every operation is a huge performance hit | 19:34.43 |
ray_laptop | chrisl: I agree that would be a performance hit, but it seems that after we find the chunk with chunk_locate_ptr we need to open the chunk if it wasn't already open | 19:37.33 |
| chrisl: we must be missing something, or how could this work ??? | 19:38.14 |
chrisl | ray_laptop: if you look at the chunk_locate macro, I think it handles the problem you're thinking of | 19:40.28 |
ray_laptop | chrisl: is i_free_object, it doesn't use chunk_locate -- it uses chunk_locate_ptr | 19:41.25 |
chrisl | ray_laptop: line 901 | 19:41.52 |
ray_laptop | chrisl: imem->cc is used in line 854 | 19:43.10 |
chrisl | ray_laptop: yes, and we should be covered by the fact that we're checking the address. | 19:44.23 |
| ray_laptop: generally speaking, the "active" chunk will always be "open" | 19:45.57 |
ray_laptop | chrisl: OK, that is only done when the the end of the object matches what's in cc.cbot, so what's in cc should be correct | 19:46.28 |
chrisl | ray_laptop: yes, so even if the chunk happens to be "closed" the data in "cc" will be correct | 19:47.18 |
ray_laptop | and the o_alone case just de-links a chunk from the list, so it doesn't modify the contents of the 'cc' | 19:48.12 |
chrisl | Yep | 19:48.23 |
| ray_laptop: And the very last case, we only mark the header with pp->o_type = &st_free | 19:50.12 |
ray_laptop | chrisl: but where does the imem->cc get copied in ? I don't see chunk_locate doing it | 19:50.24 |
chrisl | ray_laptop: copied in for what? | 19:50.44 |
| ray_laptop: I was going to say, I'm a little bemused by line 913/914 | 19:51.55 |
ray_laptop | imem->cc.int_freed_top gets examined and conditionally modified | 19:52.32 |
| chrisl: right that's the spot | 19:52.48 |
chrisl | Okay, so I'm not sure about that, but it's not really relevant for the current bug..... | 19:53.25 |
ray_laptop | chrisl: granted (probably, depending on what the int_freed_top is used for) | 19:53.57 |
chrisl | ray_laptop: oh, I think it doesn't matter - that's just the address of the highest object on a freelist, I think it's not specific to the current chunk | 19:54.27 |
| Oh, not sure.... :-( | 19:55.41 |
ray_laptop | chrisl: it seems to relate to 'trim_obj' | 19:56.08 |
chrisl | ray_laptop: Anyway, in the context of this bug, but the cbot and ctop pointers that are important - those are what gc uses to know where to scan | 19:56.58 |
ray_laptop | chrisl: or maybe the decision to call consolidate_chunk_free, but anyway, cbot and ctop, OK | 19:58.02 |
| chrisl: so since i_free_object writes directly into the chunk and doesn't really modify cbot or ctop -- just messes with the o_type of the object (ignoring the o_alone case), how is it getting confused ? | 20:00.56 |
chrisl | ray_laptop: line 857, it's writes to cbot | 20:01.34 |
ray_laptop | right, but we said that was OK didn't "we" because of the ptr comparison ? | 20:03.22 |
chrisl | ray_laptop: that means it's the current chunk, yes. But if we don't "close" it before gc, the change doesn't get written back to the chunk list | 20:04.22 |
ray_laptop | OK, so closing the chunk after the drop_redundant_changes is what is missing ? | 20:05.02 |
chrisl | Yes. But for symmetry, I added an open chunk before drop_redundant_changes(), too | 20:05.40 |
| That leaves everything in a nice stable state, so the gc code doesn't get confused | 20:06.22 |
| ray_laptop: that change cluster tests okay, but I want to run my own test script tomorrow with -Z@, too | 20:10.03 |
ray_laptop | chrisl: alloc_open_chunk probably won't do anything because alloc_save_space did alloc_close_chunk then writes mem->pcc = 0 | 20:10.32 |
chrisl | ray_laptop: pcc isn't null when I get to drop_redundant_changes()..... | 20:11.48 |
| ray_laptop: the reason being the allocator being saved is assigned before that happens line 401 | 20:13.53 |
ray_laptop | chrisl: OK, I see | 20:16.37 |
| I still don't know why we didn't see this a LONG time ago. I run with -Z@$? a lot | 20:17.51 |
chrisl | It's quite a few circumstances conspiring to get us there, although, I agree, I'm surprised it hasn't appear before | 20:19.12 |
ray_laptop | chrisl: are you going to fix that int_freed_top (potential) problem as well ? | 20:20.01 |
chrisl | ray_laptop: I can look into it sure - but I think it's benign. I think it will only mean we'll call consolidate_chunk_free() sometimes when it won't help, and won't call it sometimes when it might help | 20:21.04 |
ray_laptop | chrisl: which might mean using more memory than needed, but I am pretty sure that GC resets this | 20:22.02 |
chrisl | ray_laptop: yes, by "benign" I meant no crashes, and no *huge* memory problems. | 20:22.49 |
| ray_laptop: but what I really wanted your opinion on was the idea of getting rid "cc" and access chunks (more) directly via pcc - so we don't have to worry about keeping the "cc" entry, and the chunk list in sync with the open/close chunk copying | 20:24.19 |
ray_laptop | chrisl: I doubt I helped any, but at least you dragged me along enough to help me understand what you found, but I'll still let you fix anything else in save/restore in the future ;-) | 20:24.50 |
chrisl | Gee thanks! | 20:25.09 |
ray_laptop | chrisl: have you found any reason for the opening/closing chunk and having a copy of the 'current' chunk embedded in the gs_ref_memory ? | 20:26.37 |
| like maybe that copy gets used during the GC or something ? | 20:27.17 |
chrisl | ray_laptop: not so far. I thought it was maybe for during initialisation, but that's not the case. My best guess (so far) is that it dates from when pointer accesses were relatively expensive, so the effort of copying was offset by having to use the pointer less often | 20:28.22 |
ray_laptop | not important, just curious. It could be something like that (avoiding indirection) | 20:28.52 |
| or localizing memory access to improve likelihood of a cache hit | 20:29.23 |
| but compared to the rest of all of the stuff we do, it seems funky | 20:29.47 |
chrisl | I'm not convinced we get a net benefit from it these days, assuming we ever did | 20:30.16 |
| ray_laptop: But I only looked at it briefly, then I wanted to run it past you before I spent any more time on it | 20:30.56 |
ray_laptop | I just got the report from the weekly -Z@ run. Once you fix it, you'll probably have to get marcosw to re-run it | 20:31.31 |
chrisl | Can do. As I said, I'll run my own script tomorrow, for my own peace of mind | 20:32.43 |
| ray_laptop: anyway, I need to stop now - I'm losing the ability to type. Thanks for going through this with me...... | 20:35.18 |
ray_laptop | hmm, that's strange. I just got the email about the -Z@ regression run, and it says :results for 2013_01_23_2ae1a17..." but the latest commit it shows was on Jan 18th (the 2ae1a1a7 one) | 20:37.33 |
| chrisl: np. Thanks for being patient as I stumbled along :-) | 20:37.59 |
| methinks marcos should look into that | 20:38.23 |
chrisl | Right, goodnight, and god bless...... | 20:40.57 |
ray_laptop | maybe the cutoff time is before those later commits yesterday. | 20:41.51 |
Leolo_3 | I have what might be a silly question : how does one set the output device w/in postscript? | 20:43.44 |
| systemdict /DEVICE /ppmraw def doesn't seem to work | 20:44.08 |
| I suspect one Can't Do That For Obvious Reasons | 20:44.30 |
| I want the equiv of -sDEVICE=ppmraw | 20:44.43 |
ray_laptop | Leolo_3: with Ghostscript it is easy. (check doc/Use.htm): (ppmraw) selectdevice | 20:45.38 |
Leolo_3 | ha! | 20:45.54 |
| ok, I was looking in 100% the wrong direction :-) | 20:46.06 |
ray_laptop | Read the Fine Manual ;-) | 20:46.09 |
| Leolo_3: generally you can't define stuff in systemdict anyway | 20:46.45 |
Leolo_3 | I'm pretty much a postscript newbie. I did a lot of forth way way back in the day, but apart from that, I'm cargo culting | 20:47.19 |
ray_laptop | PS is LOTS more fun than forth, (and lots more confusing) | 20:48.16 |
Leolo_3 | would something like "devicesnames { dup = selectdevice currentpagedevice /HWResolution get == } forall" be at all feasable? | 20:48.21 |
| forth was helluva cool. but that was 20+ years ago | 20:48.39 |
| oooo... it is, except that x11 doesn't work, so I have to filter out the bad device | 20:50.09 |
ray_laptop | Leolo_3: well, you've mispelled devicenames but otherwise that works for _some_ devices. | 20:50.41 |
Leolo_3 | yeah | 20:51.28 |
ray_laptop | although, why you want to do that, I don't know | 20:51.39 |
Leolo_3 | i want to get the all the default resolutions | 20:52.56 |
| so I my prog can then calculate DEVICEWIDTHPOINTS properly | 20:53.25 |
ray_laptop | Leolo_3: not GS has PS extensions, like .sort that is handy, too. Try: devicenames dup length array copy { 100 string cvs exch 100 string cvs gt } .sort = | 20:56.01 |
| Leolo_3: but DEVICEWIDTHPOINTS is ALWAYS in 1/72 inch. But if you want to set an exact number of pixels, you can use -gWWWxHHH option on the command line | 20:56.59 |
| Leolo_3: actually on that .sort example, you probably want == | 20:58.16 |
Leolo_3 | -g is also in points, no? | 20:59.33 |
| oh fuck me, no it isn't | 20:59.49 |
| I wanted, -dDEVICEWIDTH, not DEVICEWIDTHPOINTS | 21:00.03 |
| SO MUCH TIME WASTED | 21:00.07 |
ray_laptop | Leolo_3: but DEVICEWIDTHPOINTS is the command line option. With PS use: << /PageSize [ width height ] >> setpagedevice | 21:00.08 |
| I would suggest a read through at least Use.htm :-) | 21:01.52 |
Leolo_3 | I didn't, but I guess I'm just blind | 21:03.21 |
| ok, this works better ... but still have problems | 21:04.15 |
| ok, -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r72x72 produces what I want, but -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r100x100 doesn't | 21:05.58 |
| oh, because of the 2nd conversion step | 21:06.17 |
adamben | hey all - anyone awake? | 22:24.33 |
sebras | adamben: some of us are still here. is there anything in particular you want to ask about? :) | 22:57.36 |
adamben | I thought it was the place to ask about muPDF commercial license | 22:58.15 |
| but maybe Im wrong | 22:58.17 |
sebras | adamben: no, you have come to the right place. sorry for the delay. | 23:27.07 |
adamben | Alright | 23:27.26 |
| sebras: Are you associated with Artifex? | 23:28.09 |
sebras | adamben: I'm not working for Artifex, the company who licenses MuPDF. | 23:28.16 |
adamben | ahah | 23:28.25 |
| ok | 23:28.25 |
| I was going to ask you about their pricing | 23:28.35 |
| Im looking to distribute a PDF component for Android and I'd like to license their PDF viewer | 23:28.49 |
sebras | adamben: but I recommend that you contact Scott Sackett at sales@artifex.com or at +1 940 482 7985. | 23:28.52 |
| adamben: yes, I understand. I have seen this question come up a few times. :) | 23:29.13 |
adamben | great | 23:29.20 |
| sending him an email | 23:29.23 |
sebras | adamben: I believe that you can also find contact info for him here, should you loose it: http://www.artifex.com/ | 23:29.42 |
| loose -> lose. my fingers write fast, but not correctly. | 23:30.46 |
adamben | right | 23:31.13 |
| Just sent him an emai | 23:31.16 |
| *email | 23:31.18 |
sebras | adamben: for any techincal questions you might have, feel free to ask here. | 23:31.22 |
adamben | I have some technical Q now :) | 23:31.30 |
| or more featuresets wise | 23:31.35 |
sebras | might take some time before someone answers though. :) | 23:31.38 |
adamben | why? | 23:31.43 |
sebras | adamben: some developers are in .uk, some are in the us... | 23:32.25 |
adamben | Do you think I'll get a response by tomorrow? | 23:32.40 |
sebras | adamben: technical questions rarely go unanswered that long. | 23:33.21 |
adamben | Can I PM you? | 23:33.54 |
sebras | adamben: sure, no problem. | 23:34.07 |
| adamben: I should emphasisze that I'm not working for artifex though, I'm just a hang-around here. | 23:35.24 |
adamben | no problem - sent you a message ;) | 23:35.38 |
| Forward 1 day (to 2013/01/24)>>> | |