| | <<<Back 1 day (to 2013/04/01) | 2013/04/02 |
| Robin_Watts | http://www.lexmarknewsblog.com/funai-acquiring-lexmarks-inkjet-related-technology-and-assets/ | 00:03.44 |
| k-man | hi, is this patch in 9.05? http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=430e9e345c84912f953161aa843b37f235c97708 | 04:04.27 |
| | hmm... doesn't look like it | 04:06.48 |
| | can i just patch my pdf_font.ps? | 04:07.00 |
| vtorri | hey | 07:34.08 |
| ghostbot | salut | 07:34.08 |
| vtorri | question about licences | 07:34.13 |
| | mupdf is GPL | 07:34.22 |
| | if I write a library using mupdf (and which link mupdf statically against it), may my lib be LGPL ? | 07:34.52 |
| | and similar question : if I write a GUI with my lib, must it be GPL or may it be LGPL ? | 07:35.27 |
| chrisl | vtorri: mupdf is now AGPL (as will the next release of jbig2dec). I don't see the point, though, if you write something that depends on mupdf, users will need to abide by the mupdf license in order to use your lib, anyway. | 07:38.42 |
| vtorri | I don't know AGPL | 07:39.00 |
| chrisl | Affero GPL | 07:39.13 |
| | http://www.gnu.org/licenses/agpl-3.0.html | 07:39.43 |
| vtorri | is it less strict than GPL ? | 07:40.10 |
| chrisl | No, more | 07:40.17 |
| vtorri | haha | 07:40.24 |
| | so my library must be GPL, i guess | 07:40.45 |
| chrisl | But the extra restrictions refer to "software as a service" type applications, so are unlikely to have any practical impact on you | 07:41.24 |
| | vtorri: the LGPL is falling in popularity, anyway, at least for anything other than "core" libraries like glibc | 07:43.44 |
| vtorri | ok | 07:44.51 |
| | but i think that my lib must be GPL | 07:45.00 |
| kens | chrisl ping | 07:45.51 |
| vtorri | gst, gtk are LGPL, iirc | 07:46.02 |
| chrisl | I *think* it will have to be AGPL if you link with mupdf and/or (future) jbig2dec - you are free to use a *more* restrictive license than we do, but not a less restrictive one - but don't take that as gospel. | 07:46.36 |
| | kens: pong | 07:46.40 |
| kens | chrisl how do I use valgrind ? :-) | 07:46.54 |
| chrisl | kens: is it installed? | 07:47.09 |
| kens | No idea, I can install it easily enough | 07:47.20 |
| vtorri | chrisl, ??? then what is the interest to propose GPL if people must use AGPL ?? | 07:47.31 |
| kens | computer, syas no but offers to install it | 07:47.41 |
| | DOing that now | 07:47.50 |
| chrisl | vtorri: I didn't propose GPL, you did | 07:48.17 |
| | kens: once installed, you just prepend the gs command line with "valgrind" | 07:48.42 |
| kens | chrisl OK trying that now thanks | 07:48.55 |
| | cd bin | 07:49.02 |
| | LOL | 07:49.10 |
| chrisl | kens: to get the same output as marcosw reported, you probably need to use the "--track-origins=yes" option for valgrind | 07:49.52 |
| kens | chrisl right now I'd just like to see whether I get any warnings... | 07:50.20 |
| chrisl | kens: okay. Just as an example, here's the command line I was just running: http://pastebin.com/KFFtXK6s | 07:51.10 |
| kens | pretty similar to what I'm typing, except I have a lot more options to set :-( | 07:51.39 |
| chrisl | the --track-origins has valgrind tell you not just where uninitialized variables/memory are access, but where they some from, too | 07:52.23 |
| kens | OK I'm not so bothered about that right now. I have 8 images which call the code section I want to look at and I need to reduce it to just the 1 which causes the problem | 07:53.08 |
| | ThenI need to instrument it, then try and understand teh code. | 07:53.23 |
| chrisl | Hmm, usually, valgrind errors reduce the need to cut down files like that - knowing the origin, the call stack and the line where data gets accessed is usually enough | 07:55.44 |
| vtorri | chrisl: "<vtorri> mupdf is GPL" | 07:55.45 |
| | aboce | 07:55.47 |
| | above* | 07:55.56 |
| | so i have spoken about GPL first | 07:56.12 |
| kens | chrisl its a memcmp, but its an image reduction, so I have 8 images which go through there, only one of which causes a problem, and then 'probably' because its running off the end of the data or something | 07:56.27 |
| chrisl | vtorri: mupdf is AGPL: http://www.mupdf.com/ - which is what I said, correcting your statement. | 07:56.59 |
| | kens: ah, that's more involved, yes :-( | 07:57.16 |
| vtorri | arg | 07:57.36 |
| | damn | 07:57.38 |
| | ok, sorry | 07:58.04 |
| chrisl | vtorri: the thing is, unless you want to leave your lib open for commercial use, you're probably just as well using the AGPL, too | 07:59.12 |
| vtorri | it's for open source stuff | 08:00.10 |
| | fr the Enlightenment project | 08:00.16 |
| | for* | 08:00.19 |
| chrisl | vtorri: right, I'd hope they'd be okay with the AGPL, though, since the additional restrictions in that over the GPL won't apply to their target application | 08:01.46 |
| kens | chrisl do you know much about how valgrind works ? | 09:09.27 |
| chrisl | kens: not a huge amount, what's up? | 09:10.23 |
| kens | I don't understand how there can be a problem. I expected that it would be a problem with a pointer off the end of a block of memeroy, but instead its complaining part way through the image | 09:11.07 |
| | Its OK before and after, just oneparticular scan line its complaining about | 09:11.25 |
| chrisl | Is it hitting padding bits at the end of a scanline? | 09:11.50 |
| kens | Hard to say, more likely would be a 'hole' in the tensor patch I think, but I was wondering how it could tell. | 09:12.22 |
| chrisl | valgrind is a sort of virtual machine, so every memory access is tracked through the virtual hardware layer, so it can track when bytes (and maybe bits) are uninitalised | 09:13.32 |
| kens | Hmm. SO if the shading allocted a block of memory for the image result, then only filled in part of it with data, valgeind could tell ? | 09:14.21 |
| chrisl | Yeh | 09:14.31 |
| kens | OK then this is not my problem, and I'm going to wish it onto someone else. | 09:14.47 |
| chrisl | It sounds like that's right. | 09:15.59 |
| kens | THanks | 09:16.06 |
| Robin_Watts | kens: I think there is going to be a lot of passing valgrind bugs between us. | 09:16.10 |
| kens | Robin_Watts : Not a problem,. I just needed to understand whether what I was thinking made any sense, and apparentl;y it does. | 09:16.39 |
| | I didn't want to waste someone else's time with my problems ;-) | 09:16.55 |
| Robin_Watts | Morning tor8, paulgardiner | 10:00.08 |
| paulgardiner | Hi | 10:00.17 |
| ghostbot | hello, paulgardiner | 10:00.17 |
| Robin_Watts | tor8: There are 3 (I think) reviews on robin/master for you. | 10:00.18 |
| tor8 | morning all | 10:00.27 |
| Robin_Watts | Good easter, all? | 10:00.34 |
| paulgardiner | hi tor8 | 10:00.37 |
| | Too much food!!!! | 10:00.53 |
| | So yes, good. | 10:00.59 |
| tor8 | Robin_Watts: yes, apart from the fact that they stole an hour of it by the stupid daylight savings time crap! | 10:01.38 |
| Robin_Watts | tor8: Yeah, we've lost that twice now :) | 10:01.54 |
| kens | was partying | 10:02.06 |
| Robin_Watts | Middle age man partying... were you seeking to embarrass your teenage daughter? :) | 10:03.00 |
| paulgardiner | Robin_Watts: I've looked at those. I think we decided, we really needed tor8's eyes on the third one. | 10:03.05 |
| kens | It was my parents' Golden Wedding party | 10:03.15 |
| Robin_Watts | paulgardiner: Yeah. | 10:03.16 |
| | ah! So you were the youngster :) | 10:03.24 |
| kens | Kind of :-) Melanie was there, but she couldn't dance because my mother had made her wear her prom dress (which has a train). | 10:04.01 |
| tor8 | vtorri, chrisl: GLPv3 and AGPL have a mutual compatibility clause in there to allow libs/programs with those licenses to intermingle when linking | 10:08.45 |
| vtorri | tor8, so i can choose gpl v3 as licence for my lib ? | 10:09.15 |
| tor8 | vtorri: "Both the ordinary GNU GPL, version 3, and the GNU Affero GPL have text allowing you to link together modules under these two licenses in one program." | 10:10.41 |
| chrisl | tor8: I did indicate I wasn't sure....... | 10:11.06 |
| tor8 | vtorri: so yes, you may choose either gplv3 or agpl for your library if you want to use mupdf with it | 10:11.13 |
| | chrisl: I just checked :) | 10:11.32 |
| vtorri | tor8, " under these two licenses in one program." <-- does that mean i have to provide both licences ? | 10:11.38 |
| tor8 | vtorri: it means someone writing program "c" can link two libraries "a" and "b", even if "a" is gplv3 and "b" is agpl. | 10:12.27 |
| | vtorri: http://www.gnu.org/licenses/why-affero-gpl.html | 10:13.15 |
| vtorri | honestly, for me, that licence stuff is voodoo magic | 10:13.34 |
| | i don't (want to) understand it | 10:13.49 |
| | you answer with big sentences | 10:14.16 |
| Robin_Watts | vtorri: The difference between AGPL and GPL is pretty much nonexistent, unless you are writing code to run on a server. | 10:14.21 |
| vtorri | i asked someting simple | 10:14.23 |
| | tor8, so i can choose gpl v3 as licence for my lib ? | 10:14.26 |
| | i wanted to have an answer like "yes" or "no" | 10:14.41 |
| | not discussion on licences | 10:14.53 |
| tor8 | vtorri: I answered "yes" already. quote: "so yes, you may choose either gplv3 or agpl for your library" | 10:15.09 |
| vtorri | ok then | 10:15.28 |
| | thanks | 10:15.32 |
| tor8 | Robin_Watts: .desktop is okay (did you check the casing of mupdf vs MuPDF in the Name=View with mupdf key?) | 10:15.48 |
| | Robin_Watts: no objection against the bpc change, but I'd like to know the motivation | 10:16.00 |
| Robin_Watts | tor8: I need it for pdf write. | 10:17.27 |
| tor8 | Robin_Watts: delay decoding indexed looks okay too. I can't confess to understanding all the details, I have forgotten how the delayed decoding for images works | 10:17.29 |
| | Robin_Watts: right. | 10:17.38 |
| kens | chrisl my last commit got some funny make warnings about missing dependency on valgrind.h (I'm asuming this is Robin_Watts' change) | 10:43.49 |
| Robin_Watts | kens: My change should only require valgrind.h if ENABLE_VALGRIND is defined. | 10:46.03 |
| | but it's possible that the include checker isn't smart enough to realise that. | 10:46.18 |
| | so I'd just ignore the warnings. | 10:46.26 |
| kens | New makefile issues: | 10:46.29 |
| | gsinit.$(OBJ): missing dependency on $(valgrind_h) | 10:46.29 |
| | gxclfile.$(OBJ): missing dependency on $(valgrind_h) | 10:46.29 |
| | gxclist.$(OBJ): missing dependency on $(valgrind_h) | 10:46.29 |
| | gxclmem.$(OBJ): missing dependency on $(valgrind_h) | 10:46.29 |
| | valgrind.h: missing dependency on $(valgrind/helgrind_h) | 10:46.30 |
| Robin_Watts | Right, that's perfect. | 10:46.44 |
| kens | I'm not bothered, just mentingin it | 10:46.47 |
| Robin_Watts | actually... I should fix that. | 11:02.12 |
| | will do that after I run. | 11:02.21 |
| kens | No rush | 11:02.27 |
| chrisl | kens: sorry, I was torturing myself on the bike - I saw the warnings in my earlier pushes, but I'll leave it to Robin_Watts after he's back from torturing himself on foot! | 11:18.50 |
| kens | :-) | 11:18.58 |
| Robin_Watts | While I was torturing myself on foot, I was trying to think through a problem I've got in gs now. | 12:18.44 |
| | Valgrind is reporting that at least one byte in the middle of a scanline of a device is undefined. | 12:19.14 |
| | and it tells me where the device is defined. | 12:19.28 |
| kens | of a device ? | 12:19.29 |
| Robin_Watts | a mem device. | 12:19.35 |
| kens | So in the page bufer ? | 12:19.48 |
| Robin_Watts | There is no easy way to see what operations have happened on that device (and hence what might have marked the page). | 12:20.00 |
| kens | But the entire page should be erased by the initial erasepage | 12:20.39 |
| Robin_Watts | I was pondering writing some code so I can 'call TraceDevice(dev)' in the debugger at create time, which would intercept the procs so that it printed out what calls were made. | 12:20.45 |
| | Would anyone else find that useful? | 12:20.54 |
| kens | I thought we had a trace device, I guess it doesn't do that already ? | 12:21.15 |
| Robin_Watts | I thought the trace device was indeed something different. | 12:22.07 |
| kens | I admit I don't wactually know what it does | 12:22.21 |
| Robin_Watts | I don't think it allows for being hooked up at runtime, which is what I want. | 12:22.40 |
| kens | TAh | 12:22.45 |
| | I'm still puzzled as to why the erasepage hasn't cleared the whole page though | 12:23.17 |
| chrisl | The trace device is an "output device", not a passthrough device. | 12:24.47 |
| | But I agree with kens: we shouldn't be using "un-erased" raster memory | 12:25.28 |
| Robin_Watts | kens: yeah, I see the following backtrace for the first write to the buffer after creation: | 12:25.37 |
| | ==25987== Invalid read of size 4 | 12:25.53 |
| | ==25987== at 0x9247DC: bits_fill_rectangle (gsbitops.c:121) | 12:25.55 |
| | ==25987== by 0xA7DF9D: mem_mapped4_fill_rectangle (gdevm4.c:59) | 12:25.57 |
| | ==25987== by 0xA16DE4: gx_dc_pure_fill_rectangle (gxdcolor.c:788) | 12:25.58 |
| | ==25987== by 0xA6D355: gx_default_fillpage (gdevddrw.c:1125) | 12:26.00 |
| | ==25987== by 0x954BCF: gs_fillpage (gspaint.c:93) | 12:26.02 |
| | ==25987== by 0x592D51: zfillpage (zpaint.c:50) | 12:26.03 |
| | oh, that's a read. even stranger. | 12:26.14 |
| kens | Ah, I think that *is* the erasepage | 12:26.17 |
| Robin_Watts | kens: Yes. | 12:26.28 |
| kens | But I don't see why its reading 4 bytes | 12:26.29 |
| | let me look at the code | 12:26.40 |
| chrisl | Oh, goody, a macro :-( | 12:27.00 |
| Robin_Watts | kens: I wasn't intending to trouble you with this, just supporting your case. | 12:27.05 |
| kens | Its OK I'm running valgrind in the background | 12:27.27 |
| | Trying to isolate another problem | 12:27.37 |
| Robin_Watts | Ah, it's bitmasking. | 12:28.01 |
| kens | Oddly it is masking data in | 12:28.02 |
| Robin_Watts | valgrind supposedly tracks undefined memory on a bit level. | 12:28.16 |
| chrisl | So, it's almost certainly benign | 12:28.27 |
| Robin_Watts | but it seems to have problems with bit level ops. | 12:28.29 |
| kens | Yes, I guess this is 'probably' some kind of erasure with a known colour, but I'd have to track back to find out | 12:28.48 |
| | Back in a minute | 12:29.00 |
| Robin_Watts | *ptr &= ~mask where mask = -1 | 12:30.03 |
| chrisl | Robin_Watts: could we special case a "normal" erase, and just memset the entire raster in one go? It would probably be faster, too | 12:30.35 |
| Robin_Watts | chrisl: as part of every possible bitdepth? | 12:31.01 |
| | This code already special cases 0 and FFFFFFFF fills. | 12:31.42 |
| chrisl | Oh, so this isn't a "normal" erasepage, then? | 12:32.10 |
| | It's not erasing to white?# | 12:32.20 |
| | Robin_Watts: The only other option that I see right now is to memset() the raster at allocation time for PACIFY_VALGRIND, but that risks masking "real" problems. | 12:33.59 |
| Robin_Watts | chrisl: indeed. | 12:43.22 |
| | I am tempted to try with a less stoneaged version of valgrind... | 12:43.35 |
| | after lunch. bbs. | 12:44.16 |
| kens | I'm running a reasonably current version of valgrind I think, I can try the run if you want Robin_Watts (when you get back from lunch) | 12:52.07 |
| chrisl | Current version is 3.8.1, I'm running 3.7.0 | 12:54.00 |
| kens | Then mine is also old, I have 3.5.0 | 12:54.10 |
| | I guess that's whatever Fedora last packaged | 12:54.23 |
| | I should probably install a more recent Linux | 12:55.07 |
| chrisl | You can probably just upgrade Fedora | 12:55.28 |
| kens | Maybe, 14->18 might be a big step :-) | 12:55.47 |
| chrisl | Eek, yeh - I'd take a backup before trying it! | 12:56.03 |
| kens | I'd probably just install 18 from scratch | 12:56.20 |
| chrisl | You should be able to take a snapshot of your current VM, if the upgrade fails, you can revert to the snapshot, and do an install from scratch instead | 12:57.11 |
| kens | Yes I could do that too, not too bothered right at the moment, I may do it if it becomes important | 12:57.36 |
| chrisl | Hmmm, I'd hoped there might a Ubuntu PPA of the latest valgrind, but I can't find one | 12:57.59 |
| kens | Well, you can always build it I guess | 12:58.17 |
| chrisl | I could, but I hate the way it can end up confusing the package manager when I do that - and I really can't be bothered making a .deb package out of it | 12:59.23 |
| kens | Well I think I'm doing well just to be able to run valgrind here.... | 13:00.06 |
| chrisl | Given that you're running essentially a virtual machine inside a virtual machine, I bet it ain't quick! | 13:01.00 |
| kens | Its not bad, only takes a couple of minutes for the files Marcos highlighted | 13:01.23 |
| chrisl | That's not bad at all - I've use it on a few cases that took *hours* to run on "real" hardware - haven't run across one from Marcos's reports yet, though | 13:02.31 |
| kens | I was prepared for it to be *much* worse. Even the 7Mb PostScript file was only about 5 minutes | 13:03.00 |
| | ell that seems to be all my current valgrind problems dealt with, one real bug exhibiting in several different places, and a couple that don't seem to be anything to do with me. | 13:04.37 |
| Robin_Watts | My ubuntu has 3.7.0 | 13:39.16 |
| | let me try it here. | 13:39.20 |
| | (I was working on peeves) | 13:39.25 |
| kens | Well that's reasonably up to date | 13:39.29 |
| pod`_ | hi all, I try to process a pdf file in gs with truetype font. When I use pdfwrite device, the gridfitting is done, but if I use png device or other device, gridfitting is never done. | 14:46.48 |
| kens | pdfwrite does not do gridfitting, it simply embeds the font wholesale | 14:47.09 |
| Robin_Watts | 15 minutes to meeting. Time to fetch tea. | 14:48.07 |
| pod`_ | yes it's not really done but it pass in the gridfitting code to embbed the font, ok | 14:48.50 |
| | but why this is not done when I try to output an image? | 14:49.06 |
| chrisl | pod`_: what OS are you using? | 14:49.48 |
| pod`_ | OSX | 14:49.54 |
| chrisl | Presumably with GS from macports or similar? Or did you build it yourself? | 14:50.22 |
| pod`_ | I build it myself | 14:50.32 |
| | I put breakpoint in gridfitting code, but it never break when I output image | 14:50.58 |
| kens | *WHICH* gridfitting code ? | 14:51.11 |
| | GS uses FreeType by default these days | 14:51.21 |
| | But the old code is still present as a default | 14:51.29 |
| pod`_ | I try both I think | 14:51.33 |
| | or.. it don't break for some other reason hmm | 14:51.50 |
| | when I process with pdfwrite device, it breaks in base/ttinterp.c | 14:52.29 |
| kens | Only because it uses that code to get glyph metrics, if I recall correctly. | 14:53.36 |
| | I'm almost certain the rendering code will not call that. | 14:53.45 |
| pod`_ | but it done the whole gridfitting | 14:54.06 |
| kens | If you mean pdfwrite, no it didn't it just runs the glyph program | 14:54.23 |
| | Unless your font is a CIDFont and you are outputting to ps2write, in which case it will render the bitmap | 14:54.43 |
| | Really, your question is too vague. If you wold like to put an example somewhere, then we can look at it. | 14:55.14 |
| pod`_ | hmm ok | 14:55.31 |
| | i'll try make it clear | 14:55.43 |
| | (but I also suck in english :/) | 14:55.50 |
| kens | No your English is fine, I'm just not clear on what you want | 14:56.04 |
| pod`_ | I have a pdf | 14:56.11 |
| | if I open it with my own pdf viewer | 14:56.36 |
| | I have a glitch on a font | 14:56.44 |
| | but acrobat dont have it | 14:56.49 |
| | the problem may be with my gridfitter interpreter | 14:57.05 |
| kens | Hmm, possibly | 14:57.20 |
| pod`_ | so I want to know if gs also have the bug | 14:57.24 |
| | and if acrobat just skip gridfitting | 14:57.39 |
| | or if my interpreter suck | 14:57.56 |
| kens | Depending which OS you are on Acrobat uses the OS TrueType interpreter | 14:58.01 |
| Robin_Watts | pod`_: When you run gs to a bitmap device, we use freetype to do the font handling. That will be responsible for "the gridfitting" as you put it. | 14:58.23 |
| kens | So on WIndoiws it definitely uses the Windows interpreter, on Linux I believe it does its own thing, on OS/X I expect it uses the Apple TT interpreter | 14:58.34 |
| Robin_Watts | so you want to be putting breakpoints in freetype, not in base/ttinterp.c | 14:58.52 |
| kens | Indeed | 14:59.03 |
| pod`_ | ok! | 14:59.22 |
| kens | Infatc ttinterp.c is a hacked version of FreeType 1.0 anyway | 14:59.28 |
| pod`_ | so I just have a problem with gcc don't breaking in freetype code | 14:59.37 |
| kens | s/Infatc/In fact/ | 14:59.40 |
| henrys | meeting #1? | 15:00.17 |
| Robin_Watts | henrys: indeed. | 15:00.32 |
| henrys | paulgardiner:so printing looks to be very pdf based. | 15:01.18 |
| chrisl | pod`_: put a breakpoint in load_glyph() in base/fapi_ft.c that's our interface to freetype | 15:01.29 |
| henrys | we probably should have a project to see what comes back. I wonder if they use ghostscript for some printers. | 15:01.51 |
| Robin_Watts | henrys: indeed. The changes to support printing didn't involve any calls to mupdf at all. It was all android stuff. | 15:01.56 |
| tor8 | weird that it does line breaking, that sort of defeats the point of pdf printing if true | 15:02.18 |
| mvrhel_laptop | good morning | 15:02.24 |
| henrys | of course google cloud isn't the only game - there is eprint and airprint | 15:02.57 |
| pod`_ | thanks chrisl, i'll take a look | 15:03.10 |
| paulgardiner | I've now looked into the printer side APIs of GCP and a Cloud Ready Printer could get away with supporting only PDF. | 15:03.21 |
| | GCP offers PDF, PWG-raster or the original file to the printer. | 15:03.57 |
| henrys | paulgardiner:can you register a printer and grab the output easily or is that an ordeal? | 15:05.09 |
| | I was going to do that at some point but if you are almost there .... | 15:05.43 |
| paulgardiner | tor8: it is very odd. I find it hard to believe that wasn't something to do with my particular set up, although I did try serving my printer under Linux and Windows with the same result | 15:05.50 |
| | henrys: I wondered about that. It isn't trivial, but not horrendous. 2 or 3 days, maybe. | 15:06.46 |
| henrys | paulgardiner:do you have the output going to your printer? | 15:07.13 |
| | paulgardiner: nvm I'ld like to look at that one anyway. | 15:07.39 |
| | I was thinking you could packet sniff ... | 15:07.55 |
| paulgardiner | Oh possibly. | 15:08.09 |
| henrys | tor8:I handed off localization to you, are we good? Can I get that off my list? | 15:08.40 |
| paulgardiner | I think the file is downloaded from a url separate from the commands | 15:09.02 |
| tor8 | henrys: I'll take a look at it this week | 15:09.39 |
| paulgardiner | I hadn't considered doing it that way. I was thinking of implementing the protocol. | 15:09.59 |
| henrys | tor8:great, let's just do it. It can't hurt sales wise. | 15:10.14 |
| Robin_Watts | We should update the app on there first, now we have reflow committed. I'll do that later today. | 15:10.47 |
| henrys | paulgardiner: yes if you have something like wireshark just grab the traffic going to your printers ip address. | 15:11.09 |
| tor8 | we're talking both the website and the android app right? | 15:11.09 |
| mvrhel_laptop | Robin_Watts: is you better reflow commited in the golden now? | 15:11.13 |
| Robin_Watts | mvrhel_laptop: It is. | 15:11.19 |
| mvrhel_laptop | ok. great. I am going to add that to the windows app this week. | 15:11.36 |
| Robin_Watts | but I've not uploaded that version of the app to google play yet. | 15:11.40 |
| mvrhel_laptop | So at the end of this week I should we get back to the customer who wanted the windows app as I think I will have everything in place and cleaned up | 15:13.11 |
| henrys | Robin_Watts: status of reflow? Miles wants to know. I guess you had couched the status in terms of foxit and adobe level compatibility and had given time estimates. Where are we? | 15:13.18 |
| paulgardiner | henrys: yeah, I'll have a go. Can wireshark alter packets? Would be good to see what is sent for the various choice of original file pdf or PWG-raster | 15:13.57 |
| Robin_Watts | henrys: We have reflow in place. Text only, and it picks up some of the structure from the document (subscripts/superscripts/indents/columns etc). | 15:14.10 |
| | and even tables to an extent. | 15:14.20 |
| | And now I've parked it until we get customer interest. | 15:14.35 |
| henrys | Robin_Watts:hmm he said you said something about foxit , then adobe compatibility I'll send you his schedule. | 15:16.21 |
| Robin_Watts | henrys: Right, we/I wrote a RoadMap of things to do and how long they'd take. | 15:16.59 |
| henrys | I do remember seeing that I didn't remember anything about adobe/foxit compatibility. | 15:17.38 |
| Robin_Watts | but that's "how long it'll take when we actually decide to dedicate time to it" | 15:18.00 |
| | I think in the covering email I said "we need the first X for fox it compatibility and the next Y for adobe" or something. | 15:18.27 |
| henrys | Robin_Watts: he's under the impression you started when that email was sent he he | 15:19.21 |
| mvrhel_laptop | :) | 15:19.30 |
| henrys | so you're just about done right? | 15:19.35 |
| Robin_Watts | henrys: hmmm.... I'd have to dig it up again, but we're further through than I'd expected to be. | 15:20.17 |
| | You know the old line about "no battle plan survives the first contact with the enemy"? It's true of roadmaps too. | 15:20.46 |
| henrys | Robin_Watts:I think you should just go ahead with the roadmap | 15:20.58 |
| Robin_Watts | henrys: OK. | 15:21.15 |
| henrys | how do you feel about saying foxit compatibility at this point? | 15:21.44 |
| | or foxit competitive? | 15:22.08 |
| Robin_Watts | I've not got foxit myself. | 15:22.27 |
| | mvrhel_laptop: Was it you that had foxit? | 15:22.34 |
| mvrhel_laptop | no not me | 15:22.44 |
| | I had the existing google app | 15:22.57 |
| Robin_Watts | Anyone want to own up to having foxit? | 15:22.59 |
| paulgardiner | Robin_Watts: I have it on Android. I think maybe we win on reflow | 15:23.05 |
| henrys | I thought paulgardiner had it, but I have it one windows not on the droid | 15:23.12 |
| Robin_Watts | so yeah, "foxit competative" sounds good to me. | 15:23.29 |
| paulgardiner | foxit's zoom during reflow is smoother | 15:23.59 |
| | I'd guess they aren't using a web view | 15:24.29 |
| henrys | Robin_Watts: I didn't mean the list is your responsibility, probably should be divided up between the four of you. | 15:25.54 |
| paulgardiner | Hmmm, sometimes we push text off screen | 15:25.58 |
| henrys | mvrhel_laptop: curious to hear about reflow on the windows viewer. | 15:27.00 |
| | paulgardiner: so next is digital signatures? | 15:27.57 |
| mvrhel_laptop | henrys: I don't believe it has reflow | 15:28.23 |
| henrys | are we happy with what we've learned about printing? | 15:28.28 |
| mvrhel_laptop | It is also slow as a VP from microsoft complained to me | 15:28.40 |
| paulgardiner | henrys: just remembered, since experimenting with registering my printer to GCP under Linux, I've done a server swap and lost the installation. That and my only little experience of wire shark might mean you'd get there faster... not that I don't want to do it. Just thought I should say. | 15:28.58 |
| henrys | mvrhel_laptop: I was talking about you getting something to work on windows based on the android work. | 15:29.09 |
| mvrhel_laptop | ah ok. yes. | 15:29.19 |
| | based upon what Robin_Watts told me, I think I can get it going pretty easily. | 15:29.37 |
| paulgardiner | henrys: yes, I'm back looking at digital signatures. Now looking at the details of PFCS1 & PKCS7 | 15:29.52 |
| henrys | paulgardiner: no actually I'd like to do it, because I want to poke at some stuff and see if ghostscript is being used. | 15:30.14 |
| paulgardiner | henrys: right. Makes much more sense for you to then. | 15:30.36 |
| henrys | well we are at the 1/2 hour anything else? | 15:30.48 |
| mvrhel_laptop | not much. I had been doing some thinking about icc color and mupdf | 15:31.05 |
| Robin_Watts | Nothing from me. I've mostly been wearing my gs hat this week. | 15:32.08 |
| henrys | mvrhel_laptop: I guess the ubuntu folks would like that. But if the mobile printing consists of sending a pdf to the cloud, I wonder if it will get real world use. | 15:33.02 |
| | oh anything from ubuntu? Wasn't there a meeting last week? | 15:33.56 |
| Robin_Watts | henrys: There was a meeting, not much discussed. | 15:36.29 |
| | They said they'd had a quick look at mupdf, and had a couple of questions that they would ask me offline - but nothing yet. | 15:37.03 |
| henrys | okay, well I would sell the stuff we do on the interactive side as advantages over poppler (pointing to the android app). Replacing the cairo graphics library is a dead end with those guys and it probably should be. | 15:38.21 |
| Robin_Watts | henrys: I think that doing "mucanvas" is a good idea, but I agree that trying to sell that to ubuntu is going to be tough. | 15:39.34 |
| henrys | ubuntu aside I would love to see a documented muglib | 15:41.02 |
| Robin_Watts | henrys: To do that we need to finish mupdfwrite. | 15:41.37 |
| | and I started a bit on that last week before I got sidetracked with the mem squeezing/valgrind stuff. | 15:41.57 |
| tor8 | muglib? | 15:42.41 |
| Robin_Watts | tor8: essentially documenting how to use the device interface as a graphics library. | 15:43.06 |
| henrys | yes a mupdf graphics library like cairo | 15:43.09 |
| tor8 | oh, "graphics" lib | 15:43.26 |
| | not to be confused with libglib | 15:43.41 |
| ray_laptop | we used to call the graphics library layer "fitz" | 15:59.23 |
| | didn't we ? | 15:59.29 |
| kens | 2nd meeting time ? | 16:01.00 |
| henrys | yes it is. | 16:01.12 |
| ray_laptop | mvrhel_laptop: I'd like to talk (after the meeting) about what I'm seeing with cust 532 and their GC strangeness. I picked you because the first strange thing that pops up is pdf14->ctx | 16:01.55 |
| henrys | Robin_Watts:I can't believe miles - he made a schedule of your roadmap from the time of the email, sent it to raph and didn't tell any of us. | 16:02.00 |
| mvrhel_laptop | ray_laptop: ok | 16:02.09 |
| henrys | sorry I'm trying to unravel myself from the last meeting. | 16:03.53 |
| Robin_Watts | henrys: I understood that he was forwarding the Roadmap to Raph, but I thought it was on the basis of "this is how long it would take us to do things IF you say yes". | 16:04.36 |
| | ray_laptop: Yes, but we don't want people to write apps that call the fitz rendering layer directly. | 16:05.28 |
| henrys | Robin_Watts: yes that would be the expected outcome. | 16:05.32 |
| Robin_Watts | We want people to write stuff that calls the device level interface. | 16:05.57 |
| | That way people can either get rendered output, or they can get pdfout, or svgout, or go into a display list that we can redisplay later. | 16:06.25 |
| | (assuming we write pdfout and svgout devices etc :) ) | 16:06.38 |
| | It would offer a way for people to use us for print preview/pdf export from apps without having to have any pdf knowledge. | 16:07.10 |
| henrys | Miles sent me a link about an outfit called pagedna to track down gs cheaters - I didn't think it would result in much but I said I'd get your thoughts at the meeting. | 16:07.16 |
| kens | Sounds a familiar name | 16:07.34 |
| Robin_Watts | pagedna are offering to track down cheaters? Or they are a potential cheater? | 16:07.39 |
| henrys | they find cheaters | 16:07.55 |
| | marcosw:ping | 16:08.27 |
| Robin_Watts | The lock like a webprint outfit. | 16:08.34 |
| ray_laptop | question is will they be able to tell which ones are conforming to GPL ? | 16:08.36 |
| marcosw | henrys: morning | 16:08.36 |
| Robin_Watts | s/The lock/They look/ | 16:08.43 |
| | henrys: Can we hire them on the basis of a percentage of the settlements we get? :) | 16:08.59 |
| kens | Robin_Watts : that's what I thought yes | 16:09.00 |
| ray_laptop | and if all they do is look at fingerprints in PDF files, LOTS of people use gs to make pdf's legitimately | 16:09.10 |
| henrys | marcosw:curious if fixed bugs need followup - I fixed Guilloume's issue some time ago and haven't seen anything. | 16:09.12 |
| | Robin_Watts: I would imagine it is safe to assume no. | 16:09.41 |
| marcosw | henrys: I'm behind a bit, I noticed on yesterday's bug aging report that there were issues that had to email customers about. I'll get to it today. | 16:10.07 |
| kens | Oh that's a good reminder henrys thanks, I need to follow up with Hari about that thread stuff, ahven't heard anything | 16:10.14 |
| henrys | I've always thought we should have a bounty like commission for anyone finding illegal usage though. | 16:10.17 |
| | alexcher:ping | 16:10.48 |
| chrisl | henrys: I thought we did - I seem to remember Miles talking about it | 16:10.49 |
| alexcher | henrys: yes | 16:11.14 |
| marcosw | henrys: careful, you don't want to encourage people to setup illegal use and then report themselves...that's like rewarding engineers for fixing bugs, just motivates them to write buggy code. | 16:11.58 |
| henrys | alexcher:please make sure the port monitor project gets started. | 16:12.33 |
| sebras | marcosw: if it is only a symbolic sum and the settlement is larger I doubt it would be lucrative though... | 16:13.30 |
| alexcher | henrys: OK | 16:13.44 |
| marcosw | sebras: I gather that much of the time the settlement is zero. Miles has the attorney contact them, they say the didn't understand the GPL, apologize, and say they'll never do it again and that's the end of it. | 16:15.30 |
| ray_laptop | some of them even stop using gs :-) | 16:15.56 |
| kens | marcosw I put a couple of the valgrind bugs back to support because I don't htink they are in pdfwrite, is that OK ? | 16:16.05 |
| henrys | let's all take a look at the agenda followup and work on the projects in that list throughout the quarter and not 1 week before the meeting. Other than that I didn't really have anything else. | 16:16.15 |
| marcosw | kens: off course, I'll randomly assign them to someone else :-) | 16:16.21 |
| kens | :-) | 16:16.26 |
| marcosw | s/off/of/ | 16:16.26 |
| sebras | ah, since settlements are rarely publicize that's hard to know. :) | 16:16.27 |
| Robin_Watts | marcosw: How did you assign the bugs? | 16:17.15 |
| ray_laptop | dart board | 16:17.31 |
| Robin_Watts | (was it some cunning "last person to touch that line of code" script?) | 16:17.41 |
| marcosw | Robin_Watts: based on the source file that was lowest on the call stack that wasn't a general routine. | 16:18.04 |
| Robin_Watts | ray_laptop: If it's a dart board, I'm sending him a bigger picture of you :) | 16:18.20 |
| marcosw | if it was icc or color it went to mvrhel_laptop, image it went to you, clist it went to ray. | 16:18.31 |
| | I lot of them were image, which is you (according to who_owns_what.txt) | 16:19.07 |
| Robin_Watts | Fair enough. | 16:19.12 |
| | I mentioned an idea on here earlier, and wondered if it would be of use to anyone else... | 16:19.33 |
| marcosw | the complication is that the image code sometimes calls the icc or color conversion code, and then I usually assigned them to mvrhel_laptop. | 16:20.37 |
| mvrhel_laptop | Robin_Watts is good at finding those issues too.... | 16:21.01 |
| marcosw | mvrhel_laptop: good to keep in mind for next time. | 16:21.17 |
| Robin_Watts | I'm implementing a 'spy' device, so I can do: "call gx_device_spy(dev)" in gdb and it will hook that device. | 16:21.26 |
| | Then any calls made to that device get traced out (and passed through). | 16:21.47 |
| | Does that sound useful to anyone else? | 16:22.19 |
| ray_laptop | Robin_Watts: and how is this useful ? | 16:23.18 |
| marcosw | btw, I am re-running the valgrind stuff again, with ENABLE_VALGRIND and PACIFY_VALGRIND defined, so some of the issues will hopefully go away. | 16:23.49 |
| ray_laptop | ate a big bowl of oatmeal, so my heads sort of full and new concepts have to push through the mush ;-) | 16:24.18 |
| Robin_Watts | ray_laptop: For the current valgrind bug I'm looking at for example. | 16:25.05 |
| ray_laptop | Robin_Watts: what does 'traced out' mean ? print something to stderr or stdout ? | 16:25.09 |
| Robin_Watts | ray_laptop: exactly. | 16:25.18 |
| ray_laptop | Robin_Watts: I see, so it's like a forwarding gdevtrac device | 16:25.36 |
| Robin_Watts | ray_laptop: Valgrind tells me where a gdev_memory device is created, and it tells me later on that there are undefined values in it. | 16:26.14 |
| henrys | Robin_Watts:I would forget ghostscript the e of you are going to have to focus on getting us out of the whole miles has put us in. I guess the reflow roadmap is everybody's priority. | 16:26.19 |
| | s/the/the 3/ | 16:26.30 |
| Robin_Watts | I currently have no easy way to see what happened to the device in the meantime. | 16:26.53 |
| | With my new gs_device_spy I can see what operations took place. | 16:27.15 |
| ray_laptop | Robin_Watts: I hope you leveraged the gdevtrac printout | 16:27.27 |
| Robin_Watts | I am doing so, yes. | 16:28.11 |
| kens | Robin_Watts : I can't hitnk of a use for it, myself off-hand, but it sounds like somethig which would be useful | 16:28.12 |
| Robin_Watts | henrys: fair enough. | 16:28.20 |
| | I should look back at the roadmap and figure out where we are on it. | 16:28.44 |
| ray_laptop | Robin_Watts: Thanks. I'll keep that in mind | 16:29.09 |
| marcosw | another thing I'm doing is looking at the indeterminisms and I will raise the priority of the valgrind bugs that are associated with files that have visible effects, might as well look at those first. | 16:29.46 |
| chrisl | kens: a valgrind problem with gx_hld_saved_color_equal() landed on my desk - I've got a fix, but I was hoping you'd review it, because it's a bit involved.... | 16:33.48 |
| kens | chrisl I was expecting that to come to me, I noticed some while passing on other bugs, feel free to email me it | 16:34.20 |
| | I'm going to cook shortly | 16:34.27 |
| ray_laptop | has anyone ever seen GC memory where the chain of chunk_pointers points to a chunk_pointer that doesn't have any chunk attached (cp->cbase == 0) ? | 16:34.41 |
| chrisl | kens: Okay, will do | 16:34.59 |
| ray_laptop | chrisl: or Robin_Watts: maybe you guys have ??? | 16:34.59 |
| chrisl | ray_laptop: not that I can remember - I thought that should only happen during allocator initialisation | 16:35.39 |
| Robin_Watts | ray_laptop: If I have, I haven't realised it. | 16:36.41 |
| chrisl | I mean I thought cp->cbase == 0 should only happen during allocator initialisation | 16:37.07 |
| alexcher | I have leave now for about 30 min. | 16:37.35 |
| marcosw | I have to run too but will be back at 11:00 or so (90 minutes) | 16:37.54 |
| ray_laptop | I'm seeing it while it is tracing through the chain in chunk_locate_ptr | 16:38.00 |
| chrisl | Hmm, a chunk with no allocated memory should be removed from the chain, or so I thought..... | 16:39.20 |
| ray_laptop | chrisl: I'm seeing strange stuff with cust 532's build. Doesn't happen on 8.71 or HEAD | 16:41.38 |
| | I'm resorting to turning on -ZA | 16:42.20 |
| chrisl | ray_laptop: that's worrying - but not surprising with all the patches and custom crap they've got in there :-( | 16:42.25 |
| kens | Goodnight all | 16:43.55 |
| ray_laptop | g'nite, kens | 16:44.03 |
| | the only reason I am tracing through the chain is that I'm getting "object not in any chunk" with the pdf14->ctx object | 16:45.36 |
| chrisl | ray_laptop: is the ctx actually in it's own allocation? | 16:47.20 |
| ray_laptop | chrisl: no, I don't think so, but I can't check now because I'm re-running and the previous log file is gone | 16:48.31 |
| | the ctx is not very big | 16:48.48 |
| | and it isn't "immovable", so I'm fairly certain it'll be in a shared chunk | 16:49.24 |
| | I'll keep digging into it and call for "ears" if I need to chat about what I am seeing and need ideas. I'm just tracking down the first thing I find wrong (object not in any chunk) figuring that will lead me to the cause | 16:52.26 |
| | after a bunch of these messages, it finally segfaults in the GC, i.e., some pointer leads to never never land | 16:53.21 |
| chrisl | ray_laptop: you could try activating the pointer stability checking code | 16:54.15 |
| henrys | okay mupdf'ers I sent you the schedule :-^ | 16:54.27 |
| alexcher | I'm back. | 16:58.56 |
| Robin_Watts | henrys: Milestone 1 is done. | 16:59.28 |
| | Milestone 2 is done. | 16:59.35 |
| | Milestone 3 is tor8's. I have my finger on my nose. | 16:59.48 |
| | Dehyphenation from Milestone 4 is done. | 17:00.19 |
| | But we have lifted the "orthogonal text only" restriction already) | 17:00.51 |
| ray_laptop | chrisl: thanks for the suggestion. couldn't hurt to see if that helps | 17:01.29 |
| | I am going for coffee... bbiab | 17:01.57 |
| Robin_Watts | Arguably we have done Milestone 4 completely, but there is always scope for improvement. We should at least find a document where we have problems before wasting more time :) | 17:02.36 |
| | Milestone 5 is, I guess, the next thing for me to look at. | 17:03.52 |
| henrys | tor8:so you've got 3? | 17:04.28 |
| Robin_Watts | mvrhel_laptop: In gxdevcli.h: | 17:04.34 |
| | /* | 17:04.49 |
| | This area of the transparency facilities is in flux. Here is a proposal | 17:04.51 |
| | for extending the driver interface. | 17:04.53 |
| | */ | 17:04.55 |
| | mvrhel_laptop: really? :) | 17:05.05 |
| tor8 | henrys: 3 is on me, yes. | 17:06.50 |
| Robin_Watts | henrys: Have we heard back from the potential customer? | 17:07.20 |
| | Or is this just us trying to make sure we're in a good position if they do get back to us? | 17:07.37 |
| henrys | tor8:so I can safely tell miles adobe compatibility+ mid may - correct? | 17:07.47 |
| mvrhel_laptop | Robin_Watts: sorry stepped out for sec. | 17:07.50 |
| | Robin_Watts: that does not sound like my comment... | 17:07.58 |
| henrys | Robin_Watts:this is miles sending raph a followup on schedule progress. | 17:08.24 |
| mvrhel_laptop | Robin_Watts: what does blame say? | 17:08.45 |
| Robin_Watts | mvrhel_laptop: It sounds like a left over comment - how long has it been since the transparency device interface changed? | 17:08.55 |
| mvrhel_laptop | Robin_Watts: well we have added in compositor operators in the past couple years for the softmask stuff | 17:09.35 |
| Robin_Watts | henrys: Right, so possibly we should take this opportunity to rejig the roadmap a bit to say where we are, and what remains to be done. And we can point them at the updated app. | 17:09.40 |
| mvrhel_laptop | but nothing is in flux now I hope | 17:11.02 |
| Robin_Watts | mvrhel_laptop: Right. I just thought it was an amusing comment. | 17:11.23 |
| henrys | Robin_Watts:fine by me. | 17:12.59 |
| | mvrhel_laptop and marcosw if both of you are going to the printing summit I don't feel I really need to be there. Are you definitely going? | 17:16.50 |
| mvrhel_laptop | henrys: I have not signed up yet. | 17:17.28 |
| | what is the date | 17:17.34 |
| | Looks like Wed the 15th is the stuff for us | 17:18.15 |
| henrys | right wednesday | 17:19.48 |
| mvrhel_laptop | So in the past I have given an update with what is new color wise with ghostscript. This time I think we would want that and also an overview of mupdf | 17:19.58 |
| | henrys: I am fine going and doing this or if you would prefer to do it that is fine too | 17:21.02 |
| henrys | you're closer ;-) | 17:21.26 |
| mvrhel_laptop | ok. I will go ahead. I am going to need a little help with getting stuff together about MuPDF | 17:22.01 |
| henrys | it is also possible we could ask marcosw to do it. | 17:22.21 |
| mvrhel_laptop | true. he is even closer | 17:22.30 |
| | ok. lets see what he has to say about that when he returns | 17:23.09 |
| henrys | okay | 17:23.18 |
| Robin_Watts | mvrhel_laptop: While I don't doubt Marcosw's ability to give a pre-prepared presentation, I suspect that you would be much better positioned to field questions about color management/mupdf afterwards. | 17:33.36 |
| | The last presentation I did was at a computer show, when the guy who was supposed to be doing it missed his train. It was not fun. | 17:35.03 |
| mvrhel_laptop | Robin_Watts: Yes that can be painful | 17:35.12 |
| Robin_Watts | but if you want help with bits of the presentation, I will do what I can. | 17:35.56 |
| mvrhel_laptop | Last year both marcos and I were both there and I think that went well. Robin_Watts yes some of the muPDF stuff I will need your (and tor8's) input | 17:36.26 |
| henrys | it looks like we can conference in also. | 17:36.27 |
| mvrhel_laptop | oh that is nice | 17:36.45 |
| henrys | mvrhel_laptop: but it is looking like you are the best choice to go. | 17:37.20 |
| mvrhel_laptop | ok. I am happy to do it. | 17:37.36 |
| henrys | nobody can answer the color management stuff as well as you and you are in mupdf now. | 17:37.51 |
| ray_laptop | yuck. I added the PTR_STABILITY checking -- it spews a LOT of stuff, but also changed the allocation pattern. Now a different object pops out with the first "not in any chunk" message. mvrhel_laptop you will be glad to hear that it isn't related to the pdf14 device :-) | 18:16.51 |
| mvrhel_laptop | ray_laptop: that is good to hear. | 18:17.16 |
| ray_laptop | mvrhel_laptop: maybe for you :-/ | 18:17.52 |
| mvrhel_laptop | yes sorry. I do feel your pain | 18:18.25 |
| ray_laptop | Now it's an image enum alloc, which is in a large object chunk (113604 bytes) and that's the last allocation prior to a GC, AFAICT | 18:19.41 |
| | well, not precisely. There are a couple of other elements allocated -- image_buffer of 48 bytes and image clip device (1008 bytes) | 18:20.58 |
| marcosw | henrys, mvrhel_laptop, Robin_Watts: I was planning on going to one or two days of the printing summit but agree with Robin_Watts comment that while I could give a presentation I wouldn't be good at answering questions afterwards. | 18:40.38 |
| henrys | marcosw:another question for you - have you done xps and pcl valgrind stuff? | 18:46.23 |
| Robin_Watts | marcosw: If you do them, I hope PACFIFY_VALGRIND and ENABLE_VALGRIND should work now. | 18:48.34 |
| | For those interested, I've parked my gs spy device on robin/master. | 18:49.23 |
| marcosw | henrys: I've run pcl through valgrind but haven't looked at the results yet. | 19:07.45 |
| henrys | ah okay I didn't want to be left out of all the fun | 19:08.13 |
| marcosw | if you want to look at the raw log files they are on casper in ~regression/cluster/valgrind.pcl | 19:12.16 |
| | or should I re-run them with PACFIFY_VALGRIND and ENABLE_VALGRIND set? | 19:13.31 |
| Robin_Watts | marcosw: Various fixes have gone in that should reduce the noise a bit, plus those might take the noise down a bit more. | 19:15.14 |
| henrys | from what I can gather there are no pcl tests that don't have valgrind errors ;-^ | 19:26.02 |
| | oh wait the first file I looked at had no errors. | 19:26.57 |
| mvrhel_laptop | lunch time. bbiab | 19:29.55 |
| henrys | marcosw:I'm fine grabbing these from the log files for a while. I see many problems are common library problems so will go away with gs fixes. | 20:08.19 |
| | but it you want to create bugs that is fine too. up to yoju. | 20:08.33 |
| marcosw | I'll probably won't get to the PCL valgrind issues until tomorrow; you'll probably have everything fixed by then :-) | 20:09.20 |
| henrys | marcosw:by the way I installed tmux on the Mac Pro seems like it would fit your workflow well. | 20:14.37 |
| marcosw | henrys: I use screen, though I've heard good things about tmux | 20:15.29 |
| Robin_Watts | tried mosh ? | 20:15.58 |
| marcosw | Robin_Watts: I have, though it was some time ago and i had some problem with it and gave up. | 20:16.37 |
| henrys | Robin_Watts: I just use tmux to open an emacs session and that's really all I want ;-) | 20:16.59 |
| marcosw | I think I had some issue with terminal settings and mosh having to do with connecting from Mac OS X to Linux or vice-versa. | 20:19.00 |
| henrys | but I thought marcosw might use it with his ssh'ing aboutâ¦. | 20:19.08 |
| marcosw | just found a new thing: clusterssh, seems like that would be useful too. | 20:20.58 |
| | clusterssh: This tool is intended for (but not limited to) cluster administration where the same configuration or commands must be run on each node within the cluster. Performing these commands all at once via this tool ensures all nodes are kept in sync. | 20:21.30 |
| | I often find myself ssh'ing to each node in turn and running the same command... | 20:21.59 |
| | now I can accidently 'sudo rm -fr /' on several machines at once | 20:22.36 |
| henrys | I'm closing my port | 20:22.59 |
| | ;-) | 20:23.07 |
| marcosw | not to worry, I don't have sudo access on your nodes :-( | 20:23.17 |
| henrys | mosh does look pretty cool though | 20:24.19 |
| Robin_Watts | marcosw: How old was the valgrind you ran it on? | 20:31.55 |
| | My local ubuntu has 3.7, but not enough memory to run the test file. | 20:34.58 |
| | peeves has 3.5.0 or something similarly old. | 20:35.09 |
| | I'm building 3.8.1 now on it to see if that removes some false positives. | 20:35.29 |
| | It doesn't. But it does seem faster. | 20:48.40 |
| marcosw | Robin_Watts: the valgrind version varies between nodes. Some run 3.6.0, others 3.7.0, and one at least one of alexcher's node is running 3.3.1 | 21:17.21 |
| | if you look at the log files attached to the bug you'll see the valgrind version for each test. | 21:17.39 |
| henrys | well the first valgrind problem I looked at looks good. It's a serious problem, so this is already a worth while exercise for me. | 22:14.32 |
| marcosw | Robin_Watts: valgrind 3.7 seems to take a lot more memory than 3.6. I.e. 12gigs vs 200megs. I'm not sure if this is a bug or a feature (i.e. a feature because the new valgrind does better analysis which happens to take more memory). | 23:26.24 |
| Robin_Watts | marcosw: Ouch. | 23:28.40 |
| marcosw | Robin_Watts: yeah, I was a bit surprised as well. At first I thought it was just some files taking more memory, but watching htop on the 6 nodes in my house (three of which are running 3.6 and three 3.7) I'm convinced it's a difference in valgrind versions. | 23:30.00 |
| | and your testing showed that 3.8.1 also takes a lot of memory, correct? | 23:30.18 |
| Robin_Watts | marcosw: Are there new command options? | 23:30.22 |
| | marcosw: Yes. | 23:30.27 |
| | Sorry, no. | 23:30.31 |
| | I didn't test 3.8.1 for memory use. | 23:30.39 |
| | It's on peeves installed in ~robin/sauce/valgrind-3.8.1/bin/bin | 23:30.56 |
| marcosw | you mean between 3.6 and 3.7? I haven't checked the command line option differences. Oddly enough the release notes for 3.7 say "memory use reduction", so I don't know what that means. | 23:34.45 |
| | Forward 1 day (to 2013/04/03)>>> | |
IRC Logs