| | <<<Back 1 day (to 2014/01/14) | 2014/01/15 |
| mvrhel_laptop | Robin_Watts: so later this week I will have some commits for you to look over. simple stuff, but the purpose is to untangle one of the layers in the windows 8 mupdf code from any winRT / win8 constructs so I can share that layer with gsview | 00:21.16 |
| Robin_Watts | ok. | 00:30.56 |
| zeniko | Robin_Watts: thanks for the fix for bug 694894 | 12:57.15 |
| | now I've got all the new fuzzing files passing on my local machine (modulo some potential valgrind issues) | 12:57.37 |
| | there's also one new fix on zeniko/mupdf for that colorspace memory leak | 12:58.53 |
| | (and three more fixes on zenik/ghostpdl for three more fuzzing issues in openjpeg and jbig2dec) | 12:59.51 |
| Robin_Watts | zeniko: For the logs, thanks. I will look in a mo. | 13:11.20 |
| kens | chrisl Robin_Watts tor8 anyone heard anything from Miles, or done anything about flights yet ? | 14:03.14 |
| Robin_Watts | kens: Not yet. | 14:03.36 |
| kens | OK just have to wait then thanks | 14:03.46 |
| kens | reboots WIndows to install patches, brb | 14:09.13 |
| | Hi Michael, Ray | 15:13.06 |
| ray_laptop | hi, kens | 15:13.17 |
| | well, I have the pdf14 clist accumulator working (at least with the display device). I get a heap corruption, so moving to peeves to use valgrind to help me find it. | 15:16.07 |
| | given all of the new and strange things I'm doing to the device chain, I guess I /might/ have made a mistake | 15:17.00 |
| | like my son's favorite T-shirt "I may be wrong, but I seriously doubt it" | 15:17.45 |
| kens | I need one like that :-) | 15:18.25 |
| ray_laptop | we all do :-) | 15:19.07 |
| mvrhel_laptop | hi kens | 15:22.50 |
| ray_laptop | morning, mvrhel_laptop | 15:22.58 |
| mvrhel_laptop | morning ray_laptop | 15:23.04 |
| ray_laptop | before anybody asks, I'm still pretty much the same | 15:23.21 |
| henrys | kens: one use case I was thinking of with redmon would be the ability to use feature of the print driver. Maybe you want to do some kind of special rendering with gs but still be able to use the interactive features of the driver - toner low etc. --- however I don't even know if that works. | 15:50.07 |
| kens | henrys I don't really see how that would be possible with RedMon | 15:52.50 |
| | You can't use the printer driver by then, its past it | 15:53.03 |
| henrys | marcosw: nothing relevant in the Mac Pro logs. | 15:55.55 |
| | kens:once I hook up redmon I can still use the old printer driver redmon points to right? For example toner low, paper out etc. should come back to the original driver and be displayed. | 16:00.37 |
| ray_laptop | henrys: I don't think so. Redmon is (AFAIK) a write only port and just takes data from the driver -- it doesn't 'connect' to any devices and doesn't send anything back to the driver | 16:03.11 |
| | henrys: how would it get anything back from a device like 'toner low' anyway. The printer driver hooked to redmon has no relation to other printer drivers on the system | 16:04.29 |
| | henrys: think of it as having several different PS printers -- the status of one on a USB port has no relation to another one that may be writing to a FILE: or LPT1: just because they all use PSCRIPT5.DLL | 16:06.04 |
| Robin_Watts | redmon just provides a port that data can be sent to, and then invokes a program of some kind on the received data, right? | 16:07.03 |
| ray_laptop | Robin_Watts: right. | 16:07.21 |
| Robin_Watts | So redmon doesn't need to be hooked to a printer at all. | 16:07.38 |
| henrys | ray_laptop:the original printer driver that produced the postscript is up running and talking to the printer right? | 16:07.52 |
| Robin_Watts | No. | 16:08.01 |
| kens | No its talking to redmon | 16:08.12 |
| Robin_Watts | Not to a physical printer, at least. | 16:08.21 |
| ray_laptop | henrys: I don't understand. There is no 'original PS driver up and running' | 16:08.36 |
| | there may be multiple PS printers installed on a system. Each one is independent | 16:09.12 |
| Robin_Watts | Suppose I choose to install "a postscript printer" on my windows PC, without actually having a physical postscript printer. | 16:09.21 |
| ray_laptop | Robin_Watts: right. and you select FILE: as the port | 16:09.46 |
| Robin_Watts | I would install a printer driver, which makes a "printer" entry in the computers list of printers. When I print to it, it has to send it's data somewhere. This will either be FILE: or USB: or LPT: or a network port or some other 'port'. | 16:10.23 |
| | redmon is just one more such 'port'. | 16:10.36 |
| kens | No redmon isz not a port | 16:10.45 |
| | Its a 'port monitor', it can be attached ot *any* port | 16:11.01 |
| | A port monitor 'processes' the print stream before passing it to the port itself | 16:11.28 |
| Robin_Watts | oh, I see. | 16:11.42 |
| kens | The FILE: port writes the processed stream to a file | 16:11.51 |
| | The 'rprtocess' cna be nearly anything | 16:12.03 |
| | In our case its 'convert to PDF' | 16:12.13 |
| henrys | that's not the use case I'm talking about I have a Postscript printer and windows driver - with this combo I see "no paper", toner out etc. because the driver can bidirectionally talk to the printer. Now I decide I want to do ghostscript rendering on this printer *also*, why can't I use redmon separately and have functionality from both. | 16:12.20 |
| kens | But in some of the use cases in the mail I wrote its 'put it on disk and tehn invoke some other app, which can in fact push it back hrough the print system | 16:12.45 |
| | henrys how would redmon know what to send *direct* ot the printer, and what to process internally ? | 16:13.19 |
| Robin_Watts | henrys: AIUI, what you're talking about there is having 2 printer entries in the printer list. | 16:13.25 |
| | The first one would talk direct to the printer, and get no paper/toner out etc. | 16:13.48 |
| henrys | Robin_Watts: right one for ghostscript rendering and another for windows or raw postscript | 16:13.54 |
| kens | henrys then you still don't need redmon | 16:14.04 |
| | (in the new scheme of things that is) | 16:14.24 |
| Robin_Watts | The second one would have redmon running on it's output port. but that wouldn't get the error messages back. | 16:14.24 |
| kens | I still think this is at best a 'niche' use case anyway | 16:15.37 |
| | Do we know *anybody* who is doing anything remotely like this ? | 16:15.54 |
| henrys | kens:okay well if you envision a way to do that without redmon I can't think of anything else. | 16:15.58 |
| kens | henrys you would already have to do it without redmon for the 'monitoring' part | 16:16.16 |
| | Because there is no way redmon can know what stuff to send to the printer and get comms back, and what stuff it should render internally | 16:16.48 |
| henrys | kens:I do think we should write to this customer and have them describe exactly how they have things setup, stating we are putting together a new architecture and we want to make sure we don't miss anything they might need. | 16:17.35 |
| kens | henrys I'm fine with that, a small wager on them not using RedMon at all ? | 16:17.52 |
| | :-) | 16:17.57 |
| henrys | kens: you'd have to give me decent odds 5:1 or so. | 16:18.49 |
| kens | OK | 16:18.57 |
| Robin_Watts | Loser has to wear the "Only 2 things come from Texas" T-shirt at Scotts gig in March. | 16:19.43 |
| henrys | kens:if they're using redmon I get 5 euros if not you get 1 | 16:19.45 |
| kens | is jesting really | 16:19.46 |
| | henrys dollars is probably better | 16:19.58 |
| | :-) | 16:20.10 |
| henrys | kens: I brought back all these euros last trip out there I'm trying to get rid of them ;-) | 16:20.33 |
| kens | Oh well I can always use them, we take them ski-ing | 16:20.46 |
| chrisl | Henry should get 5 euros, Ken should get 1 Canadian dollar..... useless for everyone | 16:20.49 |
| kens | ROFL | 16:20.56 |
| henrys | chrisl: right | 16:21.03 |
| | oh you guys don't have bubba teeth for Texas. You can get them on the web, you'll fit in better. | 16:21.42 |
| chrisl | I must admit, I'm rather confused about what the source of this redmon debate was - maybe I'm better off that way | 16:22.04 |
| kens | I've been to Texas before | 16:22.20 |
| chrisl | We'll need to practice saying "y'all"..... | 16:23.17 |
| henrys | of course all that is changing - texas is moving up on 40% hispanic - it could be a "blue" state next election. | 16:25.45 |
| kens | blue ? | 16:26.06 |
| henrys | kens: democrat vs. red republican, it would be quite a change for texas. | 16:27.00 |
| kens | ah right | 16:27.04 |
| chrisl | Ironic that republican should be red....... | 16:27.22 |
| ray_laptop | I don't know which customer you are talking about, but at least one customer did a TCP applet on the windows system and has the printer 'connected' to the TCP port that the applet listens to | 16:28.08 |
| chrisl | henrys: those jpeg/dct filter changes: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d67d71b3 | 16:29.13 |
| henrys | ray_laptop:I wish I could find it in the ocean of damn valgrind bugs. | 16:29.52 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=691921 | 16:31.44 |
| | ray_laptop: ^^^ | 16:31.59 |
| | chrisl: okay | 16:32.06 |
| chrisl | kens: in the Win v4 print architecture, is there any "passthrough" mode? I.E. that completely avoids XPS? | 16:32.24 |
| henrys | ray_laptop: can you take a look at chrisl changes as well. | 16:32.33 |
| kens | yes XPS_PASS | 16:32.35 |
| chrisl | So, that complicates matters..... | 16:33.11 |
| henrys | Robin_Watts: maybe you should look too. | 16:33.36 |
| kens | chriusl I don't think we would ever see it | 16:34.34 |
| ray_laptop | henrys: chrisl: Yes, I'll have a look at the changes | 16:34.49 |
| kens | I can only assume its used for (eg) EPS and PS printers | 16:34.54 |
| chrisl | Actually there's a couple of small edits in a pdfwrite file, so kens should look, too (at my commit)! | 16:34.56 |
| kens | 2 secs | 16:35.16 |
| ray_laptop | kens: so they call it XPS_PASS, not PS_PASS ? | 16:35.30 |
| kens | ray_laptop : I htink so yes | 16:35.38 |
| chrisl | kens: The pdfwrite changes are *really* trivial | 16:35.41 |
| kens | ray_laptop : I assume its because you can pass anythign through | 16:36.05 |
| | chrisl looks fine | 16:36.40 |
| Robin_Watts | chrisl: jpeg_block_s used to have a pointer 'blocks'. | 16:36.41 |
| | Instead, we now have 2 pointers. | 16:36.50 |
| | cmem and dummy. | 16:37.01 |
| chrisl | Yes, but cmem doesn't move | 16:37.34 |
| Robin_Watts | I don't see why dummy needs to exist. | 16:37.46 |
| | You say it's to keep the structures the same between encode and decode. | 16:38.04 |
| chrisl | We don't want the garbage collector meddling with cmem | 16:38.08 |
| Robin_Watts | but the structure is now larger than it was before. | 16:38.24 |
| chrisl | So? | 16:38.32 |
| Robin_Watts | I don't get the alloc_struct/alloc_bytes thing. | 16:39.38 |
| kens | join the club :) | 16:40.00 |
| chrisl | If we don't have a gc-aware pointer in the structure, we'd allocate it with alloc_bytes, if we do have a gc-aware pointer, we use alloc_struct | 16:40.30 |
| Robin_Watts | Ah. So it's because dummy is (nominally at least) gc-aware. | 16:41.38 |
| chrisl | Yes | 16:41.48 |
| Robin_Watts | Why does the decompress have a gc aware pointer in it? | 16:42.02 |
| ray_laptop | chrisl: I see the logic for the 'dummy' for the decoder. It's rather hackish, but the explanation seems OK | 16:42.05 |
| Robin_Watts | The description would be better with a reference to the fact that dummy is "gc-aware", IMHO. But that's a small thing. | 16:42.52 |
| chrisl | Robin_Watts: yeh, I should have mentioned that - I'll do so | 16:43.23 |
| ray_laptop | maybe a comment that dummy is always NULL so the GC won't trace it | 16:43.41 |
| chrisl | ray_laptop: it does say it's always NULL | 16:44.06 |
| Robin_Watts | Why does the decompress have a gc aware pointer in it? | 16:44.08 |
| chrisl | Robin_Watts: I don't know what the scanline_buffer pointer history is - it wasn't relevant to this problem | 16:44.29 |
| ray_laptop | those that have fought with the GC take that for granted (that it doesn't trace NULL pointers), but that's the reason that it's always NULL | 16:44.34 |
| Robin_Watts | Once I knew it was gc-aware, the need for it always being NULL is "obvious". | 16:45.03 |
| | actually, I'm still not happy. | 16:45.50 |
| | The comment says "The pointer that was in the same position as "dummy" is no longer needed. | 16:46.17 |
| henrys | chrisl: does immovable non gc do anything different than just non-gc. I don think it does so immovable just gives us more to study when reading the code. | 16:46.20 |
| Robin_Watts | But there was no pointer in the same position as dummy. | 16:46.29 |
| | I'm interpreting position as "position in the struct" here. | 16:46.54 |
| chrisl | Robin_Watts: dummy replaces "blocks" | 16:47.02 |
| Robin_Watts | But it's not in the same position as blocks. | 16:47.11 |
| | cmem is in the same position as blocks. | 16:47.24 |
| | swap cmem and dummy in the struct definition and I'm happy. | 16:47.44 |
| chrisl | Well, yes, I suppose. Renaming blocks to dummy was the last think I did, so was after adding cmem, so from my perspective was in the same position! But point taken | 16:48.32 |
| Robin_Watts | Why is it important that it should be in the same position? | 16:48.56 |
| | Is the same enumerator used for both encoding and decoding structures? | 16:49.07 |
| chrisl | Only for the comment, nothing else | 16:49.14 |
| Robin_Watts | ok, so it's just the english that's tripping me up. | 16:49.28 |
| chrisl | So I can sort that with "The pointer "blocks" has been replaced with "dummy" as it is no longer needed," | 16:50.02 |
| Robin_Watts | sure. | 16:50.14 |
| chrisl | henrys: yes, that's totally pointless - we really only don't need any of that, since cmem is a chunk allocator | 16:50.46 |
| Robin_Watts | and then say "dummy has not been removed as it stays as an always NULL value that can be nominally garbage collected, enabling us to consistently use alloc_struct with both encoder and decoder" or something. | 16:51.15 |
| chrisl | Yes, just updating the comment now. | 16:51.35 |
| Robin_Watts | Although I can't help feeling it'd be nicer to just use alloc_bytes and lose dummy. | 16:51.49 |
| | :) | 16:51.56 |
| | Anything freed from the gc is a win. | 16:52.29 |
| chrisl | I agree, but I'd also prefer to keep encoding and decoding consistent. I may continue and see if we can remove scanline_buffer from gc, and then we could just use alloc_bytes for both | 16:53.27 |
| Robin_Watts | cool. | 16:53.44 |
| chrisl | But this is a P1 bug, so I wanted a fix ASAP. I'd really hoped it would be much more localised than it is, and that's without having to change all the allocations! | 16:54.39 |
| henrys | chrisl: do we have a cluster run yet? | 16:55.10 |
| chrisl | henrys: Yes | 16:55.21 |
| henrys | chrisl: I'm good at this point. | 16:56.14 |
| chrisl | henrys: Cool, thanks. What's you're take on my proposal to take this further, take scanline_buffer out of gc, and just have the structure's allocated via alloc_bytes? | 16:57.27 |
| kens | I see the gspritn customer just came back again | 17:03.04 |
| mvrhel_laptop | is that the gsprint customer? | 17:03.18 |
| | they cc'd miles I see | 17:03.33 |
| chrisl | It might worth giving them hintak's suggestion | 17:04.45 |
| zeniko | Robin_Watts: (from the logs) thanks, I've tweaked the patch a bit (in case you've already cloned it locally) | 17:06.28 |
| Robin_Watts | zeniko: sorry. no, I have my head buried elsewhere today. | 17:06.44 |
| zeniko | Robin_Watts: no worries, as long as the patch goes in before there's a second caller to fz_new_image_from_pixmap | 17:07.32 |
| chrisl | Robin_Watts, ray_laptop: I've revised the comment: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=b0ee45fc | 17:08.01 |
| zeniko | henrys: 3 more patches to openjpeg and jbig2dec on zeniko/ghostpdl for review and/or to land (they've all passed the cluster and fix the remaining fuzzing crashes in MuPDF) | 17:08.23 |
| chrisl | henrys: And I've done away with the spurious _immovable and non_gc_memory stuff, too | 17:08.33 |
| henrys | zeniko okay I'll check and commit | 17:11.22 |
| | zeniko: the bugs should remain open though until the library is pulled back by mupdf, agreed? | 17:11.58 |
| Robin_Watts | chrisl: new comment looks good. | 17:12.55 |
| chrisl | Robin_Watts: thanks | 17:13.12 |
| zeniko | henrys: once these patches have landed and been extracted into the repos MuPDF uses, I'll let Robin_Watts/tor8 look over the submodule update (after which most of the MuPDF fuzzing bugs can be closed) | 17:13.36 |
| Robin_Watts | and the rest of the commit looks good to me too (at least as far as my frazzled brain will cope with today) | 17:13.55 |
| | zeniko: When henrys pushes them, they should make it out into the separate archives within 24 hours. | 17:14.50 |
| | then we can update mupdfs submodules. Remind me if I forget. | 17:15.09 |
| chrisl | Robin_Watts: ta - like I keep saying, third party libraries shouldn't, IMHO, ever use gc'ed memory, and really should never, *ever* use memory subject to Postscript save/restore operations...... | 17:15.52 |
| ray_laptop | strongly agrees | 17:16.26 |
| kens | OK family is home, time to go. Night folks | 17:16.35 |
| chrisl | nite kens | 17:16.49 |
| zeniko | Robin_Watts: and after that, it might make sense to let marcosw run all the fuzzing files again (also the first batch) to make sure we've caught the worst and not regressed anything | 17:17.05 |
| Robin_Watts | zeniko: yeah. I'm still working my way through the valgrind issues. | 17:17.31 |
| | tor8: I have a commit (or 2?) for review on robin/master | 17:18.06 |
| zeniko | Robin_Watts: the bug 694894 commit looks good (have already merged it locally) | 17:19.39 |
| Robin_Watts | yeah, that's the one I need tor8 to nod at. | 17:20.33 |
| mvrhel_laptop | Robin_Watts: I pushed some minor clean up patches into my repos | 18:16.00 |
| Robin_Watts | I've looked at the validation fixes one before, right? | 18:17.08 |
| | For the Windows 8 store validation one, why do you need NDEBUG twice? | 18:17.48 |
| | Looks like all the platform/winrt/libmupdf_winRT.vcxproj changes are pointless in that one. | 18:18.26 |
| mvrhel_laptop | It was missing in one of the architecture types the first time | 18:18.27 |
| Robin_Watts | Some of them have NDEBUG in 3 times now :) | 18:18.54 |
| | http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=commitdiff;h=c9161e3c56149e960c68ec504807ae0612dc6c18 | 18:19.11 |
| mvrhel_laptop | really? there should be a total of 2 projects that have it | 18:19.13 |
| Robin_Watts | Where was it missing? | 18:19.14 |
| mvrhel_laptop | oops | 18:19.28 |
| | why did it do that | 18:19.38 |
| | let me fix that | 18:20.08 |
| Robin_Watts | actually, even in the 8.1 commit, you've added 2 NDEBUGs into one of them. | 18:20.11 |
| mvrhel_laptop | not on purpose | 18:20.28 |
| | I had to do it for all releases | 18:20.46 |
| | and it must have been in some of them already | 18:20.55 |
| | this was a visual studio mix up | 18:21.09 |
| Robin_Watts | GetPageSize stil returns a Point, not a point_t. Is that deliberate? | 18:23.08 |
| | looks deliberate. | 18:23.26 |
| mvrhel_laptop | hold on | 18:23.40 |
| | trying to fix the property pages | 18:23.52 |
| Robin_Watts | sure, sorry. I'm just dumping stuff in here as I see it. don't feel you have to answer everything instantly. | 18:24.17 |
| mvrhel_laptop | GetPageSize is at the WinRT interface | 18:24.47 |
| | it can't return point_t | 18:25.08 |
| | must return Point | 18:25.13 |
| Robin_Watts | ok. | 18:25.29 |
| | So, you've changed string_margin and string_orig to be std::string's. | 18:25.46 |
| | and in ComputeContents you convert those to Strings. | 18:26.02 |
| mvrhel_laptop | previously they were converted to Strings^ earlier | 18:26.17 |
| | in muctx | 18:26.22 |
| Robin_Watts | by gettign them as c_str's (which are presumably char *'s). Then you call char_to_String on them. | 18:26.30 |
| | Can char_to_String ever fail? i.e. does it involve an allocation and a copy? | 18:26.43 |
| mvrhel_laptop | I removed all the refs to winRT types in muctx so that I can share this code | 18:26.43 |
| | if it does a null is returned. | 18:27.22 |
| Robin_Watts | if it fails, a null is returned ? | 18:27.37 |
| mvrhel_laptop | yes | 18:28.21 |
| Robin_Watts | Do we need to check for that failure? | 18:28.38 |
| | And, if we now have 2 copies of the string does this need changes to the finalisation to avoid leaks ? | 18:29.05 |
| mvrhel_laptop | I believe we are safe with the null return | 18:29.08 |
| | it is clean its memory use | 18:29.31 |
| | it allocates copies to String and deletes the original | 18:29.44 |
| | String itself is garbage collected | 18:29.56 |
| | s/its/in its/ | 18:30.08 |
| Robin_Watts | oh, so char_to_String(x) makes a copy of x and free's x ? | 18:30.18 |
| mvrhel_laptop | we dont have 2 copies | 18:30.21 |
| Robin_Watts | s/'// | 18:30.43 |
| mvrhel_laptop | hmm let me double check about x actually | 18:31.24 |
| Robin_Watts | no, it doesn't delete x. OK. | 18:32.06 |
| | It deletes the intermediate buffer it uses. | 18:32.16 |
| mvrhel_laptop | ok. I need to add a release on these | 18:32.26 |
| | let me add that | 18:32.31 |
| Robin_Watts | oh, ok. | 18:32.36 |
| mvrhel_laptop | that bug existed in the old code too | 18:32.49 |
| | damn it | 18:32.51 |
| Robin_Watts | in the old code, weren't they freed by gc as they were String^? | 18:33.15 |
| mvrhel_laptop | oh wait hold on | 18:36.56 |
| | let me walk myself through this. i thought I knew what i was doing.... | 18:37.51 |
| | ok so std::string should release itself | 18:40.03 |
| | but, I may add in the delete just for safety :) | 18:40.52 |
| | let me run it through the debugger and see what happens | 18:41.06 |
| Robin_Watts | ok. Looks fine to me. | 18:41.10 |
| marcosw | henrys: you around? | 18:42.30 |
| henrys | on the phone | 18:42.54 |
| marcosw | NP, let me know when you have time. | 18:44.24 |
| henrys | shoot | 18:45.00 |
| | marcosw: ^^^ | 18:45.43 |
| marcosw | henrys: that was quick. I'm trying to deal with customer 351, the one that I'm in trouble with, and am in over my head in regards to setting of paper size when converting from PostScript -> PXL | 18:56.09 |
| | I've opened a bug, assigned to you, since PXL output is yours. Can you take a look at it sooner rather than later? | 18:56.43 |
| henrys | marcosw: why is that different than the unsolved problem we were just discussing: http://bugs.ghostscript.com/show_bug.cgi?id=691921 | 19:02.08 |
| | ? | 19:02.11 |
| mvrhel_laptop | Robin_Watts: grrrrrr something weird is going on with visual studio. now there are 3 NDEBUG preproc defs in the projects.. | 19:05.17 |
| Robin_Watts | mvrhel_laptop: emacs is your friend :) | 19:05.35 |
| henrys | marcosw: kens has sort of taken the lead on this - I was just looking back and he sent a long pdf explaining everything to the customer back in 2011, but they didn't respond to it or at least I didn't see a response to kens detailed report | 19:05.45 |
| mvrhel_laptop | Robin_Watts: yes, I am thinking the text editor is the way to go | 19:05.59 |
| chrisl | Robin_Watts: emacs is no one's friend! | 19:06.15 |
| Robin_Watts | emacs is atrocious. It's just less atrocious than all the alternatives. | 19:06.55 |
| chrisl | I'll stick to nedit... clunky and old fashioned though it is | 19:07.46 |
| henrys | emacs lisp now has static and dynamic scoping, I think it is the first language to do that, but I'm not positive. | 19:08.16 |
| Robin_Watts | because it wasn't confusing enough already. | 19:08.55 |
| henrys | well I finished wool - good story ⦠not so crazy about writing or character development though. Starting Shift | 19:09.47 |
| chrisl | Really? I really liked the writing and the characters..... | 19:10.33 |
| Robin_Watts | wool/shift/dust have spawned all sorts of fan fiction. | 19:10.48 |
| | lots of "silo stories" ebooks out there. | 19:11.06 |
| henrys | chrisl: I just recently finished my 3rd go of Blood Meridian, so my bar might be a bit high. | 19:14.24 |
| chrisl | henrys: ah, I'd just read The Handmaid's Tale - so my bar might have been a bit low..... but I still really liked both Wool and Shift. | 19:15.51 |
| Robin_Watts | henrys: 3rd reading? Or 3rd attempted reading? | 19:16.27 |
| henrys | I thought I read something about Wool being derivative of some much earlier story from the 60's or something but I might not have the details right. | 19:16.34 |
| | reading, the first time I read it with a guide - every sentence really means something in the book. | 19:17.56 |
| Robin_Watts | And for your next trick, Ulysses, by James Joyce. | 19:18.25 |
| chrisl | I've got a new translation of the Divine Comedy to read soon..... | 19:19.02 |
| Robin_Watts | chrisl: goodl luck with that. I read inferno, but gave up with the second part. | 19:19.42 |
| | The in jokes about italian politics of the time were lost on me. | 19:20.10 |
| chrisl | Robin_Watts: I got through all of them with the last translation I read, and yes, it definitely takes a down turn after Inferno..... | 19:20.21 |
| | This new translation is by Clive James..... yes, really *that* Clive James | 19:20.50 |
| Robin_Watts | I trust that you'll be reading it in your head with his accent. | 19:21.11 |
| chrisl | strewth yeh! | 19:21.42 |
| marcosw | henrys: looking back at the emails from 2011 I also ran across bug 692570 | 19:23.24 |
| | henrys: I'll send a reply to customer 351 summarizing the situation. Sorry to have bothered you without checking the email logs and open bugs. | 19:23.54 |
| henrys | marcosw: no problem | 19:24.14 |
| chrisl | marcosw: we seem to still have some bugs categories that default to Alex - and I don't know how to change that..... | 19:25.24 |
| Robin_Watts | mvrhel_laptop: So you committed with the multuple NDEBUGs then ? | 19:26.58 |
| | oh, I see the followup. | 19:27.09 |
| mvrhel_laptop | hmm I think I fixed it. I suppose I should have smashed it if I were better at git | 19:27.28 |
| Robin_Watts | yeah, fixed in the followup. | 19:27.40 |
| mvrhel_laptop | ok. now I will be off working on a branch for the desk top stuff (gsview) | 19:31.17 |
| henrys | lunching ... | 19:31.35 |
| marcosw | chrisl_away: for the logs, I'll fix the bug categories that default to alex. it's in the bugzilla admin setting under <mumble> <mumble> (can't recall of the top of my head, but know it when I see it0. | 20:17.53 |
| | chrisl_away: it was all of the jbig2dec components. I've change them to support, let me know if they should be assigned to someone specifically. | 20:21.39 |
| chrisl_away | marcosw: I think henrys currently owns jbig2dec | 20:34.24 |
| henrys | marcosw: give jbig2 to me | 21:33.22 |
| | Robin_Watts: do you think 250.00 is reasonable for this? https://services.myngp.com/ngponlineservices/contribution.aspx?X=6Qyh6zeLcX17t0hUgloBQX%2bHqdgehAzSf3DlF6JMU%2bs%3d | 21:41.05 |
| | Robin_Watts: nvm I went ahead with the 250 | 22:01.03 |
| marcosw | henrys and chrisl_away: I've assigned jbig2dec to henrys, except for the build component which I've assigned to chrisl_away | 22:10.55 |
| ray_laptop | marcosw: did you contact cust 351/850 re: bug 694750 to make sure they saw my response and see if they are OK with that usage mode as a fix ? | 22:30.04 |
| mvrhel_laptop | grumble grumble. I think my original plan of sharing the winRT code portions with the win8 app and the desktop app is going to be more work than just doing a rewrite | 23:00.48 |
| | going to take a break from this for a bit while the sun is out | 23:01.36 |
| ray_laptop | mvrhel_laptop: yeah, trying to share too much code can be a major pain, particularly at the "app" level | 23:03.24 |
| Robin_Watts | henrys: That's the PDF hackathon? Yeah, $250 seems reasoanble. | 23:59.30 |
| | Forward 1 day (to 2014/01/16)>>> | |
IRC Logs