| <<<Back 1 day (to 2013/03/25) | 2013/03/26 |
Black_Knight | is this open for asking questions? | 00:38.29 |
Robin_Watts | It is. | 00:40.42 |
| This is irc, don't ask to ask, just ask. And be prepared to hang around for answers, as timezones may not be in your favour. | 00:41.17 |
Black_Knight | I installed gs 9.07 by wget the the tar. but when i check the version it still shows the 9.05 from the apt-get install ghostscript | 00:42.02 |
| any idea what I am doing wrong? | 00:42.12 |
Robin_Watts | Black_Knight: I suspect it's a question of paths etc on your installation. | 00:42.45 |
| You've got the source, then built using what? make? or make install ? | 00:42.57 |
Black_Knight | yes make and make install | 00:43.13 |
| i had to sudo it though | 00:43.20 |
Robin_Watts | OK. | 00:43.27 |
Black_Knight | could that be the issue? | 00:43.28 |
Robin_Watts | no, that sounds reasonable, as to make install, it copies the binaries into system wide accessible directories. | 00:43.56 |
| It probably copies them to /usr/bin/ or something. | 00:44.11 |
alexcher | Black_Knight: Use 'which gs' to check which version is in the path. | 00:44.14 |
Black_Knight | it is /usr/bin/gs | 00:44.33 |
Robin_Watts | and you probably have another gs somewhere else in your path, in a directory that comes before /usr/bin | 00:44.41 |
| ls -al /usr/bin/gs | 00:44.56 |
Black_Knight | -rwxr-xr-x 1 root root 5524 Sep 8 2012 /usr/bin/gs | 00:45.17 |
| the crazy thing is that i cannot find 9.07 even if i use locate ghostscript | 00:45.54 |
| it is kinda insane | 00:45.59 |
Robin_Watts | locate won't find it until the database updates, right? And that's once a night. | 00:46.28 |
Black_Knight | hmm no it should be effective immedialtely | 00:46.58 |
Robin_Watts | Well, you want "locate gs", right? | 00:47.17 |
alexcher | find /usr/local -name gs | 00:47.22 |
Robin_Watts | alexcher: Where does make install put the binary? | 00:47.40 |
Black_Knight | alexcher: no results | 00:48.24 |
alexcher | find / -name gs 2>/dev/null | 00:49.24 |
| Robin_Watts: I thought, /usr/local/bin/gs but I don't install gs often. | 00:49.53 |
Robin_Watts | alexcher: Me either. | 00:50.03 |
Black_Knight | ok its /usr/bin/gs | 00:50.23 |
| but there are no files there | 00:51.05 |
Robin_Watts | /usr/bin/gs has a date of Sep 8 2012. I don't believe that's the one you built today :) | 00:51.12 |
| Also 5524 bytes is WAY too small :) | 00:51.28 |
Black_Knight | ahhh good catch | 00:51.33 |
Robin_Watts | make install seems to copy to $(DESTDIR)$(bindir)/$(GS) | 00:52.20 |
| but I can't see where DESTDIR is defined. | 00:52.31 |
Black_Knight | i just dont get why even if i do locate gs and look thru everything that it returns i find only gs 9.05 | 00:52.37 |
| and there isnt any way to get 9.07 with apt-get yet right? | 00:53.05 |
Robin_Watts | /usr/local/bin/gs, I think is where it should be. | 00:53.38 |
| Black_Knight: That's one to ask your distro maintainers. | 00:53.47 |
| Black_Knight: Do: ls -al /usr/local/bin/gs | 00:53.57 |
Black_Knight | ok i will keep messing with the | 00:54.01 |
alexcher | Black_Knight: By default, the prefix is /usr/local I've just tried this. | 00:56.11 |
Robin_Watts | Do you have a /usr/local dir? | 00:56.32 |
Black_Knight | i actaully was able to get the newest version on another server and working. it is located at /usr/share/ghostscript | 00:56.57 |
| yea i have usr/local/bin/ | 00:57.35 |
alexcher | Black_Knight: Try to install gs again and save the logs. | 00:59.02 |
Black_Knight | ok i will give that a shot | 00:59.24 |
| on the one server that is working i have /usr/local/share/ghostscript | 00:59.52 |
| but not on the other one | 01:00.42 |
| i will do as you said and start over | 01:00.50 |
Robin_Watts | It depends on how 'install' is setup to work. | 01:00.57 |
| If you're just doing a standard build, then you'll find the binary in the 'bin' directory where you're building. | 01:01.21 |
Robin_Watts | heads to bed. 1am here. Good luck. Come back in about 8 hours to speak to chrisl who may know more. | 01:01.58 |
Black_Knight | ok thanks | 01:02.08 |
kens | Morning tor8 | 11:03.17 |
| I've just sent a bug your way, but I'd be perfectly happy to see it closed as wontfix | 11:03.35 |
tor8 | we generally do test if transparency is actually used (alpha < 1) before turning on the pdf transparency when parsing xps | 11:06.37 |
kens | tor8 oh well maybe you want to look at teh file then, it didn't 'seem' to use any transparency, but I could easily be wrong | 11:07.05 |
| Certainly it is pushing the pdf14 compositor a lot | 11:07.18 |
tor8 | I can take a look at the file, there may be some easy pickings in that detection but I'm not hopeful | 11:07.25 |
kens | Like I said, I'm not that bothered myself, its XPS after all.... | 11:07.48 |
tor8 | odd. never seen unzip say this before: "skipping: [Content_Types].xml/[0].piece need PK compat. v4.5 (can do v2.1)" | 11:08.41 |
kens | That's a new one on me | 11:09.00 |
| gxps read the file OK though | 11:09.09 |
tor8 | my guess: 64-bit long-file version of the zip format | 11:11.14 |
kens | AH, never thought of that, you're probably correct | 11:11.31 |
tor8 | which unzip can't handle but xps can... hm, or is that only muxps? | 11:11.37 |
kens | The Windows XPS viewer can :L-) | 11:11.54 |
| gxps is OK with it too | 11:12.09 |
tor8 | kens: I'm not worried about the file. the underlines on the page are done with gradients that have transparency. | 11:23.02 |
kens | tor8 well that explains it then | 11:23.18 |
tor8 | that's why we create an obscene amount of transparency groups, since each one needs two pdf shadings | 11:23.24 |
| one for the opacity mask, and one for the color | 11:23.30 |
kens | Right, we certainly end up with an enormous amount of them. I could probably be cleverer in pdfwrite and spot the duplication, they are all exactly the same I think | 11:24.02 |
| But to be honest, I can't really be bothered. | 11:24.17 |
| I suppose I should look at the output form the printer driver, I guess its converted those to images | 11:24.39 |
tor8 | I wouldn't bother either | 11:25.10 |
kens | ROFL If I uncompress the printer driver file it comes out at 6.4 Mb. I bet its almost all image data | 11:25.51 |
tor8 | converting a shading with transparency to an image sounds like a better approach if possible | 11:26.05 |
kens | Depends on what it is you want. In PDF you wouldnt' want to do that | 11:26.30 |
tor8 | you can't really spot that they're identical, since in the input xps they are all different brushes with different coordinates | 11:26.57 |
| not the same brush placed with a transform | 11:27.05 |
kens | Sure, but the SMasks are all the same | 11:27.12 |
| I don't need to write thousands of the same thing all the time | 11:27.23 |
| Can't do much about the forms though (which is where the brush data is) | 11:27.38 |
tor8 | the SMasks are also gradients, but if they come out as the same image on the back end that might be detectable | 11:27.43 |
kens | Exactly so | 11:27.53 |
| THere is quite a bit of inline image data in the file that came through the printer driver. I'm guessing that the XPS pritn code has rendered the transparency | 11:28.44 |
| All the images seem to be one lin high in the output, but scaled to 83 | 11:29.20 |
| Oh no, thay are all sorts of different sizes. | 11:29.48 |
| OK do you want to comment on the thread, or shall I ? | 11:29.58 |
tor8 | I'll do it if you wish | 11:30.37 |
kens | Please I think I;ve sadi enough there already ;-) I would close it as wontfix myself, stupid ifle in gives stupid file out | 11:31.10 |
tor8 | kens: do you always convert smasks to images in pdfwrite? | 11:33.05 |
| I would have imagined there being some way to keep them as vectors | 11:33.22 |
kens | tor8 I woudl expcet that we would too, do you see that we don't ? | 11:36.59 |
tor8 | kens: oh, I haven't actually looked at the gxps output of it :) | 11:37.30 |
| I just misunderstood something you said earlier | 11:37.51 |
kens | The reason the gxps daya is large is because fo the thousands of ExtGStates and forms in it | 11:37.55 |
tor8 | yeah. | 11:38.18 |
| I've written a comment and closed as WONTFIX. | 11:38.28 |
kens | because of the pushp/pop transparency that's going on, there are 90 pages of transparecny and each one has several lines of this stuff.... | 11:38.32 |
| OK thanks tor8 | 11:38.39 |
tor8 | it feels good to have been involved in the ghost side of things for a bit :) it's such a rare occasion! | 11:41.27 |
kens | :-) Like I said in the bug thread its been nearly 3 years since anyone raised a bug report with XPS and pdfwrite, and pdfwrite seems to be the most active use for gxps right now.... | 11:42.09 |
tor8 | Robin_Watts: minor fix on tor/master | 11:51.07 |
Robin_Watts | tor8: looks fine. | 12:25.47 |
tor8 | Robin_Watts: only one gripe I had with the reflow branch ... the code duplication in one of the commits | 12:26.50 |
Robin_Watts | tor8: the bullet point stuff. | 12:27.04 |
| I'll see if I can factor some of that out. | 12:27.10 |
| I brought my pdfwrite branch up to date yesterday. | 12:27.55 |
| tor8: Which bit did you think was duplicated? | 12:31.51 |
tor8 | the bullet detection | 12:32.06 |
Robin_Watts | ah, I see. | 12:32.38 |
tor8 | "first span a ruoman numeral?" | 12:32.40 |
| maybe we should have a basic pattern matcher in there, which would be useful for text search as well | 12:33.07 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=127e859af20fd57205a4c8cf01b29f752fc89696 | 13:21.19 |
| better? | 13:21.20 |
| In fact: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=afe9d5b08de756003bd9654861773db8e142b210 | 13:23.43 |
| fixed a comment. | 13:23.47 |
| Now to brave the waters of pcl to look at henrys latest. | 13:25.07 |
henrys | thanks for having a look good point. | 13:37.22 |
Robin_Watts | henrys: coo, early morning henrys. | 13:37.59 |
| Too hungry to sleep? :) | 13:38.11 |
henrys | my training group has 7:00 am workouts now on saturday and sunday so it's changed my schedule a bit. | 13:39.25 |
Robin_Watts | 2 less workouts to go to a week, then :) | 13:40.02 |
henrys | Robin_Watts: yesterday was a fast day though. Sabrina is going to stick with 2 days I'm thinking of going back to 1. | 13:42.37 |
paulgardiner | henrys: you and Sabrina sleep any better this time? | 13:43.30 |
henrys | paulgardiner: sabrina sleeps well I don't, a complete turnaround of the normal situation. | 13:44.06 |
paulgardiner | Interesting. I didn't sleep too well either. I was hoping my body had gotten used to the fasting, but not yet, I guess. | 13:45.13 |
tor8 | Robin_Watts: much better, thanks. | 13:55.30 |
Robin_Watts | tor8: will puah it then. Have you pushed yours? | 13:55.52 |
| If not, I will do that too. | 13:55.56 |
| s/puah/push/ | 13:56.04 |
tor8 | I have not yet | 13:56.14 |
Robin_Watts | pushed | 13:59.18 |
| tor8: I think the first commit on my pdfwrite branch is good to go. | 14:01.39 |
tor8 | the function one? yeah. I reviewed that one ages ago, but we've held off on pushing to master. feel free to drop it in. | 14:02.40 |
Robin_Watts | ok. | 14:02.47 |
| thanks. | 14:02.52 |
henrys | sigh I've found more fallout from the dreaded indent. As I recall the same thing happened when we did this in gs, so I shouldn't be surprised. | 14:03.50 |
Robin_Watts | I've lost track of timezones. Meeting in 13 mins? | 14:48.13 |
kens | yes MuPDF | 14:48.23 |
henrys | right | 14:48.27 |
Robin_Watts | clocks change here this weekend, so I think we'll be back to normal next week. | 14:48.29 |
kens | correct | 14:48.38 |
henrys | there must be an option for git pull that shows what files are being updated ... | 14:51.48 |
Robin_Watts | henrys: git pull doesn't "update files". It pulls in a series of new commits to the state tree. | 14:52.55 |
| There is no "diff" stage like there is with SVN etc. each commit is entirely separate. | 14:53.14 |
| hence it's not a natural thing to display "changed files" | 14:53.27 |
paulgardiner | Is that quite true. True of fetch, but I thought fetch also did a merge which will update your local files. | 14:53.51 |
| s/2nd fetch/pull | 14:54.06 |
| s#pull#pull/# ... I should give up now. | 14:54.30 |
Robin_Watts | yes, fair enough. probably a rebase, but true enough. | 14:54.55 |
| But I think git pull --rebase displays exactly the same messages for the rebase stage as a manual rebase would. | 14:55.17 |
paulgardiner | That's part of the reason I use fetch so that I can have a look at what's come in before deciding what to do with it. | 14:55.37 |
Robin_Watts | so the question might be "there must be an option for git rebase that shows what files are being updated..." | 14:55.51 |
henrys | well yes git pull --rebase | 14:56.02 |
Robin_Watts | -v ? | 14:56.34 |
henrys | I think -v is it. | 14:57.37 |
| well what I wanted | 14:57.41 |
| paulgardiner: report looks good as usual - a time estimate on digital signatures - probably be a good demo stuff for Robin_Watts | 14:59.05 |
| at his android show. | 14:59.14 |
| tor8:I passed off the localization stuff to you but didn't hear anything back. | 15:00.59 |
paulgardiner | I'm not quite at the level of understanding where I can really give an estimate. I've read more since the report and it's looking a bit more complicated than I thought. | 15:00.59 |
| As ever, it depends on how much coverage of features we need. | 15:01.21 |
| When's the show? | 15:01.33 |
Robin_Watts | 9 weeks. | 15:01.42 |
| or so | 15:01.58 |
paulgardiner | Ah right. I'm sure we can demonstrage something by then. | 15:02.12 |
| The more I look into it, the more I think we'll need to use OpenSSL, not nesessarily make the MuPDF library rely on it, but at least any MuPDF apps that want to check or create signatures. | 15:03.50 |
henrys | paulgardiner: what's the license? | 15:04.23 |
Robin_Watts | paulgardiner: What functions are required? | 15:04.33 |
paulgardiner | Or we can write our own algorithms, but that's going to yield demonstratable results much later | 15:04.34 |
| License is Apache | 15:04.47 |
Robin_Watts | When we've needed crypt stuff before we've found BSD implementations we can use (RC4, MD5 etc) | 15:05.24 |
paulgardiner | Robin_Watts: not completely sure, but it invovles RSA encryption, DSR encoding (which is ASN1 based - we've ben there haven't we! ), certificate chains etc, | 15:05.49 |
Robin_Watts | no. *you've* been there :) | 15:06.05 |
| I stayed well away from ASN1 :) | 15:06.13 |
henrys | paulgardiner: I hope there are no patents | 15:06.26 |
paulgardiner | No, no, I'm sure you did it!! :-) | 15:06.35 |
| henrys: They have a README and that lists patents. And they mention a config that avoids inclusion of some modules, but are careful to avoid promising that that makes you safe. | 15:08.39 |
henrys | paulgardiner: right but does adobe require one of those patented algorithms for anything with signatures? | 15:09.29 |
paulgardiner | Not yet clear. | 15:10.05 |
henrys | no word from ubuntu I assume, but I think the sooner we can start the printing project the better. | 15:10.29 |
Robin_Watts | henrys: No word, no. | 15:10.43 |
henrys | thoughts? | 15:10.44 |
Robin_Watts | The immediate job required for printing from mupdf are bitmap -> PS and bitmap -> PCL and bitmap -> PXL filters. | 15:11.42 |
| tkamppeter was going to hawk those out to GSoC people. | 15:12.09 |
| I spent some time bringing the pdfwrite device (so far) up to the current HEAD. | 15:12.47 |
paulgardiner | Robin_Watts: I was intending to look into cloud-based printing (where perhaps one can just send a PDF file), but I haven't yet found time. That's was mainly for the Android app though. | 15:12.49 |
henrys | Robin_Watts: I'd really rather pay sebras or somebody if they're interested in doing the work. | 15:13.10 |
paulgardiner | Robin_Watts: I'm probably talking about different aims that what you refer to. | 15:13.30 |
Robin_Watts | but I've been distracted this week by our mupdf customer finding some problems which I've fixed. | 15:13.37 |
henrys | paid folks are more apt to readily support their work. | 15:13.37 |
Robin_Watts | henrys: GSoC folks are paid too. | 15:13.56 |
| and they only get paid if what they write is of suitable standard etc. | 15:14.23 |
paulgardiner | henrys: apparently RSA was patented by MIT, but they've waived their rights. | 15:14.35 |
mvrhel_laptop | henrys: I will take a look at the color in mupdf this week. maybe I should start an icc branch in my repo | 15:14.59 |
| still plugging along on the windows app. I was hoping to get almost done with it this week but I suspect it may be into next week | 15:15.50 |
henrys | Robin_Watts: fair enough - I do see it as inferior to us having a direct relationship with the developer. | 15:16.05 |
Robin_Watts | henrys: Well, it doesn't preclude us forming a relationship with that developer. | 15:16.31 |
henrys | mvrhel_laptop: I think that's a good idea. | 15:16.31 |
mvrhel_laptop | I did have a VP from microsoft (whose daughter is on my daughters softball team) tell me that the native viewer is slow and he wants to know when our app is available... | 15:16.47 |
Robin_Watts | I mean, if sebras or zeniko *want* to do it, then great. | 15:16.52 |
| mvrhel_laptop: Nice! | 15:17.15 |
henrys | the only other item on my list was making mupdf more like a documented graphics library competing with cairo and say quartz but I'll wait for tor8. | 15:18.45 |
| Robin_Watts:I'll ask sebras, if no then zeniko, if no then GSoC | 15:20.39 |
Robin_Watts | henrys: I ran through the agenda earlier, and we have 3 background projects on mupdf now; svgin, pdfout, and the documented graphics lib. | 15:20.49 |
| pdfout is higher priority now, right? | 15:20.57 |
| I think we also had svgout as a background project at one stage. | 15:21.09 |
| the "documented graphics lib" I've got on my list here as "mucanvas". | 15:21.25 |
| I also have a work in progress branch for making it so that mupdf can read a file as it's still being downloaded. | 15:22.04 |
| seems to work, but it's not hugely pretty, | 15:22.24 |
henrys | It's hard to say how important pdfout is without paulgardiner investigating printing project done. Would PS output be more valuable than PS? - I don't know | 15:22.50 |
| s/PS/PDF | 15:23.07 |
kens | I htink PDF out is a better option | 15:23.35 |
Robin_Watts | for the printing project, the way we were planning to get PS out was to render to a bitmap, then wrap that bitmap (in bands) as PS. | 15:23.37 |
paulgardiner | henrys: yeah, I'll get on to that. | 15:23.53 |
Robin_Watts | That way we have a very simple stream that hopefully can be sent to any PS printer. | 15:24.06 |
kens | has sopme doubts | 15:24.15 |
Robin_Watts | Surely no PS printer out there can fail to cope with just bitmaps, right? | 15:24.27 |
kens | Robin Watts we had one that failed on CCITT G4 fax compression | 15:24.47 |
henrys | looks at the 1200 dpi HP color laser jet and scratches his head. | 15:24.58 |
kens | and another that didn't like a filter chain | 15:24.58 |
Robin_Watts | (of course, there is the fact that we need a level 3 printer to do deep color images, unless we do horrible repeated masks etc) | 15:25.02 |
kens | deep colour ? | 15:25.19 |
Robin_Watts | kens: IIRC (and this is going back a bit) with PS level 2, we are limited to indexed color images, right? (so 256 colors max). | 15:25.53 |
kens | No. | 15:25.59 |
| that's a level 1 limit | 15:26.23 |
Robin_Watts | Ah, ok. Shows how far I was thinking back :) | 15:26.35 |
kens | You cna have 24 or 32-bits (RGB or CMYK) | 15:26.37 |
| and need not have indexed colour representation | 15:26.50 |
| Actually that's a level '1 and a bit' limit | 15:26.59 |
| Because level 1 was gray only | 15:27.08 |
henrys | maybe the mobile printing investigation should come before signatures. | 15:27.15 |
paulgardiner | henrys: yes sure | 15:27.38 |
Robin_Watts | So, if we can assume that we have 1 and a bit, we can produce some very simple files (no massive sets of binds etc). | 15:27.56 |
henrys | paulgardiner: I think you'll still make the demo | 15:27.57 |
kens | I think you can safely assume level 2 | 15:28.09 |
| So 8/24/32 images | 15:28.24 |
Robin_Watts | Judging from the last show, people were most interested in seeing our render speed. I can't imagine there will be too many people massively worried about seeing digitial signatures being demoed. | 15:28.43 |
henrys | Robin_Watts: is it straightforward to output high level pdf in mupdf today? | 15:28.53 |
Robin_Watts | henrys: As I say, I have a work in progress branch. | 15:29.14 |
kens | I ouwld guess that print is more important than digital signatures | 15:29.16 |
Robin_Watts | Things like tiger work fine. | 15:29.23 |
| I don't deal with embedding new images/new fonts etc, and clip support isn't done yet. | 15:29.49 |
henrys | perhaps I asked this before: why not the ps2write procset bolted on and we're done. | 15:29.56 |
| ? | 15:30.00 |
Robin_Watts | but the structure is there. | 15:30.03 |
| henrys: I'm unfamiliar with the ps2write procset. But how does that cope with transparency etc? | 15:30.38 |
| blend modes. | 15:30.43 |
paulgardiner | henrys, Robin_Watts: Presumably, for printing of PDF documents from MuPDF, we don't need pdfout - just send the original file or a saved one if we've made changes. | 15:31.00 |
Robin_Watts | paulgardiner: If the print system accepts pdf, (and your input document is PDF :) ) yes. | 15:31.29 |
kens | Robin_Watts : p[s2write flattens trasnparency | 15:31.39 |
henrys | paulgardiner: yes but I was trying to think of a way to get nice high level postscript | 15:31.45 |
| kens:yes but the procset itself doesn't right? | 15:32.02 |
Robin_Watts | henrys: We *could* write a high level PS output device. | 15:32.15 |
| That's easy enough to do, except for the falling back to bitmaps for transparent areas. | 15:32.46 |
| which isn't amazingly hard. | 15:32.52 |
| (famous last words) | 15:33.05 |
henrys | you took the words from my mouth | 15:33.25 |
Robin_Watts | But, it seems to me, that for what tkamppeter needs, a bitmap -> PS wrapper is better. | 15:33.47 |
| Simpler output overall, less chance of hitting printer bugs, more consistent rendering etc. | 15:34.24 |
paulgardiner | During the meeting someone - I can't remember who - said that the way printing was going was you just send the file, be it PDF, Word Excel... I think. | 15:34.35 |
Robin_Watts | The downside is that the files are probably going to be larger. | 15:34.39 |
kens | henrys no, the opdfread procset does not handle transparency | 15:34.48 |
henrys | true - you could also do something as crazy as pswrite. | 15:34.50 |
Robin_Watts | paulgardiner: Some print solutions are going that way, yes. Presumably to keep data transfer sizes down. | 15:35.16 |
kens | For printing the bitmap optionis probably fine | 15:35.18 |
henrys | kens:yeah I didn't think so. next question is does it matter. mobile phone users - low level business graphics .... | 15:35.47 |
Robin_Watts | As a sidenote to this, tkamppeter was also interested in whether a 'bitmap wrapped as PS' device (psimgwrite?) would be possible for gs. | 15:35.58 |
kens | henrys XPS ? | 15:36.06 |
| Robin_Watts : yes trivial | 15:36.19 |
| Also slow, large | 15:36.31 |
Robin_Watts | kens: Well, I think tkamppeter was interested in putting that out for a GSoC thing too. | 15:36.40 |
kens | Can't go back to editable PDF etc | 15:36.43 |
| Robin_Watts : for a printing solution its no problem at all | 15:36.53 |
Robin_Watts | tkamppeter: If you're here, please feel free to join in. | 15:36.57 |
kens | very easy to make that work | 15:37.07 |
Robin_Watts | exactly, just for printing (which frankly is I think most of what PS is used for these days) | 15:37.18 |
henrys | well let's wrap up here and continue this thread with tkamppeter and tor8 when we can during the week. | 15:38.06 |
kens | Robin_Watts : lot of people using it to get a PDF file it seems | 15:38.18 |
| judging by my mailbag | 15:38.25 |
ray_laptop | Robin_Watts: the problem with a full page PS image is that some printers can't handle it, at least at full device res. | 15:38.29 |
Robin_Watts | using what? | 15:38.38 |
henrys | ray_laptop:we were discussing bands. | 15:38.56 |
kens | Robin_Watts : doesn't matter really, some printers handle large images badly | 15:39.00 |
ray_laptop | and often a full page full res bitmap on a PS printer will be slow. | 15:39.09 |
kens | Strips might work, as long as the printer butts tehm up properly (se our white lines issues) | 15:39.25 |
ray_laptop | henrys: I was commenting on an earlier comment from Robin_Watts about a PS wrapper on a bitmap | 15:39.27 |
kens | I did say slow and large earlier too :-) | 15:40.01 |
henrys | oh I thought that was in bands, ray_laptop. Even so not clear if that will be good on the printer. | 15:40.08 |
| still a lot of raster. | 15:40.18 |
| pswrite performs much better on my 4600 than the ghostscript raster driver. | 15:40.52 |
| so maybe something like that is a good approach. | 15:41.08 |
Robin_Watts | henrys: I was hoping that if we worked in bands at native printer res, the white lines problems ought to be sorted. | 15:41.11 |
ray_laptop | yep. and the even if you send bands the printer still won't start printing until you send the 'showpage' so it has to store it all anyway | 15:41.15 |
kens | pswrite is not a bitmap as a PS file | 15:41.33 |
| which supports Ray's case | 15:41.42 |
henrys | yes I'm thinking pswrite might be a good alternative to a raster here. | 15:41.56 |
kens | I woudl say iof you are going that far, go whole hog | 15:42.11 |
| Either do raster or not, halfway house is worst of both | 15:42.22 |
Robin_Watts | ray_laptop: Sending bands means that the printer has to hold "a full page bitmap" (which presumably it holds anyway), plus the current image it's working with. In the case of a band sized image, that's smaller than a full page one. | 15:42.23 |
ray_laptop | kens: right, it isn't. It sends some stuff as real PS. It just dodges the text issue by sending text as images | 15:42.28 |
Robin_Watts | I think we code the raster version first, because it's easy. If we need the full version later, well, we can do that. | 15:42.59 |
henrys | the whole hog gets into broken printer problems - by and large pswrite is drop dead simple - hard to imagine a printer screwing that up unless it runs out of memory. | 15:43.06 |
kens | ROFL bet it does | 15:43.22 |
Robin_Watts | Sorry, I'm confused here. What's pswrite ? | 15:43.30 |
kens | The CCITTG g4 fax p[roblem for one | 15:43.31 |
ray_laptop | pswrite _is_ fairly simple | 15:43.56 |
Robin_Watts | I assumed pswrite (and ps2write) were the 'high level postscript' options, but from what you're saying they arent? | 15:44.00 |
ray_laptop | since it only uses Level 1 PS | 15:44.08 |
kens | pswrite is 'higher' level | 15:44.13 |
ray_laptop | Robin_Watts: ps2write is MUCH higher level | 15:44.23 |
henrys | pswrite has no fonts mostly vectors | 15:44.25 |
kens | its not a plain bitmap, its not high level postscript either | 15:44.32 |
Robin_Watts | ok. | 15:44.39 |
henrys | like I said pswrite is significantly faster on my HP color laser jet than raster. | 15:45.19 |
kens | Yes, because you don't send all the white space :-) | 15:45.36 |
| and jump through image scaling hooops etc | 15:45.53 |
Robin_Watts | we can choose to omit whitespace too (completely white lines etc) | 15:47.25 |
kens | Yes I know | 15:47.54 |
henrys | the raster is 600 dpi con tone - that's quite a bit of data to be shipping about. | 15:48.08 |
kens | But the image scaling and positioning you can't avoid. alos deompression and so on | 15:48.11 |
| Personally I think either a raster or not a raster makes sens, halfway house to me is bad news | 15:49.11 |
Robin_Watts | We can send it at device res, hence 1:1, hence hopefully no scaling for the printer to do. | 15:49.17 |
kens | Robin_Watts : yes and I bet the interpreter still jumps through all the hoops to discover this | 15:49.36 |
| also what about pritner margins ? | 15:49.46 |
Robin_Watts | kens: I would have opted for raster, in bands eliding whitespace myself. | 15:50.03 |
kens | If you send full size A4 then the pritner will have to scale the image, or not print to the edge | 15:50.17 |
| Robin_Watts : I would go for that for pritning | 15:50.26 |
| Itsa quick and easy to implement | 15:50.33 |
Robin_Watts | printing is the sole purpose of this, AFAIK. | 15:50.45 |
kens | Yes, which is why I keep saying tis good :-) | 15:50.59 |
| Because we can implement it quickly | 15:51.05 |
| Its not like we are competing against a rip | 15:51.16 |
| IMO people will be happy to get somthing printed | 15:51.28 |
| Later we cna worry about making it good if people complain a lot | 15:51.47 |
henrys | I guess it is time for the next meeting. | 15:59.53 |
| alexcher:ping | 16:00.23 |
marcosw | morning all | 16:00.38 |
henrys | hi marcosw | 16:00.48 |
alexcher | henrys: pong | 16:00.50 |
henrys | okay good - so I was thinking about alexcher quality issues from static analysis etc. - how about hiring a graduate student whose job it would be to test and find bugs in mupdf and ghostscript presumably he would create tests that break the code …. | 16:02.16 |
| so we'd work on a static analysis problem if a real world bug could be generated. | 16:02.56 |
tor8 | henrys: oh, daylight savings mismatch? | 16:03.07 |
henrys | tor8:that's what I thought happened. | 16:03.22 |
mvrhel_laptop | now it matches.... | 16:03.22 |
ray_laptop | henrys: create PDF tests ? | 16:03.31 |
Robin_Watts | tor8: UK is out by an hour, maybe sweden too? | 16:03.35 |
henrys | yes PDF or PostScript tests. | 16:03.51 |
ray_laptop | finding a grad student that is able to compose PDF's will not be easy. | 16:04.33 |
henrys | I'd like to have test "coverage" also. | 16:04.45 |
alexcher | henrys: Create more broken files in Google facion? | 16:05.02 |
henrys | alexcher:that's a possibility and using code coverage to generate test cases. | 16:06.16 |
Robin_Watts | henrys: It seems to me that most of the time when you look at a static analysis problem, either: 1) It's obvious that it's not really a problem, and the analyser is wrong, 2) It's obvious that it is a problem, 3) It's not clear either way. | 16:07.29 |
| In the case of 2), we should just fix it. | 16:07.41 |
| In the case of 3), we should treat it like 2). | 16:07.49 |
| I'm not sure I see where having an actual file that shows the problem helps us. | 16:08.07 |
henrys | Robin_Watts: it helps get us from case 3 to case 2 without engineering hours | 16:09.34 |
Robin_Watts | Hiring a grad student to figure out which class the static analysis problems fall into would make sense. | 16:09.49 |
Gigs-- | Does a pattern color space make sense in a pre-separated file? | 16:10.27 |
kens | yes | 16:10.47 |
henrys | I'm also a fan of code coverage as far as I'm concerned we should have a test that hits each line of code (within reason devices, postscript exempt) | 16:10.58 |
alexcher | Coverity was reporting many cases when the return code was not checked. Sometimes this causes SEGV's. | 16:10.58 |
ray_laptop | Gigs: sure. If the separations are created in PDF or PS, they can use patterns, images, vectors, anything | 16:11.10 |
Robin_Watts | alexcher: Right, and having someone check those cases is worthwhile. Having someone craft files to try to make us fall over in those specific cases = long winded, painful, and ultimately unhelpful. | 16:12.00 |
henrys | I just think if we had a crashing test folks would fix it. They won't look at a return code not checked. | 16:12.02 |
Gigs-- | I think this file is raster | 16:12.03 |
kens | Gigs a pattern can be a raster | 16:12.18 |
Gigs-- | I wonder if screening is being applied somehow with the pattern color space | 16:12.20 |
kens | You can use a pattern to make something that looks like a screened area, but you can't really do screening that way | 16:12.46 |
| Not properly | 16:12.52 |
| Pre-separated files aren't 'usually' screened | 16:13.12 |
Gigs-- | hmmm... the likely origin of this file was the copy dot scanner... which scanned screened films into raster, preserving the existing screen | 16:13.15 |
| it's a really old file, going back to our film to CTP conversion | 16:13.27 |
kens | Right, so its an image | 16:13.28 |
ray_laptop | henrys: I agree with Robin_Watts that it's relatively easy and painless to fix the static analysis gripes (and often doesn't require much more than knowledge of C) but crafting tests is a LOT of very high level work | 16:13.33 |
kens | Its possible (daft but not unknown in PDF) to use a Pattern to paint a singel image | 16:13.46 |
| Gigs-- : if you want me to look at it I can give you an opinion | 16:14.20 |
Gigs-- | daft things often result from PS files from the early to mid 90s being converted to PDF :P | 16:14.23 |
| nah it's just a general question, the warning is not even coming from GS but rather from the adobe rip | 16:14.38 |
henrys | well alexcher you would certainly be capable of creating a crashing PDF or postscript file and report a bug to the owner of the crash, but you don't, so I'm trying to make it happen with outside help | 16:14.45 |
Gigs-- | unless you just want it for your own curiosity | 16:14.53 |
kens | Gigs-- : I have enough problems of my own thanks :-) | 16:15.08 |
Gigs-- | 99 problems but converted copydot pdf's aren't one | 16:15.36 |
Robin_Watts | henrys: A lot of times the way we can get a non-zero return code that we fail to check will be because we run out of memory. It's hard to code that in a test file. | 16:15.54 |
henrys | ray_laptop:not convinced that's trye. many new test cases would simply be a matter of changing parameters. Graduate students aren't high school students. | 16:15.55 |
| s/trye/true/ | 16:16.13 |
| Robin_Watts: yes simulating heavy memory loads is classic testing which we don't do. | 16:16.51 |
tor8 | paulgardiner: creating digital signatures must be easier than reading and checking all variants out there, by way of only needing to support one appreach? | 16:16.53 |
Robin_Watts | I suspect if we're hiring someone capable of making tests, they'd be perfectly capable of either fixing the trivial cases, or opening a bug saying "this is one worth looking at". | 16:16.55 |
alexcher | henrys: I'm not shure that I can always create a test case. For instance, it's hard to test failed memory allocation. | 16:16.56 |
Robin_Watts | henrys: Memento does it... | 16:17.00 |
| efficiently too. | 16:17.08 |
ray_laptop | Robin_Watts you typed faster than me. | 16:17.16 |
tor8 | anyway, if it's a significant amount of cryptography work with ASN.1 etc then let's use openssl (or another nicely licensed alternative) | 16:17.19 |
Robin_Watts | We could get marcosw to do some memsqueezing of gs? | 16:17.51 |
paulgardiner | tor8: yes, but I thought it would look odd to be able create them and not validate them. | 16:18.17 |
henrys | there are all kind of wonderful tools that can be used but nobody is actually doing it. That is the point. | 16:18.20 |
Robin_Watts | (If people are interested, I can talk them through how memento does this - it's very simple - after the meeting) | 16:18.27 |
ray_laptop | running something with fairly high feature coverage (like the Altona test suite) with the memento successive memory fail would be interesting | 16:18.27 |
kens | ray_laptop : I've had mail from Avast saying that the next update will cure the false positives on mkromfs and genarch | 16:18.31 |
marcosw | Robin_Watts: I was going to ask about running memento tests of all the files after the valgrind tests are done (which should be later today) | 16:18.45 |
Robin_Watts | marcosw: cool. | 16:18.57 |
ray_laptop | kens: thanks. I don't know if you did, but I had reported them as false postives | 16:19.12 |
marcosw | but I hadn't thought about memsqueezing. | 16:19.15 |
paulgardiner | tor8: maybe at first just be able to validate the type we intend to create. | 16:19.19 |
kens | ray_laptop : yes I did | 16:19.22 |
henrys | I still sort of feel if we had a part time person whose job it was to break the code it would be valuable, but if you think we can just use tools and marcosw okay. | 16:20.02 |
Robin_Watts | henrys: Having a part time person who's job it was to check the coverity (or whatever) output and either fix it, or spin bugs out - that sounds worthwhile to me. | 16:20.58 |
ray_laptop | having a part timer to go through the static analysis gripes would be nice. Most are quite simple, but take time away from "real work" | 16:21.01 |
| I think the person should fix it (i.e. generate git patches) and forward it to us via email | 16:21.56 |
Robin_Watts | I was merely saying that having them "make a test file that shows the crash" probably would ruin their productivity and not actually help the developer that ends up fixing it. | 16:22.17 |
marcosw | speaking of which, how should I deal with the valgrind issues that I've found? Open one bug that we can pass from engineer to engineer like we did for the fuzzing seg faults? | 16:22.19 |
Robin_Watts | marcosw: Personally, I'd rather see you open lots of bugs. | 16:22.49 |
ray_laptop | marcosw: you can't group them by where the failure is ? | 16:23.00 |
Robin_Watts | The fuzzing seg fault ones don't seem to have been passed around much yet :( | 16:23.08 |
henrys | well I have University of Colorado here which is better known for girls than computer scientists but the department is actually pretty good. If somebody knows a good grad student that would be best. | 16:23.16 |
| otherwise I'll take it on to look for somebody | 16:23.31 |
Robin_Watts | (that's not a criticism levelled at anyone - it's possible they are with me at the moment - haven't looked) | 16:23.34 |
| henrys: GSoC task? | 16:24.03 |
henrys | Robin_Watts: how do we ask about that? | 16:24.28 |
Robin_Watts | Lots of decent grad students looking for GSoC work. | 16:24.32 |
henrys | I guess I'll look into that firs. | 16:24.57 |
Robin_Watts | henrys: Anyone doing open source can propose GSoC tasks to google. | 16:24.57 |
marcosw | ray_laptop: yes, I plan on doing that. Though one of the reported problems is memory leaks, and I don't believe there is enough information in the output to triage those. | 16:25.05 |
ray_laptop | I would expect GS0C responders to be looking more for development than rather tedious work that bunches of static analysis bugs are | 16:25.55 |
henrys | anyway that's really all I had for the meeting I'm buried in PCL indent hell and I'm probably missing some stuff. Anybody else? | 16:26.25 |
Robin_Watts | henrys: I'm not 100% familiar with the requirements, but you propose tasks, and offer mentoring for the guy that does it. | 16:26.31 |
ray_laptop | marcosw: memory leaks should be pretty easy if valgrind can cause a gdb bug | 16:27.00 |
| s/bug/bp/ | 16:27.12 |
Robin_Watts | There are some SEGVs in mupdf to do with the store at the moment, I'm going to look into why. | 16:27.31 |
henrys | okay I'll look at that. I've always been curious to look at CU here though, it might be a good resource for us in the future. | 16:27.35 |
marcosw | btw, I don't know if anyone is watching the cluster dashboard, but we are running with 10 amazon instances in addition to the normal cluster nodes. | 16:28.24 |
ray_laptop | henrys: yeah, we know why you want to go check out CU ;-) | 16:28.24 |
henrys | marcosw:you have to run valgrind with fancy options I always forget to see the call that created the leak but once you do that it should be easy to assign. | 16:28.49 |
Robin_Watts | henrys: We could ask at comlab in Oxford too. paulgardiner: Are you still in touch with anyone there? | 16:28.53 |
kens | marcosw I saw teh AWS nodes, are they live now ? | 16:29.02 |
marcosw | unfortunately they don't work for the mujstests :-( | 16:29.10 |
Robin_Watts | marcosw: why not? | 16:29.20 |
paulgardiner | Robin_Watts: No, not at all now. | 16:29.22 |
marcosw | missing X11 libraries | 16:29.27 |
| x11_main.c:(.text.startup+0x32f): undefined reference to `XCreateWindow' | 16:29.35 |
Robin_Watts | mujstest needs X11? | 16:29.45 |
| That's a mistake. | 16:29.49 |
| I should fix that. | 16:29.53 |
marcosw | also pkg-config is mssing, but that might be the same issue. | 16:30.46 |
ray_laptop | I'll be curious to see what the throughput time is for the ghostpdl test with the aws nodes on the job | 16:31.20 |
marcosw | ray_laptop: should go down from 21 minutes to 16 minutes. | 16:32.11 |
| and we are paying $0.115/node per hour. | 16:32.39 |
Robin_Watts | marcosw: Does casper have the X libs on? | 16:37.48 |
| evidently not :) | 16:38.08 |
marcosw | Robin_Watts: I didn't think so. | 16:38.47 |
Robin_Watts | marcosw: What build line do you/we use ? | 16:40.29 |
tkamppeter | henrys, Robin_Watts, hi | 16:40.51 |
henrys | tkamppeter: howdy we were trying to sort out printing priorities | 16:41.26 |
marcosw | Robin_Watts: hold on, let me find it... | 16:41.49 |
Robin_Watts | marcosw: "NOX11=1 V8_BUILD=1 make build=release" should work without X11. | 16:42.06 |
marcosw | make CXX=\"$cpp_exe\" XCFLAGS=\"-DCLUSTER\" build=release -j 12 | 16:42.13 |
tkamppeter | henrys, Robin_Watts, we really should introduce this psimagewrite device, I think it would be a nice solution for consistent, reliable, resource-saving printing on PS printers, also on the cheaper ones. | 16:42.45 |
marcosw | we don't use the V8_BUILD option currently | 16:42.47 |
Robin_Watts | marcosw: Then how are we testing v8? | 16:43.07 |
ray_laptop | tkamppeter: for mupdf ? | 16:43.24 |
kens | tkamppeter note that it may not be low resource since it involves large images, and may well be slower than sending high level PostScript | 16:43.42 |
tkamppeter | henrys, Robin_Watts, I have put up GSoC project ideas on https://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2013-openprinting-projects | 16:43.52 |
Robin_Watts | marcosw: Sorry. I mean, without V8_BUILD=1, we never actually build mujstest | 16:44.04 |
tkamppeter | ray_laptop, Robin_Watts, henrys, it is mainly MuPDF. | 16:44.14 |
marcosw | Robin_Watts: don't know. Pretty sure you added the V8 stuff. | 16:45.11 |
tkamppeter | henrys, Robin_Watts, I did not post psimagewrite for GS, should I post it, too? | 16:45.43 |
Robin_Watts | oh, it's V8_PRESENT, sorry. | 16:46.24 |
henrys | we have it now viewrgb etc. | 16:46.33 |
ray_laptop | tkamppeter: we used to have psrgb and psmono devices for GS. | 16:46.45 |
Robin_Watts | And the makefile finds that from their being a v8 dir in thirdparty. | 16:47.04 |
tkamppeter | ray_laptop, they were for wrapped bitmap output? | 16:47.12 |
Robin_Watts | So, it's just a question of adding NOX11=1 and we should be fine. | 16:47.20 |
marcosw | Robin_Watts: there isn't a V8_PRESENT option either. | 16:47.20 |
ray_laptop | tkamppeter: yes | 16:47.22 |
henrys | ray_laptop:why not just a command line with the viewcmyk.ps stuff or something like that? | 16:47.37 |
tkamppeter | We should have one which sends the bitmap banded to no exhaust the printer's memory. | 16:47.40 |
Robin_Watts | marcosw: V8_PRESENT is set in Makethird according to whether we have a v8 dir in thirdparty or not. | 16:47.48 |
ray_laptop | tkamppeter: devices/gdevpsim.c | 16:48.21 |
marcosw | Robin_Watts: sorry, I was answering the question as to how make is called, I wasn't looking to the internal bit of the makefiles | 16:48.58 |
ray_laptop | henrys: I don't follow your question ? | 16:49.26 |
Robin_Watts | marcosw: Yes, my bad for thinking we'd have to tell it about V8. For X11 we have to tell it though, I think. | 16:49.35 |
tkamppeter | ray_laptop, so such an output device was always there? | 16:50.00 |
marcosw | Robin_Watts: okay, I'll modify the cluster code and try re-rerunning the mujstests on the aws | 16:50.09 |
ray_laptop | tkamppeter: yes. Just not included in the default build | 16:50.17 |
tkamppeter | ray_laptop, henrys, did someone test its reliability with PS printers? | 16:50.32 |
kens | tkamppeter : as you've seen with teh ps21write utput this is not a trivial test | 16:50.53 |
ray_laptop | tkamppeter: not for a long time. It prints way too slowly | 16:51.03 |
| even worse than pswrite | 16:51.32 |
Robin_Watts | ray_laptop: Is psim banded? And does it elide white areas? | 16:51.56 |
kens | I doubt it in both cases. I suspect its a full page bitmap | 16:53.37 |
| But I have not looked | 16:53.43 |
marcosw | Robin_Watts: NOX11=1 appears to do the trick. I'll git reset the mupdf directory so the failed mujstest tests are re-run. | 16:55.50 |
Robin_Watts | marcosw: Thanks. | 16:55.59 |
| marcosw: So... memento stuff... (I'm assuming the meeting is over now). | 16:56.47 |
marcosw | Robin_Watts: I was going to email you, but I have time now. | 16:57.08 |
Robin_Watts | What sort of testing were you hoping to do? leak checking ? | 16:57.10 |
ray_laptop | Robin_Watts: sorry -- phone call from Len (cust 532) | 16:57.28 |
marcosw | ye | 16:57.40 |
Robin_Watts | marcosw: To do simple leak checking, the best way is to: make memento XCFLAGS="-DMEMENTO_LEAKONLY" | 16:58.19 |
| That way it doesn't do the expensive memory filling/checking all the time. | 16:58.39 |
| Then just run as normal. | 16:58.49 |
henrys | tkamppeter:I have an HP 4600 you can send it a full page raster or bands it will tell you insufficient memory if you downgrade the resolution it is glacial. My printer could be an exception but I'd be surprised if a raster is going to work for any color printing device. | 16:59.09 |
marcosw | what about memsqueezing testing? | 16:59.13 |
Robin_Watts | but for coverage, we could look at mem squeezing. | 16:59.21 |
ray_laptop | Robin_Watts: psim does run length compression, so white lines use little data | 16:59.25 |
Robin_Watts | For memsqueezing, you do... (FX: fumbles around looking for notes...) | 16:59.58 |
ray_laptop | Robin_Watts: tkamppeter: and the psrgb device uses Level 2 RLE + ASCII85 filters | 17:00.18 |
henrys | ray_laptop:I was saying produce raster than use on of the lib/view* postscript programs to create an image from that and send it to the printer. | 17:01.03 |
Robin_Watts | MEMENTO_SQUEEZEAT=1 <insert program invocation here> | 17:01.17 |
| That runs the program normally, until it hits the 1st allocation. | 17:01.55 |
henrys | ray_laptop:in fact you could do jpeg with that which might be the only way to wirelessly print to a color printer without really annoying people. | 17:02.17 |
Robin_Watts | At that point it forks the program, and the child fails every successive allocation. | 17:02.20 |
tkamppeter | ray_laptop, henrys, seems that PS is a really bad printer language, no standard way to send a PS which makes any arbitrary PS printer print, so a mobile device would do best that if a printer does both PS and PCL to send PCL. | 17:02.36 |
Robin_Watts | when the child exits, the parent process continues to the 2nd allocation, where it forks again etc. | 17:02.48 |
| tkamppeter: There is a standard way. It's just that some printers are broken :( | 17:03.50 |
| marcosw: Does that make sense? (I bet you're trying it as we speak) | 17:05.34 |
tkamppeter | Robin_Watts, the standard way is PS which displays on the screen with GS ... | 17:05.53 |
ray_laptop | tkamppeter: right. And the PS that GS writes can always be handled by GS :-) | 17:06.41 |
marcosw | Robin_Watts: no, I was playing with the was cluster nodes. I find it strangely satisfying to be able to magically make 10 new instances to appear with one command. | 17:06.52 |
ray_laptop | including the ps2write | 17:06.57 |
tkamppeter | Robin_Watts, henrys, ray_laptop, so the idea to send bitmap PostScript to printers as an attempt of a more reliable PS driver is not a good idea ... | 17:07.30 |
Robin_Watts | tkamppeter: It sounds like it has more flaws than I'd realised, yes :( | 17:07.51 |
henrys | tkamppeter: well we have a project to study printing from mobile and we expect results shortly. We are going to look at how Adobe does this for example. | 17:08.01 |
tkamppeter | Robin_Watts, henrys, ray_laptop, there are some cheaper PS printers with too low memory, like the HP LJ 12xx/13xx, these print text files just fine in PS mode but often choke on images. Here the solution is really to send PCL instead of bitmap PS. | 17:10.42 |
henrys | send your pdf to the google cloud printer and let them figure it out seems like a good answer ;-^ | 17:10.44 |
marcosw | well that wasn't very satisfying, none of the git commits cluster tested the full set of products. | 17:12.36 |
henrys | tkamppeter:does ps2write work on these printers? | 17:15.05 |
| I do think output like to ps2write would get us printing on a very wide range of devices. | 17:17.47 |
kens | ps2write 'mostly' works, but there are some broken printers which we've worked around. We could alter ps2write to avoid some of them, and indeed we have, with the assistance of CUPS which turns on some undocumneted switches for certain printers. | 17:20.57 |
| Because the way to make those work slows other printers down unreasonably | 17:21.14 |
henrys | also if we ported that stuff over fixes in ghostscript would benefit mupdf printing. | 17:22.24 |
| fixed is ghostscript ps2write, of course | 17:22.54 |
kens | I don't think we cna port ps2write to MuPDF.... | 17:22.56 |
tkamppeter | henrys, my experience is with ps2write. | 17:23.09 |
henrys | kens:not exactly know but there sure would be a large parcel of common code and a fix in one would be easily moved over. | 17:23.51 |
kens | has some doubts | 17:24.02 |
henrys | kens:I guess I am gambling that a lot of the solution falls out of the procset inclusion but I'm probably missing a great deal. | 17:26.43 |
marcosw | Robin_Watts: so what do I look for in the output from memento with MEMENTO_SQUEEZEAT=1? | 17:27.48 |
henrys | kens:in any event bitmap is looking like a no go so we're going to have to do something. | 17:28.06 |
marcosw | even membin/gs -sDEVICE=ppmraw -o test.ppm ./examples/tiger.eps generates many errors of the type: | 17:28.18 |
| Unrecoverable error: VMerror in def | 17:28.27 |
| Operand stack: | 17:28.27 |
| --nostringval-- rangecheck --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- | 17:28.29 |
| --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- | 17:28.30 |
| --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- ljet2p --nostringval-- | 17:28.41 |
Robin_Watts | marcosw: sorry, back. | 17:32.14 |
marcosw | just asking what to look for in memsqueezing output. | 17:32.33 |
henrys | marcosw:has blow his stack ;-) | 17:32.45 |
| s/blow/blown | 17:32.56 |
Robin_Watts | marcosw: yeah, I suspect that's a 'good' exit. Give me a mo, and I'll have a look on peeves. | 17:33.07 |
| marcosw: You'll probably find that you have MEMENTO_SQUEEZEAT set in your environment, so all memento runs will be squeezing. | 17:35.17 |
marcosw | I set MEMENTO_SQUEEZEAT to 1, per you suggestion. | 17:36.12 |
Robin_Watts | Ok, so when I run a simple memento build I get: | 17:38.47 |
ray_laptop | oh no... another flood from Robin_Watts coming ??? | 17:39.22 |
Robin_Watts | http://pastebin.com/KjvEScUV | 17:39.22 |
ray_laptop | ahh | 17:39.31 |
Robin_Watts | With squeezing I get: | 17:41.36 |
| http://pastebin.com/9CzeeLMS | 17:41.41 |
henrys | tor8:ping | 17:43.24 |
kens | goodnight all | 17:44.45 |
Robin_Watts | marcosw: ping ? | 17:46.14 |
marcosw | yes | 17:46.22 |
Robin_Watts | so you don't see that sort of output? | 17:46.38 |
marcosw | it starts out like that, but then I get the : Unrecoverable error: VMerror in def messages | 17:48.09 |
| oops, it's time for me to run to uni for a lab meeting. I'll be back online in an hour or so. | 17:49.29 |
Robin_Watts | after how long? I'm up to 1400 or so without a problem. | 17:49.37 |
| ok, I start to get them in the 2500ishes. | 17:50.24 |
| but VMerror is a reasonable error, right? It's saying that it ran out of memory. | 17:50.50 |
chrisl | Robin_Watts: VMerror is what I would expect once we get a certain way through initialisation - really early on, we might just get an "unrecoverable error" | 17:53.30 |
Robin_Watts | chrisl: right. | 17:53.58 |
chrisl | So, from what you see, it looks like we're missing some error checking during initialisation..... | 17:54.31 |
Robin_Watts | I guess a reasonable strategy would be to fix the SEGVs first. | 17:54.36 |
| I did look at this a while ago, and started to fix some of the leaks, but I think it was felt at the time, that having a few one-off blocks leak wasn't a huge issue. | 17:55.23 |
| It looks to me like we pretty constantly leak the same 23 blocks throughout. | 17:55.53 |
chrisl | I'd be more worried about the segvs at this point | 17:56.10 |
ray_laptop | Robin_Watts: all color related ? | 17:56.11 |
Robin_Watts | ray_laptop: THe leaks? no. | 17:56.34 |
| ray_laptop: peeves: ~robin/sauce/ghostpdl.git/gs/log if you're interested. | 18:05.24 |
| To reproduce a given one, do: MEMENTO_FAILAT=n <same invocation> | 18:06.26 |
marcosw | Robin_Watts: I'm back | 19:04.02 |
Robin_Watts | I'm still here. | 19:04.14 |
marcosw | the errors start sometime after: | 19:05.07 |
| Memory squeezing @ 2131 | 19:05.08 |
| [a+]gs_malloc(large object chunk)(184) = 0x0: failed, used=674766, max=674766 | 19:05.08 |
| Unrecoverable error: VMerror in --nostringval-- | 19:05.10 |
| Operand stack: | 19:05.11 |
| .schedule_init 0 --nostringval-- 2 index known --nostringval-- if --nostringval-- 3 1 roll .growput | 19:05.12 |
Robin_Watts | ok, so that's a clean exit. | 19:05.31 |
| We run out of memory, so gs reports a VMerror. | 19:05.48 |
marcosw | Child status=65280 | 19:05.49 |
| Memory squeezing @ 3259 | 19:05.50 |
| [a+]gs_malloc(large string chunk)(184) = 0x0: failed, used=766014, max=766014 | 19:05.52 |
| [a+]gs_malloc(large string chunk)(100) = 0x0: failed, used=766014, max=766014 | 19:05.53 |
| Unrecoverable error: VMerror in def | 19:05.54 |
| Operand stack: | 19:05.55 |
| and then later: | 19:06.18 |
Robin_Watts | again, that's a clean exit. | 19:06.18 |
marcosw | Child status=65280 | 19:06.19 |
| Memory squeezing @ 3587 | 19:06.20 |
| Unrecoverable error: VMerror in array | 19:06.21 |
| Operand stack: | 19:06.22 |
Robin_Watts | and again. | 19:06.39 |
marcosw | does it ever stop? | 19:06.42 |
Robin_Watts | It stops when the whole thing has run through. | 19:06.55 |
marcosw | first of all is there a way to only report non-clean exits? Second of all, how long does "the whole thing has run through" take? | 19:07.35 |
Robin_Watts | membin/gs -sDEVICE=ppmraw -o out.ppm examples/tiger.eps | 19:08.13 |
| Total memory malloced = 30833322 bytes | 19:08.24 |
| Peak memory malloced = 12475357 bytes | 19:08.26 |
| 70034 mallocs, 69955 frees, 0 reallocs | 19:08.28 |
| so it'll stop at 70034+69955. | 19:08.38 |
| marcosw: Personally, I'd do: | 19:09.00 |
| MEMENTO_SQUEEZEAT=1 membin/gs -sDEVICE=ppmraw -o out.ppm examples/tiger.eps > log 2>&1 & | 19:09.23 |
| and then grep log for SEGV. | 19:09.32 |
| I'm fixing some now. | 19:10.51 |
| Bah. No ray. | 19:15.07 |
mvrhel_laptop | fun all morning with windows asnyc calls. figured out one main issue. lunch time now | 19:19.30 |
Robin_Watts | I think these SEGVs are down to broken cleanup code. | 19:29.49 |
| And git blame says ray from 2000. | 19:32.12 |
alexcher | Does Artifex have a good stochastic threshold screen? SAI is looking for a new screen that looks less wormy than their current one. | 19:55.09 |
Robin_Watts | alexcher: mvrhel_laptop and ray had some tools to generate such things I think. | 19:56.30 |
mvrhel_laptop | I think ray was going to add the stochastic stuff to toolbin/halftone | 19:57.56 |
| but I don't see it in there | 19:59.00 |
| only the ordered screen stuff | 19:59.12 |
alexcher | Great, there's one in toolbin/halftone/gen_stochastic/ | 20:00.30 |
| Forward 1 day (to 2013/03/27)>>> | |