| | <<<Back 1 day (to 2013/08/15) | 2013/08/16 |
| selim | after which I found the search parameters: -dDoNumCopies but it seems not to work | 00:27.29 |
| ray_laptop | I guess selim just doesn't get it. Kens told him "the pdfwrite device IGNORES NumCopies". He's have to change the C code to make it do otherwise. | 00:54.20 |
| toothrot | it sure seems like what he wants to do can be done externally anyways | 03:31.44 |
| mdih | hello guys, where can we download old version of ghostscript like version 8+, just have to simulate something | 04:15.43 |
| neves | kinda small | 05:58.12 |
| | writing | 05:58.13 |
| | http://downloads.ghostscript.com/public/ | 05:58.14 |
| ray_laptop | neves: the git has sources for ALL old versions back to 6.0 when it starts | 06:20.51 |
| neves | heh he only need 8+ thought it might be easier than git | 06:21.23 |
| ray_laptop | for instance: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=dbacf7abe721f77d2c11475072eeab2a6dfb7430 | 06:23.18 |
| | is the 8.50 release | 06:23.27 |
| | 8.71 is a particularly good version prior to the 9.00 ICC CM release | 06:24.37 |
| | such as: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=c8c0f515c0601d7bd79878d6435d7cda96a4d587 | 06:25.35 |
| | neves: I hope that helps. On the upper right of http://git.ghostscript.com/?p=ghostpdl.git;a=shortlog there is a search box and you can look for version numbers in the commit messages | 06:27.05 |
| neves | Thanks ;) | 06:27.58 |
| | bbl | 06:28.03 |
| ray_laptop | Of course, that just gets you the commit snapshot. You still have to build it, but on modern CPUs that is < 1 minute | 06:28.14 |
| | neves: I won't be here for about 8 hours (sleep) | 06:29.00 |
| | but our .eu folks will be online in a few hours | 06:30.31 |
| kens | chrisl ping | 06:47.31 |
| chrisl | kens: pong | 06:48.12 |
| kens | The cluster got better last nigth and ran my test and it seems OK, so I'm going to commit the change | 06:48.35 |
| | DOn't know what you want to do about releases. | 06:48.49 |
| chrisl | Well, I really think we should pull in your change, and go again, but opinions varied..... | 06:49.17 |
| kens | I'm in agreement, I don't think we should pull in more changes without a test cycle, but.... | 06:49.41 |
| | Don't really want to wait for Marcos to come back and rerun the tests | 06:49.57 |
| | Oh and can you test GV please ? | 06:50.12 |
| chrisl | Yes, I'll do that. But gv seems to just use the gs exe, so it'll almost certainly work | 06:50.37 |
| kens | In effect so does GSView, that's how I was able to reproduce the problem, by feeding in PostScript | 06:51.12 |
| chrisl | I thought gs view used the dll | 06:51.27 |
| kens | It does, but it could equally well have used the executable, the problem would have been the same | 06:51.48 |
| chrisl | Anyway, gv is *much* simpler than GSView | 06:52.01 |
| kens | OK chrisl the commit is there | 07:01.17 |
| chrisl | Right, I'll get it, and do a test build | 07:01.34 |
| | kens: gv works just fine | 07:09.00 |
| kens | OK well that's as good a set of test as I can contrive. It *seems* to be OK | 07:09.19 |
| | I see Selim really doesn't undersatand that pdfwrite doesn't do what he wants, and I'm not going to change it..... | 07:09.53 |
| chrisl | I doubt you could change it to do "properly" do what he wants. | 07:16.50 |
| kens | There are problems with what he wants for uses involving more than one PS file. What of the 2st file has /NumCOpies 3 and the second has NumCopies 2 ? | 07:17.32 |
| | Of course he doesn't care, because he's using RFedMon and so only ever sees one file at a time | 07:17.49 |
| chrisl | Does redmon use the dll or the exe? | 07:18.54 |
| kens | I think the executable | 07:19.05 |
| | Saves the PS to file, runs teh executable as a process over it | 07:19.21 |
| chrisl | I wonder if it would be possible to configure the print dialog to not offer the "Copies" option | 07:20.07 |
| kens | I think you would have to have a custom print dialog. Possible but a load of work. | 07:20.39 |
| chrisl | I'd hoped it might be a simple setting we could twiddle | 07:21.10 |
| kens | We do honour NumCopies *if* you set -dDoNumCopies, by writing each page 'numcopies' times to the output, what we don;t do is write multiple files. | 07:21.34 |
| | mvrhel mvrhel_laptop for the logs, this one on Stack Overflow maybe could use your input: | 07:23.02 |
| | http://stackoverflow.com/questions/18259668/windows-8-supported-api-test-failed | 07:23.02 |
| | Oh good grief someone (not terribly clued up by the tone of the post) wants to use Ghostscript on an AS/400. How do you fancy one of those in your garage chrisl ? | 07:29.08 |
| chrisl | I think I'll give it a miss! | 07:29.37 |
| kens | :-) | 07:29.43 |
| chrisl | Actually, don't the AS/400s have a "Unix compatibility" option? GS would probably just build on that | 07:30.37 |
| kens | I did find someone talking about 'PASE' and saying that using that they got an AIX binary to work | 07:30.59 |
| | cluster test for my commit is fine, so I'm going to fetch a coffee and then go back to BeginPage/EndPage again | 07:32.15 |
| | reboot time | 08:03.38 |
| mdih | hmm hello guys, do you have any idea what caused this ghostscript error? i understand that i may need to upgrade its version but i can't tell what the problem is exactly | 08:10.40 |
| | heres the error: https://dl.dropboxusercontent.com/u/75841015/ghostscript_error.txt | 08:10.45 |
| kens | It means something is wrong, without seeing the file I can't tell more than that | 08:11.07 |
| | Well, I can tell its font related | 08:11.20 |
| mdih | kens, thanks. hmm yeah as i was suspected, but is it lacking? or perhaps the file is corrupted somehow? | 08:12.30 |
| kens | I think you posted this on Stack Overflow and said that recent versions work, so most likely its a bug, but again I dcannot tell without seeing teh file | 08:13.03 |
| mdih | ohh. Thanks a lot kens! | 08:15.56 |
| | cheers | 08:16.00 |
| kens | no problem, didn't do anything :-) | 08:16.09 |
| Robin_Watts | chrisl: In view of the closeness of ubuntus new release I think you should just do what you need to to get a new release out. | 08:29.43 |
| | i.e. just do kens change if that's all you feel confident about. | 08:29.58 |
| chrisl | Robin_Watts: My concern with your change(s) is that although the regression tests didn't show the problem, they might uncover a regression caused by the change | 08:33.20 |
| | Robin_Watts: FWIW, I'm not totally convinced that the weekly regression would test the three/four changes any better than a normal cluster test does. | 08:39.21 |
| Robin_Watts | chrisl: I know that the code I introduced in this release is hopelessly broken for bpp < 8. | 08:47.02 |
| | And the fix I've done only affects bpp < 8 (it's in an if (bpp >= 8) { old code } else {new code} | 08:47.53 |
| | ) | 08:47.57 |
| | hence the sole risk with my new code would be that I might have broken the bpp <8 case even worse than before. | 08:48.23 |
| | but there are always risks with such logic, so I'd understand if you wanted to leave it. | 08:49.49 |
| chrisl | Robin_Watts: given the nature of yours and the other fixes involved, I really don't see any gain from rerunning the weekly tests - but I had the impression henrys felt differently | 08:50.00 |
| Robin_Watts | tor7: As keeper-of-makefiles what do you think about bug 694428 ? | 10:39.39 |
| | paulgardiner, tor7: I guess I should look at the few android bugs and then do an android build of the release. | 10:40.32 |
| | Any last minute android changes we want to get in before I do that ? | 10:41.07 |
| srp | Hey there⦠anyone from the MuPDF team around? | 10:49.08 |
| sebras | srp: yes, several of them. feel free to ask your questions! :) | 10:52.50 |
| srp | hooray :) I've been trying to get in touch with Artifex about a commercial license for MuPDF, but haven't been able to get a response for the past few weeks | 10:53.22 |
| | any suggestions as to how to find out who to contact very gratefully received! | 10:53.46 |
| chrisl | srp: how were you trying? | 10:56.03 |
| srp | emails to sales@artifex.com and info@artifex.com | 10:56.22 |
| chrisl | Oh, strange, I'd have expected you to get something back within a week or two..... | 10:57.00 |
| Robin_Watts | srp: I'd have expected something faster than that, Scott is generally very good. | 10:57.16 |
| srp | maybe he's on vacation I guess | 10:57.30 |
| Robin_Watts | srp: Can you resend your email to sales@artifex.com, but copy scott.sackett@ and robin.watts@ at the same time please? | 10:57.44 |
| srp | will do! thanks for your help | 10:57.52 |
| Robin_Watts | no worries. | 10:57.59 |
| | I'll confirm receipt on here if you hang around. | 10:58.17 |
| srp | doing it now | 10:58.24 |
| Robin_Watts | I have to pop off now for a bit, but will be back later, sorry. | 11:03.43 |
| | (picking up replacement glasses :) ) | 11:03.58 |
| | srp: It's arrived. | 11:04.10 |
| srp | excellent, thanks! | 11:04.17 |
| kens | Ah crfap, now we have a customer complaining about 9.08 | 11:13.06 |
| | chrisl, best stop release | 11:13.11 |
| chrisl | kens: Really, I haven't seen it | 11:13.41 |
| kens | just arrived 'Wide char environment in GS 9.08' | 11:13.55 |
| chrisl | No, not seeing that..... unless it's a regression, I'm not sure we should stop the release | 11:15.06 |
| kens | He claims environment variables not working *at all* on WIndows | 11:15.53 |
| | I forwarded it to you | 11:16.32 |
| | I'll try a test myself | 11:16.49 |
| | Oh God and a 'doesn't work withg ancient version of GS#' mail | 11:17.09 |
| | Actually this may be a VS 2008 bug | 11:18.41 |
| chrisl | Yes, I'm wondering that. | 11:19.05 |
| kens | I'm certainly not getting any environemtn variable for GS_LIB | 11:19.35 |
| chrisl | Do you have one set? | 11:19.56 |
| kens | Oh probably helps if I had set one first | 11:20.03 |
| | lets play the control panel roulette wheel, where have MS hidden it this time..... | 11:20.49 |
| chrisl | And I don't know what "If I define in base\windows_.h" means..... | 11:21.26 |
| kens | no idea, just a moment, have env variable now | 11:21.41 |
| | still returns NULL | 11:21.54 |
| | and I do have a GS_LIB defined | 11:22.19 |
| chrisl | kens: can you try a build using GS_NO_UTF8=1 and see if it works, then? | 11:23.12 |
| kens | OK one moment | 11:23.19 |
| | will be a minute, did a clean and rebuild | 11:24.06 |
| chrisl | It's odd that that support mail never got to me...... | 11:25.03 |
| kens | Hmm yes that is strange | 11:25.14 |
| | presumably you checked spam ? | 11:25.22 |
| chrisl | Yes, don't see it there | 11:25.38 |
| kens | Very odd | 11:25.42 |
| | If this turns out to be true (and no reason to doubt) I'm thjinking maybe we should restart rc | 11:26.07 |
| | marcos is back next week I htink | 11:26.16 |
| kens | goes to check | 11:26.20 |
| | yes back Monday | 11:26.54 |
| chrisl | Well, again, this is code that the regression tests never test, so...... | 11:27.19 |
| kens | yes I know | 11:27.26 |
| | but was thinking if we stick more changes in, may as well have the lot | 11:27.40 |
| chrisl | You mean pull in *everything* from master? | 11:28.02 |
| kens | That didn't build properly, GS_NO_UTF8 is not defined. Stupid compiler | 11:28.04 |
| | chrisl yes, and retest | 11:28.10 |
| | chrisl if I define GS_NO_UTF8 I get the unresolved external | 11:30.15 |
| | gs_sprintf | 11:30.24 |
| chrisl | Sometimes, I *hate* VC++ | 11:30.43 |
| kens | I'm at a loss to see where it refernces it in that function | 11:31.10 |
| | somehow strlen is doing it | 11:31.27 |
| chrisl | Huh?? | 11:32.08 |
| kens | If I comment out strlen it compiles | 11:32.11 |
| | line 154 in gp_wgetv.c | 11:32.25 |
| | but I still get no environment variable | 11:32.44 |
| | tgetenv calls the same function as wgetenv, 'tgetenv_helper_nolock' | 11:33.54 |
| chrisl | I can't see any way that strlen() could cause that error | 11:33.59 |
| kens | I agree, but... | 11:34.07 |
| | Oh wgetenv just goes to _tegtenv, so getenv() and wgetenv() do the same thing. | 11:34.44 |
| | No surprise the result is the same I guess | 11:34.58 |
| | Hmm, despite me setting my environment, VS debugger isn't showing it in teh environment. | 11:36.55 |
| | I'll try restarting it | 11:37.00 |
| chrisl | Maybe you have to log out for the change to take effect, or something? | 11:37.28 |
| kens | Looks that way, restart of VC not enough, will be abck in a moment | 11:37.45 |
| | OK variable is in environment now | 11:40.01 |
| | But it fails to match | 11:40.21 |
| | Hmm, will have to read this code a bit more to see why | 11:41.16 |
| | It looks like its treating the 'GS_LIB' as a double byte string. | 11:42.10 |
| | So it actually looks for a string of length 3 of some odd Japanese characters | 11:42.41 |
| | And now I cna't get rid of the unresolved external error... | 11:51.54 |
| chrisl | if you look at my repo, there's a fix in there | 11:52.28 |
| kens | aha | 11:52.34 |
| | just for the reference ? | 11:52.43 |
| | and can you remind me how to look at your repository ? | 11:53.08 |
| chrisl | It's listed here: http://git.ghostscript.com/ | 11:53.43 |
| kens | ah I see | 11:54.21 |
| chrisl | I've no clue why the linker can't find gs_sprintf() though :-( | 11:55.01 |
| kens | OK that seems to compile now at least | 11:56.42 |
| chrisl | That fix is now up on casper "proper" | 11:57.04 |
| kens | and option looks OK | 11:57.07 |
| | OK that works for me | 11:57.43 |
| | environment variable duly detected | 11:57.52 |
| chrisl | That's without the UTF8 code? | 11:58.13 |
| kens | yes | 11:58.17 |
| | had to put GS_NO_UTF8 in the C file though, does not seem to work in the preprocessor definition | 11:58.42 |
| chrisl | You can add it to the nmake options: GS_NO_UTF8=1 on the command line | 11:59.36 |
| kens | Hmm, I'll try that | 11:59.45 |
| | fari enough, that works | 12:00.56 |
| | So its called from gs_main_init_with_args. | 12:01.47 |
| | The definition of GS_LIB and GS_OPTIONS should be different for UTF8 I guess, one should be a wcahr | 12:02.21 |
| | wchar | 12:02.26 |
| chrisl | I thought the code converted to wchar | 12:03.02 |
| kens | There's no call that does htat, i uses a #define | 12:03.23 |
| | see imainarg.c | 12:03.27 |
| chrisl | No, I thought it gp_getenv() we converted the char * parameter to a wchar * but apparently not | 12:05.39 |
| kens | Nope, certainly don't, and I think that's where it has to be done | 12:05.53 |
| | can't do it in imainarg.c without pulling in windows.,h | 12:06.14 |
| chrisl | It does it in gp_getenv_registry(), though..... | 12:06.53 |
| kens | Good, then you can copy it from there :-) | 12:07.16 |
| | OK I need to get some lunch, back in a bit | 12:07.45 |
| chrisl | Me too | 12:08.22 |
| Robin_Watts | kens, chrisl: hmm UTF8 crap. Do I need to look at that? | 12:45.06 |
| kens | Robin_Watts : I have a fix here | 12:45.13 |
| | and chris fixed the first part | 12:45.22 |
| | I'm goping to send him a diff in a minute | 12:45.31 |
| | going* | 12:45.34 |
| henrys | I can't seem to shake this customer off my tail | 12:47.45 |
| kens | could be worse, chrisl can't shake the release :-( | 12:48.04 |
| chrisl | henrys: whilst I take their point about the different between Linux and AIX being a worry, their reasoning about the size of the input and output influencing memory use and clist size is distressingly fauly | 12:49.55 |
| | or faulty, even! | 12:50.01 |
| henrys | yes I didn't bother correcting that. | 12:51.40 |
| chrisl | henrys: I can look at the memory use on AIX next week - although, IIRC, they use AIX 5.3 and we can't get that any more | 12:52.55 |
| kens | chrisl mail sent with a diff that works for me with UTF8 and environment variables | 12:53.59 |
| henrys | chrisl: okay thanks. | 12:54.26 |
| chrisl | kens: that looks fine to me | 12:54.41 |
| kens | OK I'll commit it then ? | 12:54.48 |
| | or you can if you prefer | 12:54.53 |
| chrisl | You go ahead | 12:55.00 |
| kens | OK | 12:55.07 |
| | OK comitted | 13:03.13 |
| | Right, I'mgoing to bisect for the file supplied by customer #330 using 8.71 (!) | 13:06.08 |
| | I'm not at all sure a patch will be possible for such an old version, since it appears to be transparency related | 13:06.35 |
| chrisl | So, I suppose we start the release pantomime over completely on Monday..... | 13:07.10 |
| kens | I think we have to yes, unless you are completely OK with just those 2 patches. | 13:07.32 |
| | Oops sorry 3 patches | 13:07.46 |
| kens | mutters about chief weapons | 13:08.03 |
| chrisl | Well, I would be, but I feel I'd be in the minority. | 13:08.26 |
| Robin_Watts | None of Marcosw's testing can affect the UTF8 stuff, right, cos it's windows only? | 13:09.00 |
| kens | Absolutely true | 13:09.08 |
| | Personally I'd be OK with just those 2 | 13:09.39 |
| Robin_Watts | I'd therefore be in favour of skipping the release testing. | 13:09.43 |
| kens | the scope of both is quite limited | 13:09.50 |
| Robin_Watts | For the SF readers here, I highly recommend "Wool". | 13:10.54 |
| kens | Who by ? | 13:11.13 |
| Robin_Watts | New bloke on the scene. Hugh Howey | 13:11.37 |
| kens | Its easier to find with an author, instead of treatises on sheep care.... | 13:12.00 |
| chrisl | Robin_Watts: I can't actually see how the weekly regression would exercise the other fixes suggested for inclusion differently to the normal cluster testing | 13:12.11 |
| Robin_Watts | I also recommend the Expanse stuff by James S A Corey (Leviathan Wakes, Calibans War, Abaddons Gate) | 13:13.29 |
| | I have the first 2 of those as dead tree books that I can lend, and the 3rd as an ebook. | 13:14.33 |
| chrisl | I just read Simulacron-3 by Daniel F. Galouye - I was *really* impressed by that | 13:14.41 |
| Robin_Watts | must eat lunch. | 13:15.43 |
| kens | aha Mr Von Lipwig is back in the next Pratchett book | 13:19.38 |
| henrys | chrisl: your call on the release, no need for democracy with that. | 13:27.11 |
| chrisl | henrys: I feel we should run with the GSView fix, the UTF8 fix and the three that Ray pointed to yesterday. I don't think any those get extra testing in the weekly regression | 13:28.44 |
| henrys | sounds good, do it monday? | 13:32.35 |
| chrisl | henrys: if we're doing that, I can do an RC this afternoon | 13:33.03 |
| henrys | if you want Friday releases aren't usually worth hurrying since most won't look at it until Monday, but I guess you like having it out of the way. | 13:35.21 |
| kens | reboot time, WINdows thnks my Temp directory is read-only for some weird reason | 13:39.53 |
| chrisl | Can anyone remember exactly what the weekly regression does now? I'm working under the assumption it tests different/odd devices/configurations, but I vaguely recall Marcos talking about moving things around so some of the more time consuming jobs were only run weekly..... | 13:57.08 |
| kens | no idea sorry | 13:57.35 |
| henrys | me too I don't know | 14:11.42 |
| Robin_Watts | So, when PDF files are signed, Acrobat adds a little logo to the annotation. | 14:26.59 |
| | but the logo is a registered trade mark. | 14:27.09 |
| | so we probably can't use the same logo. | 14:27.14 |
| | so we need a logo of our own. | 14:27.18 |
| tor7 | Robin_Watts: should we use a generic "sigil" kind of logo, or the mupdf logo? | 14:27.38 |
| Robin_Watts | http://ghostscript.com/~robin/MuPDFSigned.pdf | 14:27.41 |
| | That's a silhouette version of the MuPDF logo that might work. | 14:28.13 |
| tor7 | Robin_Watts: that looks nice. | 14:28.22 |
| Robin_Watts | I did debate about changing the contents of the magnifying glass to be a tick, but that would require me to be able to draw a tick :) | 14:28.45 |
| tor7 | [ SIGNED ] diagonally across it in a faded stamp font? ;) | 14:29.20 |
| Robin_Watts | Acrobat uses the trilobed red thing, and then on top of that puts "Document signed by Paul Gardiner" etc. | 14:30.26 |
| tor7 | we could make this magnifying glass logo the mupdf/ghostscript blue and have the same type of text | 14:31.11 |
| Robin_Watts | We'd do the same except that instead of the trilobed red thing, we'd have the simplified logo given above (probably in grey or mupdf blue) | 14:31.16 |
| | yeah. | 14:31.22 |
| | I think paul already adds the text; it's just the logo definition that is in flux. | 14:31.46 |
| tor7 | I read that as trilo-bed at first, thinking of trilobite / bed bug hybrids... | 14:32.07 |
| | so we'll need the logo as a smallish content stream / xobject thing that can be easily embedded in the document then? | 14:32.42 |
| Robin_Watts | tor7: yeah, paul said he could grab it from a PDF. | 14:33.07 |
| | so I tweaked stuff in Xara and exported as PDF. | 14:33.15 |
| | If you're happy, I'll pass that PDF file to him for him to work with. | 14:33.26 |
| tor7 | Robin_Watts: that PDF could be simplified a bit, it uses a black image with the path as a clip | 14:35.17 |
| | but I'm happy with the logo | 14:35.34 |
| Robin_Watts | ok. | 14:35.53 |
| tor7 | all we'd need is to extract the path and make it a proper unit size for drawing as an xobject with a proper transform | 14:36.07 |
| Robin_Watts | pauls code copes with scaling etc I believe. | 14:36.26 |
| tor7 | the XObject content stream draws a path, clips with W* and then /Im0 Do | 14:37.12 |
| | Im0 is a fully black image | 14:37.16 |
| | size 300x360 units | 14:37.26 |
| | so I think if we just change the W to a fill and scale it by 1/360 we should have something perfect | 14:37.50 |
| | maybe translate by 30/360 unit as well, to center it horizontally in a unit square | 14:38.20 |
| Robin_Watts | as I say, pauls code does the scaling/centring. | 14:38.35 |
| henrys | kens: I know you've been busy so I'll bisect Stephan's problem a bit later. I have an appointment now. | 14:44.12 |
| kens | henrys thanks I am having troubl;e with not building | 14:44.26 |
| | WOudl not be surprised if it is not feasible to produce a pathc though | 14:45.01 |
| Robin_Watts | tor7: New simplified file in the same place. | 14:59.26 |
| tor7 | Robin_Watts: looks good! much simpler now. | 15:00.44 |
| mvrhel_laptop | Robin_Watts: I am going to install mupdf on the Raspberry Pi and see how it does with the test files | 15:15.50 |
| | I may need a little help from you today with this if that is fine | 15:16.50 |
| | I have to run my son off to camp this morning and daughter to soccer though | 15:17.14 |
| | first | 15:17.16 |
| Robin_Watts | mvrhel_laptop: On con-call at the moment, but sure. | 15:17.40 |
| mvrhel_laptop | ok thanks | 15:17.45 |
| Robin_Watts | ok. off con-call. | 15:40.41 |
| | tor7: 2 commits on robin master | 17:02.52 |
| ray_laptop | Robin_Watts: mvrhel has a few mupdf questions. He's on the phone to me (he's stuck at the park w/o wi-fi) | 17:34.22 |
| Robin_Watts | ok. | 17:34.30 |
| ray_laptop | 1: Can mudraw render in bands ? It used to be in there | 17:35.00 |
| | 2: how best to monitor memory usage on the Pi running mupdf | 17:35.40 |
| | we assume that mudraw -o /dev/null will work to dump the output in the bit bucket. Is that true, or does it need a file ? | 17:36.38 |
| | 3: Are images in the display list in the "original" (compressed) format or are have they been expanded ? | 17:39.10 |
| Robin_Watts | mupdf is capable of rendering in bands; we draw to the display list and then draw the display list out repeatedly. | 17:39.45 |
| | mudraw does not currently use that feature, not has it ever done. | 17:39.55 |
| | (That is to say, it will use a display list, but it just plays the list back once to a full size bitmap currently). | 17:40.31 |
| ray_laptop | Robin_Watts: I know it's possible. I guess mvrhel will have to add that. The Pi doesn't have enough RAM to render 1200 dpi RGB | 17:40.57 |
| Robin_Watts | how best to monitor memory usage... a tweaked memento build? | 17:41.29 |
| | -o /dev/null is fine. | 17:41.41 |
| | Images in the display list are kept compressed. | 17:41.55 |
| | I can add a banded mode fairly easily if mvrhel wants me to. | 17:42.37 |
| ray_laptop | Robin_Watts: if the output is /dev/null does it still render the bitmap and then just throw it away ? Or does it just write it "raw" | 17:42.43 |
| Robin_Watts | It renders to a bitmap and fwrites it to /dev/null | 17:43.13 |
| | There is no special case spotting of '/dev/null/ | 17:43.24 |
| ray_laptop | Robin_Watts: OK. Thanks. | 17:43.25 |
| | Robin_Watts: well it looks at the filename for the type. So if it doesn't have .ppm or whatever, it'll just use "raw" | 17:44.14 |
| Robin_Watts | oh, yeah, I always forget that. | 17:44.29 |
| | It'll assume png I think. | 17:44.34 |
| ray_laptop | Robin_Watts: mvrhel recalls mudraw had something to render multi-threaded in bands | 17:44.53 |
| Robin_Watts | ray_laptop: Nope. Nothing multithreaded in mudraw. | 17:45.08 |
| | We have an example app (multithreaded.c) that uses bands. | 17:45.31 |
| ray_laptop | Robin_Watts: I hope it doesn't use png -- that's MUCH slower than ppmraw or just raw | 17:45.34 |
| Robin_Watts | ray_laptop: It's png by default, I'm afraid. | 17:45.48 |
| | cos png was the first thing we ever supported. | 17:46.02 |
| ray_laptop | Darn! | 17:46.04 |
| | So, we'll need to customize mudraw to default to ppmraw | 17:46.51 |
| Robin_Watts | let me look at doing a version that takes a band height as a param. | 17:47.06 |
| | Oh, hmm. | 17:47.15 |
| | All our pixmap writing code assumes that we have the whole pixmap in memory. | 17:47.37 |
| | I suspect that you may be better off doing a custom app based on a cutdown mudraw.c | 17:48.01 |
| ray_laptop | Robin_Watts: mvrhel says "that would be great" | 17:48.02 |
| Robin_Watts | So, if I do such an app for you... | 17:48.14 |
| ray_laptop | Robin_Watts: right | 17:48.17 |
| Robin_Watts | What formats do you want? | 17:48.22 |
| | just ppmraw ? | 17:48.26 |
| ray_laptop | yes | 17:48.31 |
| Robin_Watts | and just rgb? | 17:48.34 |
| ray_laptop | internally it's always RGB, right ? | 17:48.55 |
| Robin_Watts | rgb or greyscale | 17:49.01 |
| ray_laptop | RGB is good enough | 17:49.15 |
| Robin_Watts | ok, so we want a cutdown mudraw that only does ppmraw output at a configurable band height. | 17:49.41 |
| ray_laptop | Robin_Watts: right, that we can write to a file or /dev/null | 17:50.04 |
| | mvrhel says Thank You ! | 17:50.18 |
| Robin_Watts | I'll trade it to mvrhel in exchange for a function that will take a pcs and give me a polarity :) | 17:50.20 |
| ray_laptop | mvrhel says "sold" | 17:53.00 |
| tor7 | Robin_Watts: ray_laptop: mudraw -m without an output file will render to ram, run an md5 checksum on the result and print that. if you want to benchmark without getting filesystem overhead in the way. | 18:03.53 |
| | sorry, it only does md5 checksum with -5 (-m5) and -m will do a benchmark render to ram only | 18:04.39 |
| ray_laptop | Robin_Watts: can you think of anything else that is easy (or needed) that would help mupdf benchmarking as a "printer" rip ? | 18:04.40 |
| Robin_Watts | ray_laptop: Not offhand. | 18:05.08 |
| tor7 | ray_laptop: mudraw -m without -o will benchmark rendering performance without I/O overhead | 18:05.18 |
| ray_laptop | tor7: actually that sounds good enough (we wouldn't want the md5 overhead, so -m sounds like the ticket) | 18:05.30 |
| | I'll make sure mvrhel knows this | 18:06.03 |
| tor7 | Robin_Watts: it might be easier to tweak "docs/example.c" to do banded rendering as a quick benchmark app | 18:06.37 |
| | but having banded rendering in mudraw would be nice | 18:06.48 |
| Robin_Watts | tor7: I think I can just add banded rendering to mudraw. | 18:06.52 |
| ray_laptop | and what about memory usage ? anything better than memento | 18:07.00 |
| Robin_Watts | The most painful part is splitting the bitmap writing out. | 18:07.04 |
| | ray_laptop: I can add a flag to mudraw to track that too. | 18:07.28 |
| ray_laptop | Robin_Watts: looks like that was already done. So | 18:07.33 |
| | Robin_Watts: that would be handy | 18:07.46 |
| mvrhel_laptop | Robin_Watts: thanks a bunch for you help with this | 18:35.27 |
| Robin_Watts | mvrhel_laptop: No worries. | 18:35.39 |
| mvrhel_laptop | getting mupdf on raspberry pi now | 18:35.44 |
| Robin_Watts | mvrhel_laptop: Do you need .pbm format? (i.e. monochrome rather than greyscale?) | 18:36.50 |
| mvrhel_laptop | Robin_Watts: for now we are looking at timings for a color laser printer | 18:37.34 |
| | so just the contone rgb is what I need, but I am sure in the future we may want pbm | 18:38.04 |
| Robin_Watts | ok, I have banded working here. | 18:50.51 |
| | on robin/master | 18:53.31 |
| | If tor7 looks it over we can see about minimising the hackery, but it should be enough to get mvrhel_laptop working. | 18:54.06 |
| | I'll look at adding something to track memory use now. | 18:54.16 |
| mvrhel_laptop | ok. is there anything special about building mupdf on linux? I see I needed some X11 stuff. Do I just do make? | 18:59.59 |
| | Robin_Watts: ^^ | 19:00.04 |
| Robin_Watts | NOX11=1 make | 19:00.36 |
| mvrhel_laptop | ah | 19:00.49 |
| | and that seems to be doing a debug build? | 19:01.41 |
| | at least everything is going into build/debug | 19:01.51 |
| | Robin_Watts: ^^ | 19:02.52 |
| Robin_Watts | NOX11=1 make build=release | 19:03.01 |
| mvrhel_laptop | hehe | 19:03.07 |
| | ok thanks | 19:03.10 |
| Robin_Watts | sorry. | 19:03.17 |
| mvrhel_laptop | np | 19:04.11 |
| | I should know these things | 19:04.19 |
| | perfect. now let me see if I can get what you have in your repos | 19:05.31 |
| Robin_Watts | OK, new commit there with memory use tracking too. | 19:12.24 |
| | I'm going to cook a pizza. will be back in a mo. | 19:12.33 |
| mvrhel_laptop | Robin_Watts: ok great. | 19:16.48 |
| | ok. I was able to apply the first patch on my ubuntu mupdf checkout. just doing that while the raspberry pi is still building | 19:19.51 |
| | grabbing second patch | 19:20.06 |
| | so if I understand correctly I will want to do -r 1200 -b 0 -m -c rgb -B "Magic value to test" | 19:28.01 |
| mvrhel | hmm -M does not seem to work Robin_Watts | 19:30.44 |
| | oh hold on | 19:31.20 |
| Robin_Watts | works for me. What command line? | 19:31.46 |
| mvrhel | ./mudraw -r600 -b0 -B100 -M J9_acrobat.pdf | 19:32.08 |
| | comes back with "nothing to do" | 19:32.25 |
| Robin_Watts | You need a -o out | 19:32.32 |
| mvrhel | oh. ok. ./mudraw -r600 -b0 -B100 -m J9_acrobat.pdf worked fine | 19:32.53 |
| | that was my confusion | 19:33.01 |
| | ok working now | 19:33.48 |
| | very good | 19:34.01 |
| | thanks Robin_Watts ! | 19:34.05 |
| Robin_Watts | no worries. | 19:34.12 |
| | Are you getting valid results? :) | 19:34.21 |
| mvrhel | have to eat lunch now. raspberry pi is done building. will apply patches on that, then test on there | 19:34.29 |
| Robin_Watts | ok. I'll check back in during the evening. | 19:34.46 |
| mvrhel | ok thanks | 19:34.50 |
| Robin_Watts | text me if I am away from keyboard. | 19:35.06 |
| mvrhel | building with patches on raspberry pi | 20:05.08 |
| Robin_Watts | mvrhel: just checking in. | 20:24.50 |
| mvrhel | Robin_Watts: running now | 20:35.10 |
| | wife as house guests coming tonight so I am attempting to multiplex | 20:35.28 |
| Robin_Watts | I understand | 20:36.02 |
| mvrhel | Robin_Watts: is the default color space rgb? | 20:37.11 |
| | if I dont specify? | 20:37.16 |
| Robin_Watts | mvrhel_laptop: It's picked up from the suffix of the -o filename | 20:37.38 |
| | default is png | 20:37.47 |
| mvrhel | and if I am doing -m there is no -0 | 20:37.52 |
| | -o | 20:37.54 |
| Robin_Watts | rgb raw. | 20:38.01 |
| mvrhel | ok thanks | 20:38.04 |
| mvrhel_laptop | ok so I am going to play around a bit with the -B size. | 20:41.27 |
| | with -B100 mupdf took twice as long as gs on the J9 file | 20:41.45 |
| Robin_Watts | what bandheight was gs using ? | 20:42.07 |
| mvrhel_laptop | good question. I had specified a buffer space amount for gs | 20:42.29 |
| Robin_Watts | what amount? | 20:42.37 |
| mvrhel_laptop | 16M | 20:42.42 |
| | was the best | 20:42.45 |
| | I am also running 1200 dpi A4 | 20:42.56 |
| Robin_Watts | a4 is 8.5" right? | 20:43.12 |
| mvrhel_laptop | 8.27 | 20:43.59 |
| | a little smaller than letter | 20:44.20 |
| Robin_Watts | 29772 bytes per scanline then for rgb. | 20:44.43 |
| | so 563 bandheightish | 20:45.05 |
| | mupdf uses 4 bytes per pixel for rgb. | 20:45.21 |
| mvrhel_laptop | ok | 20:45.25 |
| | let me try that | 20:45.30 |
| | that is speeding it up a bit | 20:46.12 |
| Robin_Watts | A bandheight of 422 will take about 16 Meg with mupdf. | 20:46.41 |
| | oh, did you build with ARCH_ARM ? | 20:48.49 |
| mvrhel_laptop | uh no | 20:49.12 |
| Robin_Watts | There may be some additional speedups we can get then. | 20:49.24 |
| mvrhel_laptop | ok good . mupdf is taking 95 secs vs 60 secs with gs | 20:49.36 |
| Robin_Watts | for the bitmap scaling and color conversion. | 20:49.38 |
| mvrhel_laptop | so what do I need to do NOX11=1 ARCH_ARM =1 make build=release | 20:50.23 |
| | ? | 20:50.25 |
| Robin_Watts | mvrhel_laptop: Are you comparing mupdf against gs with -dTextAlphaBits=8 -dGraphicsAlphaBits=8 ? | 20:50.35 |
| mvrhel_laptop | no AA | 20:50.42 |
| | for either | 20:50.44 |
| | 1200 dpi not needed | 20:50.50 |
| | I have -b0 | 20:50.56 |
| | for mupdf | 20:50.59 |
| Robin_Watts | Ah, right. | 20:51.04 |
| mvrhel_laptop | Robin_Watts: Is above correct? | 20:51.28 |
| Robin_Watts | Using -b 0 we build the antialiasing in, but disable it in software. | 20:51.38 |
| | mvrhel_laptop: Thinking. | 20:52.09 |
| mvrhel_laptop | is NOX11=1 ARCH_ARM =1 make build=release correct? | 20:52.13 |
| Robin_Watts | I think... | 20:52.32 |
| | NOX11=1 make build=release XCFLAGS="-DARCH_ARM" | 20:53.00 |
| mvrhel_laptop | ok | 20:53.08 |
| Robin_Watts | NOX11=1 make build=release XCFLAGS="-DARCH_ARM -DAA_BITS=0" | 20:53.41 |
| mvrhel_laptop | ok | 20:53.54 |
| Robin_Watts | That might be slightly faster than using -b 0. | 20:54.04 |
| mvrhel_laptop | hmm that does not work | 20:54.35 |
| Robin_Watts | what's the error ? | 20:55.05 |
| mvrhel_laptop | make: nothing to be done for 'default' | 20:55.17 |
| Robin_Watts | you need to make build=release clean | 20:55.31 |
| mvrhel_laptop | ah yes. ok all is well now | 20:56.21 |
| | compiling takes some time. off to start ice cream maker brb | 20:56.34 |
| Robin_Watts | np. | 20:56.40 |
| | We *may* be able to further improve bitmap scaling performance by building with: | 21:05.13 |
| | NOX11=1 make build=release XCFLAGS="-DARCH_ARM -DAA_BITS=0 -DARCH_ARM_CAN_LOAD_UNALIGNED" | 21:05.29 |
| | but I don't know if that will work on the pi or not. It's down to how the ARM has been set up. | 21:05.52 |
| | You could do a build to try it out - but keep your old binary in case :) | 21:06.12 |
| ray_laptop | Robin_Watts: what's the option you added to report memory usage ? | 21:11.39 |
| Robin_Watts | -M | 21:11.48 |
| ray_laptop | Robin_Watts: I see so mvrhel wants -m -M | 21:12.23 |
| mvrhel_laptop | still building... | 21:12.24 |
| ray_laptop | Robin_Watts: -b 0 is still OK if built with -DAA_BITS=0, right ? | 21:13.00 |
| Robin_Watts | ray_laptop: yes. | 21:13.07 |
| ray_laptop | well, I hope that mupdf can get up to at least as fast as gs ;-) | 21:13.54 |
| | mvrhel: were you using the gs PDF times or the gs PS times (the latter are faster, iirc) | 21:14.21 |
| Robin_Watts | I suspect it won't without some more major fiddling. | 21:14.21 |
| | Perhaps I should spend some time setting my rpi up and doing some tests. | 21:14.48 |
| mvrhel_laptop | I am comparing PDF to PDF | 21:14.55 |
| | just looking at J9 now (smallest file) | 21:15.11 |
| ray_laptop | frankly I am surprised that it is slower (having traced through the spaghetti that is gs) | 21:15.13 |
| mvrhel_laptop | gs is CMYK contone 1200 dpi A4 | 21:15.25 |
| ray_laptop | mvrhel from the PDF or the PS | 21:15.40 |
| mvrhel_laptop | PDF | 21:15.46 |
| ray_laptop | so going from PS is even faster ? | 21:16.00 |
| mvrhel_laptop | yes PS is faster | 21:16.07 |
| | what is intersesting is that gs pdf 1200 dpi contone is not much different compared to 600 dpi 4bpp at 600dpi | 21:18.13 |
| Robin_Watts | Do the J files have much in the way of transparency etc? | 21:18.13 |
| mvrhel_laptop | one of them does | 21:18.20 |
| | at least for J9 on the above comment | 21:18.42 |
| Robin_Watts | but if it's just 1 that's not the main issue. | 21:18.43 |
| mvrhel_laptop | but comparing PS to PDF for example, J9 at 600dpi 4bpp cmyk, PDF was 56 sec, and PS was 36 sec in clist mode and 27 sec in immediate mode | 21:19.51 |
| | ok done building | 21:20.08 |
| | let me run previous command | 21:20.15 |
| ray_laptop | mvrhel: I only see one page of J11 that has transparency | 21:20.45 |
| mvrhel_laptop | ok | 21:20.52 |
| | that may be the one that also has overprint | 21:21.03 |
| | oh I was going to check for interpolation too | 21:21.09 |
| | ok. same time with mupdf as before the arm compile option | 21:22.30 |
| ray_laptop | Robin_Watts: many of these have Japanese text on them. Is the font caching of mupdf decent ? | 21:22.43 |
| Robin_Watts | ray_laptop: Yes. | 21:22.53 |
| mvrhel_laptop | so i gs getting an advantage that it is doing A4 ? | 21:23.07 |
| | what page size does mupdf use by default? | 21:23.36 |
| ray_laptop | mvrhel: isn't mupdf doing A4 ? That's the media size isn't it ? | 21:23.41 |
| mvrhel_laptop | and can I specify | 21:23.42 |
| | I dont know | 21:23.47 |
| Robin_Watts | mupdf runs at media size. | 21:23.53 |
| | so it's doing the right thing. | 21:24.44 |
| mvrhel_laptop | ok | 21:24.50 |
| ray_laptop | J2 is the only one that is A3 and you aren't testing it | 21:25.02 |
| mvrhel_laptop | now at 600dpi mupdf is faster | 21:25.03 |
| | than gs | 21:25.05 |
| | gs took 56 sec for J9 | 21:25.16 |
| Robin_Watts | What OS are you using on the pi? | 21:25.16 |
| mvrhel_laptop | mupdf took 27 secs | 21:25.24 |
| ray_laptop | awesome. Faster than gs PDF or faster than gs PS ? | 21:25.28 |
| mvrhel_laptop | faster than gs PDF | 21:25.34 |
| | it ran the same as gs PS immediate mode | 21:25.51 |
| ray_laptop | mvrhel: apples to apples (both 1200 dpi RGB) ? | 21:25.57 |
| | because above you had 1200 dpi 4-bit CMYK | 21:26.28 |
| | for gs | 21:26.34 |
| mvrhel_laptop | oh true | 21:26.36 |
| | gs is doing 600dpi 4bit in this particular case | 21:26.48 |
| Robin_Watts | mvrhel_laptop: Did you use NOOBS ? | 21:26.50 |
| mvrhel_laptop | the 1200 dpi is all contone | 21:27.02 |
| | Robin_Watts: so it is using Debian | 21:27.29 |
| | I had a sdcard already loaded | 21:27.40 |
| | and updated | 21:27.45 |
| | after starting | 21:27.54 |
| Robin_Watts | Debian, not raspbian ? | 21:27.56 |
| mvrhel_laptop | hmm I would have to reboot to see what comes up officially | 21:28.27 |
| Robin_Watts | Not all distros use the hardware floating point on the pi. | 21:28.34 |
| mvrhel_laptop | I assume that it is some simplied version of Debian | 21:28.37 |
| | Robin_Watts: I have a fpu. How do I check if I have one that does | 21:28.55 |
| | use it | 21:29.03 |
| | that would be a killer | 21:29.08 |
| Robin_Watts | mvrhel_laptop: All the pi's have an FPU as part of the ARM. | 21:29.25 |
| mvrhel_laptop | yes | 21:29.29 |
| | I know that | 21:29.30 |
| ray_laptop | the kernel probably doesn't have much FP use. And mupdf is built to use h/w FP, right ? | 21:29.37 |
| Robin_Watts | It's just that not all the distros use hard float, some use soft float. | 21:29.44 |
| mvrhel_laptop | how do I check that | 21:29.51 |
| | I am ok there | 21:30.02 |
| ray_laptop | disasm ? | 21:30.06 |
| Robin_Watts | https://wiki.debian.org/RaspberryPi | 21:30.33 |
| mvrhel_laptop | autogen would have reported yes? | 21:30.38 |
| Robin_Watts | autogen? | 21:31.46 |
| mvrhel_laptop | never mind I was thinking of something else | 21:31.58 |
| | brb | 21:32.00 |
| Robin_Watts | dmseg | less and look in there? See if it says armel or raspbian | 21:32.35 |
| ray_laptop | looks like armhf is also an issue ? | 21:33.42 |
| Robin_Watts | armhf won't work. | 21:33.55 |
| | as armhf requires an ARMv7 and the pi is ARMv6 | 21:34.14 |
| | The beagleboard here is ARMv7 I believe. | 21:34.31 |
| ray_laptop | that's what I think is saying. And It is compatible with Debian armel (armv4t, soft(emulated) FP), but floating-point tasks will be slow when running the Debian armel port. | 21:34.50 |
| mvrhel_laptop | ok back | 21:34.53 |
| Robin_Watts | dmesg | less ? | 21:35.19 |
| ray_laptop | Robin_Watts: but does that affect the apps or just the kernel ? | 21:35.31 |
| Robin_Watts | everything. | 21:35.39 |
| ray_laptop | oh :-( | 21:35.46 |
| | that will affect gs as well (maybe not as much as mupdf) | 21:36.11 |
| mvrhel_laptop | Robin_Watts: that did not work | 21:36.39 |
| | but I restarted | 21:36.46 |
| | and it says Debian GNU/Linux 7 raspberry pi tty1 | 21:37.10 |
| | on start up | 21:37.13 |
| | oh | 21:37.55 |
| ray_laptop | what about uname -a | 21:38.10 |
| mvrhel_laptop | it does say | 21:38.11 |
| | Linux raspberrypi 3.6.11+ | 21:38.38 |
| Robin_Watts | Essentially, unless you're running raspbian you're not using hardware FP. | 21:39.27 |
| mvrhel_laptop | specifically Linux raspberrypi 3.6.11+ #474 PREEMPT Thu Jun 13 armv6l GNU/Linux | 21:39.47 |
| | so I think I am using the proper thing | 21:40.02 |
| | let me try a larger band size with mupdf. it is blazing at 600dpi | 21:40.31 |
| Robin_Watts | Right, professor google suggests that that is Raspbian. | 21:41.31 |
| mvrhel_laptop | good | 21:42.58 |
| | personally, I dont understand why you would ever need contone at 1200dpi | 21:43.29 |
| | I would think you would take 600 and the do an expansion via the threshold screen | 21:43.49 |
| ray_laptop | mvrhel: I agree | 21:44.46 |
| mvrhel_laptop | part of me wants to just give the 600dpi data and not share 1200 dpi contone | 21:45.17 |
| Robin_Watts | Nonetheless, it sounds like it's worth me having a quick look at mupdf to see if I can see where the performance is going. | 21:45.23 |
| ray_laptop | but there are some people that insist that they can see the difference between 600 and 1200 dpi text. I don't believe them, of course | 21:45.36 |
| Robin_Watts | 1200dpi with a bandheight of 400 or so? | 21:46.05 |
| ray_laptop | mvrhel: I'd go with 1200 dpi 4-bit and 600 dpi contone | 21:46.09 |
| Robin_Watts | That's a 3rd of an inch per band. | 21:46.19 |
| mvrhel_laptop | ray_laptop: that sounds like a good idea | 21:46.24 |
| ray_laptop | at least for gs. Then compare that to mupdf 600 dpi contone | 21:46.30 |
| Robin_Watts | I bet we're slicing lots of text doing that. | 21:46.50 |
| mvrhel_laptop | brb | 21:46.59 |
| Robin_Watts | Gotta go get Helen from the station. | 21:47.14 |
| ray_laptop | Robin_Watts: is the font cache held between bands. If not, that could be a killer to have to re-render glyphs | 21:47.57 |
| Robin_Watts | ray_laptop: It is. | 21:48.13 |
| ray_laptop | OK. that means that slicing text isn't too bad (probably). clipping bitmaps is easy, comparitively | 21:48.54 |
| mvrhel_laptop | ray_laptop: ok I am going to work on getting numbers together as you suggest. gs and mupdf at 600dpi contone | 21:55.19 |
| | and gs at 1200 dpi 4bpp | 21:55.28 |
| | does that sound reasonabl? | 21:55.37 |
| | I will also run mupdf at 1200 dpi for us to look over | 21:55.48 |
| | I am going to play around a bit with the band height on mupdf | 21:56.02 |
| | doing large heights helps | 21:56.10 |
| ray_laptop | oh, darn. cust 532's latest issue is an indexed colorspace that looks like it has a 'lookup' string that gets freed during a 'restore', but we still have a 'ref' laying around that points to that string. :-( | 21:57.40 |
| mvrhel_laptop | customer with 8.71 question too.... | 21:57.54 |
| | ok. need to head out for a bit. ray_laptop and Robin_Watts thanks for the help | 21:58.30 |
| ray_laptop | mvrhel: is that Leitermann ? | 21:58.31 |
| mvrhel_laptop | ray_laptop: yes | 21:58.37 |
| sebras | Robin_Watts: I have about 15 fuzz-testing errors for the released mupdf. | 22:14.57 |
| | Robin_Watts: is it necessary to create 15 bugs or can I upload all files into a single bug-report? | 22:15.18 |
| | hm... given that the files all together are about 140MB I opt for uploading them all to a single bug (then I can compress them to 5MB which seems more reasonable). | 22:21.07 |
| | who manages bugzilla? is it marcosw? mupdf version 1.2 and 1.3 are both missing in the list when reporting new bugs. | 22:27.09 |
| sebras | wonders why he always is active on friday nights/evenings... | 22:32.53 |
| Robin_Watts | sebras: Interesting. | 23:13.32 |
| sebras | Robin_Watts: which part? | 23:13.55 |
| Robin_Watts | The fuzzing stuff in general. | 23:14.06 |
| sebras | Robin_Watts: ok. I was unsure if any of you know how it works. | 23:14.39 |
| | and zzuf seems easy enough to automate. | 23:14.49 |
| Robin_Watts | No, I've never used a fuzzing tool, and zzuf does indeed seem interesting and automatable based on your write up. | 23:15.08 |
| sebras | Robin_Watts: of course you could overwhelm yourselves with fuzzing bugs, but on the other hand you'd rather fix the bugs before customers find them. :) | 23:16.26 |
| | Forward 1 day (to 2013/08/17)>>> | |
IRC Logs