| | <<<Back 1 day (to 2012/03/08) | 2012/03/09 |
| RaducuL | hello | 08:29.38 |
| ghostbot | hey | 08:29.38 |
| RaducuL | latest mupdf, iOS sample fails to build with this message: make: *** No rule to make target `build/debug-ios-i386/opj_cidx_manager.o', needed by `build/debug-ios-i386/libopenjpeg.a'. Stop. | 08:30.54 |
| | we tried on two machines once with xcode 4.2 one with 4.3 | 08:31.15 |
| chrisl | RaducuL: you probably need to wait 2-3 hours for the mupdf devs to be around | 08:38.33 |
| RaducuL | chrisl: I know, they will see it once they wake up | 08:43.43 |
| kens | chrisl Robin_Watts sent me a patch overnight with some changes to the GC macros, so that the names can be marked easily. Also he did the work for separations and devicen and added some (presumably required) code to the PCL interpreter. | 09:00.08 |
| | I've applied and checked the call sequence on the Linux problem and it works fine. | 09:00.24 |
| | So now I'm doing a clean rebuild and will do a cluster test (I know Robin did one, but I'm paranoid I screwed up applying the patch) | 09:00.52 |
| chrisl | Great! When I looked at the gc code, I realised Robin was right about adding the name_strings to the ENUM_PTRS ability - I originally thought we needed a type "sub-struct" which would have about doubled the size of the name string object, but it's *much* easier than that. | 09:08.47 |
| kens | Its all Greek to me :-) | 09:09.02 |
| | But it seems to work perfectly | 09:09.09 |
| | And its a lot easier than adding a new callback function to the strictire | 09:09.23 |
| chrisl | Basically, this way of doing it means the garbage collector relies on the ENUM_PTRS call to tell it what the object is, and how to mark it - we don't actually need to garbage collector itself to know about the object type. | 09:10.24 |
| kens | Sounds good, its nice and simple anyway | 09:10.40 |
| chrisl | Yeh - another "crazy that this hasn't come up before....." case! | 09:11.05 |
| kens | Well, there are few internal structures that need to maintain a name I suppose.... | 09:11.29 |
| | Oops, got italics turned on there somehow | 09:12.07 |
| chrisl | Sure, but given how heavily color spaces are used, and the proliferation of DeviceN spaces these days......... | 09:12.25 |
| kens | Don't forget that prior to (approximately) 8.71 htis was all done in PostScript..... | 09:12.52 |
| chrisl | That's still two years+ - anyway, it's (very nearly) fixed now | 09:14.02 |
| kens | Hopefully :-)_ | 09:14.15 |
| | Oh,oh.... | 09:18.58 |
| chrisl | Trouble? | 09:19.16 |
| kens | Looks like I have a line ending screw up in the patched files. | 09:19.18 |
| | I used 'patch' in MinGW and it has added Linux endings | 09:19.41 |
| chrisl | does MinGW has unix2dos? | 09:20.00 |
| kens | Not sure, one moment | 09:20.09 |
| chrisl | s/has/have | 09:20.09 |
| kens | No is the short answer | 09:20.23 |
| chrisl | Oh, that's annoying..... | 09:20.44 |
| kens | Well it won't hurt the cluster push | 09:20.46 |
| | I'll have to go and fix it manually in VS I guess | 09:20.59 |
| | Oh it has dos2unix :-) | 09:21.25 |
| chrisl | Well, nearly there! | 09:21.39 |
| kens | XClearly its a one way system, you aren't supposed to go back | 09:21.58 |
| chrisl | IIRC, on Linux they are both in the same package | 09:22.51 |
| kens | I guess not in MingW | 09:23.14 |
| chrisl | Do you have sed? | 09:23.33 |
| kens | Seems so yes | 09:23.49 |
| chrisl | sed 's/$/\r/' UNIX_file > DOS_file | 09:23.57 |
| kens | Let me try that. | 09:24.07 |
| chrisl | waits for all hell to break loose....... | 09:24.24 |
| kens | Still have to do each file individually though :-( I was just figuring out the same sort of sequence in VS search/replace :-) | 09:24.39 |
| chrisl | How many files are there? | 09:25.15 |
| kens | 6 | 09:25.33 |
| | Great VS can search for \n but not \r | 09:25.54 |
| | I think I'll do this the slow way, I don't trust myself with a Linux command line | 09:27.35 |
| | OK manually updated. | 09:35.54 |
| | rebuilding again | 09:36.03 |
| | Hmm. 19-04.ps seg faulted o nhenrysx6, that's not a normal problem is it ? | 09:58.32 |
| chrisl | It doesn't ring a bell with me, no | 09:58.55 |
| kens | But only on plank device, that's weird. | 09:59.04 |
| chrisl | Does the delta page work again? | 09:59.20 |
| kens | trying it now | 09:59.37 |
| | Taking a long time.... | 09:59.48 |
| | I'm going to do another push with my modified line endings. If its a rela problem it should occur again | 10:00.31 |
| | At least the CR/LF warnings have all gone, so that's good | 10:01.32 |
| Robin_Watts | Morning | 10:12.56 |
| kens | Hi Robin_Watts | 10:13.09 |
| viric | I wonder how GNU can remove the references to the copyright owner. | 10:18.18 |
| | Showing the copyright owner is part of the GL | 10:18.29 |
| | GPL | 10:18.31 |
| | Robin_Watts: ^ | 10:18.35 |
| | henrys: ^ | 10:18.41 |
| chrisl | viric: I didn't think they removed the copyright notices, just the stuff about there being a commercial license available, too. Legally, they cannot remove the copyright notices | 10:20.58 |
| paulgardiner | Hi Robin | 10:26.21 |
| Robin_Watts | Morning | 10:27.19 |
| viric | ah ok | 10:30.01 |
| | that's quite a little removal then | 10:30.14 |
| chrisl | viric: we're not exactly happy with the GNU GS fork - we get a reasonable number of people who are, quite reasonably, confused by there being GPL Ghostscript and GNU Ghostscript, and where they should discuss/report problems for each. | 10:52.11 |
| viric | I understand | 10:52.27 |
| | as for me, a simple user, I prefer the gpl ghostscript, as gnu is always lagging behind | 10:52.43 |
| chrisl | In general, for a number of reasons, GPL GS is a better choice - I doubt the GNU fork gets any where the testing ours does | 10:53.49 |
| viric | there has been times where gnu was way behind | 10:56.27 |
| | 7.x vs 9.x or so | 10:56.32 |
| | and I simply couldn't open some PDFs with their version | 10:56.41 |
| | well, render. | 10:56.49 |
| | rasterise. | 10:56.57 |
| | whatever :) | 10:56.58 |
| | I thought they abandoned it.. but I see they are back at 9.x | 10:57.14 |
| chrisl | Yeh, I did approach them about if there was anything we could do to make releases easier, so keep them more up to date - but they basically said "if you do all this extra stuff for each release, it would make our lives easier.....", I wasn't too interested in that. | 10:58.23 |
| viric | weird | 10:59.07 |
| chrisl | Seems to be the way of it. I've had the same kind of response from Linux distribution maintainers, too. | 10:59.55 |
| viric | well, I'm one of such | 11:03.45 |
| | we've to such what to link programs with. yours or gnu's | 11:03.57 |
| | well, in fact we give the option. It's a matter of the "default". | 11:04.10 |
| | I'll try to make gpl gs the default | 11:04.42 |
| chrisl | Default really should be our GPL - that's what most distributions use. | 11:04.56 |
| Robin_Watts | Ho ho. I've just had the information pack about my holiday arrive. | 11:05.09 |
| chrisl | viric: do you mind me asking which distribution you work on? | 11:05.14 |
| viric | nixos.org/ | 11:05.21 |
| | well, it's a package manager. It works 'anywhere' | 11:05.28 |
| Robin_Watts | Apparently, I have to register all electronic equipment with Bhutanese customs when I arrive. | 11:05.30 |
| | I may be there all day... | 11:05.39 |
| viric | but we have also a distribution, that uses the nix package manager. | 11:05.44 |
| | (nixos = distro. nix = package manager. nixpkgs = packages available) | 11:05.58 |
| chrisl | Interesting, thanks, I'll have to have a proper look when I have some time | 11:06.19 |
| viric | basically, we have: ghostscript.gnu = true/false :) | 11:06.32 |
| | https://nixos.org/websvn/nix/nixpkgs/trunk/pkgs/misc/ghostscript/default.nix | 11:06.58 |
| | there is the 'gnuFork' variable. | 11:07.35 |
| chrisl | Well, if you want the option of reporting problems to us, and possibly pulling in important patches between releases, you want to use our release. | 11:07.59 |
| viric | aha, clear | 11:08.13 |
| | thank you | 11:08.42 |
| chrisl | FWIW, I'm not aware we've had any feedback from the GNU GS guys, and at least three of four users have come here to report problems because reporting them to the GNU GS list got no response. | 11:10.59 |
| Samae | Robin_Watts: hi, about the automatic zoom feature, it's literally 3 lines to add. | 11:26.21 |
| Robin_Watts | Samae: Cool. Gimme a patch. | 11:26.32 |
| Samae | Is it a feature that would fit in the roadmap ? | 11:26.39 |
| | Robin_Watts: other question, a patch over what version ? latest stable ? | 11:27.21 |
| Robin_Watts | If it's easy to add, doesn't conflict with anything we have planned etc, and doesn't cost us much time to take on, we'd be stupid not to. | 11:27.42 |
| | If it's only 3 lines, pretty much any version :) | 11:27.51 |
| Samae | right :) I'll patch against 0.9 then | 11:28.01 |
| | Robin_Watts: where shall I send it ? | 11:38.14 |
| Robin_Watts | If it's only 3 lines, pastebin it, and pop the link here? Or mail me: robin.watts@artifex.com | 11:38.46 |
| Samae | I'll with the mail :) | 11:39.00 |
| | done :) What's next ? | 11:40.54 |
| Robin_Watts | I'll have a look as soon as I finish doing what I'm doing. | 11:53.18 |
| Samae | Robin_Watts: ok, i'll leave the chan now, please tell me if there's anything more you need (you got my email adress :) | 11:55.37 |
| Robin_Watts | chrisl, kens: Thinking about customer 532s performance again... | 13:20.06 |
| | It seems that most of the time is spent in scan conversion. | 13:20.30 |
| | And the only thing we scan convert are glyphs. | 13:20.42 |
| | There may be some tweaks I can make to the scan conversion code to get a few % here and there, but basically, we're not going to get a huge amount, unless we can scan convert a whole lot less. | 13:21.27 |
| chrisl | So, can we make the cache bigger? | 13:21.53 |
| Robin_Watts | What function puts a char into the cache ? | 13:23.44 |
| chrisl | Just a sec..... | 13:24.01 |
| Robin_Watts | gx_image_cached_char plays it out, and I see 53000 calls to that - which seems plausible. | 13:24.22 |
| kens | chrisl would probably remember this stuff better than me | 13:25.19 |
| Robin_Watts | gx_add_cached_char, I'd guess. | 13:26.31 |
| | I see 834 calls to gx_add_cached_char. | 13:26.45 |
| kens | Sounds plausible | 13:26.50 |
| | How many fonts are on the page ? | 13:26.59 |
| Robin_Watts | 1. In 1 point size. | 13:27.12 |
| chrisl | Yes, probably - but that doesn't include (all?) the logic for whether a glyph should be cached | 13:27.19 |
| kens | Well then I guess 834 is a lot of calls, cahce must be getting flushed | 13:27.29 |
| Robin_Watts | I'd assumed that was "83.4 per page", and so was reasonable. | 13:27.32 |
| kens | Only if it restores fonts between pages. | 13:27.47 |
| | Or uses different names or soemthing | 13:27.56 |
| Robin_Watts | And that was what I was about to ask. | 13:28.08 |
| chrisl | IIRC, the pdf interpreter does discard fonts between pages | 13:28.19 |
| Robin_Watts | (I think there is a low gravity zone between my ears, cos pennies take a long time to drop sometimes) | 13:28.24 |
| kens | Many jobs do an end of page restore | 13:28.25 |
| chrisl | kens: this is PDF | 13:28.33 |
| Robin_Watts | chrisl: Right. And is there a good reason for that ? | 13:28.41 |
| kens | I haven't seen the files :-) | 13:28.49 |
| | Robin_Watts : caution | 13:28.54 |
| Robin_Watts | i.e. is it something we could trivially change ? | 13:28.57 |
| kens | On the part of the programmers | 13:29.02 |
| chrisl | Robin_Watts: no, not a trivial change | 13:29.07 |
| kens | We cna't change it, no. | 13:29.11 |
| Robin_Watts | OK. | 13:29.16 |
| chrisl | There is a good reason: lots of jobs have different subsets of the same font referenced by different pages. | 13:29.41 |
| Robin_Watts | Actually, there may be 2 fonts used in 1 font size each on each page. | 13:32.12 |
| | so 83.4 glyphs per page sounds reasonable. | 13:32.20 |
| kens | Depends on the text, but yes, quite plausible | 13:32.32 |
| Robin_Watts | so we're not (obviously) thrashing the cache, and there is no quick win we can get by reusing from page to page. | 13:33.03 |
| | I suppose it's too much to hope that our move to freetype will have changed anything here ? | 13:33.36 |
| kens | If we used object numbers intead of names for fonts, we wouldn't have to clear them between pages (for PDF) | 13:33.50 |
| | Robin_Watts : might be a little faster | 13:34.01 |
| Robin_Watts | (if we're dropping fonts, I bet we drop the font handle, and so freetype would drop it too) | 13:34.05 |
| kens | a few percent perhaps | 13:34.06 |
| | I'm pretty sure FAPI will discard everything | 13:34.24 |
| chrisl | In general, performance between the FT code and the AFS code was comparable. | 13:35.45 |
| Robin_Watts | paulgardiner: Fix pushed. | 13:41.33 |
| paulgardiner | Ta. | 13:42.01 |
| kens | Robin_Watts : have you got time to answer a dumb question ? | 13:43.14 |
| Robin_Watts | probably, though this is a role reversal... | 13:43.30 |
| kens | Not in this case :-) | 13:43.38 |
| | I have a Memento build of PCL (I believe) | 13:43.52 |
| | from teh irc log henrsy said that owl.pcl showed leaks | 13:44.03 |
| | I tried running it, but nothing happened unusual | 13:44.14 |
| | What do I need to do ? | 13:44.18 |
| | Should I see a log or something ? | 13:44.28 |
| | Or have I built it/run it incorrectly ? | 13:44.37 |
| Robin_Watts | When it exits it should say something. | 13:44.42 |
| | Let me try here. | 13:44.47 |
| kens | Nope. | 13:44.47 |
| Robin_Watts | command line ? | 13:45.23 |
| kens | pcl6 owl.pcl | 13:45.28 |
| | You may have to use ../../tools/owl.pcl or something similar | 13:45.46 |
| | So its going to the display device on Windows | 13:46.07 |
| | Du, I suppose it would help if I selected pdfwrite.... | 13:46.28 |
| Robin_Watts | Buildng now. | 13:46.32 |
| chrisl | Robin_Watts: did you see Ray's reply about the other performance problem from cust 532 - about the changes in pdf_font.ps? | 13:46.49 |
| kens | Robin_Watts : also tried 'pcl6 -sDEVICE=pdfwrite -o out.pdf owl.pcl' same effect. | 13:47.17 |
| Robin_Watts | bugger, said Pooh. | 13:47.20 |
| kens | I do get a nice PDF file though | 13:47.35 |
| Robin_Watts | OK. If I run it in the debugger I see Memento_inited called. | 13:48.40 |
| kens | I can try that | 13:48.49 |
| Robin_Watts | So... why don't I see any output. I wonder if henrys is redirecting stderr somewhere wacky. | 13:50.03 |
| | Damn. Was running gs in VS, sorry. | 13:50.46 |
| | I don't see Memento being called. | 13:50.51 |
| kens | Oh :-( | 13:50.56 |
| Robin_Watts | There must be a problem with the makefiles under windows. | 13:51.02 |
| kens | Well, at least its not just me, I feel happier already | 13:51.19 |
| Robin_Watts | Yeah for some reason -DMEMENTO=1 isn't making it through. | 13:52.05 |
| kens | I could set that as a flag | 13:52.19 |
| | compile flag ? | 13:52.54 |
| Robin_Watts | Yeah. | 13:54.45 |
| kens | building already :-) | 13:54.52 |
| Robin_Watts | I have a fix. | 13:54.54 |
| kens | That's good too | 13:55.03 |
| Robin_Watts | oh, well, if you have something that works. | 13:55.06 |
| | I'll look for a nice fix after lunch. | 13:55.14 |
| kens | I'm not sure it works yet .... | 13:55.19 |
| | But certainkly have lunch, no rush | 13:55.33 |
| Robin_Watts | As long as it's saying -DMEMENTO or -DMEMENTO=1 on every compile command, you should be sorted. | 13:55.42 |
| kens | says -dMEMENTO | 13:56.15 |
| | Err -DMEMENTO | 13:56.21 |
| | Doesn't call Memeneot_inited though | 13:57.08 |
| | Ah, because its an unknown symbol | 13:57.57 |
| | Guess that didn't work then | 13:58.03 |
| kens | will wait for Robin to eat | 13:58.33 |
| cipri | hi. I have question to mupdf, again :P. When do you think you might make a new release? | 14:12.09 |
| kens | 'soon'. Version 1.0 is due for release shortly | 14:12.26 |
| cipri | that's great. | 14:12.38 |
| | any regressions? because i noticed that mupdf changed in the last month quite a bit. | 14:14.10 |
| kens | I don't believe there should be any regressions, MuPDF is tested, but I'm not a MuPDF developer as such. | 14:14.37 |
| | And eys, thre have been a lot of recent changes, mainly to get everything done for release | 14:15.08 |
| cipri | Do you think soon means, less than 1 month or less than 2 weeks? :) | 14:18.44 |
| kens | Could be either, I haven't been following that discussion. | 14:19.42 |
| | I'd hoped tor8 might chime in here (hint, hint) | 14:19.55 |
| cipri | let him, otherwise we get a bigger delay :) | 14:20.21 |
| Robin_Watts | I do love it when people wait for the answers to their questions. | 14:31.29 |
| | chrisl: common/msvc_top.mak | 14:36.56 |
| | Line 69: I check for MEMENTO and add the flag to CFLAGS if it's there. | 14:37.33 |
| chrisl | Yeh, I see that | 14:37.55 |
| Robin_Watts | Hmm. I was about to say it's not working, but... | 14:38.07 |
| | Do CFLAGS get propogated everywhere? like to the underlying gs lib build? | 14:39.31 |
| | Or should I use XCFLAGS for that ? | 14:39.46 |
| | Ah, maybe the rules at line 105ish need to pass MEMENTO too. | 14:40.46 |
| chrisl | CFLAGS does not seem to be propagated, I'm not sure if you want to pass MEMENTO, or add it to XCFLAGS, depends on how the underlying makefiles handle MEMENTO being defined | 14:41.59 |
| Robin_Watts | chrisl: Look just after the memento stuff. | 14:42.13 |
| | CFLAGS is updated to cope with GX_COLOR_INDEX_TYPE | 14:42.36 |
| | that won't be propogated into the lib either. | 14:42.48 |
| | Is that right ? | 14:42.50 |
| chrisl | Yes, hmmm. | 14:43.17 |
| | Ah, but only for PSI_INCLUDED - that seems odd, too..... | 14:44.02 |
| | I wonder if that is the source of some of the strange problems with the language_switch build...... | 14:47.12 |
| Robin_Watts | I suspect I assumed I was safe to just fiddle with CFLAGS there because of the GX_COLOR_INDEX_TYPE stuff. | 14:47.13 |
| | (either that, or I just screwed up, and the GX_COLOR_INDEX_TYPE followed me into the ditch) | 14:47.41 |
| chrisl | The way the pcl/xps make files pass data to the GS makefiles is pretty appalling, IMHO........ | 14:49.22 |
| Robin_Watts | Hey, it was broken when I found it. | 14:49.37 |
| chrisl | :-) | 14:50.19 |
| kens | :-) | 14:50.20 |
| Robin_Watts | kens: Fix pushed. | 14:53.03 |
| kens | Thanks Robin will fetch it now | 14:53.13 |
| | OK Memento_inited breask now | 15:12.40 |
| | And I get output at end, thanks Robin | 15:13.01 |
| Robin_Watts | Fab. | 15:15.21 |
| | sorry about that. | 15:15.24 |
| kens | NP seems to be fine now. | 15:15.32 |
| | Now all I need to do is understand it | 15:21.26 |
| Robin_Watts | Can I help? | 15:34.08 |
| kens | Not yet, maybe next week :-) | 15:34.17 |
| Robin_Watts | When it ends, you get a list of blocks that leaked. | 15:34.33 |
| kens | Yep, lots of them | 15:34.50 |
| Robin_Watts | OK, the 'num' is the interesting thing. | 15:35.04 |
| kens | I'm going to have to capture it before I can see anything much | 15:35.18 |
| Robin_Watts | Run it once in the debugger, all the way through, and write down some of the nums. | 15:35.21 |
| | Then run it again, with a breakpoint on Memento_inited. | 15:35.37 |
| kens | OK | 15:35.43 |
| Robin_Watts | When it stops there, hit Ctrl-Alt-Q and you'll get a window up. | 15:35.57 |
| kens | OK again | 15:36.07 |
| Robin_Watts | In there, type: Memento_breakAt(1234) | 15:36.10 |
| | (where 1234 is one of your nums) | 15:36.21 |
| kens | OK will try that in a bit | 15:36.31 |
| Robin_Watts | Hit return to execute that, then escape to clear the window. | 15:36.37 |
| kens | Thanks | 15:36.43 |
| Robin_Watts | Then continue execution, and you'll stop in Memento_breakpoint (put a breakpoint on Memento_breakpoint) on the allocation of one of your leaked blocks. | 15:37.04 |
| | Actually, I'm going to pull the latest Memento back from mupdf to gs, cos it has a funky feature that might help you. | 15:37.37 |
| kens | OK that sounds interesting | 15:40.23 |
| paulgardiner | tor8,Robin_Watts: mupdf is doing a better job of displaying forms than I was expecting, presumably because the documents I'm looking at have widgets with appearance streams. Is there any specific missing feature that would be good to target as the first addition? Or do you know of any example documents where parts of the forms don't display? | 16:15.54 |
| Robin_Watts | I don't, off the top of my head. | 16:16.40 |
| | You have signed the NDA, right? | 16:16.51 |
| | which means you have SVN access to our private repo. | 16:17.02 |
| | Our private repo contains a set of files given to us from sumatrapdf. | 16:17.19 |
| | these are ones that have caused problems for them in the past. | 16:17.30 |
| | And may well have cases for things like this in. | 16:17.52 |
| paulgardiner | Oh ok. That sounds handy. | 16:17.56 |
| Robin_Watts | svn+ssh://robin@svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk | 16:18.46 |
| | and inside that, it's really tests_private/pdf/sumatra that you want. | 16:19.15 |
| | hehe. | 16:34.29 |
| | kens: New memento has a feature that when it lists the leaked blocks, it does a cunning search on them first. | 16:35.06 |
| | So that it lists them nested (so if you have several blocks that have leaked just because the reference count on the parent block was wrong, it's obvious where that was). | 16:35.53 |
| | Unfortunately, pcl uses a chunked allocator. Which means that every block memento sees has a pointer back to the previous block :) | 16:36.26 |
| kens | Hmm, OK, that sounds interesting | 16:36.28 |
| Robin_Watts | so the nesting is "uninteresting" :) | 16:36.33 |
| kens | Oh.... | 16:36.38 |
| | owl says it leaks 822k so I have a lot to look at | 16:37.15 |
| viric | hello! | 16:38.39 |
| | again | 16:38.48 |
| Robin_Watts | hi | 16:39.16 |
| ghostbot | niihau | 16:39.16 |
| viric | I managed to get GPL ghostscript as default in the distro | 16:39.17 |
| | BUT | 16:39.19 |
| | it made our programs crash due to an internal old libpng version | 16:39.28 |
| | so we are back at gnu ghostscript | 16:39.34 |
| | (internal *in ghostscript*) | 16:39.39 |
| Robin_Watts | What version of ghostscript were you using? | 16:40.01 |
| viric | 9.05 gpl ghostscript | 16:40.12 |
| Robin_Watts | We appear to be on 1.2.44 | 16:41.13 |
| | and the latest is indeed 1.2.47 (or 1.5.9) | 16:41.46 |
| viric | We are at 1.5.9 | 16:42.03 |
| | which is not binary compatible iirc | 16:42.09 |
| chrisl | We should be able to use 1.5.9 | 16:42.17 |
| viric | gnu ghostscript uses it just fine. | 16:42.28 |
| Robin_Watts | So, why should the version of libpng that we use affect how other peoples code runs? | 16:42.48 |
| viric | I think it may be about it picking the header files for the system libpng1.5 | 16:43.07 |
| | and linking with your copy | 16:43.14 |
| | I don't know | 16:43.16 |
| | I can check further. | 16:43.26 |
| Robin_Watts | Our copy of libpng is only intended to be used with OUR code. | 16:43.36 |
| viric | Well | 16:43.51 |
| Robin_Watts | If you've exposed any of the libs from inside gs as system ones - that's an integration bug. | 16:43.56 |
| viric | if you don't limit what symbols are exported in the shared object... | 16:43.57 |
| | you leave all up to the dynamic linking | 16:44.02 |
| chrisl | If you're building a shared library, you should probably remove the libpng code from the gs directory and let configure use the system one | 16:44.17 |
| viric | libgs | 16:44.18 |
| | A simple configure parameter can achieve that? | 16:44.38 |
| chrisl | Just delete or rename the libpng directory in the gs directory - configure will then work out the right thing to do | 16:45.39 |
| viric | I saw GNU Ghostscript people specifically remove extra code in gpl ghostscript (libpng, ...) | 16:45.40 |
| | ok! | 16:45.46 |
| | I'll try | 16:48.11 |
| | looks like going | 16:49.55 |
| | imagemagick was segfaulting at a simple run | 16:50.02 |
| chrisl | viric: all the third party libs work that way - except openjpeg. | 16:50.13 |
| viric | perfect | 16:50.20 |
| henrys | kens:I looked briefly most of the leaks are coming from pdf_set_drawing_color(). | 16:53.22 |
| kens | Thanks henrys, my job for the morning :-) | 16:56.53 |
| Robin_Watts | Ok, I have the nesting stuff fixed. | 16:58.10 |
| | Sadly not as useful in this case as I'd hoped. | 16:58.22 |
| henrys | I wonder if that gc fix is implicated in other memory problems we've had. Nice work! | 16:59.41 |
| kens | henrys I hope it hasn't been causing problem, but I am very happy to have got rid of it :-) | 17:01.05 |
| Robin_Watts | kens: Updated memento pushed, but I wouldn't bother updating if you're in the middle of stuff. | 17:02.21 |
| kens | Not really in the middle of stuff, just playing and looking at pdf_set_drawing_color | 17:09.55 |
| | I think it must be a subfunction though | 17:10.08 |
| Robin_Watts | The advantage of tracking the leaks via 'num' is that you can rerun and get back to exactly the spot where it leaked. | 17:11.15 |
| kens | yep | 17:11.23 |
| Robin_Watts | It's often best to start with the last thing leaked in a document. | 17:11.30 |
| kens | But there are no akllocations in that routine | 17:11.33 |
| Robin_Watts | Ah. You need to get henrys to send you his gdb traces. | 17:12.02 |
| | Or make a list of nums in increasing order and step from one to the next and look at the stack trace until you see one that goes through pdf_set_drawing_color | 17:12.44 |
| henrys | kens:I am not clear this is the fastest way to a pdf server though... you said something about the %d being a separate problem. | 17:13.07 |
| Robin_Watts | (You can repeatedly Memento_breakAt(...) as long as you use a larger number each time) | 17:13.21 |
| kens | henrys, thre is a crahs, and apparent memory leaks | 17:13.52 |
| | 2 problems I feel | 17:14.00 |
| | At the moment I'm looking at memory allocations | 17:14.48 |
| viric | chrisl: all clean! thank you | 17:15.33 |
| | it works fine with the system png | 17:15.39 |
| | no crashes anymore | 17:15.42 |
| chrisl | viric: cool! | 17:15.46 |
| viric | thank you all | 17:16.21 |
| | I'll come again if I see more troubles :) | 17:16.31 |
| henrys | kens:I put the backtrace log on casper.ghostscript.com trace.log in my home directory if you want to look at all the leaks at once. | 17:18.48 |
| kens | Thanks henrys | 17:20.32 |
| | Though I may not understand it :-) | 17:20.44 |
| henrys | Well if you successively search for the keyword Breakpoint - after each you will find the stackfrom of a leak. | 17:22.16 |
| kens | hmm, | 17:22.29 |
| henrys | s/stackfrom/stackframe | 17:22.31 |
| kens | OK | 17:22.34 |
| Robin_Watts | henrys: How do you generate that? | 17:23.01 |
| henrys | every set_drawing_color issue seems to be associated with a pattern yuck. | 17:23.29 |
| Robin_Watts | Do you run once, grab the numbers of the leaked blocks then rerun with Memento_breakAt and some gdb script hackery ? | 17:23.34 |
| henrys | Robin_Watts:I write a custom .gdbinit script with breakpoint gathered from memento. | 17:24.17 |
| kens | Shouldn't be that many patterns, but maybe the patterns are real, and a problem | 17:24.19 |
| henrys | Robin_Watts:there thats something you can't do with VS | 17:25.39 |
| Robin_Watts | "breakpoints gathered from Memento" - in what sense? Memento doesn't keep breakpoints ? | 17:25.48 |
| | Yes. gdb is better than VS when you want to script it. VS is better than gdb when you actually want to use it though :) | 17:27.40 |
| henrys | I grab the global.sequence from the memento output and write the .gdbinit with conditional breakpoints. I'll send you the script | 17:27.42 |
| Robin_Watts | henrys: Are you talking memsqueezing here? | 17:28.14 |
| | Oh, I see. Rather than call Memento_breakAt() and just put a breakpoint on Memento_breakpoint, you fudge it yourself with conditional breakpoints. | 17:29.58 |
| henrys | right. | 17:30.33 |
| Robin_Watts | I *could* do something with memento to make it save out a list of leaked blocks and then replay that list next time. That would work with VS. | 17:31.26 |
| marcosw | henrys: did you want to have a support meeting? | 17:31.31 |
| henrys | if you like. Do we need one? | 17:32.05 |
| marcosw | I don't think we do. | 17:32.15 |
| henrys | I'll take your word for it ;-) | 17:32.42 |
| marcosw | if no one objects I'm going to change tiffsep so that the composite file uses the same compression as the separations (see http://bugs.ghostscript.com/show_bug.cgi?id=692907) | 17:34.51 |
| Robin_Watts | marcosw: Sounds good to me. | 17:35.22 |
| henrys | why do I get invalid bug # when I click on that. | 17:35.56 |
| | ? | 17:35.57 |
| kens | Robin_Watts : you do know MuPDF commits are failing on the cluster ? | 17:36.03 |
| henrys | nvm it was grabbing the ')' | 17:36.14 |
| Robin_Watts | kens: I didn't. | 17:37.30 |
| kens | 2 commits on dashboard, bot failed | 17:37.44 |
| Robin_Watts | marcosw: Can you update the cluster nodes with a new thirdparty.zip please? | 17:38.06 |
| marcosw | Robin_Watts: sure. Is there a way we can automate this? Perhaps using rsync to grab thirdpary.zip if it's changed? | 17:38.39 |
| Robin_Watts | marcosw: Sure. | 17:38.59 |
| | We endeavour to keep mupdf.com/download/thirdparty.zip up to date with git. | 17:39.26 |
| marcosw | the last time the thirdparty.zip file has a date as part of the filename, was that a one time thing? | 17:39.42 |
| Robin_Watts | marcosw: The plan is that all the thirdparty.zips are uploaded as one with a date, and we have a symlink to the latest for thirdparty.zip | 17:41.02 |
| marcosw | that should work | 17:41.12 |
| kens | Robin_Watts : memento builds all fail for me with latest code | 17:48.03 |
| Robin_Watts | Any error? | 17:48.14 |
| kens | 5>.\base\memento.c(546) : error C2065: 'MEMENTO_SEARCH_SKIP' : undeclared identifier | 17:48.14 |
| | Bit more: | 17:48.41 |
| | 5>.\base\memento.c(108) : warning C4067: unexpected tokens following preprocessor directive - expected a newline | 17:48.41 |
| | 5>.\base\memento.c(546) : error C2065: 'MEMENTO_SEARCH_SKIP' : undeclared identifier | 17:48.41 |
| | 5>.\base\memento.c(853) : warning C4028: formal parameter 1 different from declaration | 17:48.41 |
| | 5>.\base\memento.c(854) : warning C4028: formal parameter 1 different from declaration | 17:48.41 |
| | Doesn't like: | 17:49.20 |
| | #ifdef MEMENTO_GS_HACKS (2*sizeof(void *)) | 17:49.20 |
| | missing #deine ? | 17:49.50 |
| Robin_Watts | Bah. | 17:50.24 |
| | I must have git added before vs saved it out. Hold on. | 17:50.47 |
| | #ifdef MEMENTO_GS_HACKS | 17:51.29 |
| | #define MEMENTO_SEARCH_SKIP (2*sizeof(void *)) | 17:51.30 |
| | That's what's supposed to be there. | 17:51.38 |
| kens | Thought so | 17:51.47 |
| | Looks better. Still get a formal parameter warning, going to ignore it for now | 17:52.51 |
| Robin_Watts | That's a signal handler. | 17:53.01 |
| | just ignore that. | 17:53.03 |
| kens | OK | 17:53.07 |
| | THat built OK, I'll do a full build now, thanks. | 17:55.17 |
| | And off for the night, have a good weekend all. | 17:55.30 |
| Robin_Watts | Night. | 17:55.36 |
| | mvrhel: ping | 18:08.10 |
| mvrhel | pong | 18:08.19 |
| Robin_Watts | I've got a customer bug here about a pdf rendering very slowly. | 18:08.47 |
| mvrhel | uhoh | 18:08.56 |
| Robin_Watts | and it's down to it rendering strokes to a pdf14 device. | 18:09.00 |
| | because we go to a pdf 14 device, we have to turn all the stroke into a path and then fill it, rather than filling it a segment at a time. | 18:09.37 |
| | because if we do otherwise we get nasty effects at the points where we double plot. | 18:09.52 |
| | (make sense?) | 18:09.57 |
| mvrhel | makes sense | 18:10.10 |
| Robin_Watts | I'm wondering if there is an optimisation we can make here. | 18:10.33 |
| mvrhel | probably | 18:10.42 |
| Robin_Watts | and be smarter about it. | 18:10.42 |
| | In this case, I think it's a black patch being plotted in a 'darken' blend mode. | 18:11.08 |
| | which I believe still means we'll end up marking solid black, right? | 18:11.20 |
| mvrhel | I have to look at what the darken blend mode does | 18:11.43 |
| Robin_Watts | Selects the darker of the backdrop and source colors: | 18:11.57 |
| mvrhel | oh, in that case, we would be fine to overight | 18:13.03 |
| Robin_Watts | So the question is, where to put that in... | 18:13.35 |
| | pdf14_fill_path has code that sets up a new image state and calls the default fill path. | 18:14.06 |
| | and probably has all the information it needs. | 18:14.16 |
| | Would it be OK to add a check in there ,and to pass through without the new imager state if it was one of these special cases ? | 18:15.01 |
| mvrhel | does it eventually end up in mark_fill_rectangle but there may be multiple over prints correct? | 18:15.42 |
| Robin_Watts | Oh, pdf14_stroke_path I mean. | 18:15.49 |
| | pdf14_stroke_path ends up calling back to pdf14_fill_path | 18:16.10 |
| | and that goes down into the scan conversion code, which presumably calls mark_fill_rectangle, but with potential multiple overprints. | 18:16.43 |
| mvrhel | ok that would be fine if we have a cases where multiple overprints wont cause any effects | 18:17.38 |
| Robin_Watts | Darken is always fine for any value, right ? | 18:18.25 |
| | Yes, because it's idempotent. | 18:18.41 |
| mvrhel | I am not sure. does the alpha value have no effect with darken? | 18:19.05 |
| Robin_Watts | Darken with a solid alpha, sorry. | 18:19.17 |
| mvrhel | ok with a solid alpha yes I agree. but you have to worry about what the destination alpha is and you dont know what has already been drawn | 18:19.47 |
| Robin_Watts | dev->{opacity,shape,alpha} = 1 | 18:19.59 |
| mvrhel | but you have also the destination alpha to worry about too yes? | 18:20.19 |
| Robin_Watts | oh, so just checking the device alpha is not enough. Ass. | 18:20.29 |
| | I don't suppose you have a flag in the pdf14 device to mean "we know the destination alpha is all solid" ? | 18:21.32 |
| | presumably a lot of the time for pdf14 devices, that will be the case, right? | 18:22.08 |
| mvrhel | no, unfortunately there is not a flag for that | 18:22.24 |
| Robin_Watts | Could there be? | 18:22.34 |
| | Is that something that could be (cheaply) tracked ? | 18:22.46 |
| mvrhel | it would be hard I would think to do this | 18:22.48 |
| Robin_Watts | Presumably once the destination alpha is solid, it never becomes 'unsolid', right ? | 18:23.15 |
| mvrhel | true. but I would not want to put it in the low level mark_fill_rect stuff. I suppose you would throw the flag if you encountered any softmask and any changes to opacity that was not 1 | 18:24.30 |
| Robin_Watts | I wasn't thinking that you'd need to. | 18:24.50 |
| mvrhel | that would be at a sufficiently high level | 18:24.56 |
| Robin_Watts | I was thinking we'd set/unset it at pdf14 creation time, and never change it. | 18:25.14 |
| mvrhel | that is not possible | 18:25.41 |
| | when the pdf14 device is created you have not idea what is going to get sent to it | 18:25.56 |
| Robin_Watts | I might be way off here, but I thought that when we created a pdf14 device, we either created it with a solid alpha plane, or with a varying one. | 18:25.59 |
| mvrhel | no it is a blank slate | 18:26.15 |
| | you could have a soft mask coming or pretty much any drawing object with what ever alpha value | 18:26.36 |
| Robin_Watts | Ah, ok, so there is no easy way to know it's completely solid. Damn. | 18:26.37 |
| | So the alpha levels are initially 0, rather than 255. | 18:26.52 |
| | (i.e. transparent, not opaque) | 18:27.03 |
| mvrhel | right | 18:27.08 |
| Robin_Watts | Right, so ignore that idea then. | 18:27.15 |
| mvrhel | how hard is it to change the path code not to generate overlaps | 18:27.37 |
| Robin_Watts | Unless there is a very common case where pdf14 devices are often set to be entirely solid. | 18:27.38 |
| | mvrhel: Consider a self intersecting stroke. | 18:27.55 |
| mvrhel | yes | 18:28.03 |
| Robin_Watts | It's hard to make a single segment not overlap its neighbour at the endpoints with fill adjust. | 18:28.45 |
| mvrhel | right | 18:28.54 |
| Robin_Watts | It's impossible (practically) to stop a curve intersecting itself. | 18:29.02 |
| | It's even worse trying to make a whole path once stroked not intersect itself. | 18:29.16 |
| mvrhel | yes | 18:29.39 |
| Robin_Watts | So I fear we're stuffed here :( | 18:30.00 |
| mvrhel | sorry not to have a good answer on this one. | 18:30.54 |
| Robin_Watts | Before I give up on this... how can I find the pdf14 image buffers from a pdf14 device pointer? | 18:31.13 |
| | I want to view the alpha buffer in the memory window to convince myself it's not completely solid. | 18:31.34 |
| mvrhel | hold on | 18:31.42 |
| | pdf14_buf_new creates the buffer | 18:32.33 |
| | data is the member variable and the last plane in that is the "alpha" plane | 18:33.13 |
| | planestride * 4 if cmyk | 18:33.39 |
| Robin_Watts | I'm stopped in the debugger with a gx_device *dev | 18:33.40 |
| | Which is a gx_pdf14_device *dev really | 18:33.55 |
| mvrhel | put a break point in gdepp14.c at line 523 | 18:34.11 |
| | to catch the buffer creation | 18:34.23 |
| Robin_Watts | No, you misunderstand what I'm trying to do. | 18:34.26 |
| mvrhel | this is not a clist case is it? | 18:34.29 |
| | oh sorry | 18:34.32 |
| Robin_Watts | I'm not trying to catch the buffer when it's created. | 18:34.41 |
| | I'm trying to see the buffer as it is NOW. | 18:34.48 |
| mvrhel | ah | 18:34.52 |
| Robin_Watts | This is a clist case. | 18:34.55 |
| mvrhel | ok | 18:34.56 |
| | sorry | 18:34.58 |
| | oh are you clist reading now? | 18:35.04 |
| Robin_Watts | Yes. | 18:35.10 |
| mvrhel | ok | 18:35.12 |
| Robin_Watts | I have a pdf14gray device, in fact. | 18:35.20 |
| mvrhel | oh what is your target device | 18:35.35 |
| Robin_Watts | And the target device is an image1 | 18:35.57 |
| | (I'm going to tiffg4) | 18:36.09 |
| mvrhel | ok | 18:36.12 |
| | so you want tos->data | 18:36.51 |
| | ctx->stack->data | 18:37.11 |
| | actually | 18:37.14 |
| | oops | 18:38.08 |
| | dev->ctx->stack->data | 18:38.26 |
| Robin_Watts | Right. Full of 0's. | 18:38.35 |
| mvrhel | that should get you to the buffer | 18:38.40 |
| | ok | 18:38.43 |
| Robin_Watts | pdf14 data is planar ? | 18:39.33 |
| mvrhel | yes | 18:39.39 |
| Robin_Watts | And the alpha plane isn't the first one, right? | 18:39.44 |
| mvrhel | right. for the gray device it is the second one | 18:39.55 |
| Robin_Watts | So presumably I need some offset into ctx->stack->data | 18:40.02 |
| mvrhel | planestride | 18:40.10 |
| | dev->ctx->stack->planestrice | 18:40.23 |
| | dev->ctx->stack->planestride | 18:40.26 |
| | is your offset | 18:40.39 |
| Robin_Watts | Still all zeros. OK. I give up :) | 18:40.54 |
| mvrhel | right. when ever I dump and view the buffers, the alpha is zero where we have not drawn | 18:41.30 |
| Robin_Watts | Is there a command line flag to say -dNOTRANSPARENCY ? | 18:42.00 |
| mvrhel | yes | 18:42.22 |
| Robin_Watts | That makes it a lot faster :) | 18:42.50 |
| | henrys: Am I OK to resolve bug 692870 to WONTFIX ? | 18:47.01 |
| mvrhel | oh wait | 18:47.17 |
| | Robin_Watts | 18:47.21 |
| | I have one idea | 18:47.24 |
| Robin_Watts | waiting... | 18:47.26 |
| mvrhel | I am wondering if you could do the trick of pushing a new transparency group, and then drawing this as a knockout | 18:48.00 |
| | and the end the group. Like what I did for the stroke and fill command | 18:48.12 |
| | then overlaps will be fine as will all the overlaps from the fill adjust | 18:48.25 |
| Robin_Watts | I like the idea. I dislike your use of the word "you" :) | 18:48.26 |
| mvrhel | hehe | 18:48.29 |
| | ok well if you want to drop this on me, that is fine. I don't think it will take too long | 18:48.52 |
| | we need to understand when we should do this though | 18:49.29 |
| | can we always do it with strokes? | 18:49.56 |
| | I am trying to think why we would not | 18:50.25 |
| Robin_Watts | (on phone, sorry!) | 18:50.36 |
| mvrhel | no problem brb | 18:51.50 |
| | I need to step out for a minute | 19:01.42 |
| Robin_Watts | back. | 19:09.11 |
| | We could always do it for strokes. | 19:09.23 |
| | You mean "always do it for strokes within a pdf14 device" presumably. | 19:10.04 |
| mvrhel | ok I am back too | 19:14.11 |
| | Robin_Wattt: yes | 19:14.20 |
| Robin_Watts | There may be a downside to that for very short strokes. | 19:14.52 |
| mvrhel | Robin_Watts: is there any way to make a decision? | 19:15.12 |
| Robin_Watts | Without having done some measurements on both ways of working? | 19:15.33 |
| mvrhel | true. we can implement and see how it does | 19:15.53 |
| Robin_Watts | Not that my friday evening brain can immediately see. | 19:15.54 |
| mvrhel | and if we see issues we can figure out how to decide | 19:16.18 |
| Robin_Watts | If it was easy to code, then I'd be in favour of trying it, and maybe fiddling with some heuristics. | 19:16.21 |
| | yeah. | 19:16.30 |
| mvrhel | yes. I dont believe it will be too difficult (famous last words in ghostscript-land) | 19:16.45 |
| Robin_Watts | HowHardCanItBe(TM) | 19:17.04 |
| mvrhel | go ahead and hand the issue off to me. | 19:17.12 |
| Robin_Watts | Thanks. | 19:17.22 |
| mvrhel | I am going to get to a breaking point in this tiffsep stuff | 19:17.24 |
| | and then I will look at this trans stroke issue early next week | 19:17.42 |
| Robin_Watts | Thanks. | 19:19.52 |
| mvrhel | trying to figure out how to handle the "depth" for the tiffsep device | 19:21.25 |
| | tiffsep planar device | 19:21.32 |
| | there is going to be much confusion about this I fear in the code | 19:21.43 |
| Robin_Watts | depth ? | 19:21.43 |
| mvrhel | well right now it is 64 | 19:21.52 |
| | color_info->depth | 19:22.06 |
| Robin_Watts | Right. | 19:22.12 |
| | And you want to be able to have that > 64 ? | 19:22.21 |
| mvrhel | but really it is now going to depend upon the number of spot colors + cmyk | 19:22.21 |
| | yes | 19:22.27 |
| Robin_Watts | So... why can't you set it to num_planes * 8 ? | 19:22.48 |
| mvrhel | yes | 19:22.56 |
| | the thing is, there are some confusing things going on before I know all the spot colors | 19:23.20 |
| chrisl | Are you still going to reset it to the actual number of plates in force for the job? | 19:23.26 |
| Robin_Watts | Ah, so it might increase over time ? | 19:23.37 |
| mvrhel | well, no. we eventually do know before we start drawing | 19:23.57 |
| | at that time, I think we will be OK. just there are some funny things going on before we have that information | 19:24.19 |
| | for instance, for some reason the clist is trying to create planar buffers before I have this information. It does 2 calls to create them and then a third one that finally has the information I need. of course this is using the depth information which is wrong at the time. | 19:25.19 |
| Robin_Watts | Right, so it will increase during setup, but then be static during drawing. | 19:25.38 |
| mvrhel | yes | 19:25.49 |
| Robin_Watts | ah. clist. Might have guessed :) | 19:25.49 |
| | Why is clist creating planar buffers? | 19:26.04 |
| mvrhel | because the tiffsep wants planar buffers. it is the clist that does this during playback | 19:26.25 |
| | the clist is also planar | 19:26.33 |
| | since the tiffsep device is planar | 19:26.39 |
| | anyway. I need to step out for 30 minutes for lunch. supposed to meet stephanie.... | 19:27.06 |
| Robin_Watts | planar targets cause planar clists, right. I remember us (you) changing that. | 19:27.08 |
| mvrhel | already late... | 19:27.11 |
| Robin_Watts | OK. ttyl. | 19:27.16 |
| marcosw | chrisl: your cluster run is failing to compile on the MacPro, it should be sending out an email with the error but it needs to time out. | 19:47.47 |
| chrisl | marcosw: the one that's running now? The one before failed because of the memento hiccup | 19:48.27 |
| marcosw | I think it's still having the same problem. | 19:48.44 |
| | gcc -m64 -DHAVE_MKSTEMP -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_BSWAP32 -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long int" -I./obj -I./base -DWHICH_CMS="lcms2"= -o ./obj/memento.o -c ./base/memento.c | 19:49.26 |
| | ./base/memento.c:39: error: expected declaration specifiers or '...' before numeric constant | 19:49.26 |
| | ./base/memento.c:39: error: expected ')' before '!=' token | 19:49.27 |
| | ./base/memento.c:39: error: expected ')' before '?' token | 19:49.27 |
| | make: *** [obj/memento.o] Error 1 | 19:49.27 |
| chrisl | Well, my tree is tree is up to date, and memento.c got pushed up to the cluster...... | 19:50.06 |
| marcosw | the timestamp on the file on MacPro seems correct: | 19:50.42 |
| | 80 -rwxrwxr-x 1 marcosw staff 39343 Mar 9 12:37 base//memento.c* | 19:50.46 |
| | that's 13 minutes ago. | 19:50.54 |
| Robin_Watts | grep memento.c for MEMENTO_GS_HACKS ? | 19:51.54 |
| marcosw | #if defined(__linux__) | 19:52.17 |
| | #define MEMENTO_HAS_FORK | 19:52.17 |
| | #elif defined(__APPLE__) && defined(__MACH__) | 19:52.17 |
| | #define MEMENTO_HAS_FORK | 19:52.17 |
| | #endif | 19:52.18 |
| | sorry, | 19:52.29 |
| | #ifdef MEMENTO_GS_HACKS | 19:52.35 |
| | #include "valgrind.h" | 19:52.36 |
| | #else | 19:52.36 |
| | ... | 19:52.36 |
| Robin_Watts | I see 1 #define MEMENTO_GS_HACKS and 3 #ifdef MEMENTO_GS_HACKS | 19:53.53 |
| | And that's all. | 19:53.56 |
| chrisl | Yes, that's what I see in my local copy | 19:54.13 |
| Robin_Watts | I was hoping marcosw would see the same... | 19:54.26 |
| marcosw | the memento.c in chrisl's directory appears to be the same on as in the git repository | 19:54.40 |
| | marcosw@macpro:[23]% grep MEMENTO_GS_HACK base/memento.c | 19:54.42 |
| | #define MEMENTO_GS_HACKS | 19:54.42 |
| | #ifdef MEMENTO_GS_HACKS | 19:54.43 |
| | marcosw@macpro:[24]% | 19:54.43 |
| Robin_Watts | spot on. | 19:54.49 |
| | So those compile errors are hopefully from the old run ? | 19:55.08 |
| marcosw | I'm trying a make clean | 19:55.16 |
| | which shouldn't work, since the cluster code does that as well. | 19:55.31 |
| chrisl | Builds fine here. | 19:56.45 |
| marcosw | under Mac OS X? | 19:56.57 |
| chrisl | No, Linux - my Mac isn't on just now | 19:57.36 |
| marcosw | the linux versions build fine on the cluster as well; it's only the macpro which is failing. | 19:57.57 |
| | my manual build fails as well. you could just down the macpro on the cluster dashboard and launch your clusterpush | 19:58.53 |
| henrys | why didn't this fail upon Robin_Watts' commit? | 19:59.23 |
| marcosw | henrys: I was just trying to figure that out. | 19:59.44 |
| chrisl | Hmm, I can't disable nodes, I get an error....... | 19:59.48 |
| Robin_Watts | CLUSTER_UNTESTED | 20:00.00 |
| | This shouldn't be able to affect non memento builds. | 20:00.12 |
| henrys | ah | 20:00.24 |
| marcosw | I've owned the macpro manually until we get this sorted. | 20:00.51 |
| | ^owned^downed | 20:00.58 |
| Robin_Watts | thought marcosw was being all l33t. | 20:01.14 |
| chrisl | So I can push now? | 20:01.29 |
| marcosw | yes. | 20:01.34 |
| chrisl | This won't take long - gs and lowres only | 20:01.51 |
| marcosw | we'll have to leave the macpro down until this is fixed, since git commit cluster runs will fail until this is resolved. | 20:02.47 |
| | bbiab | 20:03.17 |
| Robin_Watts | Can you get the compile error ? | 20:03.37 |
| | Oh, I see the problem. | 20:04.43 |
| | Fix pushed. Sorry about that. | 20:13.33 |
| chrisl | I'm just relieved it wasn't me! I'd forgotten I'd pulled in updates earlier, tbh | 20:15.14 |
| | Well, I'm too tired to carry on - 'night all....... | 20:27.50 |
| DrZimmerman | hello everyone | 20:51.25 |
| | i just scanned 10 pages of A4 and after converting from pnm to ps to pdf the resulting file was 7.9mb | 20:52.39 |
| | at my former workplace we had a xerox workcenter which did like 10 pages in 800kb, what does the xerox do differently? | 20:53.22 |
| | why can't i achieve the same with ghostscript? | 20:53.33 |
| Robin_Watts | What compression are you using in the pdf ? | 20:53.48 |
| DrZimmerman | if tried in the last 2 hours endless different options and never achieve something below these 7.9mb | 20:53.54 |
| | i have no clue, the one gs, respectively the ps2pdf and pdf2ps scripts use | 20:54.15 |
| Robin_Watts | When you scanned, did you scan in rgb or greyscale or monochrome? | 20:54.27 |
| | And at what resolution did you scan ? | 20:54.45 |
| DrZimmerman | rgb at 300dpi, ppi or whatever | 20:55.15 |
| | with xsane | 20:55.17 |
| Robin_Watts | And you're scanning colour documents? | 20:55.41 |
| DrZimmerman | both, colored and non colored (things written with crayon) | 20:56.09 |
| Robin_Watts | Well, it's possible that the xerox is being smart and spotting colored/non-colored things and adjusting accordingly. | 20:56.41 |
| | It's also possibly applying some filtering to the scanned output to reduce noise, which will make the data much more compressible. | 20:57.47 |
| DrZimmerman | ok | 20:58.53 |
| Robin_Watts | Ghostscript will never throw away data; it performs losslessly. | 20:59.04 |
| | So the Xerox thing may be using jpeg based compression, where we won't. | 20:59.18 |
| DrZimmerman | when i zoom one of these xerox pdf it looks like they got converted into some vector graphics, because when i look to an M letter the stright lines are not straight like normal but the have little stairs, or so, dunno how to describe it | 21:00.18 |
| Robin_Watts | sounds like bitmaps to me. | 21:00.45 |
| DrZimmerman | i dunno | 21:01.17 |
| | is there a way to take pdf's apart and figure out how their built? | 21:01.34 |
| Robin_Watts | Yes. | 21:01.48 |
| DrZimmerman | cool, but how? | 21:02.08 |
| Robin_Watts | I generally do it by loading it into a text editor and looking. | 21:02.11 |
| DrZimmerman | ok | 21:02.17 |
| | i hoped for a more "automated" way :-) | 21:02.32 |
| Robin_Watts | but you need to know a certain amount about the PDF format to do that. | 21:02.41 |
| DrZimmerman | of course theirs a catch to it :-) | 21:03.09 |
| Robin_Watts | gotta go. | 21:03.23 |
| DrZimmerman | bye | 21:04.02 |
| | thanks | 21:04.04 |
| henrys | DrZimmerman:you can try pdfedit: http://www.jpedal.org/PDFblog/2010/09/useful-pdf-tools-pdfedit/ | 21:06.02 |
| DrZimmerman | thx henrys, but i don't find pdfedit in gentoo's repository | 21:14.46 |
| | i looked trough one of the ghostscript pdf's and one of the xerox one's, what i saw was that the xerox pdf has a lot of /FlateDecode and /JBIG2Decode before streams | 21:16.04 |
| henrys | how exactly are you producing the pdf? command line? | 21:19.20 |
| DrZimmerman | i'm scanning them with xsane into a multipageproject and save them as ps, then i convert them to pdf, but dunno which command line produced the 7.9mb file, i've used so many different command lines | 21:29.10 |
| | have to go, good night | 21:29.19 |
| mvrhel | Robin_Watts: you there? | 21:51.47 |
| | question about planar buffer creation.... | 21:52.20 |
| | I am guessing that you (as you should be) are done for the day..... | 21:53.59 |
| | I am getting a bit confused about this..... | 22:00.26 |
| drac_boy | hi | 22:39.07 |
| | don't mean anything against the team that probably wrote the html documents but hmm just wondering how come they wrote a good lengthy page on how to make it but theres no mention of needed deps outside autoconf being mentioned? | 22:40.43 |
| | to 'make'* | 22:40.59 |
| | Forward 1 day (to 2012/03/10)>>> | |
IRC Logs