| | <<<Back 1 day (to 2015/05/14) | 20150515 |
| rayjj | mvrhel: For the logs. Well, I've determined that the t_level_adjust, delta, and delta_sum is TOTALLY bogus. It results a non-monotonic relation between the t_level and the 'l' level, and delta_sum gets so large that the largest t_level we have is 0x7f. | 01:37.09 |
| | mvrhel: for small num_levels, the 'delta' stays negative, since t_level_adjust is always smaller than t_level | 01:40.36 |
| | so we never "adjust" the t_level (which matches my original code) | 01:41.01 |
| rayjj | wishes there were an example of what this was supposed to 'fix' | 01:41.34 |
| | Note that I do see *very slight* single pixel differences between the non-fast thresholding output compared to the code with the t_level set as the original (no t_level -= delta_sum). But it isn't nearly as broken | 01:46.00 |
| Robin_Watts | Morning tor8 | 08:32.01 |
| | Commits ready for review when you are. | 08:32.07 |
| jogux | morning all | 08:37.13 |
| kens | morning | 08:37.21 |
| jogux | anyone know if there's any kind of Artifex branding guide or anything? is the blue in the mupdf/ghostscript logos on the website an official Artifex blue? | 08:37.52 |
| kens | I guess you'd have to ask our VP of Marketing :-) | 08:38.15 |
| tor8 | Robin_Watts: hm, pdf_new_offset bothers me :( | 08:38.50 |
| jogux | kens: That's Ted right? :) | 08:40.56 |
| kens | Correct | 08:41.03 |
| tor8 | and I've run into the same issue of 'cannot seek backwards' on pdfref17.pdf as sebras did yesterday | 08:41.33 |
| | Robin_Watts: ifeq "$(largefile)" "yes" to match our other tests in the makefile | 08:42.58 |
| | and I'd put that section in Makerules | 08:43.40 |
| | jogux: it's the unofficial artifex blue at least :) | 08:58.05 |
| jogux | :-) | 08:58.17 |
| sebras | tor8: Robin_Watts: that cannot seek backwards thing might be covering up a bug. | 09:08.22 |
| tor8 | sebras: the warning comes from pdf object streams in pdfref17.pdf | 09:12.51 |
| | sebras: is it the same with your test.pdf file? | 09:12.58 |
| sebras | tor8: test.pdf is pdfref17.pdf | 09:15.03 |
| | tor8: ah.. no... it is pdfimpl81.pdf which is the pdf collection containing pdfref17.pdf and the addendums. | 09:15.33 |
| | tor8: I saw differences in the stm->rp ->wp pointers last night when I tried to debug. | 09:16.01 |
| | tor8: so it seems to me like we are reading from the stream when we really shouldn't be, but I haven't figured out why yet. | 09:16.22 |
| tor8 | in pdf_load_obj_stm in pdfref17.pdf on object content stream 36054 | 09:17.54 |
| | gdb shows 'first' as being 0 | 09:18.02 |
| | but the /First entry in object 36054 is 1236 which is exactly the offset the code is trying to search backwards | 09:18.30 |
| | of course, when I try to run 'mutool show' on the same object I get a different 'first' | 09:21.16 |
| | so something has corrupted the cached objects? | 09:21.32 |
| sebras | tor8: I notice that first is bogus too. | 09:39.26 |
| tor8 | Robin_Watts: there's a bug hiding somewhere in pdf_dict_find() | 10:35.10 |
| kens | reboot, brb | 10:39.27 |
| Robin_Watts | tor8: how so? | 10:40.15 |
| tor8 | when running 'mutool show pdfref17.pdf grep' I run into a case where pdf_dict_get(... PDF_NAME_First) and pdf_dict_gets(... "First") do not return the same value | 10:40.45 |
| Robin_Watts | jogux: I have heard that blue referred to as "Artifex Blue" before. | 10:40.57 |
| tor8 | the dict flag says it is sorted, and on a cursory glance through gdb, the keyval key pointers are in ascending order | 10:41.21 |
| | but if I #ifdef out the sorted half of the branch in pdf_dict_find the bug does not appear | 10:41.38 |
| Robin_Watts | tor8: Hmm. | 10:42.13 |
| | Ah, so it's case where the sort order is failing because PDF_NAME_First and "First" are somehow not equal in the sorting order. Ass. | 10:43.19 |
| | will look at that in a mo. | 10:43.34 |
| tor8 | Robin_Watts: when running 'mutool show pdfref17.pdf 109960' (the same object that first triggers the error) there are no problems | 10:48.04 |
| | but in that instance, the obj->flags do not have sorted set | 10:48.14 |
| sebras | tor8: hm... when I'm debugging we ask pdf_dict_find() to look for N in the dict. | 11:18.54 |
| | tor8: which in my build equates to key == 0xe4. | 11:19.06 |
| | tor8: and we do find it in the sorted half of the function! | 11:19.22 |
| | tor8: but the value stored in *location is bogus. | 11:19.33 |
| | tor8: I should get key index 3 in the dict, but I get -8640. | 11:19.57 |
| | tor8: curiously enough l and m both equal 3 when the function returns | 11:20.36 |
| | tor8: and c == 0 | 11:20.46 |
| Robin_Watts | sebras: This may turn out to be my inability to write a binary search :) | 11:21.34 |
| sebras | Robin_Watts: it could, so that was the first thing I checked. (compared it with one in pdf-encoding.c) | 11:22.00 |
| Robin_Watts | Hmm. The update for location looks wrong. | 11:22.28 |
| sebras | Robin_Watts: one thing that annoys me though is that when you assign c then you do key - k | 11:22.32 |
| | so c == 5 in one case even though key == 0xe4 and k == 0xcf | 11:22.55 |
| Robin_Watts | c = comparison. | 11:23.07 |
| sebras | I know. but how come 0xe4 - 0xcf == 5!? | 11:23.19 |
| Robin_Watts | It's intended to be <0, 0, >0 like strcmp | 11:23.20 |
| | sebras: Oh. Pointer arithmetic. | 11:23.50 |
| | Crap. | 11:23.53 |
| | (char *)key - (char *) k | 11:24.16 |
| | That fixes it. | 11:26.06 |
| | Well spotted. | 11:26.09 |
| sebras | Robin_Watts: is that really correct? both key and k are of type pdf_obj * so if you do arithmetic on them shouldn't you get the number of items inbetween the elements? | 11:26.11 |
| | ...in the items array. | 11:26.27 |
| Robin_Watts | sebras: We special case values 1....PDF_OBJ__LIMIT | 11:26.44 |
| sebras | yeah and __LIMIT is 371... | 11:27.00 |
| | and in my case both 0xe4 and 0xcf < 371, so we do end up in the key-k case. | 11:27.20 |
| Robin_Watts | Right. So 0xe4 and 0xcf are both in those special case regions. | 11:27.26 |
| sebras | yes. so how come c = key - k becomes 5..? | 11:27.45 |
| Robin_Watts | It's a hack^H^H^H^Hcunning engineering solution. | 11:27.49 |
| sebras | is confused. | 11:27.59 |
| Robin_Watts | sebras: Because pdf_obj * is of size 4 or 8. | 11:28.01 |
| | so the compiler does (0xe4-0xcf)/4 | 11:28.23 |
| sebras | Robin_Watts: yes, of course. I'm so stupid. :) | 11:29.33 |
| Robin_Watts | sebras: Not at all! | 11:29.43 |
| | You spotted the problem, when I'd have been hunting for ages. | 11:29.55 |
| sebras | Robin_Watts: well, tor8 narrowed it down very well. I didn't notice that there was a problem in pdf_dict_find(). | 11:30.39 |
| tor8 | Robin_Watts: sebras: I love going for lunch and have the problem solved when I get back :) | 11:31.35 |
| Robin_Watts | I'm just putting together a commit now. | 11:32.38 |
| | tor8: Other than the Makefile thing, were you happy with the commits from yesterday? | 11:33.22 |
| tor8 | Robin_Watts: I'm not convinced of the pdf_new_offset name | 11:36.00 |
| sebras | Robin_Watts: you did adjust that assignment of location too, right? | 11:36.18 |
| Robin_Watts | tor8: Right... | 11:36.19 |
| tor8 | could we not just make the pdf_new_int take a fz_off_t silently? (since it'll always upcast) | 11:36.23 |
| Robin_Watts | sebras: I did, but in the opposite sense to what I expected on first glance :) | 11:36.40 |
| tor8 | pdf_to_offset solves the problem of implicit truncation if we made pdf_to_int return an int64, so I want to keep that one | 11:37.03 |
| Robin_Watts | tor8: We *could*, but that's a change to the API that people might not understand immediately. | 11:37.06 |
| | I liked the idea of people having to explicitly say they wanted a big number. | 11:37.28 |
| tor8 | pdf_new_offset is a confusing and/or a misleading name though :( | 11:37.52 |
| Robin_Watts | Because maybe in future we'll change to have int's and int64's internally as separate types to save space ? | 11:37.53 |
| tor8 | or use int64's everywhere just because we can | 11:38.11 |
| | the space savings of int32 or int64 in a pdf_obj is going to be swamped by any malloc overhead for the actual pdf_obj | 11:38.44 |
| sebras | tor8: does mupdf run on any memory constrained systems at all nowadays..? | 11:38.46 |
| tor8 | sebras: ios ;) | 11:39.20 |
| Robin_Watts | tor8: currently, other than known names/null/true/false, which are all now 0 bytes effectively, pdf_obj's are 32bits + type specific sizes. | 11:40.56 |
| | It's conceivable that people might have special 'small block' malloc handlers out there to cope with 8/16/32 byte blocks. | 11:42.17 |
| | but yes, I admit that without that, the change from 32 to 64bits is probably not going to matter. | 11:42.41 |
| tor8 | pdf_new_int_offset? | 11:42.49 |
| Robin_Watts | pdf_new_off_t ? | 11:43.01 |
| | or your one. | 11:43.13 |
| | As kens (or chrisl) pointed out yesterday, the PLRM makes reference to the fact that byte offsets are 'special' and not constrained by the usual limitations of representation. | 11:44.16 |
| tor8 | Robin_Watts: we could make a special parser for object stream trailed dictionaries... | 11:44.51 |
| | but I'd rather not | 11:45.07 |
| Robin_Watts | indeed. | 11:45.30 |
| | hence pdf_new_offset (or whatever we call it) is pretty much going to be an internal function. | 11:46.01 |
| tor8 | pdf_new_int_imp/aux/x then? | 11:47.53 |
| | and yes, but it's used in a lot of different parsing functions | 11:48.10 |
| Robin_Watts | pdf_new_int_offset works for me. | 11:48.29 |
| tor8 | let's go with that then :) | 11:48.39 |
| Robin_Watts | I'll get that updated. | 11:48.48 |
| sebras | Robin_Watts: btw... why does pdf_dict_find() have a location out-parameter? it is only called once from pdf_dict_get() where it sets location to NULL. | 11:49.23 |
| | Robin_Watts: oh, you did add new reference to it in pdf_dict_put() in a later commit! | 11:50.20 |
| Robin_Watts | sebras: Yes. There was a good reason for that. | 11:50.58 |
| | In the case were we are putting a value in, we look for the old value first. If we find it, we can replace it immediately (using the return value of the function). | 11:52.16 |
| | If we don't find it, previously we'd have to search again to find out where to insert it. | 11:52.30 |
| | So we do twice the searching we need to. A customer/user pointed out that that was inefficient, and had a case where it made a noticable profile difference. | 11:53.09 |
| | So we now return 'location' (in the 'failed to find' case) so we know where to insert it. | 11:53.38 |
| | Hence the fix I have here is to move the setting of location out of the loop. | 11:53.49 |
| | Hmm. | 11:54.18 |
| | Shame on me. | 11:54.20 |
| | I shouldn't need 'location'. | 11:54.31 |
| | I should just return -1-location | 11:54.42 |
| | So pdf_dict_find would return -ve for 'did not find' as now. | 11:55.27 |
| | and the location could be recovered from that value too. | 11:55.48 |
| | I'll do that in a separate commit. | 11:55.57 |
| | tor8: Updated commits for your approval. | 12:12.32 |
| tor8 | Robin_Watts: shouldn't that be: ifeq "$(verbose)" "yes" ? | 12:23.34 |
| | I mean largefile | 12:32.46 |
| Robin_Watts | tor8: crap, yes. | 12:44.12 |
| | will fix in a bit. | 12:44.19 |
| | http://www.telegraph.co.uk/news/worldnews/europe/sweden/11603383/Swedish-underwater-gay-sailor-to-scare-off-Russian-submarines.html | 13:30.34 |
| | tor8: Updated versions on robin/master | 13:41.34 |
| tor8 | Robin_Watts: all LGTM | 13:48.34 |
| Robin_Watts | tor8: Ta. | 13:48.40 |
| tor8 | Robin_Watts: also a handful of epub commits on tor/master | 13:48.45 |
| Robin_Watts | tor8: Just looking at the white space one. | 13:54.27 |
| | I might have been tempted to defined the WS_NORMAL/PRE/NOWRAP/etc constants as values, so that: | 13:55.11 |
| | box->style.white_space & WS_COLLAPSE | 13:55.40 |
| | etc. | 13:55.42 |
| | i.e. have the values picked as bitfields. | 13:56.05 |
| | Would save you an ugly switch. | 13:56.13 |
| tor8 | Robin_Watts: yeah. that'd probably look nicer. | 13:56.36 |
| Robin_Watts | All the others look plausible to me. | 13:59.44 |
| tor8 | Robin_Watts: the font-size inherit one is still not 100% correct | 14:01.59 |
| | the spec is really crappy | 14:02.08 |
| | consider the html snippet <p>foo<i>bar</i></p> | 14:02.26 |
| | then for the css p{font-size:0.5em} i{font-size:0.5em} | 14:02.43 |
| | the 'bar' text will be sized at 0.25em (p * i sizes) | 14:02.58 |
| | but p{font-size:0.5em} i{font-size:inherit} | 14:03.09 |
| Robin_Watts | tor8: really? | 14:03.13 |
| tor8 | yeah, it's 0.5 * the container blocks font-size | 14:03.33 |
| Robin_Watts | is font-size:0.5 em not an absolute size? | 14:03.41 |
| | or does em make it a relative scale? | 14:03.48 |
| tor8 | nope. 'em' is a relative scale. | 14:03.51 |
| Robin_Watts | ok, fair enough. Go on with your but... | 14:04.12 |
| tor8 | but the inherit should copy the 0.5em, but not really, since the 'bar' "inherits" the parent font size but not textually so it isn't scaled | 14:04.52 |
| | but nowhere in the spec is this actually clear | 14:04.57 |
| | absolute insanity. I think I'm going to have to hard-wire the css property lookup stuff to explicitly ignore 'inherit' on font-size properties | 14:05.44 |
| Robin_Watts | tor8: I have some sympathy with the spec, I think. | 14:07.41 |
| | I would expect 'font-size:inherit' to mean 'inherit the font-size' rather than 'inherit the way in which the font size was calculated'. | 14:08.20 |
| tor8 | yeah, that's the "reasonable" way to think about it, but it goes counter to every other way the css spec works | 14:08.49 |
| | and the font-size inheritance and scaling is just wacked and different from everything else too | 14:09.12 |
| | so no wonder... | 14:09.15 |
| rayjj | kens: I haven't looked into Phil's big file, but in general, it /might/ help to no-op some of the painting operators (i.e., change '*fill' and 'stroke' to newpath). Skipping images is harder if the DataSource doesn't have a filter with an implicit EOF and relies on the image operator to consume the correct amount of data | 14:10.20 |
| kens | rayjj yes they could do that. I haven't (yet) figured otu why its so slow, except that there's some images in a CIEBasedABC space | 14:11.00 |
| rayjj | kens: and skipping text, since it shifts 'currentpoint' is problematic | 14:11.00 |
| tor8 | Robin_Watts: updated font-size commit on tor/master and a possible rework of the WS properties | 14:11.57 |
| | not convinced the flags are better though | 14:12.03 |
| kens | Its not all the pages, its only some of them. Of coruse, the original was a PDF file whcih has been converted to DSC PostScript by printing from Acrobat. WHich amongs other things means each page has a large prolog | 14:12.06 |
| rayjj | kens: if the images use a filtered DataSource that _is_ defined, then just consuming the stream is *much* faster than processing the image | 14:12.08 |
| kens | I don't know where the imte is going | 14:12.27 |
| | And to be honest, I wasn't going to bother looking | 14:12.37 |
| rayjj | imte ??? | 14:12.43 |
| kens | time | 14:12.47 |
| Robin_Watts | tor8: Ah, no, you misunderstood me. | 14:26.29 |
| | enum { WS_NORMAL = WS_COLLAPSE | WS_ALLOW_BREAK_SPACE, WS_PRE = WS_FORCE_BREAK_NEWLINE ... } | 14:27.18 |
| | So generate_text stays as it is in the new commit. | 14:27.57 |
| | and white_space_from_property as it was in the old. | 14:28.12 |
| | font-size commit looks good though. | 14:31.57 |
| tor8 | Robin_Watts: ah, I see what you mean. | 14:32.55 |
| | Robin_Watts: something like tor/master now? | 14:37.15 |
| Robin_Watts | Yes. | 14:38.07 |
| | I might personally have called the WS_COLLAPSE things WS_FLAG_COLLAPSE or something to highlight that some of them are flags... | 14:38.43 |
| | but that's a personal thing. Looks fine as is. | 14:39.00 |
| tor8 | Robin_Watts: thanks. | 15:05.23 |
| Robin_Watts | no worries. | 15:05.29 |
| | mvrhel_laptop: You here? | 15:30.45 |
| mvrhel_laptop | Robin_Watts: I am | 15:32.32 |
| Robin_Watts | You said you had a version that when run did not increase in memory use. | 15:32.55 |
| | Or rather, it did not leak. | 15:33.03 |
| mvrhel_laptop | right | 15:33.11 |
| | that has been committed | 15:33.16 |
| | and I send it to jung | 15:33.21 |
| | but he said it still leaks and I have is project here to test | 15:33.33 |
| Robin_Watts | Can you do a quick test for me please, and run that, and look at it in process explorer (or process manager, whichever) | 15:33.38 |
| mvrhel_laptop | s/is/his/ | 15:33.38 |
| | that being mine or jung's? | 15:33.54 |
| Robin_Watts | Yours. | 15:34.00 |
| | I have an old version of jungs, with my fixes in. Memento says no leaks. | 15:34.13 |
| | but I still see the memory use rising in process explorer. | 15:34.25 |
| mvrhel_laptop | odd | 15:34.30 |
| Robin_Watts | yeah. | 15:34.35 |
| mvrhel_laptop | let me see if I see the same thing | 15:34.36 |
| Robin_Watts | I am waiting for a clone of gsview to try your version out. | 15:34.46 |
| mvrhel_laptop | are you running it in visual studio or outside? | 15:34.49 |
| Robin_Watts | Within visual studio, currently. | 15:35.00 |
| mvrhel_laptop | ok | 15:35.03 |
| | give me a sec | 15:35.11 |
| | explorer is staying steady | 15:36.51 |
| | at 5.3 Meg | 15:37.10 |
| | so Robin_Watts I am not seeing any increase | 15:37.51 |
| | that is with my project mind you | 15:38.10 |
| Robin_Watts | ok, so that's good. | 15:38.10 |
| | I'm about to retry with your project here. | 15:38.28 |
| | I should drop your 'MemoryTest' directory into the top level of gsview ? | 15:39.27 |
| mvrhel_laptop | yes | 15:39.48 |
| Robin_Watts | Hmm. | 15:40.46 |
| | It won't load the mupdfwinrt or mupdf_cpp projects for me, telling me I need windows 8.1 | 15:41.12 |
| mvrhel_laptop | oh | 15:41.18 |
| | yes | 15:41.25 |
| | that is ok | 15:41.27 |
| | you don't need those for this | 15:41.33 |
| | those do require 8.1 | 15:41.42 |
| Robin_Watts | ok. | 15:41.45 |
| mvrhel_laptop | I can't figure out where jung's main solution is | 15:41.59 |
| | this is a bit of a mess | 15:42.07 |
| Robin_Watts | oh, God, it's horrible, yes. | 15:42.37 |
| mvrhel_laptop | he has solutions for each project.... | 15:42.59 |
| Robin_Watts | platform/windows/mupdf.sln I think. | 15:43.10 |
| mvrhel_laptop | nope. not in this version.... | 15:43.37 |
| | found it | 15:44.10 |
| | it was in mupdfnet/mupdfnet and called submodules.sln | 15:44.28 |
| | why I don't know | 15:44.35 |
| | when he zipped it up he included all the obj and binary output | 15:45.12 |
| | no wonder it took forever to download | 15:45.22 |
| Robin_Watts | mvrhel_laptop: OK, so the gsview.git solution won't load all the projects, because they need converting from vcproj to vcxproj. | 15:46.40 |
| | I've converted the mupdf ones by loading the mupdf.sln into vs2013 and then closing it. | 15:46.58 |
| mvrhel_laptop | oh | 15:47.05 |
| Robin_Watts | but it still won't load libmupdf_winrt and libthirdparty_winrt | 15:47.19 |
| | where do those live? | 15:47.25 |
| mvrhel_laptop | there are details of what you need to do in the README | 15:47.25 |
| | I would not worry about them now though | 15:47.43 |
| | that is for the windows tile app | 15:48.02 |
| Robin_Watts | right, | 15:48.11 |
| mvrhel_laptop | and there is still something that I need to fix with respect to them | 15:48.28 |
| | you basically have to make a copy of the standard one and change a pile of settings as well as convert it to 8.1 | 15:48.51 |
| Robin_Watts | fair enough. | 15:48.52 |
| | OK, I'll follow through the README at some point. | 15:49.10 |
| mvrhel_laptop | good. let me know if you trip up on something | 15:49.20 |
| | It is always possible I left out some crucial detail | 15:49.31 |
| Robin_Watts | with the memorytest stuff you sent... I've dropped that into the project and it says that Properties/AssemblyInfo.cs is missing. | 15:49.39 |
| mvrhel_laptop | hmm. I have not tried it yet | 15:50.12 |
| | oh | 15:50.21 |
| | I see what you are saying | 15:50.25 |
| | sorry | 15:50.27 |
| | hold on | 15:50.47 |
| | oops | 15:51.08 |
| | ok let me send that along | 15:51.17 |
| | Robin_Watts: resent you the project file including that folder/file | 15:52.42 |
| | sorry about that | 15:52.45 |
| Robin_Watts | mvrhel_laptop: No worries. Thanks. | 15:53.14 |
| mvrhel_laptop | Running Jung's project now. Not seeing any increase with the process explorer | 15:56.09 |
| | let me check with the tool | 15:56.33 |
| | are these guys a pretty big customer? | 15:58.32 |
| Robin_Watts | not large enough to justify the time :) | 15:58.51 |
| mvrhel_laptop | they seemed to be getting some prime support | 15:59.13 |
| | s/seemed/seem/ | 15:59.22 |
| kens | As I recall ActivePDF are a top ten customer ? | 16:00.17 |
| mvrhel_laptop | oops | 16:00.23 |
| | edit the logs... | 16:00.26 |
| kens | I htnk they don't mind they open their own bug reportss | 16:00.44 |
| mvrhel_laptop | Robin_Watts: can you do that? | 16:00.55 |
| Robin_Watts | I can edit it if required. | 16:01.03 |
| kens | They are a current 'high support' customer | 16:01.07 |
| | # 7 of 10 | 16:01.19 |
| mvrhel_laptop | ok well they are getting it | 16:01.26 |
| | checking jung's program now with the visual studio memory tool | 16:01.56 |
| | Robin_Watts: I would think we would want to remove their name from the log | 16:02.49 |
| Robin_Watts | will do. | 16:03.28 |
| mvrhel_laptop | thanks | 16:03.35 |
| Robin_Watts | mvrhel_laptop: I might be tempted to write a script to copy/convert the project files. | 16:04.12 |
| mvrhel_laptop | Robin_Watts: that would be great | 16:04.27 |
| | or are you telling me I should.... | 16:04.34 |
| | It would be nice to have it automated | 16:05.26 |
| Robin_Watts | I'm saying it would be nice to have it done, and I am pondering volunteering :) | 16:05.51 |
| mvrhel_laptop | ha. don't worry about it. It would be a good exercise for me to do | 16:06.16 |
| Robin_Watts | I was thinking that the script could copy the project files out of the submodules and then convert them. | 16:07.04 |
| | but then I bet the paths in there would need massaging too. | 16:07.11 |
| mvrhel_laptop | yes | 16:07.26 |
| | I would love to do the following | 16:07.58 |
| | have my solutions out of the submodules | 16:08.08 |
| | and just get the paths/files/filters that are in those projects | 16:08.41 |
| | and obviously adjust | 16:08.52 |
| | and avoid having to do a bunch of project settings | 16:09.07 |
| | that I could probably handle actually | 16:09.14 |
| | Robin_Watts: so windows says there are no leaks here | 16:09.33 |
| Robin_Watts | Let me send you an exe to run... | 16:09.47 |
| mvrhel_laptop | ok | 16:10.12 |
| Robin_Watts | Ok. I've send an exe. When I run that from the command line, I can see both "Working Set" and "Private Bytes Size" increasing. | 16:13.02 |
| mvrhel_laptop | ok I am watching for the email | 16:18.19 |
| | odd that it has not gotten here yet | 16:19.43 |
| | did you hit send ;) | 16:21.07 |
| Robin_Watts | I did. It bounced cos it has a zip in it. | 16:22.07 |
| | sending again as a .piz | 16:23.40 |
| mvrhel_laptop | got that one | 16:25.06 |
| Robin_Watts | Interesting. My converted projects opted to use precompiled headers, which of course made everything fall in a heap. | 16:26.02 |
| mvrhel_laptop | Robin_Watts: I am not seeing consistent increase in the private working set of memory for this | 16:27.34 |
| | it is sitting at 2476 max and going down and back up over time | 16:27.55 |
| | I wonder if I should try this on windows 7 | 16:29.12 |
| | unfortunately I have to go to Alden's school right now | 16:29.44 |
| | Robin_Watts: not sure how best to proceed with this | 16:30.17 |
| Robin_Watts | mvrhel_laptop: Your project is complaining here that pdfclean_main does not exist. | 16:30.36 |
| mvrhel_laptop | oh that is in the Readme too | 16:30.49 |
| | I need to fix that | 16:30.54 |
| | so that you don't need to add it | 16:30.59 |
| | and use the changes you had made | 16:31.10 |
| Robin_Watts | not in my README :( | 16:31.34 |
| mvrhel_laptop | oops | 16:31.39 |
| | I was just looking and I see I left that out | 16:31.46 |
| Robin_Watts | You shouldn't need to call pdfclean_main any more. | 16:31.59 |
| mvrhel_laptop | what I will do when I get back is make it so it is not needed | 16:32.01 |
| | yes | 16:32.03 |
| Robin_Watts | Call pdf_clean_file instead. | 16:32.43 |
| | ok. | 16:32.45 |
| mvrhel_laptop | if you can just add if for now, then that will fix you up in the short term. | 16:32.47 |
| | I will. need to run now | 16:33.00 |
| Robin_Watts | no worries. | 16:33.39 |
| | I'm almost there I think. | 16:33.47 |
| | I get 'System.BadImageFormatException' when it tries to load the mupdfnet64.dll | 16:40.44 |
| | chrisl: You still here? | 17:04.59 |
| | Any objections to us removing main.h and gserver.c from gs? | 17:05.30 |
| chrisl | Er, where are they? | 17:09.22 |
| Robin_Watts | gs/psi | 17:09.35 |
| | neither are used. | 17:09.39 |
| chrisl | No objection to main.h, gserver.c seems like an example we should maintain, maybe? | 17:11.17 |
| Robin_Watts | gserver requires the stuff in main.h | 17:11.31 |
| | hence it will never work, as the stuff in main.h has been commented out. | 17:11.47 |
| chrisl | Robin_Watts: yes, I mean we should tidy it up so it does work | 17:12.27 |
| | It's nice having a simple, self contained example of how to drive Ghostscript like that | 17:12.50 |
| Robin_Watts | chrisl: Ok. i'm going to remove it here locally, and we can reintroduce it properly once the carpet has stopped being dragged about. | 17:13.08 |
| chrisl | Robin_Watts: actually, no, I'm fine with getting rid - it doesn't do quite what I thought it did.... | 17:13.55 |
| Robin_Watts | Ah, cool. thanks. | 17:14.04 |
| chrisl | It doesn't actually run Ghostscript as a "server" in the way I expected | 17:14.36 |
| | I am, however, heading off now...... | 17:16.51 |
| Robin_Watts | Apparently "gs_main_run_file_open" is an internal routine that is exported for some "special" clients. Anyone remember offhand what those special clients are? | 17:41.30 |
| henrys | Robin_Watts: maybe gsview? | 18:02.28 |
| | but I'm guessing | 18:02.40 |
| Robin_Watts | yeah, I've killed it in my local copy. | 18:03.00 |
| | I'm committed to keeping the gsapi_... functions intact. | 18:03.22 |
| | cos I figure most people will be calling with those. | 18:03.34 |
| | I'm going to be slightly more cruel/judgemental with the gs_main_ ones. | 18:04.10 |
| henrys | chrisl for the logs all missing glyphs present and accounted for! | 18:07.12 |
| rayjj | Robin_Watts: w.r.t. gserver.c, as chrisl said, it doesn't really properly do the server stuff. The -dJOBSERVER command line option does it "properly" even though it is implemented in PS | 18:07.26 |
| Robin_Watts | rayjj: Yeah, and it wouldn't have worked anyway cos the macros it needed were all commented out. And those soon won't work, cos I may be moving the stuff they rely on. | 18:08.22 |
| rayjj | it's so archaic and nobody has used it | 18:08.52 |
| Robin_Watts | I'm going to try to pull the command line argument handling out from the languages (as much as possible) | 18:09.29 |
| | The top level stuff will handle the obvious stuff, and any args it doesn't understand will be passed into the languages for processing. | 18:10.12 |
| rayjj | Robin_Watts: OK. Are you going to take on the creation of a trival parser so we can have options like arrays and dicts that are needed (mostly for pdfwrite) ? | 18:10.50 |
| Robin_Watts | rayjj: Not at the moment. | 18:10.58 |
| rayjj | that's important because people want to create PDF's (and PDF/A) from other than PS. But as long as you keep it in mind in designing your new cmd line processing | 18:12.11 |
| Robin_Watts | I understand the issue. | 18:12.22 |
| rayjj | Robin_Watts: thanks | 18:12.28 |
| mvrhel_laptop | Robin_Watts: I am back | 18:13.13 |
| Robin_Watts | mvrhel_laptop: I've given up on that for now. | 18:13.27 |
| rayjj | Robin_Watts: so something like -Ipath (that's only used by PS, afaik) will be handled by the PS language ? | 18:13.31 |
| mvrhel_laptop | Robin_Watts: ok | 18:13.36 |
| Robin_Watts | rayjj: Yes, paths look to be gs language specific. | 18:13.46 |
| mvrhel_laptop | I am going to tell Jung that I can not duplicate from his project any signs of memory leaks | 18:13.50 |
| Robin_Watts | mvrhel_laptop: Yeah. | 18:14.16 |
| | Do you want to send me a copy of your exe ? | 18:14.23 |
| mvrhel_laptop | Sure | 18:14.29 |
| Robin_Watts | Then I can test it to see if it grows here. | 18:14.36 |
| mvrhel_laptop | ok | 18:14.38 |
| rayjj | mvrhel_laptop: welcome back. Did you see my comments at the top of today's logs about the t_level_adjust ? | 18:14.39 |
| mvrhel_laptop | rayjj: I did. I don't have anything for you though | 18:14.52 |
| | as far as recalling why I changed it | 18:15.03 |
| | there was a difference between the tiling and threshold array though | 18:15.18 |
| rayjj | mvrhel_laptop: specifically, can you recall at all why you did this ? or why it was done this way ? | 18:15.25 |
| mvrhel_laptop | see above | 18:15.30 |
| | that was quite a long time ago | 18:15.53 |
| Robin_Watts | AIUI, this stuff sets up the dither so that the right dots appear at the right time, yes? | 18:16.37 |
| rayjj | mvrhel_laptop: OK. I've run a bmpcmp with that ripped out, and I'll look into it | 18:16.40 |
| mvrhel_laptop | rayjj; thats what I would do at this stage. sorry | 18:17.00 |
| Robin_Watts | As I noted in my latest change to the code, it's still not right. | 18:17.11 |
| rayjj | Robin_Watts: well, (see the logs) it is clearly wrong. It results in a non-monotonic t_level that can't be riight | 18:17.23 |
| Robin_Watts | so I wonder if maybe we ought to just recode it from scratch... | 18:17.38 |
| mvrhel_laptop | that is my feeling | 18:17.45 |
| | I feel like it needs a complete rework | 18:17.52 |
| | rather than being a bit of a Frankenstein | 18:18.05 |
| Robin_Watts | It shouldn't be brain surgery to code this simply and correctly, should it? | 18:18.11 |
| mvrhel_laptop | it should not be | 18:18.18 |
| Robin_Watts | (and if it is, then dear God, let's comment it!) | 18:18.27 |
| rayjj | Robin_Watts: It basically looks fine without all the 'adjust' stuff, it just may not match the non-fast halftoning (which is what I will investigate) | 18:18.35 |
| mvrhel_laptop | the goal is to get the same result as the tiling halftone code | 18:18.56 |
| rayjj | Robin_Watts: it is pretty simple | 18:18.57 |
| Robin_Watts | rayjj: I *believe* that was still less than ideal. | 18:18.58 |
| mvrhel_laptop | Robin_Watts: oh you think the tiling halftone is wrong? | 18:19.17 |
| Robin_Watts | If it matches this, then yes :) | 18:19.26 |
| mvrhel_laptop | what is "this" | 18:19.39 |
| Robin_Watts | Suppose we have 3 levels available to us. | 18:19.43 |
| rayjj | Robin_Watts: "this"? | 18:19.43 |
| mvrhel_laptop | ;) | 18:19.46 |
| Robin_Watts | and we've got 256 dots in the dither. | 18:20.18 |
| rayjj | clearly non-monotonic levels from any tiling code (where it gets darker instead of when it's supposed to get lighter) would be wrong | 18:20.37 |
| Robin_Watts | actually, ignore me. I need to go look at my last comment again. | 18:20.46 |
| | rayjj: I agree. | 18:20.49 |
| mvrhel_laptop | rayjj: I don't think anyone is arguing about that rayjj | 18:21.06 |
| Robin_Watts | The problem I was seeing was that the top and bottom 'levels' were different sizes to all the others. | 18:21.21 |
| rayjj | you two guys are busy having other fun. I'll run my findings by the both of you, but I don't think it needs all three of us | 18:21.31 |
| mvrhel_laptop | in the tiling code? | 18:21.32 |
| | Robin_Watts: ? | 18:21.34 |
| | or in the threshold code? | 18:21.57 |
| rayjj | Robin_Watts: OK, and I will look for that as well | 18:21.58 |
| Robin_Watts | Yeah, see the commit comment on my last change. The "and this bit is still broken, but that's another job" section. | 18:22.07 |
| rayjj | Robin_Watts: but if it doesn't match the tiling HT results, I'm not sure that we want to diddle with the thresholds to make them 'ideal' | 18:22.38 |
| Robin_Watts | rayjj: I'd argue that we should make the tiling HT results be ideal too. | 18:22.59 |
| rayjj | I want the threshold number to EXACTLY match the level that the HT tiling code uses. At least as a first step. | 18:23.25 |
| Robin_Watts | I can understand the attraction of that. | 18:23.47 |
| rayjj | Improving things to adjust the transitions (of both) is a different (enhancement) issue | 18:23.55 |
| | IMHO | 18:24.07 |
| | I have to run lunches in. bbiaw | 18:24.21 |
| Robin_Watts | You forget that I know our definition of enhancement :) | 18:24.23 |
| mvrhel_laptop | Robin_Watts: I just sent you my build of Jung's exe | 19:02.10 |
| | to see if you are seeing process explorer memory grow | 19:02.24 |
| | I will also see what this is doing on windows 7 here | 19:02.41 |
| | Robin_Watts: ok. so that is interesting. | 19:23.49 |
| | I am seeing the problem happen in windows 7 | 19:23.56 |
| | this is going to be a pain in the ass to figure out | 19:24.14 |
| | I am going to eat some lunch and think about it a bit | 19:24.27 |
| | I will need to get VS 2013 on this other machine | 19:32.02 |
| | Robin_Watts: I will let Jung know what I have found and that I will be working on figuring it out | 19:38.31 |
| Robin_Watts | mvrhel_laptop: Ah! | 20:10.45 |
| mvrhel_laptop | Robin_Watts: so it is very likely a managed code issue then | 22:33.33 |
| Robin_Watts | mvrhel_laptop: A .net runtime issue maybe? | 22:34.38 |
| mvrhel_laptop | maybe I am getting vs2013 on the windows 7 vm machine and then I will see | 22:35.07 |
| | Forward 1 day (to 2015/05/16)>>> | |
IRC Logs