| | <<<Back 1 day (to 2011/11/09) | 2011/11/10 |
| Robin_Watts | tor8: I fear I've got a long way to go in Fallout 3 yet. | 00:13.05 |
| arthurf | playing around a little with browsing XPS files through the iOS viewer | 04:12.00 |
| Robin_Watts | tor8: ping | 12:10.07 |
| tor8 | Robin_Watts: pong! | 12:10.14 |
| Robin_Watts | Today I plan to look at the iOS stuff. | 12:10.27 |
| | Has apple changed the hoops you need to jump through? | 12:10.47 |
| tor8 | I'm buying airplane tickets. Guess what, the default option was to fly in via london city airport and leave through heathrow again! | 12:10.54 |
| Robin_Watts | Can I develop for the simulator without having to pay again? | 12:11.02 |
| tor8 | Robin_Watts: no, the hoops remain largely the same. | 12:11.08 |
| Robin_Watts | So I still need a valid developer account? | 12:11.31 |
| tor8 | yeah, you can develop for the simulator without getting into the mine field! | 12:11.33 |
| Robin_Watts | Oh, ok, simulator it is then. | 12:11.44 |
| tor8 | but if you want to run on a device, it's nasty time. | 12:11.49 |
| Robin_Watts | oh, but the simulator is x86 based? | 12:12.08 |
| | rather than emulated ARM ? | 12:12.16 |
| | I had a thought while running. | 12:12.50 |
| | In fz_gridfit_matrix there are lots of references to FLT_EPSILON | 12:13.05 |
| | Try changing those to 0.001 | 12:13.19 |
| | That might fix the idempotency issues. | 12:13.40 |
| | FLT_EPSILON is quite small, as I remember. | 12:13.58 |
| | but with numbers in the 1000s, the actual epsilon is much larger. | 12:14.16 |
| tor8 | yeah, the simulator is x86-based | 12:14.28 |
| Robin_Watts | Sorry marcos :( | 12:41.48 |
| | kens: Dunno if you got a second monitor, just got mailed this one: http://www.ebuyer.com/286511-philips-e-line-227e3lsu-lcd-led-full-hd-21-5-dvi-monitor-227e3lsu-00 | 12:55.06 |
| | That one has DVI and VGA. | 12:55.12 |
| kens | And its reasonably cheap ;-) | 12:55.47 |
| Robin_Watts | I think that's the cheapest I've seen a DVI one. | 12:56.04 |
| | In the same mail they have a 120Gig SSD for 99quid, which is 30 quid cheaper than I got mine for last month. | 12:59.57 |
| kens | remarkable price. | 13:00.20 |
| Robin_Watts | yeah. I wouldn't have just an SSD in the machine (I like an HD for bulk/frequently changed storage), but it does make stuff much faster. | 13:01.08 |
| | And that's my last customer bug closed. woo hoo! | 13:02.37 |
| kens | You can have some of mine if you like >:-) | 13:02.57 |
| Robin_Watts | Suggest a few, and I'll have a look in a bit to see if there's anything that tickles me ... | 13:04.31 |
| kens | Just joking, the only ones I have really are pdfwrite/ps2write enhancements | 13:04.59 |
| Robin_Watts | 1.8Gig to update to the latest xcode. sheesh. | 13:26.06 |
| kens | Ai Caramba! | 13:26.31 |
| norbertj | hello tor8 | 13:51.17 |
| tor8 | hi norbertj | 13:51.26 |
| norbertj | I have a question on building xps with msvc 2010. | 13:51.31 |
| tor8 | okay? | 13:52.26 |
| norbertj | I use latest. git pull --rebase (on master). And when building from git-bash shell I get warnings on jxr_get_TILING_FLAG etc. | 13:52.48 |
| | Luckily it still produced a gxps.exe (I thought it failed). | 13:53.33 |
| tor8 | the microsoft reference code for jpeg-xr (the jxr) is chock full of warnings | 13:53.49 |
| | so I wouldn't worry too much about warnings when compiling that particular library. | 13:55.15 |
| norbertj | On our printer (B&W) we have a complaint about bad looking xps-output (i.e. a jpeg-picture is badly converted to b&w, it looks very flattened (very few grayscales). | 13:55.56 |
| tor8 | that sounds more ominous. I know mvrhel has worked on some issues with images in xps recently, but I don't think that was anything to do with jpeg. | 13:57.11 |
| norbertj | If printing to -sDEVICE=display, it looks ok. (i.e. the gxps.exe displaydevice is color. | 13:57.15 |
| | It's probably not jpeg, but conversion from color to b&w. | 13:57.41 |
| tor8 | does it affect other images and gradients too? | 13:58.01 |
| norbertj | I don't know. The guy from the xps-driver came with page 111 (from a 214 page job) showing the output, and I didn't have the time yet to investigate further. | 13:59.46 |
| | I will make it into a 1 page xps job and create a bug for it. | 14:00.07 |
| tor8 | norbert: thanks. | 14:19.33 |
| Robin_Watts | tor8: ok, xcode updated to 4.2, mupdf built and running in simulator. | 14:44.38 |
| | now to try and get a file in there for it to view. | 14:44.50 |
| norbertj | tor8: I re-checked and our printer has currently 9.02 (with a problem). When I compare git (9.05) with 9.02. I see 9.02 has (bmpmono) bad (flattened) output, and the git shows far better output. So we have to integrate 9.04 ;) | 14:46.18 |
| tor8 | Robin_Watts: in ~/Library/Application Support/iPhone Simulator/5.0/Applications/...hex-code.../Documents | 14:47.53 |
| Robin_Watts | Ah! | 14:48.03 |
| | How do I zoom in the simulator ? | 14:52.54 |
| tor8 | alt-click | 14:52.59 |
| | that starts a faked pinch gesture | 14:53.06 |
| Robin_Watts | Gottit, ta. | 14:53.18 |
| norbertj | tor8: FYI, the 9.04 also has the problem , but the git-master has it fixed. | 14:53.29 |
| Robin_Watts | norbertj: Yes, various xps bugs were fixed within the last week or so my mvrhel2 and myself. | 14:54.02 |
| | ok, tor8? | 15:21.45 |
| tor8 | Robin_Watts: yeah? | 15:22.06 |
| Robin_Watts | I've put a printf of the ctm values at the start of fz_gridfit_matrix, and another at the end. | 15:22.17 |
| | I've then put a printf of "------" after the actual paint is done. | 15:22.33 |
| | When I first run the app, and it renders page 217 of DragonAge.pdf, I see lots of 'paired' calls, as you'd expect. | 15:23.10 |
| | The first one genuinely gridfits. | 15:23.24 |
| | the second ones are often called with different values than the first, but they are always grid aligned, and are never changed. | 15:24.09 |
| | (Presumably that's clipping or something) | 15:24.19 |
| | So the problem is not gridfitting being done twice. | 15:24.42 |
| | We will get different results from gridfitting an image, scaling it, then clipping it, then plotting it, than we will with scaling, clipping, then gridfitting. | 15:25.55 |
| | actually, it can't be clipping... | 15:36.54 |
| | tor8: There is a </File> missing from libmupdf.vcproj after the entry for doc_outline.c in the ios branch. | 15:41.28 |
| tor8 | Robin_Watts: d'oh | 15:42.18 |
| Robin_Watts | I've found a bug in the gridfitting code to do with rotated images. | 16:02.02 |
| | but it doesn't fix the main problem. | 16:02.07 |
| | tor8: If you switch to running it on the iphone sim, rather than the ipad sim. | 16:09.08 |
| | ignore that. | 16:11.02 |
| | tor8: OK. If I disable smooth scaling entirely, and disable all interpolation, then I get perfect results, as long as I remove the u += 0.5, v += 0.5 thing. | 16:38.00 |
| tor8 | Robin_Watts: yeah, the += 0.5 thing didn't seem to do what we wanted in my testing either | 16:39.01 |
| Robin_Watts | If I force the use of linear interpolation, then I get a y shift of 1 texel. | 16:40.28 |
| | I have something that seems to work perfectly. | 16:50.14 |
| | but I don't understand it :( | 16:50.27 |
| kens | Perfect! | 16:50.43 |
| Robin_Watts | marcosw_: Sorry. I fear I've just changed every image in the cluster by tiny shifts in color. | 16:55.50 |
| marcosw_ | henrys and rayjj: as usual I'm prepping for my 10:00 meeting and so would like to postpone or cancel today's support meeting. | 16:55.55 |
| | Robin_Watts: again? I've just recovered from the last change you made! | 16:56.12 |
| Robin_Watts | Sorry. | 16:56.28 |
| marcosw_ | seriously, how much shift in colour? The compare uses fuzzy with a reasonable threshold for intensity differences | 16:57.11 |
| kens | regression showed about 20-25% files differed | 16:57.36 |
| Robin_Watts | Well, each encode color change from 16 to 8 bits can now be changed by 1. | 16:57.38 |
| | but I did a bmpcmp run with a threshold of 4 and it still found differences (in shadings mostly, I think) | 16:58.05 |
| | and of course halftones may cause pixels to snap from 0 to 255. | 16:58.36 |
| henrys | marcosw_:okay | 17:00.09 |
| marcosw_ | Robin_Watts: the halftone issue isn't a problem, I scale the images down to 72 dpi and then compare the bitmaps. | 17:01.55 |
| Robin_Watts | 72dpi halftoned ones will be :) | 17:02.17 |
| kens | Time to go, night all | 17:04.54 |
| Robin_Watts | tor8: ping | 17:20.26 |
| | tor8: http://ghostscript.com/~robin/0001-tor.patch is now updated with a patch from the head of the ios branch as published in your repo to something that works for me. | 17:29.34 |
| tor8 | Robin_Watts: that patch also has the android and arm fixes, if that's intentional? | 17:30.47 |
| Robin_Watts | yes. | 17:30.53 |
| tor8 | just checking. | 17:31.04 |
| Robin_Watts | because that introduces fz_scale_simple etc | 17:31.15 |
| tor8 | I tried the arm version on my iPad, but got a crash with some obscure error message | 17:31.27 |
| Robin_Watts | A crash, or a fail to build ? | 17:31.37 |
| tor8 | you may have missed it in the logs | 17:31.40 |
| Robin_Watts | I saw something about a literal pool being too far away. | 17:31.55 |
| | We can work to fix that. | 17:32.03 |
| tor8 | yeah, that was with no-thumb on armv6 | 17:32.15 |
| | with thumb it compiles but crashes | 17:32.21 |
| Robin_Watts | Are you building with thumb enabled ? | 17:32.58 |
| tor8 | yes. I'm building with armv7 and thumb enabled | 17:33.18 |
| | as per apple's recommendations, that's the way Xcode builds by default | 17:33.41 |
| Robin_Watts | ok. Then I'd expect you to have to build with ARCH_THUMB and ARCH_ARM both defined - dunno why it crashes. Would need to look at the object file to see what apples god awful assembler is doing with it. | 17:34.30 |
| tor8 | yes, I built with both -DARCH_THUMB and -DARCH_ARM | 17:34.58 |
| | any other way and I get compiler errors :) | 17:35.04 |
| Robin_Watts | tor8: When you get a mo, can you mail me the draw_simple_scale.o when built with the ARM code please? | 17:57.28 |
| ray_laptop | mvrhel: Holy Cow !! the halftone generator sure outputs a lot of junk files (___.raw) Do you mind if I make those conditional on #ifdef DETAIL_DEBUG ??? | 17:59.25 |
| mvrhel | hmm | 17:59.44 |
| | it should not be doing that by default | 17:59.53 |
| | sorry | 17:59.55 |
| | but maybe I forgot to disable some stuff. Feel free to add in the ifdef | 18:00.23 |
| | I wouldnt call them junk files.... | 18:00.34 |
| ray_laptop | mvrhel: Oh, I see. RAW_SCREEN_DUMP is 1 by default. I'll change that (along with my other changes) | 18:01.53 |
| mvrhel | ok thanks | 18:02.03 |
| ray_laptop | mvrhel: they're 'junk' to me because I don't know what they all are. | 18:02.53 |
| | mvrhel: I'm sure they are quite valuable to you :-) | 18:03.07 |
| | mvrhel: what does the "Levels" mean in the stdout ? | 18:06.54 |
| mvrhel | hmm. hold on. let me look | 18:07.16 |
| ray_laptop | I assume the last line printed is the "choice" params: | 18:08.09 |
| | x y u v Angle LPI Levels | 18:08.11 |
| | 3 3 3 -3 45.0 70.7 18 | 18:08.13 |
| mvrhel | oh that is the number of quantization or gray levels achieved by that particular sub cell | 18:08.39 |
| ray_laptop | mvrhel: I had requested -q 1024 (to test out the 16-bit PS code) | 18:09.03 |
| mvrhel | well yes | 18:09.14 |
| | that is differnt | 18:09.16 |
| | this is the number of levels in the small cell not the whole screen | 18:09.32 |
| | I have not tested the 16 bit stuff yet | 18:09.45 |
| | just so you know | 18:09.49 |
| | so if you do 1024 for -q you *should* see that many levels in the large screen | 18:10.18 |
| ray_laptop | my params were -r300 -a 45 -l 60 -q 1024 -f ps | 18:10.30 |
| mvrhel | but again I have not tested this particular case out | 18:10.31 |
| ray_laptop | so did I get more than 256 levels ? | 18:10.40 |
| mvrhel | you should bet 1024 levels in the large screen | 18:11.05 |
| | the subcell size sets the lpi | 18:11.10 |
| | and it has its own quantization amount | 18:11.18 |
| | and sets the stage for how much dithering of the subcells needs to occur in the large screen | 18:11.32 |
| | s/bet/get/ | 18:11.53 |
| ray_laptop | mvrhel: oops -- I also had -s 64 | 18:12.00 |
| mvrhel | I am not sure who is going to win in that case | 18:12.16 |
| | a size of 64 is going to constrain you on the levels | 18:12.47 |
| | this is a case that I need to take a look at | 18:12.56 |
| ray_laptop | the threshold array ended up 66x66 which (in theory) can have up to 4,356 levels | 18:13.02 |
| mvrhel | well likely not with an ordered subcell | 18:13.33 |
| | that you wanted to get the lpi | 18:13.38 |
| | there are several competing parameters in this case | 18:13.50 |
| ray_laptop | mvrhel: If I don't specify the -s 64 I get a 6x6 array | 18:15.14 |
| mvrhel | once I get finished up with getting copy_planes working with Robin_Watts' patch I will go and take a closer look at the 16 bit case as well as what happens when small screen requests with high lpi and quantization | 18:15.22 |
| | ray_laptop: that doesnt seem rigvht | 18:15.38 |
| | right | 18:15.40 |
| Robin_Watts | mvrhel: If it gets to the point where you have something you want to kick back to me for me to keep on at, please say. | 18:15.55 |
| ray_laptop | mvrhel: 60 lpi at 300 dpi isn't particularly high (IMHO) | 18:16.12 |
| mvrhel | Robin_Watts: no I almost have my initial cut written. and then I was going to test | 18:16.29 |
| | ray_laptop: no its not I agree | 18:16.38 |
| | I don;t know what is going on | 18:16.44 |
| ray_laptop | mvrhel: let me commit the changed version ... (at least it doesn't crash) | 18:16.52 |
| mvrhel | I will have to take a look at it in a bit | 18:16.53 |
| | did it crash before? | 18:18.04 |
| | ray_laptop? | 18:18.25 |
| ray_laptop | mvrhel: no, the original didn't crash. I just meant that my changed version doesn't crash | 18:24.29 |
| mvrhel | ok | 18:24.44 |
| ray_laptop | mvrhel: but I _could_ make the original crash if I forgot to put a value for an option (get_arg returned NULL) | 18:25.17 |
| mvrhel | oops | 18:25.32 |
| ray_laptop | mvrhel: I fixed that | 18:25.42 |
| | mvrhel: I'm going to push the changes for you to look at. When you get a chance, please review and let me know if the README looks OK now, and if you think I messed up anything (I didn't touch the actual screen gen code -- just the options) | 18:38.40 |
| mvrhel | ok thanks. I will dig into the issues that you found | 18:39.02 |
| ray_laptop | mvrhel: OK. pushed. | 18:39.51 |
| mvrhel | ok thanks | 18:40.12 |
| ray_laptop | oops. Typo in the 16-bit halftone. I'll do a quick fix, but that won't hold you up. | 18:40.58 |
| ray_laptop | forgot to actually test that the 16-bit PS loaded :-( | 18:41.24 |
| Robin_Watts | mvrhel: In gsicc_get_link_profile, line 519 in the debug statement there... should that be found_link? link is uninitialised at that point, I believe. | 18:53.34 |
| | mvrhel: In gsicc_get_link_profile, line 519 in the debug statement there... should that be found_link? link is uninitialised at that point, I believe. (in case you didn't see it before) | 18:59.34 |
| mvrhel | hold on | 18:59.48 |
| | yes. strange since I ran this before | 19:01.42 |
| | I am surprised it did not complain at that time | 19:02.05 |
| Robin_Watts | Also, in xpspath.c, line 50, do you mean &xy ? | 19:03.09 |
| | I'd imagine you mean xy or &xy[0] | 19:03.24 |
| tor8 | Robin_Watts: '&array' and 'array' both end up being the same address, but presumable it should just say 'xy' | 19:04.33 |
| mvrhel | good grief yes | 19:04.35 |
| | I would just put xy | 19:04.50 |
| Robin_Watts | ok. | 19:05.11 |
| | just squashing some warnings. | 19:05.18 |
| mvrhel | sure | 19:05.21 |
| | I actually would have thought &xy would have been a problem | 19:07.17 |
| Robin_Watts | Yeah, I would have expected that to be undefined. but then C does wacky things with pointers. | 19:08.05 |
| mvrhel | ok. back to threshold fun | 19:08.05 |
| ray_laptop | mvrhel: OK. I pushed the fixed 16-bit PS output (I actually tested it). | 19:09.59 |
| mvrhel | ok. great. thanks ray_laptop. when I get to stopping point in this other HT stuff i will go back and take a look at the case you brought up | 19:10.37 |
| Robin_Watts | tor8: Did that fix the scaling/offset etc to your satisfaction ? | 19:11.15 |
| mvrhel | finally ready to run and test. I am sure things are going to explode | 19:11.45 |
| ray_laptop | mvrhel: no rush. BTW, the 16-bit 66x66 threshold array looks OK. | 19:11.47 |
| mvrhel | oh thats good | 19:11.56 |
| ray_laptop | of course GS just ignores the low bits :-/ | 19:12.03 |
| mvrhel | well at least it did not crash | 19:17.42 |
| | output is wacky though | 19:18.32 |
| | hmm only the first channel is correct | 19:18.55 |
| Robin_Watts | ray_laptop: gp_wgetv.c, line 231... presumably that should be just buf, not &buf | 19:20.46 |
| | mvrhel: http://git.ghostscript.com/?p=ghostpdl.git;a=blame;f=gs/base/gxicolor.c;h=6d5f45e50b8b339cf3d07b9ce1297b6608e266ed;hb=HEAD Line 450 | 19:26.58 |
| | penum->rect.w is an int. So is src_size. Why "- 1.0" ? | 19:27.17 |
| | (sorry, I'm hoping that the link interrupts you less than making you hunt for a file) | 19:27.40 |
| mvrhel | I think 1 is fine | 19:27.56 |
| Robin_Watts | thanks. | 19:28.47 |
| mvrhel | oh I think I see the issue | 19:53.20 |
| | a misunderstanding on my part of what plane_height was | 19:53.38 |
| Robin_Watts | mvrhel: Oh, sorry, I thought you were talking to ray. | 19:54.23 |
| mvrhel | Robin_Watts: so when is plane_height different from h? | 19:54.39 |
| Robin_Watts | plane_height = number of 'rasters' to move to get from one plane to another. | 19:54.55 |
| | Suppose you have a pattern tile of 100x100. | 19:55.04 |
| | but you only want to plot a rectangle that's 50 high. | 19:55.30 |
| mvrhel | oh I was never thinking about that case | 19:55.37 |
| Robin_Watts | height will be 50, but plane_height will be 100. | 19:55.40 |
| mvrhel | patterns that is | 19:55.42 |
| Robin_Watts | Sadly, I had to think about that case :( | 19:55.53 |
| mvrhel | for my case, h is always the plane_height | 19:55.56 |
| | yes | 19:55.58 |
| | ok thanks | 19:56.06 |
| Robin_Watts | np. | 19:56.09 |
| mvrhel | ok. cool. got a reasonable looking output in the portrait case | 19:59.16 |
| Robin_Watts | excellent. | 19:59.56 |
| mvrhel | now I need to check the landscape case | 20:01.00 |
| | hmm seems to be in an infinite loop in my set up... | 20:04.01 |
| | not sure how I managed to do that | 20:06.36 |
| | oh I think I see | 20:07.59 |
| | the landscape buffers require a bit more work | 20:09.05 |
| ray_laptop | mvrhel: what non-GS tool do you use to look at the separations ? | 20:14.35 |
| mvrhel | from tiff sep? | 20:14.56 |
| ray_laptop | mvrhel: no, I mean what other than GS can generate the seps ? | 20:15.23 |
| mvrhel | which seps? I am confused | 20:15.43 |
| Robin_Watts | photoshop can load .raw files and display specified layers, apparently, if that's what you mean. | 20:16.11 |
| ray_laptop | mvrhel: sorry. I am still trying to figure out what's going on with file 1 of Bug 692618 | 20:16.14 |
| mvrhel | you mean for the above discussion with robin? | 20:16.16 |
| | ok hold on let me look at that | 20:16.48 |
| ray_laptop | it's a PDF flle with LOTS of spot colors (9) | 20:16.59 |
| mvrhel | weird can't get to the bug data base | 20:17.05 |
| Robin_Watts | Me either | 20:17.23 |
| mvrhel | ray_laptop: yes if it is the *.raw files, I open those in photoshop | 20:17.25 |
| Robin_Watts | and yet, my ssh session to casper works fine. | 20:17.38 |
| | mvrhel: Oh, for some reason, the link above was trying via https:// | 20:18.22 |
| ray_laptop | hmm... I can get there | 20:18.25 |
| Robin_Watts | http:// to the bugs database works fine. | 20:18.32 |
| mvrhel | ah ok | 20:18.55 |
| ray_laptop | I am trying to see if the banded mode (even with 1 band) is really wrong or not, and if so, where. | 20:20.03 |
| mvrhel | so yes ray_laptop, I use photoshop. the file name will give the information | 20:20.28 |
| | ray_laptop: you can see the issue in the combined file | 20:20.37 |
| ray_laptop | because I don't trip over the NON_ENCODABLE_COLOR breakpoints as I do with page mode | 20:20.44 |
| Robin_Watts | ray_laptop: If you find something other than photoshop, please let me know. | 20:20.47 |
| mvrhel | notice all the white drop outs | 20:20.49 |
| Robin_Watts | I end up using a hex editor and setting the width :( | 20:20.57 |
| mvrhel | Robin_Watts: I am guessing you have an issue with PS... | 20:21.19 |
| Robin_Watts | mvrhel: I have an issue about paying a 4 figure sum for a copy, yes :) | 20:21.39 |
| mvrhel | yes | 20:21.51 |
| Robin_Watts | Photoshop elements doesn't support layers. | 20:22.04 |
| | (well, it only does RGB, I believe) | 20:22.25 |
| ray_laptop | mvrhel: OK. I see the funky 'white' pattern around the "BANG" on the left image. | 20:23.55 |
| mvrhel | need to take a break for lunch. the landscape case is a bit more complex due to the way that the buffer position information was reset with each plane prevsiosly. | 20:24.02 |
| | ray_laptop: yes | 20:24.09 |
| Robin_Watts | mvrhel: I've just pushed a patch to change template to templat. | 20:24.22 |
| ray_laptop | mvrhel: thanks. Enjoy your lunch | 20:24.23 |
| mvrhel | where the gradient (or transparency is/was) | 20:24.24 |
| Robin_Watts | Were there any more such words? | 20:24.31 |
| mvrhel | Robin_Watts: great! | 20:24.36 |
| Robin_Watts | alexcher mentioned 'this' but I can't see it. | 20:24.41 |
| mvrhel | I only ran across template | 20:24.50 |
| Robin_Watts | (only in zlib, and that's not ours) | 20:24.54 |
| | Oh, wait, found lots of this in ttf stuff. | 20:25.18 |
| | I'll change from "this" to "self" later. | 20:25.46 |
| ray_laptop | Robin_Watts: I see 'this->' in: base/gscicach.c base/gsgcache.c base/gxclist.c base/gxhintn.c base/gxhintn1.c base/gxpflat.c base/gxttfb.c base/ttfmain.c | 20:28.39 |
| Robin_Watts | ray_laptop: Me too. | 20:28.47 |
| ray_laptop | Robin_Watts: but thanks for the improvements (even templat helped) | 20:30.36 |
| Robin_Watts | Hmm. template -> templat caused differences. | 20:43.55 |
| | I'll look into that tomorrow. | 20:44.18 |
| tor8 | Robin_Watts: should I build draw_scale.c or draw_simple_scale.c or both? | 21:07.17 |
| Robin_Watts | draw_simple_scale.c | 21:29.11 |
| mvrhel | off to take the car for emissions check | 21:45.31 |
| | bbiab | 21:45.33 |
| | Forward 1 day (to 2011/11/11)>>> | |
IRC Logs