| | <<<Back 1 day (to 2013/06/13) | 2013/06/14 |
| Jon5 | Mobilesharecbox.tk | 02:32.33 |
| chrisl | Brando753: Ghostscript reads Postscript and PDF, it doesn't read PNG. | 06:47.11 |
| kens | Hmm, Bugzilla seems to have a problem, if I try to go to bug 693945 it gives me a red screen of death | 07:05.41 |
| vtorri | kens, bugzilla is hosted on a Windows box ? :p | 07:06.24 |
| kens | No | 07:06.31 |
| chrisl | kens: it comes up for me: http://bugs.ghostscript.com/show_bug.cgi?id=693945 | 07:14.24 |
| kens | our URL works, but if I type the bug # into Bugzilla's search page, it gives me a nasty red screen | 07:14.54 |
| | It also teels me to inform Marcos :-) | 07:15.10 |
| chrisl | That's what I did to get the URL - use the search | 07:15.25 |
| kens | Didn't work for me :-( | 07:15.34 |
| | And now it does, its magically got better :-( | 07:15.56 |
| chrisl | Maybe you just caught it during the bugzilla restart? | 07:16.19 |
| kens | I guess that's a possibility | 07:16.34 |
| | Anyway, its Tor's bug not mine, whish is all I really wanted to know :-) | 07:16.54 |
| chrisl | Personally, I think the crash should be a separate bug..... | 07:17.54 |
| kens | Which crash ? | 07:18.35 |
| chrisl | 693945 | 07:19.00 |
| kens | I didn't think any of the three bugs were crashes | 07:19.25 |
| chrisl | The last comment(s) | 07:19.36 |
| kens | Oh yes, it should be | 07:19.51 |
| | But I cna safely ignore it when its in a bug like that :-D | 07:20.10 |
| | Personally I don;t really care about gxps much, I have several bigs outstanding on it. | 07:20.50 |
| | I could really do without Marcos opening 3 new P1 bugs for me at the moment too | 07:22.35 |
| chrisl | One or two of them are memory problems, so you could assign them to me | 07:24.13 |
| kens | I may ask you to look at them. | 07:24.24 |
| | The first one Marcos says 'Acrobat can open it' which is true, but when I close the file it asks if I want to sabe the changes, so its clearly a broken file. | 07:24.54 |
| | I bet this is a zeniko bug, its has a comment at the top saying '$repair me!" | 07:25.31 |
| | And no xref | 07:25.42 |
| chrisl | Hmm, I thought we'd still be able to handle that, if the file is well formed otherwise | 07:27.26 |
| kens | I think that we're trying to handle it as PostScript, because it doesn't look enough like a PDF file | 07:27.43 |
| | hence 'undefined in xref' | 07:27.58 |
| chrisl | Ah, I guess that makes some sense. TBH, I think you can downgrade that to low priority | 07:28.37 |
| kens | I think so too, I may even close it as 'wontfix' | 07:28.50 |
| | I'll just quickly see how we determine if a file is PDF | 07:29.11 |
| | ROFL, it turns out we don't accept anything as a PDF file unless its at least 400 bytes | 07:48.12 |
| | I cna get past that, then get a warning about the file being corrupted, then get a different error. | 07:49.07 |
| chrisl | I guess 400 bytes is the smallest a valid PDF can be - I did work it out, once upon a time...... | 07:50.51 |
| kens | THat's what the comment says, yes | 07:51.00 |
| | Though I'm not certain that's true in PDF 1.6 or better using compressed streams | 07:51.22 |
| chrisl | I guess so - it's hard to worry about a file that intentionally broken like that, though | 07:53.03 |
| kens | I think so, yes. | 07:53.17 |
| | Hmm, I wonder if there's somethign wrong with the macro definition for "gs_private_st_ptrs2_final" | 09:16.25 |
| | Whenever I try to use it, it fails to compile | 09:16.39 |
| | And it never gets used in teh GS code base currently | 09:17.36 |
| | Of course its alll buried in teh twisty macro hell of the garbage collector, so its kind of hrad to tell.... | 09:18.42 |
| chrisl | Let me see if I can expand it in gdb | 09:19.26 |
| kens | chrisl here's an example. If I use: | 09:20.00 |
| | typedef struct ramfs_state_s { | 09:20.00 |
| | char *t; | 09:20.00 |
| | ramfs* fs; | 09:20.00 |
| | } ramfs_state; | 09:20.00 |
| | gs_private_st_ptrs2_final(st_ramfs_state, struct ramfs_state_s, | 09:20.08 |
| | "ramfs_state", ramfs_state_enum_ptrs, ramfs_state_reloc_ptrs, ram_finalize, t, fs); | 09:20.09 |
| chrisl | What's the compile error? | 09:20.47 |
| kens | Several: | 09:21.13 |
| | 1>.\base\gsioram.c(67) : error C2373: 'ramfs_state_enum_ptrs' : redefinition; different type modifiers | 09:21.13 |
| | 1> .\base\gsioram.c(67) : see declaration of 'ramfs_state_enum_ptrs' | 09:21.13 |
| | 1>.\base\gsioram.c(67) : error C2070: 'void (*)(const gs_memory_t *,void *)': illegal sizeof operand | 09:21.13 |
| | 1>.\base\gsioram.c(67) : error C2109: subscript requires array or pointer type | 09:21.13 |
| | 1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl.EXE"' : return code '0x2' | 09:21.13 |
| | 1>.\base\gsioram.c(67) : warning C4047: 'initializing' : 'const gs_memory_struct_type_t *' differs in levels of indirection from 'void (*)(const gs_memory_t *,void *)' | 09:21.13 |
| | 1>Stop. | 09:21.14 |
| | 1>.\base\gsioram.c(67) : error C2065: 'ramfs_state_reloc_ptrs' : undeclared identifier | 09:21.14 |
| | 1>.\base\gsioram.c(67) : error C2099: initializer is not a constant | 09:21.15 |
| | 1>.\base\gsioram.c(67) : warning C4047: 'initializing' : 'void (*)(const gs_memory_t *,void *)' differs in levels of indirection from 'const gc_ptr_element_t (*)[2]' | 09:21.15 |
| | line 67 is hte st_ptrs2_final execution | 09:21.37 |
| | If I change that to a ptrs1 (and remove the extra pointer from the macro arguments) but leave the structure untouched, then it compiles | 09:22.19 |
| chrisl | Hmm, odd..... | 09:22.34 |
| kens | If you want I can push my code out to my private repository so you cna take a look | 09:23.09 |
| chrisl | That might help | 09:23.28 |
| kens | OK give me a second | 09:23.36 |
| chrisl | (but no promises!) | 09:23.40 |
| kens | It might be easier to see the problem if you have my code :-) | 09:24.25 |
| | Drat, I'm going to have to fix the whitespace errors before it'll let me commit the files. THis may take a minute | 09:26.40 |
| chrisl | erm, "commit -n" I think will let you | 09:27.12 |
| kens | just doing global search and replace ;-) | 09:27.46 |
| chrisl | Well, I have the macro expansion, but frankly, I'm rather confused by even that! | 09:28.50 |
| kens | I can't say I'm surprised.... I lost track trying to expand the macros calling the macros, calling the macros... | 09:29.14 |
| | OK pushed ramfs_branch to my repository on casper | 09:34.02 |
| chrisl | Right, looking at the expansions, there is definitely something wrong - I'll grab the source now | 09:38.46 |
| kens | The sourec is broken :-( | 09:39.21 |
| | I'll fix it. | 09:39.26 |
| | I globally replaced something I shouldn't have | 09:39.49 |
| | chrisl I just did a quick experiment and replaced the '2' ptrs with a '3' ptrs, and that compiles. So it looks like its spcific to the '2' macro | 09:42.53 |
| chrisl | Yeh, it's definitely expanding completely wrong: the finalize method goes completely missing, and there's two declarations of ramfs_state_enum_ptrs | 09:43.44 |
| kens | Fixed code is there now using the '2' macro | 09:44.04 |
| | chrisl well that explains the compilation errors, which were incomprehensible | 09:44.33 |
| | Of course, I could work around this by declaring a third pointer and ignoring it :-) | 09:44.56 |
| chrisl | OKay, I'll grab the code - I can see at least one error in the macro definition | 09:45.09 |
| kens | Well, you're way ahead of me... | 09:45.20 |
| chrisl | Hmm, next question: will this work on Linux.....??? | 09:47.14 |
| kens | I believe so, what do you think won't ? | 09:47.30 |
| | I think the original author was using Linux (based on the patch) | 09:47.45 |
| chrisl | Only that you've been experimenting on Windows rather than LInux | 09:48.42 |
| kens | True. But I *think* it'll be OK on Linux. I will check it there too of course. | 09:49.10 |
| | I've had ot make some changes to make it work on Windows | 09:49.21 |
| | The original code used malloc and free, and that's what I'm trying to get rid of, hence messing with the garbage collector... | 09:50.16 |
| chrisl | Hmm, errors galore..... | 09:50.19 |
| kens | Oh dear, I have a nasty feeling I just sent that to the wrong place. | 09:50.42 |
| chrisl | Erm, some things look wrong, for example: typedef struct _ ; | 09:51.25 |
| kens | Damn, I did I sent it to master instead of casper | 09:51.26 |
| | Try now | 09:51.34 |
| | And can someone tell mehow to delete a branch from master :-( | 09:51.46 |
| chrisl | As it's on a branch, does it matter? | 09:52.08 |
| kens | Its not desperate but I'd still like to kill it | 09:52.20 |
| | The casper one should be OK | 09:52.28 |
| | fingers crossed... | 09:53.32 |
| chrisl | Not sure, but I think: "git push origin :ramfs_branch" | 09:53.49 |
| kens | I think its gone now, I just got the email | 09:54.03 |
| Robin_Watts | chrisl: yup. | 09:55.56 |
| chrisl | Yes, it's gone. I've got the updated code, trying a build now | 09:56.08 |
| kens | OK with the '3' macro and a dummy pointer, my code now works (well, this little bit does) | 09:56.45 |
| kens | would like to state again how horrendous the garbage collector and its dreadful macros are.... | 09:59.22 |
| chrisl | Hmm, I get an error about too few arguments to ramfs_open | 09:59.27 |
| kens | chrisl yes you will | 09:59.34 |
| | If you cna get past the error in line 67 that's fine | 09:59.44 |
| chrisl | Yes, that doesn't error out now. | 10:00.11 |
| kens | OK, sounds like you fixed it :-) | 10:00.21 |
| | If you commit that, then I can give it a whirl here | 10:00.39 |
| chrisl | BTW, there's some spaces in lib.mak that should be tabs | 10:00.46 |
| kens | Hmm, I thought we were supposed to use spaces. | 10:01.02 |
| | Otherwise giot complains at me | 10:01.20 |
| chrisl | In makefiles some separators *must* be tabs | 10:01.24 |
| kens | Great :-( | 10:01.30 |
| chrisl | I've put a fixed lib.mak in my repo, and I'm going to commit the macro fix to the main repo | 10:02.42 |
| kens | That sounds ideal | 10:02.50 |
| | I think I've fixed my lib.mak here, I just undid the tab changes | 10:03.05 |
| chrisl | This is where the "commit -n" comes in handy. So I usually commit -n makefile changes, and commit other changes normally, and then squash the two commits. | 10:03.50 |
| kens | Yeah, I don't normally commit makefile changes.... | 10:04.05 |
| | And I use git gui, I'm not sure how to do that there | 10:04.56 |
| | Tripping over a bug in those macros is not a good sign for my day | 10:05.54 |
| chrisl | The fix is pushed to casper | 10:06.08 |
| kens | Thanks, now... How do I get it back to me from your repository ? :-) | 10:06.23 |
| kens | has never tried this before | 10:06.37 |
| chrisl | No, it's on the central repo, on the master branch | 10:06.48 |
| kens | Oh, right, I'll update then thanks | 10:07.00 |
| | ah yes, there's the mail | 10:07.11 |
| chrisl | Once you've got that commit on your local master branch, you can then rebase your branch to master | 10:07.33 |
| kens | I'll carry on with my branch for now, since I've made one now :-) | 10:08.05 |
| chrisl | Yes, rebase your branch to master, so all the new commits from master are also on your branch | 10:09.02 |
| kens | Yes, I'm just pulling the change into my masternow | 10:09.17 |
| | and rebuilding.... Of course it means rebuilding almost everything | 10:11.17 |
| | builds perfectly, thanks chrisl | 10:12.58 |
| chrisl | kens: np - of course, I don't promise that it *works*! | 10:13.20 |
| kens | It works adequately well, the pointer is correct when I get to release the memory | 10:13.39 |
| | And its been through a gc (I know because that's where it went wrong before) | 10:13.57 |
| | I can at least start and stop GS now without it crashing | 10:14.11 |
| | Now I need to fix the rest of the allocations that are using malloc | 10:14.23 |
| chrisl | Right, I'm going to be offline for an hour or so, whilst I install a new cable modem - and brace myself for 120mb broadband....... | 10:15.45 |
| kens | :-O | 10:15.55 |
| Robin_Watts | chrisl: All so the NSA can back up your hard drives that much faster :) | 10:16.33 |
| chrisl | Well, it was already 100, but they offered 120 at no extra cost, so, what the hell! | 10:16.44 |
| | Anyway, back in a while! | 10:17.03 |
| Robin_Watts | kens: He could have given the extra 20 to us, I'm sure it would have been more use :) | 10:17.41 |
| kens | I'd have taken it | 10:17.52 |
| | I'm looking at going to fibre here (fibre to the cabinet though) | 10:18.08 |
| Robin_Watts | I'd take it like a shot, but it's not likely to be an issue here for a long time. | 10:19.16 |
| kens | I'm not entirely sure how much benefit I would get | 10:20.01 |
| | I don't trust the marketing puff | 10:20.12 |
| paulgardiner | kens: What's "fibre to the cabinet": Is that to the end of the street, with existing copper the rest of the way? | 10:24.03 |
| kens | paulgardiner : yes pretty much, its fibre to the green cabinet at the roadside | 10:24.21 |
| Robin_Watts | paulgardiner: Yes. | 10:24.25 |
| kens | Then copper (or aluminium if you are *truly* unlucky) | 10:24.38 |
| paulgardiner | I'd guess that would just mean getting your full 20MB, which I get already, pretty much. | 10:24.55 |
| | Maybe a better share ratio too. | 10:25.07 |
| kens | chrisl the good news on that bug is that the patch contributor has his own domain and its still answering pings, so he may even get my email | 10:25.37 |
| paulgardiner | Robin_Watts: I looked over the annotation-smoothing patch. Looks good. I think there was a missing call to finish off the arc in the PageView changes, so I've put an updated version on my master, also with some white-space changes to fit better with the rest of the code | 10:28.13 |
| Robin_Watts | paulgardiner: Fab. | 10:28.29 |
| kens | paul my ISP reckons up to 38Mb download | 10:28.51 |
| | The premium package reckons up to 76Mb | 10:29.13 |
| paulgardiner | kens: oh! Okay, that'd be worth having if it comes here. | 10:29.15 |
| Robin_Watts | paulgardiner: It depends on the exchange. | 10:29.22 |
| | The highest I can get here is ADSL Max (8K down, 448 up). | 10:29.37 |
| kens | does not trust numbers from ISPs | 10:29.39 |
| Robin_Watts | and that's what I get. | 10:29.42 |
| | Woodstock has "WBC (21CN)", and hooky doesn't. | 10:31.07 |
| kens | My ISP 'estimates' that if I went for the premium fibre package I'd get 57.2Mb download and 15.7Mb upload, for £20 per month | 10:34.21 |
| | Oh, and no usage limit (bet they use throttling though) | 10:34.41 |
| Robin_Watts | bugger. got to page 8 of the bmpcmp before finding a problem :( | 10:36.15 |
| kens | hates that, gets you all hopeful then dashes you | 10:36.49 |
| | ROFL, apparently UK airlines have been told not to fly Edward Snowden to the UK. I gues they don't want him hiding out in the Ecuadorain embassy in the room next to Assange | 10:39.10 |
| Robin_Watts | They're gonna need a bigger embassy. | 11:23.27 |
| sebras | Robin_Watts: :) | 11:48.17 |
| vtorri_ | hey | 12:01.17 |
| ghostbot | hey, vtorri_ | 12:01.17 |
| vtorri_ | is libgs written using c++ ? | 12:01.26 |
| kens | If you mean Ghostscript itself, no | 12:02.25 |
| vtorri_ | the shared lib | 12:02.53 |
| | libgs | 12:02.58 |
| | or gs64dll.dll | 12:03.09 |
| kens | libgs.so is just Ghostscript, so no, its written in C | 12:03.12 |
| vtorri_ | hmm | 12:03.19 |
| kens | Same is true for the DLLs | 12:03.34 |
| vtorri_ | of course | 12:03.49 |
| | i don't understand my problem, then | 12:04.09 |
| | chrisl: ping | 12:28.45 |
| chrisl | vtorri_: pong | 12:28.56 |
| vtorri_ | chrisl: why don't you use automake or libtool for ghostscript builds, and just autoconf ? | 12:29.34 |
| chrisl | vtorri_: ghostscript pre-dates libtool and automake by a couple of decades - retrofitting would be a pain in behind. Besides, libtool especially is completely horrid | 12:30.34 |
| vtorri_ | chrisl: well, i would be glad to try using automake and libtool in a branch :p | 12:31.20 |
| | but only if that work would have a chance to be merged | 12:31.50 |
| chrisl | vtorri_: I wouldn't be keen on it. As I say, I really dislike libtool | 12:32.13 |
| vtorri_ | my main concern is that, currently, i can't compile libgs with MSYS/MinGW-w64, and the current pre-built binaries on windows have problems with mingw-w64 | 12:33.11 |
| kens | That's not a supported build configuration | 12:33.38 |
| vtorri_ | chrisl: libtool is a tool for devs, and once it's done, you don't touch it anymore | 12:33.39 |
| | kens: i know | 12:33.45 |
| | that's why i propose to use autotools | 12:34.05 |
| | it will work with that configuration, as well as plenty of others | 12:34.22 |
| kens | Feel free (this is open source code) but don't expect us to support it | 12:34.25 |
| vtorri_ | then no | 12:34.35 |
| chrisl | vtorri_: yeh, as long as it works - when it goes wrong (which is does) it becomes a tangled nightmare | 12:34.46 |
| vtorri_ | if it's not upstream, there is no interest | 12:34.51 |
| | chrisl: i've been the maintainer the autotools of a dozen of libraries, during 7 years | 12:35.22 |
| | without any problem at al | 12:35.29 |
| | all* | 12:35.31 |
| chrisl | vtorri_: what's the problem with msys? I pulled in several patches from msys developers to make it work | 12:35.59 |
| vtorri_ | no Makefile created (in the latest release source, not the latest code) | 12:36.32 |
| chrisl | So there should be an error | 12:36.47 |
| vtorri_ | the way you are creating Makefile's are also diferent to most of the other projects i've seen | 12:37.12 |
| chrisl | Much of ghostscript's build is different from most other projects | 12:37.42 |
| vtorri_ | that's what isaid :) | 12:38.04 |
| kens | I'd say different to any other project, on any platform you care to name | 12:38.13 |
| vtorri_ | implicitely | 12:38.14 |
| chrisl | The overall arrangement of the build isn't likely to change any time soon | 12:39.37 |
| kens | None of us like the build system, but changing it woudl be a huge project, and there would be no real gain | 12:40.07 |
| vtorri_ | kens: gain : make libgs working in my project, as the current pre builts are the problem | 12:40.44 |
| kens | No gain for us | 12:40.50 |
| vtorri_ | for now, i just can't make libgs working on windows | 12:41.00 |
| | ho | 12:41.04 |
| | ok | 12:41.06 |
| | sorry | 12:41.12 |
| | you don't care about other users, i understand more... | 12:41.32 |
| chrisl | I don't really care about users on a crazy half-breed, niche platform | 12:42.11 |
| kens | No. We are not likely to invest time and effort in changing a working build system (working for our supported configurations) in order to accomodate someone using an unsupported platofrm, unless there is some gain for us | 12:42.34 |
| vtorri_ | ok | 12:42.36 |
| | i stop here | 12:42.43 |
| | kens: **I** propose to do some work | 12:43.02 |
| | kens: not you or chrisl | 12:43.10 |
| kens | vtorri, but then we would have to maintain it | 12:43.13 |
| | In tools we are not expert in | 12:43.25 |
| vtorri_ | i can maintain it | 12:43.40 |
| | but abyway, you don't want | 12:43.53 |
| | so this discussion is useless | 12:44.00 |
| kens | vtorro, no offence but we have to cinsider it long term, you may not always be available | 12:44.09 |
| vtorri_ | no offense ? | 12:44.16 |
| kens | And if you want to maintain it, then go ahead and do it and maintain it, where's the difference ? | 12:44.29 |
| vtorri_ | honestly, do you read how you speak to someone who wants to help ? | 12:44.37 |
| kens | Yes | 12:44.42 |
| vtorri_ | ok | 12:44.47 |
| chrisl | vtorri_: is there a reason you can't just use the gs executable? | 12:44.56 |
| kens | I'm being polite here | 12:44.56 |
| | As opposed to accusing others of not caring about users.... | 12:45.09 |
| vtorri_ | chrislI don't really care about users on a crazy half-breed, niche platform | 12:45.25 |
| kens | I didn't say that | 12:45.36 |
| vtorri_ | and you say you care about users ? | 12:45.38 |
| kens | Yes we do, look at the number of bug fixes we provide for free users, often with < 24 hour turn around | 12:45.58 |
| vtorri_ | ok, not you | 12:45.59 |
| | but you are on the same side, anyway | 12:46.12 |
| | of course you're polite and all | 12:46.20 |
| | but taht's not kind | 12:46.42 |
| chrisl | vtorri_: if you're a windows user, I'll help. If you're a LInux user, I'll help. If you're a UNix user, I'll help. But msys causes it's own problems by being some one, and bits of the other | 12:46.43 |
| kens | As well as supplying custom PostScript solutions for free users, maintaining a presence in online forums to answer PostScript-related questions etc. | 12:46.43 |
| vtorri_ | say for example what you said to me on tuesday | 12:46.53 |
| kens | vtorri a\gain I feel you started that one | 12:47.04 |
| | I was prepared to answer questions, you seem to head straight to the 'you don't care' response | 12:47.29 |
| vtorri_ | chrisl: "is there a reason you can't just use the gs executable?" <--- i prefer using lib rather exec a binary | 12:48.13 |
| | a* lib | 12:48.19 |
| kens | You still haven't said why you can't use the pre-built lilbraries | 12:48.21 |
| vtorri_ | i didn't say that | 12:48.34 |
| | i can use them | 12:48.45 |
| | but | 12:48.47 |
| kens | Well you've been asked and not repsonded | 12:48.47 |
| | We still don't understand your actual problem | 12:49.17 |
| vtorri_ | when i link one of my module against libgs, LoadLibrary refuses to load my module | 12:49.28 |
| kens | If it involves building on an unsupported platform, then yes, you're on your own | 12:49.42 |
| | vtorri tghis is under Winedows ? | 12:49.50 |
| vtorri_ | windows +gcc ? | 12:50.00 |
| kens | dear me, my typing is deteriorating :-( | 12:50.04 |
| chrisl | vtorri_: IIRC, msys doesn't support symlinks - and that caused a problem with the 9.07 and earlier releases | 12:50.21 |
| kens | vtorri, well Windows+ gcc is not a supported build | 12:50.25 |
| | We can try and answer questions, but we aren't really ion a position to do much more | 12:50.49 |
| vtorri_ | chrisl: what do symlinks have to do here ? | 12:50.53 |
| chrisl | vtorri_: Makefile.in is a symlink to base/Makefile.in | 12:51.18 |
| vtorri_ | symlink just don't exist anyway on Windows (there are some similar stuff on Win >= vista or 7) | 12:51.23 |
| kens | vtorri, but on Windows we expect you to use msvc.mak | 12:51.40 |
| chrisl | vtorri_: cygwin supports symlinks | 12:51.50 |
| vtorri_ | chrisl: they emulate symlinks | 12:52.08 |
| chrisl | How does that differ from "support"? | 12:52.25 |
| vtorri_ | i would say that "support" means it exist on Windows and cygwin allows them to be used in its environment | 12:53.38 |
| kens | vtorri, so when LoadLibrary fails, what is the error return from GetLastError ? | 12:54.08 |
| vtorri_ | 998 | 12:54.13 |
| chrisl | Well, from a users point of view, "ln" works and does what's expected | 12:54.21 |
| vtorri_ | chrisl: question : why using a symlink at all?? | 12:54.41 |
| chrisl | vtorri_: beats me, I didn't do that! In fact, I removed in shortly after the 9.07 release - Makefile.in is now a "real" file | 12:55.23 |
| vtorri_ | ok | 12:56.22 |
| | i've looked only at the latest release source code | 12:56.38 |
| chrisl | I agree, *that* was barking mad - but there may be been good reason at the time it was done - before my time | 12:56.57 |
| vtorri_ | the reason was probably to avoid recursive make :p | 12:57.38 |
| kens | Interesting, error code 998 is ERROR_NOACCESS which is a memory error. | 12:58.21 |
| | I can't see hwo that can be anything to do with the DLL. | 12:59.26 |
| chrisl | vtorri_: in 9.07 by copying base/Makefile.in to ./Makefile.in and re-running configure, I can build a libgs.so under msys. The file names get borked up, so the example apps don't link, but the library is created. | 13:06.20 |
| vtorri_ | kens: it's just that libgs can't be mapped | 13:12.18 |
| kens | vtorri I'm not sure why that's a problem in the build | 13:13.01 |
| | The DLL exists, if LoadLibrary fails with a noaccess memory error, then where is the actual problem ? | 13:13.19 |
| vtorri_ | the visual studio linker gives an address to the dll | 13:13.51 |
| kens | Its been a long while since I looked at this but my understanding was that teh DLL was simply loaded into memory by LoadLibrary, I didn't think it performed much verfiication | 13:13.55 |
| vtorri_ | if that address is already taken in another DLL used in my module, then you will have that error | 13:14.26 |
| kens | vtorri, its a dynamic link, so the address should be assigned at load time I'd have thought, is it not ? | 13:14.52 |
| vtorri_ | not on windows | 13:15.17 |
| kens | I thougth you were using gcc ? | 13:15.46 |
| vtorri_ | windows is a piece of crap | 13:15.52 |
| kens | Or are you trying to use a DLL buylt with gcc in MSVC ? | 13:15.55 |
| vtorri_ | i'm building my module with gcc, using libgs (named gs64dll.dll or something like that) which is built with visual studio | 13:16.35 |
| kens | OK so your module is buitl with gcc, GS is a DLL built with MSVC ? | 13:16.58 |
| vtorri_ | yes | 13:17.07 |
| | the prebuilt binary provided on the ghostscript web site | 13:17.17 |
| kens | And teh application loading the DLLs is buitl with ? | 13:17.27 |
| vtorri_ | gcc | 13:17.34 |
| | everything is built with gcc | 13:17.44 |
| | i just use one lib built with VS : libgs | 13:17.54 |
| kens | Well that sounds like you should take it up with the gcc people. | 13:18.00 |
| vtorri_ | heh | 13:18.17 |
| kens | The pre-built DLL definitely works in a C applicationh | 13:18.21 |
| | The standard GS executable uses the DLL | 13:18.33 |
| vtorri_ | that's why i ask if c++ was used | 13:18.40 |
| kens | No, both are using only C | 13:18.46 |
| vtorri_ | because the stdc++ ABI are different | 13:19.00 |
| | so it should work | 13:19.09 |
| | but it fails | 13:19.14 |
| | i don't understand why | 13:19.21 |
| | that's why i wanted to build ghostscript myself | 13:19.36 |
| | but it (== gs 9.07) failed | 13:19.45 |
| kens | I have to say I dont either, but I do know that the DLL will work aith a variety of tools, albeit all from MS | 13:19.50 |
| vtorri_ | i'll try with the latest code | 13:20.02 |
| kens | chrisl did say it builds for him on msys | 13:20.07 |
| vtorri_ | i'll try that | 13:20.30 |
| | the .lib provided by the pre built binaries are the static lib or import lib ? | 13:21.28 |
| | is* | 13:21.39 |
| chrisl | import lib. We don't (normally) build a static lib | 13:22.00 |
| kens | Hmm, I thought it was hte DLL static lib | 13:22.04 |
| | Yes the import library | 13:22.12 |
| vtorri_ | ok | 13:22.32 |
| | may I ask you to prefix the dll and import lib with 'lib' ? | 13:22.50 |
| chrisl | vtorri_: the "so" build on msys gets the file names wrong because on msys the executable needs the ".exe" extension | 13:23.20 |
| vtorri_ | chrisl: i don't understand :) | 13:23.47 |
| chrisl | On proper Unix there is no file name extension for executables | 13:24.21 |
| vtorri_ | it's not needed, indeed | 13:24.40 |
| chrisl | So, the Ghostscript executable is just "gs" so we also use that string as the basis for the name of the shared lib: libgs.so and co | 13:25.22 |
| | On msys, the executable name is "gs.exe", and the build system still uses that string as the basis for the shared lib name - so it ends up being called "libgs.exe.so" etc | 13:26.21 |
| vtorri_ | note that libtool would do all that for you, and correctly :p | 13:26.42 |
| kens | Realistically we can't change the names of the DLL or the import library, too many people are using them as they are. | 13:26.51 |
| vtorri_ | kens: that's what i thought | 13:27.12 |
| chrisl | Hmm, does libtool work on Windows? | 13:30.42 |
| kens | I can't see Windows users being persuaded to use it even if it does | 13:31.10 |
| vtorri_ | chrisl: yes | 13:31.16 |
| kens | make that Windows developers | 13:31.20 |
| chrisl | vtorri_: how does it work without a shell to run in? Is there a windows batch file implementation? | 13:31.59 |
| vtorri_ | chrisl: https://github.com/vtorri/ecrin/tree/master/etui | 13:32.34 |
| | chrisl: i'm currently devolopping it on windows as i've no linux box at home | 13:32.50 |
| | chrisl: MSYS is needed | 13:33.03 |
| chrisl | So it doesn't work on Windows, it works on MSYS | 13:33.20 |
| kens | Well that makes some sense at least | 13:33.40 |
| vtorri_ | chrisl: if "working on Windows" means "working in the console", indeed, it does not work on windows | 13:33.57 |
| Robin_Watts | We shouldn't change the way MSVC builds work. We shouldn't change the way builds on unix work. | 13:33.59 |
| | IF vtorri can point us to changes that we can use to make msys builds work without breaking the other ones, then we can consider taking them on. | 13:34.31 |
| kens | chrisl syas it does work | 13:34.43 |
| chrisl | vtorri_: "working on Windows" would mean works with standard development tools for the platform - which is Visual Studio | 13:35.11 |
| vtorri_ | chrisl: the autotools need a set of POSYX tools, which aren't provided by Windows, so... | 13:35.29 |
| | POSIX* | 13:35.35 |
| Robin_Watts | vtorri: Get VMWare player and a linux image from thoughtpolice. Problem solved. | 13:35.41 |
| vtorri_ | Robin_Watts: or any virtual machine like virtualbox | 13:36.04 |
| | Robin_Watts: i know that | 13:36.08 |
| chrisl | Robin_Watts: There is already someone working on tidying up the msys related parts of the build, although he's been quiet for some time: http://bugs.ghostscript.com/show_bug.cgi?id=693493 | 13:36.37 |
| vtorri_ | Robin_Watts: i just have a problem installing my Archlinux on a computer with a UEFI bios | 13:36.46 |
| Robin_Watts | vtorri_: Not if you use a virtual machine. | 13:37.13 |
| vtorri_ | sure | 13:37.59 |
| Robin_Watts | It just seems like you're spending an inordinate amount of time (both yours and poor kens and chrisls) fighting to get something working on a really non-standard system. | 13:38.00 |
| vtorri_ | but i prefer develop "natively" | 13:38.10 |
| chrisl | vtorri_: can't you use rEFIt or something like that? | 13:38.15 |
| Robin_Watts | There is NO WAY you can consider msys as being "native". | 13:38.24 |
| vtorri_ | chrisl: i don't know that | 13:38.30 |
| chrisl | http://refit.sourceforge.net/ | 13:38.37 |
| vtorri_ | Robin_Watts: sure, it's cross compilation | 13:38.42 |
| kens | Gentlemen, shall we leave vtorri alone while he builds GS under msys, and then if that doesn't work he can come back | 13:39.03 |
| chrisl | vtorri_: I use rEFIt on my Mac (it runs linux), you might need something less Mac-oriented | 13:39.42 |
| vtorri_ | chrisl: i'll check that | 13:39.44 |
| chrisl | WOW, that extra 20 per cent broadband speed makes IRC really whizz! | 13:42.49 |
| kens | sROFL | 13:43.12 |
| Robin_Watts | chrisl: smugness is unattractive :) | 13:43.18 |
| chrisl | Robin_Watts: from the earlier comment - I would gladly donate the extra 20Mb to the less fortunate, but I'm told it doesn't work that way | 13:43.56 |
| henrys | chrisl:better broadband? | 13:44.39 |
| chrisl | henrys: yeh, I got a free upgrade from 100Mb to 120Mb - for no apparent reason | 13:45.02 |
| henrys | cable? | 13:45.34 |
| Robin_Watts | The NSA needed more bandwidth for snooping. | 13:45.36 |
| chrisl | henrys: yes, cable | 13:45.42 |
| kens | Well, I think I have the ramfs code using GC memory properly now, and it still seems to work. I've sent an email to the author (and as I said before, his personal domain still pings) so I'm going to leave this branch be for now. | 13:45.56 |
| henrys | the best I can do here cable wise is 50 | 13:45.58 |
| kens | Hmm, see earlier, my ISP reckons I get get more than 50 with FTTC | 13:46.27 |
| chrisl | They installed fibre to the cabinet here a couple of years ago | 13:46.39 |
| kens | Admittedly I can practically see the cabinet from my office window..... | 13:46.59 |
| Robin_Watts | We barely have this new fangled "electricity" stuff. | 13:47.08 |
| kens | really wants fibre to the premises :-( | 13:47.32 |
| Robin_Watts | kens: The exchange is 400 yards away, as the crow flies from me. | 13:47.32 |
| kens | Robin_Watts : yeah but you're lving in amongst the peasants | 13:47.55 |
| Robin_Watts | pheasants. | 13:48.08 |
| henrys | Robin_Watts:I'm surprised you aren't stuck with satellite, or maybe my impression was more rural than it actually is. | 13:48.10 |
| kens | It could only be worse if you were in Scotland (or possibly Wales) | 13:48.21 |
| chrisl | The village I spent a long weekend in a couple of weeks ago had no broadband at all | 13:49.09 |
| | in Somerset | 13:49.15 |
| kens | OOh arr... | 13:49.29 |
| henrys | chrisl:you must have multiple channels. | 13:49.49 |
| chrisl | henrys: I don't *think* so - but the available technical data is very limited | 13:50.20 |
| henrys | our city is going to offer fiber soon and all of a sudden the cable company is getting more friendly. | 13:50.42 |
| | chrisl:AFAIK it is all DOCSIS - see wikipedia | 13:51.51 |
| chrisl | henrys: yes, but there are quite a few variants | 13:52.19 |
| | henrys: actually, you're right. It looks like they use up to four channels for 120Mb | 13:53.19 |
| | I have come to the conclusion that the solution to the world's ills, not to mention the secrets of the Universe will be unlocked by the same non-reversible mathematics which apparently govern the manufacturer's packing of items into boxes, and the folding of certain maps. | 14:18.49 |
| Robin_Watts | chrisl: Kalami ? | 14:20.17 |
| chrisl | what's that? | 14:20.41 |
| Robin_Watts | http://tmoliff.blogspot.co.uk/2011/08/kalami-n.html | 14:21.09 |
| | I'll assume you've read "The Meaning of Liff" ? | 14:22.12 |
| chrisl | Aha! That must be from the Greater Meaning of Liff (or whatever the follow up was). I thought the original was all UK names - it's been a while | 14:22.29 |
| Robin_Watts | Deeper. | 14:26.44 |
| chrisl | Yes, that's it - both of mine are up the loft now | 14:27.05 |
| | Robin_Watts: my favourite is still Didcots | 14:27.50 |
| Robin_Watts | woking. | 14:28.19 |
| paulgardiner | Ah. That would make a nice company for the lonely books residing in my Nook. | 14:28.52 |
| | s/a// | 14:29.01 |
| Robin_Watts | or wimbledon. | 14:29.08 |
| chrisl | Oh, or wetwang - I used to know someone that lived in Wetwang | 14:29.09 |
| Robin_Watts | and Throcking. | 14:30.18 |
| chrisl | I can't find throcking | 14:31.29 |
| Robin_Watts | http://folk.uio.no/alied/TMoL.html | 14:31.42 |
| chrisl | I feel slightly guilty looking these up on a website..... | 14:32.50 |
| Robin_Watts | http://www.amazon.co.uk/Deeper-Meaning-Liff-Douglas-Adams/dp/0330322206/ref=sr_1_1?ie=UTF8&qid=1371220413&sr=8-1&keywords=The+deeper+meaning+of+liff | 14:33.52 |
| | Alas no kindle version. | 14:34.11 |
| chrisl | I have both original and Deeper, but like I said, up the loft. If there was an e-version that might prompt me to get an e-reader | 14:35.11 |
| paulgardiner | I shall click the "Tell the Publisher" link | 14:35.13 |
| henrys | C-style.htm says don't use inline in header files - these days static inline is fairly common. Any opinions about inlines in header files? | 15:09.39 |
| kens | I have a sneaky supicion we alredy have some | 15:10.02 |
| henrys | I know lcms does it quite a bit. | 15:10.17 |
| kens | I seem to remember running into some in may last round of macro craziness | 15:10.24 |
| Robin_Watts | Where available, static inline is preferable to macros, generally. | 15:10.33 |
| | BUT static inline is not available everywhere. | 15:10.44 |
| kens | This was macro->macro->inline->macro->macro | 15:10.57 |
| henrys | is it c99 at least ? | 15:11.02 |
| Robin_Watts | We can't assume C99. We can barely assume C89 :( | 15:12.35 |
| henrys | I wonder if using something like cmsINLINE would be okay in gs. I guess it is okay since gs requires LCMS ;-) | 15:12.37 |
| Robin_Watts | henrys: yeah, we could use gsINLINE or something and #define it away if the compiler doesn't support it. What's one more configuration thing for chrisl to handle ? :) | 15:13.18 |
| chrisl | I actually thought we already did that...... | 15:13.57 |
| henrys | well cmsinline doesn't compile it away - that won't work - I'm talking about putting the body of the function in the header file. | 15:14.06 |
| | lcms sees to require either __inline or static inline | 15:14.31 |
| | s/sees/seems | 15:14.37 |
| chrisl | I would say: don't put the body of a function in a header file at all...... | 15:15.01 |
| henrys | okay then static inline can't be used. | 15:16.45 |
| Robin_Watts | chrisl: static inline should only be used for tiny things, akin to the way macros *should* be used. | 15:17.48 |
| henrys | but we do have to support it or kick out lcms see _cmsQuickFloorWord for example - am I missing something? | 15:17.50 |
| Robin_Watts | static inline gives you macros with type safety (and better debugging). | 15:18.19 |
| henrys | static inline should usually trump a macro IMHO | 15:18.35 |
| | portability is the problem. | 15:18.58 |
| chrisl | Robin_Watts: if the function is that small, most compilers will optimise it away anyway, these days | 15:19.08 |
| Robin_Watts | Not if they are across compilation blocks. | 15:19.22 |
| | hence why the implementations need to be in header files. | 15:19.34 |
| henrys | yes clang does but gcc doesn't ... | 15:19.39 |
| Robin_Watts | i.e. in the same place macros would have been. | 15:19.41 |
| chrisl | Oh, I thought recent gcc's did, too. | 15:19.59 |
| Robin_Watts | clang will not optimise away tiny functions across compilation blocks. | 15:20.00 |
| henrys | that's what I've read | 15:20.13 |
| | anyway clearly many compilers won't | 15:20.28 |
| kens | so inline in header is better | 15:20.41 |
| Robin_Watts | henrys: Do you have a source to hand for that? | 15:20.56 |
| chrisl | My worry is that allowing it opens it up to abuse - like in the rendering code..... | 15:21.02 |
| Robin_Watts | That's OK, we'd never abuse macros... oh wait... | 15:21.23 |
| henrys | I can also #include a c file with the inline functions. | 15:21.36 |
| | avoiding .h abuse. | 15:21.57 |
| | but that annoys some. | 15:22.08 |
| | and finally I could repeat the definition in each file needing it. That would suck. | 15:22.53 |
| chrisl | What I don't like is having a function body in a header file, and using a macro defined in the C file which changes the behaviour of the function | 15:23.25 |
| Robin_Watts | chrisl: You mean chameleonic (sp?) headers? | 15:24.11 |
| | like the runrop stuff ? | 15:24.20 |
| chrisl | Yep | 15:24.24 |
| | I know there are (*very* occasional) good reasons for doing it, but....... | 15:25.13 |
| Robin_Watts | I think that's absolutely fine, as long as it's just one thing in the header, and it's clearly defined (and commented) what it does. | 15:25.13 |
| | It's the clearest way of doing templating in C, IMHO. | 15:25.41 |
| | The alternative (having monolithic macros) is much much worse. | 15:26.03 |
| | at least you can step through the header in a debugger. can't do that with a macro. | 15:26.47 |
| chrisl | Like I say, there are times when it's worth doing, but generally, I'd rather get there some other way. | 15:27.47 |
| Robin_Watts | But at any rate, such things aren't static inlines, that's a different issue. | 15:31.59 |
| chrisl | henrys: I guess what it all boils down to is: if you have a good reason, then we're okay with it. We'll worry about portability issues if/when they arise | 15:33.56 |
| henrys | thanks for the feedback folks | 15:36.21 |
| chrisl | "feedback" == "gibbering nonsense".... ;-) | 15:37.15 |
| henrys | kens: did you try 687697 with ps2write, I assume it is not an issue ... | 15:37.54 |
| | ? | 15:37.55 |
| kens | henryslet me look | 15:38.09 |
| | henrys ps2write wil preserve the glyphs, so it should not be a problem. | 15:38.51 |
| | But if what the thread says is correct, its not a pswrite problem either really | 15:39.27 |
| | its a decoding bug | 15:39.32 |
| henrys | of static inline - it would be nice to have 1 big endian accessor definition instead of 47 IMHO? | 15:47.39 |
| Robin_Watts | henrys: What big endian accessors do we currently have? | 15:48.24 |
| | gah. I finally see what's going wrong here. | 15:49.09 |
| | I have a type3 image, which uses an interpolated image for the data, which plots through a clipmask decoded at the same time for the alpha data. | 15:49.54 |
| | If the size calculations for the 2 destination images get out of sync, we get blank lines because the interpolate image is plotted through a clipmask that isn't there yet. | 15:51.04 |
| henrys | I do recall reading about inlining across compilation units but I can't seem to find it now. | 15:59.15 |
| Robin_Watts | henrys: I guess it would have to be implemented by the same kind of techniques as you'd use to do templating in C++. | 15:59.56 |
| kens | Robin_Watts : is that the white line problem I wished onto you ? | 16:01.16 |
| Robin_Watts | kens: part of it. | 16:01.58 |
| kens | Oh, sorry about that :-( | 16:02.06 |
| Robin_Watts | I can solve that original problem by changing the rounding of the interpolation stuff, so the image gets slightly bigger. | 16:02.29 |
| | but that then triggers this problem. | 16:02.39 |
| kens | Oh :-( | 16:02.53 |
| Robin_Watts | Essentially I think the problem is that all the image types do their own 'step through the data' stuff and they all do it slightly differently. | 16:03.12 |
| kens | That sounds about normal :-( | 16:03.44 |
| mvrhel_laptop | Robin_Watts: you still around? | 17:10.55 |
| Robin_Watts | I am. | 17:10.59 |
| | are you? :) | 17:12.44 |
| mvrhel_laptop | so I did a significant rework of the display list use in the windows app. Now there is a display list cache at the level that interfaces with mupdf and this is not visible above this level. This is more in line to what you were thinking and I believe this makes more sense and is a bit cleaner and easier at the app level | 17:12.47 |
| | sorry typing a big message | 17:12.51 |
| Robin_Watts | np :) | 17:12.55 |
| | certainly sounds nice. | 17:13.18 |
| mvrhel_laptop | i need to beat on it a bit and make sure everything is well behaved | 17:13.25 |
| | hopefully I may have something in the next hour | 17:13.45 |
| Robin_Watts | How many display lists can you hold at once? | 17:13.49 |
| mvrhel_laptop | it is set by a define | 17:14.03 |
| Robin_Watts | N in the cache, plus however many are 'in use' ? | 17:14.17 |
| | Ordinarily when we have such things we arrange that the cache in use is the 'fz_store'. | 17:14.54 |
| mvrhel_laptop | so it is possible that the cache could get full and all those be in use plus others in use | 17:14.57 |
| Robin_Watts | which automatically evicts when mallocs start to fail. | 17:15.16 |
| mvrhel_laptop | but if I just use it for the current zoom page, that would not happen | 17:15.22 |
| Robin_Watts | mvrhel_laptop: Right. I'd have thought you could reasonably have the cache just be 3 lists in size (for the current page, the previous page, and the next page) | 17:16.04 |
| | although even a single place cache would be a win. | 17:16.24 |
| mvrhel_laptop | Robin_Watts: right. right now I did happen to set it to 3 to start out with | 17:17.23 |
| | let me do some testing for bit now | 17:18.20 |
| Robin_Watts | ok. | 17:18.40 |
| ray_laptop | mvrhel_laptop: I found another thing I had not changed correctly in gs_pdf14_device_color_mon_set (I forgot to change the line of code that set pageneutralcolor so it was always setting it false) | 17:31.09 |
| mvrhel_laptop | ray_laptop: hmm. a lot of good my review did for you. I feel a bit bad | 17:31.46 |
| ray_laptop | mvrhel_laptop: np. I am lousy at desk checking code that I don't step through. | 17:32.16 |
| | some people seem to have a knack for it. | 17:32.30 |
| | marcosw: Since it is now a feature, I suggest a periodic run with '-dGrayDetection=true -sDEVICE=pnmcmyk'. This device produces P7 for color pages and P5 for monochrome pages. | 17:38.25 |
| | (if I don't hear from you here, I'll send an email) | 17:38.53 |
| | I sure wish we could figure out a way to get those funky image files to print (the ones that fill with black, then overlay with an imagemask stencil, painting white) | 17:50.10 |
| | I haven't tried mupdf to see what it does. We sure have seen a bunch of those, initially from cust 531 and cust 700, but now also from cust 780 | 17:51.29 |
| Robin_Watts | ray_laptop: In what way don't they print ? | 17:55.48 |
| ray_laptop | Robin_Watts: they print, but leave black lines sporadically, or at some resolutions leave an all black page | 17:59.29 |
| | s/page/image/ | 17:59.36 |
| mvrhel_laptop | Robin_Watts: ok. so now there are 3 commits in my repos | 17:59.49 |
| Robin_Watts | ray_laptop: The sporadic black lines I understand. | 18:00.03 |
| mvrhel_laptop | the top one adds the display list cache | 18:00.07 |
| ray_laptop | Robin_Watts: if you run one of these with -dPDFSTEP when you get to the relevant area, you can watch the progress on the display | 18:00.34 |
| mvrhel_laptop | if we can get through these three, then I will start the store submission | 18:00.45 |
| ray_laptop | Robin_Watts: as far as I can tell, this is some convoluted way for the image data to print 'negative image' (rather than just changing the Decode array) | 18:01.52 |
| Robin_Watts | mvrhel_laptop: OK, so the first commit on there is the one I've looked at before. | 18:06.59 |
| | which looks absolutely fine, except for the possibility of races, yes ? | 18:07.17 |
| mvrhel_laptop | yes. and the new commit should fix the races | 18:07.21 |
| | yes | 18:07.27 |
| Robin_Watts | and I've looked at the +/- one before, and it makes as much sense to me now as it did then :) | 18:07.56 |
| mvrhel_laptop | that is just UI stuff | 18:08.12 |
| Robin_Watts | Rather than adding/removing buttons, you now just make them visible or not ? | 18:08.43 |
| | The last commit contains a change to win32/mupdf.sln that shouldn't be there. | 18:09.22 |
| mvrhel_laptop | I did move the searching stuff, into the xaml. It allowed me to do some resizing when we are in the partial snap view | 18:09.28 |
| | that is the searching buttons | 18:09.38 |
| Robin_Watts | mvrhel_laptop: Right, makes sense. That ones fine too. | 18:09.47 |
| mvrhel_laptop | previously, I was dynamically creating them in the code | 18:09.49 |
| Robin_Watts | The caching thing doesn't work the way I'd expected it to. | 18:14.48 |
| | I'd imagined that you'd have a "FindDisplayList" call that would find you a display list, first by looking in the cache, and if it wasn't there, then by creating one and putting it in the cache. | 18:16.15 |
| mvrhel_laptop | that is what it does | 18:16.28 |
| Robin_Watts | That would return an fz_keep_display_list(ctx, list); | 18:16.35 |
| | then you'd use it, and fz_drop_display_list(ctx, list); at the end. | 18:16.57 |
| | No need for the 'cached' variable in the CreateDisplayList call. | 18:17.18 |
| | no need for ReleaseEntry. | 18:17.27 |
| | no need for the cache to keep track of what is in use and what isn't. | 18:17.36 |
| mvrhel_laptop | ah ok. I see what you mean | 18:18.17 |
| | I agree. I am not taking advantage of the ref counting of the list. let me fix this. hold on about 10 minutes | 18:19.13 |
| Robin_Watts | ok. | 18:19.56 |
| mvrhel_laptop | Robin_Watts: a question though | 18:20.22 |
| | oh never mind. I guess, when I add an item to the cache, I can simply do a drop entry of the tail and add the new one | 18:21.10 |
| | i.e. I don't have to worry about if someone is using an entry from the cache when I remove it | 18:22.13 |
| Robin_Watts | And whenever you "CreateDisplayList" (or "FindDisplayList", whatever you want to call it), you can move any one you do find to the head of the chain. | 18:22.13 |
| mvrhel_laptop | yes | 18:22.20 |
| | ok. hold on, let me rework this | 18:22.32 |
| Robin_Watts | mvrhel_laptop: exactly. You remove it and drop your reference. When they finish they'll drop their reference and everyone will be happy. | 18:22.39 |
| mvrhel_laptop | yes | 18:22.48 |
| | ok. rewritten and simpler. let me test to make sure nothing explodes | 18:31.04 |
| Robin_Watts | mvrhel_laptop: I'm going to walk the dog now. will be back later. | 18:32.57 |
| mvrhel_laptop | Robin_Watts: ok. I should have this for you when you return | 18:33.13 |
| | Robin_Watts: ok. repos has the update now | 18:45.12 |
| | bbiab | 18:45.18 |
| Robin_Watts | mvrhel_laptop: It still has the change to mupdf.sln that shouldn't be there. | 19:03.11 |
| | RenderPage probably needs some try/catch magic in - if we hit a problem and it throws, we should catch and clean up. | 19:06.13 |
| | but otherwise it looks fine. | 19:06.47 |
| mvrhel_laptop | Robin_Watts: back | 19:25.16 |
| Robin_Watts | mvrhel_laptop: OK, I just took your patches, fixed the win32 thing and a few white space issues. | 19:25.34 |
| | I'm about to push them. | 19:25.37 |
| mvrhel_laptop | oh. I had changes in win32? | 19:25.50 |
| | oops | 19:26.10 |
| Robin_Watts | Outstanding issues: 1) You need some try/catch magic around the fz_run_display_list to prevent leaks on error. | 19:26.21 |
| | 2) You have a 'use' param to AddEntry that you don't really need. | 19:26.34 |
| | but those are both minor. | 19:26.39 |
| | oh, balls. I screwed up the whitespace fix. | 19:27.14 |
| | I'll have to do it again. | 19:27.22 |
| mvrhel_laptop | Robin_Watts: the use entry is needed as when the item is added to the cache, if I want to use the entry then I do a keep during the add entry which is released after I use it | 19:27.46 |
| Robin_Watts | mvrhel_laptop: Right, but you never call AddEntry without use = true. | 19:28.02 |
| | So why have the param? | 19:28.05 |
| mvrhel_laptop | good point. I was thinking I might want it | 19:28.48 |
| | but I can remove it for now | 19:28.59 |
| Robin_Watts | I think you needed it before, but you don't now. | 19:29.02 |
| mvrhel_laptop | to keep things clean | 19:29.03 |
| | if you want to wait until I fix these issues up that is fine | 19:29.40 |
| | did you already push? | 19:29.46 |
| Robin_Watts | I have not pushed yet. | 19:29.52 |
| | I can wait, or I can do it now, it's up to you. | 19:30.00 |
| mvrhel_laptop | lets wait a minute. let me fix these items up | 19:30.12 |
| Robin_Watts | ok. There is some stray whitespace too. spaces/tabs at the end of lines. | 19:30.41 |
| mvrhel_laptop | doesnt the try and catch around fz_run_display_list sufficient? | 19:32.06 |
| | s/doesnt/isnt | 19:32.11 |
| | where do I need to do more? | 19:32.22 |
| Robin_Watts | You should put the fz_drop_display_list in the fz_always. | 19:32.46 |
| mvrhel_laptop | oh yes | 19:32.54 |
| Robin_Watts | and set it to NULL initially. | 19:33.00 |
| | I'm being called for dinner. I will do the push later or tomorrow, sorry! | 19:33.26 |
| mvrhel_laptop | Robin_Watts: ok | 19:33.56 |
| | Robin_Watts: ok. I fixed the top commit in the repos. Removed win32 solution changes, fixed up the try always catch so the display list is included, removed the use bool in AddEntry and removed at least one white space | 19:45.40 |
| | bbiab | 19:46.41 |
| Robin_Watts | back. will fix whitespace and commit now. | 20:16.08 |
| mvrhel_laptop | Robin_Watts: ok. thanks | 20:23.25 |
| | I am going to have one other minor UI fix in a minute too | 20:23.49 |
| | just found it while playing on the surface | 20:24.00 |
| Robin_Watts | ok, those 3 pushed. | 20:27.35 |
| | I removed an fz_var(dlist); line from the last one, cos it wasn't needed. | 20:27.59 |
| | You only need to fz_var(xxx); if xxx is changed within the fz_try { ...} | 20:28.16 |
| mvrhel_laptop | but it could be changed from null to the a display list | 20:29.34 |
| | s/to the a/ to a/ | 20:29.43 |
| Robin_Watts | mvrhel_laptop: Not within the fz_var | 20:30.16 |
| mvrhel_laptop | oh its internals | 20:30.37 |
| Robin_Watts | unless I screwed up my reading of the code, that happens before the fz_var, right? | 20:30.41 |
| | before the fz_try, sorry. | 20:30.48 |
| mvrhel_laptop | ok hold on. i want to make sure I understand this | 20:31.00 |
| Robin_Watts | I want to make sure I haven't screwed up :) | 20:31.18 |
| | Balls. I have screwed up. sorry. | 20:32.02 |
| mvrhel_laptop | oh. do I need to add anything in CreateDisplayList with respect to dlist? | 20:32.07 |
| Robin_Watts | I will put a fix in with a mea culpa. | 20:32.11 |
| mvrhel_laptop | i.e. a fz_var(dlist) | 20:32.38 |
| | so when do I need to vs. not need to do the fz_var(xxx) prior to the try | 20:33.56 |
| Robin_Watts | You had it absolutely right. | 20:34.11 |
| | The rule is "if a variable x might change it's value at any point during the fz_try then you should fz_var it". | 20:34.41 |
| mvrhel_laptop | Robin_Watts: do I need a fz_var(dlist) in CreateDisplayList too | 20:35.02 |
| | there is not one there | 20:35.08 |
| Robin_Watts | You do. | 20:35.33 |
| mvrhel_laptop | based upon my understanding I would think yes | 20:35.38 |
| | ok. | 20:35.44 |
| Robin_Watts | You also need a bit more magic there to ensure that it's not leaked in the error case. | 20:35.48 |
| mvrhel_laptop | yes | 20:35.54 |
| Robin_Watts | Let me take care of that. | 20:36.26 |
| mvrhel_laptop | ok | 20:36.31 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=217761efbf5e047001f36c37a4c34bd67fc94ad1 | 20:39.55 |
| | mvrhel_laptop: If you review that, I'll push it. | 20:40.03 |
| mvrhel_laptop | Robin_Watts: won't the fz_drop_display_list(ctx_clone, dlist); negate the ref count increment that I added in AddEntry | 20:41.36 |
| | wouldnt this go in the catch? | 20:41.56 |
| Robin_Watts | mvrhel_laptop: No, because if you succeed in AddEntry we'll have done dlist = NULL; | 20:41.57 |
| | but it might be more neat to do it in the catch actually. | 20:42.29 |
| mvrhel_laptop | but, then I would return null | 20:42.37 |
| Robin_Watts | mvrhel_laptop: D'Oh! | 20:42.49 |
| | Yes, you're right. I'll fix it. | 20:42.54 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=08b6fc12487eddbcbf1c445489e22426252b94da | 20:43.56 |
| mvrhel_laptop | yes. that makes sense to me | 20:44.10 |
| Robin_Watts | pushed to golden. | 20:44.36 |
| mvrhel_laptop | Robin_Watts: ok. thanks | 20:44.44 |
| Robin_Watts | no worries. I can break your commits any time you like :( | 20:44.59 |
| mvrhel_laptop | hehe. let me see what happens when I fetch these now. | 20:45.30 |
| Robin_Watts | paulgardiner: I can't see the smooth review you said was on your repo. | 20:46.13 |
| mvrhel_laptop | Robin_Watts: so there is one more minor commit now in my repos | 20:49.13 |
| | related to UI stuff | 20:49.47 |
| | I am going to beat on this a bit more tonight and then start going through the store process | 20:50.23 |
| | now I will let you off for the weekend Robin_Watts :) | 20:51.13 |
| Robin_Watts | so if doc->Content = FULL_RESOLUTION you can set the selectedindex without redrawing anything? | 20:51.17 |
| mvrhel_laptop | yes, the flip view object acts like a cache in a way | 20:51.43 |
| | if it already has a full resolution image, then we will just display it | 20:51.57 |
| Robin_Watts | oh, cos that means that it's already done the HQ redraw. right. | 20:52.02 |
| mvrhel_laptop | if it is a thumbnail then we redraw | 20:52.08 |
| Robin_Watts | OK. seems fair enough. | 20:52.09 |
| mvrhel_laptop | the flipview object is data binding is setup to a vector of bit maps essentially | 20:52.52 |
| Robin_Watts | pushed. | 20:53.25 |
| | have a good weekend! | 20:53.29 |
| mvrhel_laptop | usually there are only a few that are HQ but on the surface, things are a bit slower and as I zipped around it apparently had not freed ones yet | 20:53.32 |
| | Robin_Watts: you too. thanks for your help | 20:53.40 |
| Robin_Watts | you're welcome. | 20:54.03 |
| | Forward 1 day (to 2013/06/15)>>> | |
IRC Logs