| | <<<Back 1 day (to 2012/04/18) | 2012/04/19 |
| Robin_Watts | mvrhel: If you use Chrome, then look for 'google input/output' in the chrome webstore. | 00:00.08 |
| mvrhel | dinner time. bbiaw | 00:02.19 |
| henrys | Robin_Watts:still working on the fill code - uncovered a few gl/2 bugs in the process. HP's path code is insane. | 00:04.10 |
| Robin_Watts | henrys: What phone do you have? | 00:06.23 |
| henrys | iphone | 00:06.52 |
| Robin_Watts | Can you tether to that? | 00:07.17 |
| henrys | no I haven't broken it or ordered tethering. | 00:07.41 |
| | sabrina just told me we wouldn't have internet at a couple of places. You have internet in bhutan and I can't have it in the UK? | 00:08.30 |
| Robin_Watts | henrys: I can loan you my cell phone overnight while you're at the horse and groom. That can be a wifi hotspot (assuming the cellphone can get service). | 00:09.11 |
| henrys | it really isn't a big deal I can last a few days without the internet, hell I might do something useful without it. | 00:10.39 |
| | your up late! | 00:10.59 |
| Robin_Watts | henrys: I keep trying to tell myself that too, but the shakes set in after about 12 hours of no IP packets. | 00:12.34 |
| | Yeah, just off to bed... | 00:12.44 |
| henrys | good night I'm heading out to dinner. | 00:13.16 |
| debjan1 | Hello. I cloned MuPDF git on Ubuntu 11.04. By default it builds fine, but I was asked to make shared library, and I tried by adding "-fPIC" in CFLAGS variable in Makerules file. However I get same result as w/o "-fPIC" so I guess it's not so trivial. Can someone suggest how it could be possible? | 03:28.11 |
| ccotton_ | Thanks Robin_Watts for the info | 04:54.51 |
| kens | What a wonderful comment : | 07:43.21 |
| | * Write the Cos objects for resources local to a content stream. Formerly, | 07:43.22 |
| | * this procedure also freed such objects, but this doesn't work, because | 07:43.22 |
| | * resources of one type might refer to resources of another type. | 07:43.22 |
| | So instead of fixing the problem, we just decided to stop freeing memory.... | 07:43.41 |
| vtorri | it reminds me some weird commit in openjpeg | 07:52.57 |
| | they use winsock 2 | 07:53.10 |
| | but including winsock2.h breaks compilation | 07:53.34 |
| | they found that including winsock.h does not break compilation | 07:53.53 |
| | so they included it instead of winsock2.h... | 07:54.07 |
| kens | :-) | 07:54.12 |
| | In my case it leads to pdfwrite leaking hundreds of memory allocations.... | 07:54.31 |
| vtorri | i told them it was very wrong | 07:54.34 |
| | hiding bugs... | 07:54.44 |
| | hehe | 07:54.46 |
| | of course :) | 07:54.51 |
| kens | Yes, hiding bugs is bad. | 07:54.53 |
| | Its taken me a week to figure this one out | 07:55.19 |
| vtorri | valgrind couldn't help ? | 07:55.37 |
| | btw, i left the openjpeg project because of that | 07:55.50 |
| kens | Afraid not. | 07:55.50 |
| | Its a double free in our own memory allocator. It only shows up if the first free sets a particular part of the freed structure memory to 0. | 07:56.20 |
| vtorri | i can't work with devs that can't understand that hiding bugs like that is very bad | 07:56.28 |
| | ha | 07:56.35 |
| | ok | 07:56.37 |
| kens | I could only reproduce the problem at alll on a 64-bit Linux with a specific configuration. | 07:57.04 |
| | Even then, in our 5,000+ tests it only shows up in about 15 cases | 07:57.29 |
| | 50,000 | 07:57.35 |
| | But there it shows up as a seg fault | 07:57.52 |
| | Debugging using ddd over ssh is not my idea of a fun time ;-) | 07:58.32 |
| vtorri | :) | 07:59.46 |
| kens | btw chrisl, that comment explains the 'half cocked' apporach to memory management in pdfwrite. At some point the memory was properly tracked and freed, then someone (I can take a guess at who) found that problem, and removed half the code that frees memory, leaving the remainder in place.... | 08:03.07 |
| naveen_ | Hi Robin, I tried to encrypt a file and decrypt the same file with the functions in muPDF...but the decrypted file is not same as the original file...Any ideas? | 08:04.55 |
| kens | naveen_ : Not the same in what way ? | 08:05.17 |
| naveen_ | decrypted file is corrupted and I'm not able to open in adobe reader.. | 08:05.48 |
| kens | Ah, well not what I was thinking of then. | 08:06.01 |
| | What kind of encryption are you using ? | 08:06.16 |
| | BTW naveen_ Robin_Watts probably won't be here for another hour to an hour and a half | 08:06.56 |
| naveen_ | ohh..can you help me on this? | 08:07.28 |
| kens | Not a lot, I'm not really a MuPDF developer, I work on Ghostscript | 08:07.44 |
| naveen_ | ok thanks...I'll contact Robin when he is in.. | 08:07.59 |
| kens | NP, as long as you know you'll need to wait a bit :-) I'm sure he will read the irc log | 08:08.38 |
| vtorri | kens: btw, one question about gs | 08:13.25 |
| kens | yes ? | 08:13.32 |
| | Don't guarantee I can answer though | 08:13.40 |
| vtorri | for our rendering library, i use libspectre | 08:13.43 |
| | which is a wrappper above libgs | 08:13.57 |
| kens | Yep | 08:14.01 |
| vtorri | i would like to remove that layer | 08:14.15 |
| kens | OK | 08:14.26 |
| vtorri | would it be difficult to just use libgs for a rendering ? | 08:14.33 |
| kens | vtorri I don't see why it would be difficult | 08:14.43 |
| vtorri | i didn't look at libspectre code | 08:14.49 |
| | (yet) | 08:14.55 |
| | so | 08:14.57 |
| | is there some simple examples somewhere ? | 08:15.08 |
| kens | Well you can get GS to return you a buffer with a bitmap in it, which should be enough I woudl think | 08:15.11 |
| | The WIndows display device does that. | 08:15.21 |
| | 'simple' and Ghostscript shoul d never appear in the same sentence.... | 08:15.36 |
| vtorri | hehe | 08:15.56 |
| | i think that i already did something similar with dvilib | 08:16.16 |
| | (similar than libspectre) | 08:16.28 |
| kens | The simplest solution is probably to look at a few of the existing devices. But if it was me, I think I woudl start with teh display device on the relevant OS | 08:16.35 |
| | Linux ? | 08:16.48 |
| vtorri | all | 08:16.53 |
| | unix + windows | 08:16.56 |
| kens | Umm, I'm not so familiar with teh Linux display device(s) | 08:17.15 |
| vtorri | more precisely : linux, bsd, mac, solaris and windows | 08:17.15 |
| kens | I guess all you really want is a memory full of image smaples ? | 08:17.30 |
| vtorri | yes | 08:17.37 |
| | i want the (a)rgb data of page N | 08:17.50 |
| kens | alpha is a problem | 08:17.58 |
| | I don't know much about that | 08:18.12 |
| | chrisl you know anything about this topic ? | 08:18.49 |
| | I guess the PNG device might be a decent start | 08:19.28 |
| vtorri | http://cgit.freedesktop.org/libspectre/tree/libspectre/spectre-device.c#n214 | 08:20.12 |
| | it seems that they use the 'display' device | 08:20.23 |
| kens | Yes, which is what I was suggesting too :-) | 08:20.31 |
| | Because it returns a bunch of samples in memory | 08:20.53 |
| | That should be easy for you to code I woudl think | 08:21.14 |
| vtorri | yes | 08:21.22 |
| chrisl | Sorry, I'm dealing with the guys fitting a new back door just now....... | 08:21.28 |
| vtorri | that libspectre layer is, imho, useless | 08:21.31 |
| kens | Well, some people seem to find it helpful, I've never looked at it myself | 08:21.49 |
| vtorri | dev is halted since 2010 | 08:22.04 |
| kens | Oh, that's not so good. | 08:22.14 |
| chrisl | FWIW, if all you're after is a big ole' raster, then the display device is where I would go. The only thing is, I'm not sure it supports banding. | 08:22.52 |
| kens | That code looks like it was cobbled up from our Windows code | 08:22.57 |
| vtorri | and is there some multithreading stuff in libgs ? :) | 08:23.34 |
| kens | chrisl if the libspectre code is good enough for vtorri now, and it uses the display device, then its probably fine. | 08:23.47 |
| | vtorri, only for rendering from display list | 08:23.54 |
| | interpretation is a mostly single threaded operation really | 08:24.11 |
| vtorri | ok | 08:24.16 |
| | thank you | 08:24.49 |
| kens | NP | 08:24.55 |
| vtorri | not really related, but is there some DVI library except DVIlib ? | 08:25.32 |
| chrisl | kens: yes, I just figured it might be worth mentioning, just in case. | 08:25.49 |
| kens | I have no iodea, sorry | 08:25.52 |
| vtorri | ok | 08:25.54 |
| chrisl | I doubt there is a widely used/available well supported DVI implementation other than dvilib, due the patent problems with the format. | 08:26.38 |
| vtorri | really ? | 08:26.54 |
| | there are still patents ? | 08:27.01 |
| | i thought the format was quite old | 08:27.11 |
| chrisl | The are still unexpired patents relating to it, I believe | 08:27.50 |
| | It is old and basically dead - it's hard to get an "open format" accepted when it involves patents that are being enforced | 08:28.48 |
| vtorri | ok | 08:29.00 |
| | it's not dead for me, as i use LaTeX in my work | 08:29.22 |
| | (and not pdflatex) | 08:29.32 |
| chrisl | Can't latex output straight to PS these days? | 08:30.29 |
| vtorri | don't know | 08:31.24 |
| | i compile with emacs (+auctex) | 08:31.38 |
| | i didn't look at all the compile options | 08:31.49 |
| Robin_Watts | naveen_: Morning | 09:28.52 |
| | I have no immediate ideas about the encryption stuff beyond what I said yesterday. | 09:29.33 |
| | Have you verified that both java and C versions of the code are giving the same keys ? | 09:29.56 |
| naveen_ | Hey Robin..are you in? | 09:30.38 |
| | Morning .. | 09:30.52 |
| Robin_Watts | I am. | 09:30.53 |
| naveen_ | I have verified both java and c versions....key is same | 09:31.20 |
| | I tried to encrypt the file with "aes_crypt_cbc" and decrypt the same file with "aes_crypt_cbc" | 09:32.18 |
| | but the decrypted file was not same as original file | 09:32.43 |
| | Any idea why this is happening? | 09:33.45 |
| Robin_Watts | None at all. | 09:34.26 |
| naveen_ | ideally decrypted file should be same as original file..fight? | 09:34.47 |
| | right* | 09:34.55 |
| Robin_Watts | Are you saying you're using the C code to encrypt the file,then using the C code to decrypt it again? | 09:35.14 |
| naveen_ | yes.. | 09:35.21 |
| Robin_Watts | I'm not sure we ever use the C code to encrypt. | 09:35.29 |
| naveen_ | hmm...do you think there is something related to signed/unsigned cnars ? | 09:36.35 |
| Robin_Watts | I don't see why. | 09:36.44 |
| | Certainly encryption -> decryption *should* give the same file - that's kind of the whole point. | 09:37.16 |
| | but being encyption it's very sensitive to correctness - the smallest detail wrong will give completely different results. | 09:37.53 |
| | It's hard for me to debug blind... | 09:38.09 |
| naveen_ | Can you just try encrypting & decrypting some file using my code? | 09:38.38 |
| Robin_Watts | naveen_: Sure. If you can share your code with me, I can try it out. | 09:38.58 |
| naveen_ | http://pastebin.com/N0mJdyJk | 09:40.17 |
| | just add some logic to populate m_key | 09:40.41 |
| Robin_Watts | ok. It's going to be an hour or 2 before I get to this, I fear, sorry. | 09:42.23 |
| naveen_ | ok...NP | 09:42.47 |
| Robin_Watts | naveen_: Just looking at the code now. | 10:44.41 |
| | When you 'encode' you presumably call aes_setkey_enc and use AES_ENCRYPT, right? | 10:45.41 |
| naveen_ | right | 10:51.10 |
| | ohh sorry I was using "aes_setkey_dec" even for encryption | 10:51.54 |
| Robin_Watts | That may explain it | 10:54.12 |
| | OK. My test works. | 10:56.35 |
| | http://ghostscript.com/~robin/test.c | 10:57.04 |
| naveen_ | yup it works.. | 10:59.03 |
| Robin_Watts | fab. | 10:59.08 |
| naveen_ | I need to figure out why my file is not getting decrypted properly... :( | 10:59.25 |
| Robin_Watts | naveen_: Did you say before that there were 512 header bytes before the first block ? | 10:59.50 |
| naveen_ | yaa..I'm removed it actually | 11:00.15 |
| Robin_Watts | ok, so it's not that... | 11:00.24 |
| | Presumably somewhere in those 512 bytes the real size of the file is encoded? | 11:00.45 |
| naveen_ | yaa..its not that... | 11:00.50 |
| Robin_Watts | You're running under cygwin, right? | 11:01.10 |
| naveen_ | yes | 11:01.14 |
| Robin_Watts | ok, so no windows crlf rubbish. | 11:01.27 |
| naveen_ | md5 digest is signed in java where as it is unsigned in C..do you think that will make a difference? | 11:16.01 |
| Robin_Watts | No. | 11:16.58 |
| | naveen_: If you give me a file, and the key for that file, I can then encode/decode that file, and we can check it compared to the java version. | 11:39.11 |
| | That way you'll be giving me a single key, not the key generation mechanism itself, so you won't be sharing anything important. | 11:39.35 |
| | Does that sound acceptable ? | 11:39.39 |
| naveen_ | Robin..I got this to work...like you said I was writing some extra bytes.... | 11:50.37 |
| Robin_Watts | oh, fab. | 11:50.53 |
| naveen_ | So now I see read_file function...Can you explain how should I pass the data to it.. | 11:51.51 |
| Robin_Watts | Well, you're presumably implementing a new read_file, function, read_encrypted_file or something, right? | 11:53.17 |
| naveen_ | right .. | 11:53.31 |
| | how much data will it expect each time ? | 11:54.18 |
| Robin_Watts | No, you've got this wrong. | 11:54.35 |
| | Juet let me pull up the code. | 11:54.51 |
| | read_file will be called with a buffer, and a length. | 11:55.33 |
| | It's your job to read the next len bytes from the file and put that into the buffer. | 11:55.58 |
| | If you read less than n bytes (because you hit the end of the file) then you should return the number of bytes you do read. | 11:56.29 |
| | The important thing to realise is that you aren't just walking through the file "in order" - seek_file may be called to change the position within the file, and the next read_file should then read from that position. | 11:58.01 |
| | So, on a given read, a naive implementation would grab the appropriate 64K from the file, decrypt it, and copy out the required bytes. | 12:00.04 |
| naveen_ | hmm...as my file will be encrypted.. do i need to get the file pointers current position...based on the postion get the block and decrypt the data and send it in buffer...is that right? | 12:00.07 |
| Robin_Watts | You have to be careful to allow for the idea that a fetch might straddle 2 blocks. | 12:00.48 |
| | (or more, potentially) | 12:00.56 |
| naveen_ | but I'll be able to get the file pointer position..right? | 12:01.22 |
| Robin_Watts | You can put anything into stm->state that you want. | 12:01.45 |
| | I suspect you'll want that to be a structure that contains things such as: | 12:02.13 |
| naveen_ | but how would I know from which position of the file to read from.. | 12:02.19 |
| Robin_Watts | 1) The position that was last seeked to. | 12:02.23 |
| | (or rather the 'file position in the decrypted file') | 12:02.42 |
| | 2) some buffers to use. | 12:02.51 |
| miha | hmmm trying mupdf on android... got libmupdf cannot parse token in array for some pdf (might be incomplete, but still it shouldnt just hang?!) | 12:03.00 |
| Robin_Watts | 3) the decryption key | 12:03.01 |
| sebras | miha: do you have that file available? | 12:03.45 |
| Robin_Watts | naveen_: Given that you'll be reading data from the *real* file in 64K chunks, the *real* fileposition will be different from the fileposition as far as mupdf is concerned. Does that make sense ? | 12:03.51 |
| | miha: We'll look into it, but as sebras says, we'll need a file. | 12:04.17 |
| miha | sebras: will see, might be i tried to open before download finished.. but still some dialog would be nice instead of just hanging infinetly | 12:04.39 |
| Robin_Watts | miha: Does the same file cause hangs on windows? | 12:04.49 |
| naveen_ | hmm...so I don't need to bother about fz_stream...I need to maintain my own fileHandler here...is that right? | 12:05.12 |
| Robin_Watts | miha: The android app can't even try to open a file before the download finishes, AIUI. | 12:05.17 |
| | naveen_: fz_stream is the abstract interface that mupdf calls to read data. | 12:05.43 |
| | You need to provide an fz_stream otherwise mupdf won't be able to work on your data. | 12:06.03 |
| | But we have lots of different fz_stream implementations; one works from memory, one works from a file etc. | 12:06.28 |
| | All you are doing is copying the fz_stream file based implementation and modifying it so that it will work from an encrypted file. | 12:06.59 |
| | On the outside it will look like a normal fz_stream. but on the inside it will work differently. | 12:07.21 |
| sebras | miha: we'd be grateful if you could attach the file over at bugs.ghostscript.com and we'll take a look at it. I'm a bit surprised that mupdf hangs completely though. | 12:07.24 |
| Robin_Watts | Do you see what I am trying to say ? | 12:07.28 |
| naveen_ | yes..I get that Robin...Will work on that and will update you on the progress.. | 12:08.05 |
| Robin_Watts | naveen_: Cool. Let me know how you get on, and if I can help. | 12:08.22 |
| naveen_ | sure..Thanks... | 12:08.35 |
| Robin_Watts | naveen_: It's worth saying that mupdf seeks around a LOT while reading from the file. | 12:08.40 |
| | We may only read a few bytes at a time before seeking off somewhere else to read from there. | 12:09.00 |
| | so it's probably worth making sure that the code copes efficiently with seeking. | 12:09.21 |
| naveen_ | ok..I'll try to do it efficiently... | 12:09.55 |
| Robin_Watts | (i.e. maybe only decrypt part of the 64K at a time? At least make sure that if we seek within the 64K block we don't refetch/redecode it.) | 12:09.58 |
| | miha: If you can open a bug and attach a file, then I'll look into it after lunch. | 12:11.03 |
| naveen_ | ok..got that.. | 12:11.20 |
| miha | Robin_Watts: i still think i open it too soon :) | 12:34.48 |
| sebras | miha: ok, if you can not reproduce it then that's good. maybe we should take a look at the parsing code anyway to make sure that there are not infinte loops lurking there still... | 12:43.51 |
| miha | sebras: either it cant parse or it cant lock file. in both cases it should display dialog | 12:46.47 |
| | it doesnt always crash, sometimes it just shows waiting :) | 12:47.16 |
| | now i make sure it's .pdf.tmp while downloading so i dont open too son :$ | 12:48.07 |
| | otherwise it's pretty awesome :) | 12:48.38 |
| | good work | 12:48.42 |
| | sebras: if you want to reproduce, just truncate .pdf .. it happens often enough :) | 12:52.23 |
| Robin_Watts | I suspect it's probably the repair code hunting for a trailer. | 12:56.17 |
| | i.e. it's not hung, it's just taking a long time. Or something like that. | 12:56.29 |
| sebras | Robin_Watts: maybe we should have the progress-argument indicate how far in the file it has searched? | 12:59.47 |
| | Robin_Watts: maybe we already do. I haven't checked. | 13:00.15 |
| Robin_Watts | sebras: Urm... searching is based on the text extraction device. | 13:00.20 |
| | We feed the text extraction device from the list device. | 13:00.27 |
| | The list device is the thing that updates the cookie. | 13:00.47 |
| | Oh, we might be feeding it direct from the interpreter. Let me see if that does the cookie. | 13:01.06 |
| sebras | I think we do. | 13:01.16 |
| | and if so we may be able to have the repair code do something similar. | 13:01.38 |
| Robin_Watts | I'd like to reproduce the problem before hunting for solutions... | 13:03.01 |
| sebras | Robin_Watts: naturally. | 13:03.12 |
| | I'm surprised that he mentions crashes. | 13:03.33 |
| | doesn't the android-app print something nicely upon exceptions? | 13:04.04 |
| Robin_Watts | pass. | 13:05.02 |
| kens | often people think crash = error message | 13:08.03 |
| Robin_Watts | I don't think the android app does anything nice when it crashes - I think it just exits. paulgardiner ? | 13:09.47 |
| | (of course, it never crashes, so... :) ) | 13:09.58 |
| sebras | Robin_Watts: I was thinking about calls to fz_throw. | 13:10.27 |
| Robin_Watts | If we fz_throw without an fz_try in place, then it just prints to stdout and exits, I belive. | 13:11.01 |
| | believe. | 13:11.07 |
| sebras | Robin_Watts: right. maybe that should be printed to a dialog as in the windows app. I think stdout is only sent to logcat or so. | 13:14.11 |
| Robin_Watts | It does only go to logcat. | 13:14.30 |
| | and I'd rather we just made it so that it could never happen. | 13:14.45 |
| | (fz_throws always being within an fz_catch should be something we can guarantee) | 13:15.09 |
| sebras | fz_document functions seem like a good candidate. I'm not sure if tor8 has any opinion on it though. | 13:16.38 |
| Robin_Watts | The fz_document functions are defined as throwing exceptions I think (I'd need to check with the bloke that wrote the docs :) ) | 13:17.15 |
| sebras | Robin_Watts: he might know, yes. ;) but the interface may be up for change. | 13:21.43 |
| Robin_Watts | Well, I'm damned if I understand bug 692847. OR specifically zenikos fix. | 13:24.47 |
| sebras | Robin_Watts: ok, so there are patterns with huge tiling bounding boxes (larger than the desitination areas), so instead of drawing and then scaling down he draws the pattern without tiling at all...? | 13:30.33 |
| | Robin_Watts: I might be able to see how that could be faster, but I'm not sure if the drawn region would be correct. in fact I would easily be convinced that it would not be. | 13:31.21 |
| Robin_Watts | Surely the right thing to do then is to reduce the tiling bounding box to match the destination area? | 13:32.03 |
| sebras | Robin_Watts: that seems like the best solution to me. unless there is some fiddling with subpixelcoordinates at the borders or so. | 13:33.27 |
| | Robin_Watts: I can see why he chose 50 though. | 13:36.28 |
| | Robin_Watts: (5000x5000) / (500x500) = 100, which means the pattern is drawn scaled down 100 times. | 13:37.53 |
| tor8 | sebras, Robin_Watts: display list execution also updates a cookie | 14:03.37 |
| Robin_Watts | tor8: yeah. | 14:03.47 |
| tor8 | Robin_Watts: I think we can get around the case where the tile bbox is much bigger than the drawn content (that's what I read is happening here) in a more roundabout way using the bbox device to pre-compute the real bounds | 14:04.31 |
| Robin_Watts | tor8: I have a fix for this particular file that's much simpler | 14:55.47 |
| | In fz_draw_begin_tile, if the calculated view bbox (i.e. pat->bbox * ctm) entirely encloses the region we are writing to, then just chop it down to that size. | 14:58.35 |
| | The thing is, that case is a sub case of "is only 1 tile required to cover the output", so I think the above test must be wrong somehow. | 15:00.04 |
| | s/above test/test in the function above/ | 15:00.32 |
| | paulgardiner: Your forms report sounds great -real progress! | 15:04.52 |
| | I reckon we should make a forms branch, and publish that to casper. We can periodically pull master into it to keep it up to date. | 15:05.42 |
| | marcosw: I updated pngs2html to pull stuff into the webpage. | 15:07.29 |
| marcosw | it now looks at the .out files? | 15:08.03 |
| Robin_Watts | It does. | 15:08.07 |
| | Also, a pet peeve of mine; if you update my perl (which I accept is required at times) please can you keep the indentation correct? | 15:08.52 |
| | You added an if (blah) { .... } around a block to work around an error case, but didn't indent the block inside. | 15:09.32 |
| | I understand the reasoning (not wanting to cause lots of diffs), but I'd rather take the diffs than have me get all confused by not following my code afterwards :) | 15:10.34 |
| | (I'm sure I do things that you find similarly annoying when I edit the cluster code, and I apologise for them - if you tell me what, I'll try and avoid them in future). | 15:16.18 |
| ray_laptop | diff -w ignores whitespace | 15:26.56 |
| | in vimdiff use :set diffopt=iwhite | 15:29.12 |
| Robin_Watts | ray_laptop: Yes. I'd rather have to use -w than get spend time wondering why my file no longer works because I've inadvertantly deleted a } that didn't have the associated whitespace before it. | 15:29.29 |
| | s/get/ | 15:29.35 |
| | marcosw has a style of adding new if (...) { ... } stuff to perl files without indenting the contents. (The cluster code has many such cases in). His brain is clearly able to cope with it. Mine is not that flexible. :) | 15:31.06 |
| marcosw | Robin_Watts: this is why I don't like python :-) | 15:31.35 |
| | when it becomes too bad I run ~cluster/bin/mytidy, which cleans up the indenting. | 15:32.30 |
| Robin_Watts | Can we put that on a cron job? :) | 15:32.41 |
| marcosw | ^~cluster^~regression | 15:32.42 |
| | causes lot of whitespace differences, so makes git blame less useful, otoh, since the clutter code changes are all committed by user regression blame isn't very useful | 15:33.41 |
| | I'll go ahead and run tidy on the cluster code now (after checking the current code into git). | 15:34.06 |
| Robin_Watts | marcosw: My ailing brain thanks you :) | 15:34.24 |
| ray_laptop | Robin_Watts: on another topic -- when I do a command line "git commit -a" it pops up a 'vim' edit window, which is what I want, but the syntax highlighting is really funky -- it wants to put my message in yellow on a white background. | 15:34.40 |
| | Robin_Watts: is there a way to for :set syntax=off for the git message edit session ? | 15:35.15 |
| Robin_Watts | feels like this is like complaining that you might get splinters from the guillotine, but... | 15:36.10 |
| | ray_laptop: Is the syntax editing any different than you'd get by invoking vim manually ? | 15:36.53 |
| | Presumably there must be a .vimrc or something? | 15:38.20 |
| ray_laptop | hmm... nope. I tried "vim ../.git/COMMIT_EDITMSG" and it looks the same. But with 'givm' it looks OK. So maybe it is using a different vimrc | 15:38.33 |
| kens | Well, let's see how long this lasts ;-) | 15:38.51 |
| ray_laptop | kens: how long what lasts ? | 15:39.11 |
| Robin_Watts | ray_laptop: So vim ../.git/COMMIT_EDITMSG has the horrible coloring? | 15:39.18 |
| kens | My internet connection.... | 15:39.20 |
| | chrisl from teh status page : | 15:40.21 |
| | "At approximately 4.00pm BT Wholesale suffered an unexpected network outage that disconnected a significant number of our broadband customers." | 15:40.21 |
| Robin_Watts | and what's givm? | 15:40.27 |
| ray_laptop | Robin_Watts: yep. Is there a way to tell git to use gvim instead of vim (as was the case with SVN_EDITOR= and svn) ? | 15:40.53 |
| Robin_Watts | EDITOR? | 15:41.06 |
| | I have: export EDITOR=emacs in my .bashrc | 15:41.37 |
| ray_laptop | Robin_Watts: gvim is a windows port of vim -- runs in a separate process, supports cut and paste to the clipboard, that sort of stuiff | 15:41.44 |
| Robin_Watts | Ah. | 15:41.49 |
| | Well export EDITOR=gvim | 15:42.00 |
| ray_laptop | Robin_Watts: thanks. That works !! :-) | 15:42.25 |
| chrisl | kens: well, at least you know what happened...... | 15:42.27 |
| Robin_Watts | ray_laptop: Fab. | 15:42.34 |
| henrys | in ~/git/.gitconfig I have [core] editor = /Applications/Emacs.app/Contents/MacOS/Emacs | 15:42.35 |
| | | 15:42.35 |
| | sorry ~/.gitconfig | 15:43.07 |
| Robin_Watts | export EDITOR=emacs works on macos too. | 15:43.09 |
| ray_laptop | henrys: thanks. I'll try that, but in case there are other msys apps that use EDITOR, I generally want gvim anyway | 15:43.46 |
| Robin_Watts | The unix (and hence msys) convention is to use EDITOR (or VISUAL if that's set) | 15:44.21 |
| | So for belt and braces, set both. | 15:44.32 |
| marcosw | Robin_Watts: perltidy.pl found errors in bmps2html.pl: | 15:45.44 |
| | Scalar found where operator expected at bmps2html.pl line 87, near "$javascript" | 15:45.51 |
| | (Missing semicolon on previous line?) | 15:45.51 |
| | Scalar found where operator expected at bmps2html.pl line 88, near "$javascript" | 15:45.52 |
| | (Missing semicolon on previous line?) | 15:45.52 |
| | Scalar found where operator expected at bmps2html.pl line 89, near "$javascript" | 15:45.52 |
| | (Missing semicolon on previous line?) | 15:45.52 |
| | Scalar found where operator expected at bmps2html.pl line 90, near "$javascript" | 15:45.53 |
| | (Missing semicolon on previous line?) | 15:45.53 |
| | syntax error at bmps2html.pl line 87, near "$javascript " | 15:45.53 |
| Robin_Watts | Fixed. THanks. | 15:46.36 |
| marcosw | perltidy run and the results committed and pushed | 15:49.33 |
| henrys | As a linux user I've always used EDITOR, I tripped over something on macos and I can't remember what it was - anyway, right EDITOR is best. | 15:50.09 |
| Robin_Watts | henrys: I've ordered a USB 3G mobile broadband dongle thing, so you can borrow that while you're in the country. | 15:51.51 |
| | So as long as you're not so far out in the sticks that you have no mobile coverage you should be OK. | 15:52.15 |
| henrys | well now I've found out we are going to have wifi at the pub/inn - I'll just be dark on the sheep farm - probably best ;-) | 15:53.07 |
| marcosw | anyone have any idea what might have changed on casper? I'm getting a new warning from bugs.ghostscript.com: The local XML file '/var/www/bugs.ghostscript.com/data/bugzilla-update.xml' cannot be created. (you may not see this message, it's generated by the code that checks if there is an updated bugzilla available, which only occurs if you are logged in and listed as a bugzilla admin) | 15:53.41 |
| henrys | Robin_Watts:so you use that a lot? | 15:54.21 |
| | a cellular network for internet that is? | 15:54.46 |
| Robin_Watts | I don't as a rule. I have done in the past when my broadband has died. | 15:55.08 |
| | And when I'm at heathrow, my cellphone will do the "be a wifi hotspot" thing. | 15:55.26 |
| chrisl | marcosw: I installed a couple of applications a couple of days ago, but that wouldn't have caused that problem.... | 15:56.06 |
| Robin_Watts | My next door neighbour used a 3G dongle for ages before getting broadband put in. | 15:56.09 |
| henrys | oh you're like a homeless person in the united states. | 15:56.13 |
| Robin_Watts | will code for food ? | 15:57.25 |
| henrys | well I guess if you have unlimited data it's okay but kind of pokey no? | 15:57.30 |
| Robin_Watts | I have unlimited data on my monthly plan (limited to 500Meg or something on the dongle, before it throttles) | 15:58.32 |
| | no, mobile broadband speeds here are quite decent, I think. | 15:58.57 |
| marcosw | henrys: I tether my iPhone 4s to my laptop occasionally and it's faster than you'd expect. The biggest problem is that it only supports http (and https), so no ssh or irc (I use a web to irc gateway, so it's only ssh that I can't use). | 15:59.39 |
| Robin_Watts | Well, 2Mbps or so seems typical, which is about average for ADSL in the sticks (though I get 8 now. Weee!) | 15:59.54 |
| henrys | wow that is faster than I thought. | 16:00.47 |
| Robin_Watts | marcosw: It's possible that since you updated casper to the new ubuntu, web stuff has run with less permissions. | 16:02.53 |
| marcosw | Robin_Watts: I think I would have noticed this warning before now. | 16:03.10 |
| Robin_Watts | I think there was a problem with the delta stuff to do with that. (Though it was masked by larger problems for a while) | 16:03.20 |
| Robin_Watts | points excitedly at the lovely empty mupdf deltas :) | 16:04.00 |
| marcosw | I checked the casper backups and bugzilla wrote to this directory on the 17th. So something changed in the last two days. | 16:04.00 |
| | Does anyone object if I reboot casper? mvrhel just started a clusterpush, but I'll restart that after it's back up. | 16:04.46 |
| kens | marcosw I put a copy of ghostpdl in my directory, don't see how that could have affected it | 16:04.58 |
| marcosw | I don't think it's anyone did, I think bugzilla has become confused. This happened before, though the symptoms weren't the same. | 16:05.42 |
| henrys | You bastards! | 16:09.42 |
| | south park humor ... | 16:10.22 |
| marcosw | you guys suck, I'm going home! | 16:10.25 |
| | unfortunately bugzilla still display the warning!? | 16:11.03 |
| kens | permissions problem ? | 16:11.22 |
| | Time to be off. On the plus side, my fix for patterns in pdfwrite is OK, so I've committed it to my branch. | 16:12.39 |
| | Goodnight all | 16:12.44 |
| henrys | alexcher:yikes 2 week customer bug without a comment ... 692969 | 16:32.48 |
| alexcher | henrys: The file has one incorrect object. We try to rebuild xref but cannot do this for PDF 1.5. | 16:44.28 |
| | henrys: The file runs to completion if we drop xref verification. | 16:45.05 |
| | henrys: I plan to do it for the files with object streams. | 16:45.39 |
| mvrhel | marcosw: I am getting close to having this sep planar stuff done. some of the diffs I have in bmpcmp are actually progression | 16:45.47 |
| | s | 16:45.49 |
| henrys | but we agree a customer bug shouldn't sit for 2 weeks with nothing - marcos reports the numbers back to the customer they check it and see absolutely nothing, it's not ver good, right? | 16:46.17 |
| marcosw | mvrhel: great, I'm not going to tell Gemma, no point getting her hopes up. | 16:46.28 |
| mvrhel | right | 16:46.37 |
| marcosw | henrys: that is what the bug aging report is supposed to be used for, it lists the number of days since the bug owner last commented on the bug. | 16:47.03 |
| ray_laptop | alexcher: we should be able to rebuild the xref if we decompress the object stream, right ? | 16:47.54 |
| henrys | marcosw:yes and I missed it. | 16:48.01 |
| alexcher | ray_laptop: yes, we should but this is not yet implemented. | 16:48.46 |
| ray_laptop | mvrhel: I'm really looking forward to seeing what the performance difference (hopefully improvement) will be. | 16:49.14 |
| Robin_Watts | mvrhel: The information from the bmpcmp email should now be in the bmpcmp webpages too - please let me know if you see anything odd with it. | 16:49.42 |
| ray_laptop | I should run some files now as baselines, so I can compare them after your commit | 16:49.49 |
| mvrhel | ray_laptop: with transparency present we should see some improvement. I have not done any timings yet | 16:49.51 |
| henrys | alexcher:please add analysis to customer bugs promptly (days), I understand if it takes a while to fix but most problems can be analyzed quickly. | 16:50.33 |
| alexcher | henrys: yes, I'll try to post new findings as soon as possible. | 16:51.53 |
| henrys | thank you | 16:52.08 |
| mvrhel | wow the mupdf cluster run is so fast | 16:52.46 |
| Robin_Watts | mvrhel: Looking at your latest bmpcmp (I'm nosey) there look to be lots of files where the candidate and reference bitmaps look identical, but the diff shows lots of differences. | 16:53.12 |
| | Those are presumably differences in spot planes. But I would have hoped that that should show up in the candidate/reference bitmaps too, as I now map the spots down. | 16:53.48 |
| mvrhel | Robin_Watts: which one are you looking at? | 16:54.12 |
| Robin_Watts | Look at the top of page 2 for example | 16:54.18 |
| | Number 12. | 16:54.31 |
| henrys | tor8:I assume you know about the new meeting time with paulgardiner, we changed this while you weren't here and hope it is okay with you. | 16:54.32 |
| mvrhel | well those are halftoned | 16:55.23 |
| tor8 | what new meeting time? | 16:55.33 |
| | what's the new meeting time? | 16:55.39 |
| mvrhel | the levels are slightly different so the screen level is different Robin_Watts | 16:55.48 |
| | making for the -t 5 not to really help | 16:55.56 |
| | in filtering them out | 16:56.12 |
| Robin_Watts | Right, but I'd have expected to see the difference in the blink test. | 16:56.27 |
| mvrhel | blink test? | 16:56.43 |
| henrys | tor8:that leads me to guess you haven't read paulgardiner's status report - it came out this morning to tech - but ... Friday 9:00 PST | 16:56.45 |
| Robin_Watts | mvrhel: Roll the pointer into and out of the left hand image, and the left hand and middle images swap. | 16:57.06 |
| mvrhel | oh | 16:57.24 |
| | let me try that | 16:57.32 |
| Robin_Watts | Let me try and find another example. | 16:57.33 |
| marcosw | bugzilla has recovered from not being able to write to the directory. The strange thing is that it didn't work when I first tried it after reboot but now it's okay. | 16:57.42 |
| Robin_Watts | On the same page, number 20. | 16:57.54 |
| henrys | so does BST and GMT not and they are the same geographical area, is that how it works? | 16:58.13 |
| Robin_Watts | marcosw: Maybe it tries on a timer, and you were seeing a 'cached' message ? | 16:58.14 |
| henrys | does BST have Daylight savings time and GMT not ... | 16:58.38 |
| Robin_Watts | GMT is fixed. BST changes with daylight. Same geographical areas. | 16:58.45 |
| marcosw | Robin_Watts: probably, but still odd. | 16:58.48 |
| Robin_Watts | BST = British Summer Time. GMT = Greenwich Mean Time. | 16:59.08 |
| | BST is the fault of those pesky scots :) | 16:59.26 |
| henrys | oh my S for summer and not Standard. very confusing. | 16:59.52 |
| Robin_Watts | mvrhel: Do you see the blink effect with number 20 ? | 17:00.30 |
| mvrhel | yes | 17:01.29 |
| | I will take a look at that one real quick | 17:03.12 |
| | rather interesting | 17:03.17 |
| Robin_Watts | I'm not suggesting this is a problem with your code. | 17:03.28 |
| mvrhel | I am curious what the diff is | 17:03.52 |
| | the top of page 2 (number 29) is interesting | 17:04.14 |
| | that is actually a progression | 17:04.19 |
| Robin_Watts | The thing that concerns me, is that if there is a change in the spots, we should see a change in the candidate and reference bitmaps that bmpcmp is producing. | 17:05.44 |
| | and we don't. | 17:05.46 |
| mvrhel | looking at 34, I think the new code is correct | 17:05.47 |
| | Robin_Watts: I dont think those files have spots | 17:06.04 |
| | let me show you one that does have spots | 17:06.21 |
| | let the current bmpcmp finish | 17:06.37 |
| Robin_Watts | 34 is down to clist instability. | 17:06.39 |
| mvrhel | hehe. Robin_Watts | 17:09.22 |
| | look at the new ones now | 17:09.27 |
| | first page | 17:09.29 |
| | number 20 | 17:09.31 |
| | the source files are wrong | 17:10.17 |
| | 23 is the same way | 17:10.44 |
| vtorri | and 42 ? | 17:10.45 |
| Robin_Watts | mvrhel: Shift reload :) | 17:11.04 |
| | Your browsers cache is confused. | 17:11.13 |
| mvrhel | ah ok | 17:11.18 |
| Robin_Watts | (I just had the same experience :) ) | 17:11.30 |
| mvrhel | ok fixed | 17:11.44 |
| Robin_Watts | You're comparing planar cmyk to non planar pamcmyk here? | 17:12.35 |
| mvrhel | planar psdcmyk to non planar psdcmyk | 17:12.59 |
| Robin_Watts | When you use the planar device, the clist buffer sizes work out slightly differently (and you get +/- 1 line in the bandheight sometimes) | 17:13.06 |
| mvrhel | why does it put all the no diff detected in here now | 17:13.12 |
| | ah ok | 17:13.23 |
| Robin_Watts | This can cause different things to go into different bands, hence 1 pixel rounding differences. | 17:13.37 |
| | mvrhel: Because that was requested :) | 17:13.48 |
| mvrhel | by whom | 17:13.55 |
| Robin_Watts | marcosw. The same code that does that does the 'I couldn't compare the two files because the number of spots changed" stuff. | 17:14.57 |
| | Number 41, top of page 2 has some dropouts in the text that's really images. | 17:16.26 |
| | Gradients look noticably smoother though. | 17:18.03 |
| | (Number 58, page 2 for example) | 17:18.25 |
| | Let me remove the ones that just say "bmpcmp: No differences detected" | 17:19.51 |
| henrys | mvrhel:2000 lines wow... | 17:20.57 |
| mvrhel | Robin_Watts: that would be good | 17:22.39 |
| | henrys: that was a guesstimate by me looking at what git was showing was added | 17:23.41 |
| | Robin_Watts: so number 740 on page 4 (starting from page 0) has diff in spots | 17:24.35 |
| | the compare is wacky but it drew my attention | 17:24.56 |
| Robin_Watts | ok. so we do see a difference in the bmpcmp results. | 17:25.46 |
| mvrhel | yes | 17:25.55 |
| Robin_Watts | Are the bmpcmp images a true reflection of the output ? | 17:26.14 |
| mvrhel | 862 on page 6 is troubling | 17:26.20 |
| | I am not seeing this come out this way locally | 17:26.29 |
| | I will take another look at it | 17:26.38 |
| ray_laptop | mvrhel: can you look at the comment I just added to http://bugs.ghostscript.com/show_bug.cgi?id=689805 (you aren't on the CC list and I don't know if you get the gs-bugs email) | 17:26.45 |
| Robin_Watts | bmpcmp: We only support v1 psd files! | 17:26.50 |
| | That's an error message we shouldn't be getting. | 17:27.05 |
| ray_laptop | bbiab | 17:27.15 |
| Robin_Watts | It suggests that bmpcmp is reading the file wrong. | 17:27.19 |
| mvrhel | oh yes | 17:27.39 |
| Robin_Watts | mvrhel: Could you generate me the psdcmyk output with your new code for that please? | 17:27.47 |
| | (the cluster will have lost it by now) | 17:27.54 |
| mvrhel | Robin_Watts: which number is this? | 17:28.05 |
| Robin_Watts | 740 | 17:28.10 |
| | tests_private/comparefiles/Bug688584.ps.psdcmyk.300.1 | 17:28.18 |
| | 741 is similarly broken. | 17:28.45 |
| mvrhel | oh yes | 17:28.50 |
| | ok | 17:28.51 |
| Robin_Watts | (Again, to be clear, this is bmpcmp broken, not your code) | 17:29.16 |
| mvrhel | well maybe not | 17:29.22 |
| | let me make sure the file is ok | 17:29.32 |
| | we do max out on our allowed spot colors in this file | 17:30.50 |
| | ok there *is* an issue with the output when I add the %d to the file name to get multiple pages | 17:31.27 |
| | hehe and the single page one is wacked | 17:32.25 |
| | sigh | 17:32.31 |
| | very strange | 17:32.44 |
| | so Robin_Watts: this is my problem | 17:32.53 |
| Robin_Watts | oh, fair enough :) | 17:33.44 |
| mvrhel | let me look at rays comment then I am going to dig into this | 17:33.47 |
| Robin_Watts | IF you find that bmpcmp is giving you any such error messages in future, please let me know. | 17:34.13 |
| mvrhel | ok will do | 17:34.46 |
| | this thing is majorly confused since it only has 1 spot color | 17:38.53 |
| | I bet there is some screwy PS stuff going on here | 17:39.08 |
| ray_laptop | oops. I wanted to see the bmpcmp output from my last run of gitpush.sh gs -- but I did gitpush.sh gs bmpcmp and it put two jobs in | 17:54.49 |
| | if I kill the 'gs' run, will it confuse the bmpcmp behind it ? | 17:55.20 |
| | oh, well. it doesn't take that long to run just 'gs' | 17:55.58 |
| Robin_Watts | ray_laptop: Yes, almost certainly. | 17:56.07 |
| ray_laptop | Robin_Watts: thanks -- that's what I figured | 17:57.07 |
| Robin_Watts | tor8: So, familiar refrain: What do we need to do before releasing MuPDF 1.0 ? | 18:01.43 |
| mvrhel | bbiaw off to lunch. | 18:06.32 |
| ray_laptop | hmm... must be some indeterminisms -- my initial 'gs' run showed 7 diffs -- this time I only got 4 :-( | 18:24.26 |
| | and bmpcmp shows "no differences detected" on all 4 :-( | 18:26.06 |
| tor8 | Robin_Watts: I don't know. | 19:01.12 |
| Robin_Watts | We should figure that out. | 19:01.30 |
| | Our tasks from the last meeting were "Get MuPDF 1.0 out", so it'd be good to go to the next meeting with that done :) | 19:01.53 |
| tor8 | henrys: huh? friday night? that's ... not good ... not for a regular thing. | 19:02.03 |
| | was there some problem with tuesdays after the regular meeting? | 19:02.28 |
| Robin_Watts | tor8: Tuesdays aren't great for Paul. | 19:02.38 |
| tor8 | Robin_Watts: agreed :) | 19:02.41 |
| Robin_Watts | But if fridays are particularly painful for you, he said he'd cope with tuesdays. | 19:03.06 |
| tor8 | friday night is regular gaming night with friends... | 19:03.29 |
| | what other days are good for paul? | 19:03.42 |
| Robin_Watts | I know he has a regular engagement tuesday evenings (and maybe thursdays too) | 19:04.04 |
| | We could do *before* the regular meeting on tuesdays maybe? | 19:04.21 |
| | I'd not be averse to kicking 1.0 out the door as is now. | 19:05.17 |
| tor8 | fridays so that we finish by 5 or at latest 6pm CE(S)T will work, or earlier on tuesdays | 19:05.19 |
| | Robin_Watts: right. did we fix the main build issues that were reported? | 19:05.33 |
| Robin_Watts | tor8: Which were? | 19:05.46 |
| | "Didn't build on Android" turned out to be "The reporter is a muppet" | 19:06.09 |
| tor8 | Robin_Watts: something about a broken vs2005 build? | 19:06.11 |
| Robin_Watts | Ah, right, yes. I need to talk to you about that. | 19:06.29 |
| tor8 | oh, right. the usual android bug reports :) at least one email a week from someone who hasn't installed the thirdparty package. | 19:06.37 |
| | Robin_Watts: we could strip out the 256x256 icon variant if that makes it easier | 19:06.56 |
| Robin_Watts | You added a new .ico file that contains a windows vista style image (256x256 png). | 19:06.57 |
| | That kills VS2005. | 19:07.06 |
| tor8 | ototh, 2005 is getting ancient :) | 19:07.12 |
| Robin_Watts | I'd personally rather lose the 256x256 image than lose VS2005 compatibilty. | 19:07.24 |
| tor8 | then let's drop the 256x256 image | 19:07.34 |
| Robin_Watts | Can you do that? I don't have an .ico editor immediately to hand. | 19:07.55 |
| tor8 | I use gimp for ico editing :) | 19:08.08 |
| Robin_Watts | It wasn't so much thirdparty being missing as "I've cocked up EVERYTHING about my android install", I think. | 19:08.36 |
| tor8 | yeah, that particular one did seem a bit like "my environment is FUBAR and I don't know it" | 19:09.05 |
| Robin_Watts | oh, right, I was going to look at bug 692924. | 19:09.49 |
| | I was going to change the logic in the loop there to treat anything that didn't look like a page range specifier as a filename. | 19:10.20 |
| | When you disabled the link following button in mupdf did you mean to completely disable link following? | 19:11.23 |
| tor8 | Robin_Watts: yes, to match what iOS does. unintentionally following invisible links by tapping on the page is awkward; I want a better way to interact with the links. | 19:12.32 |
| Robin_Watts | ok. Matching ios seems fair enough. | 19:12.54 |
| tor8 | we can experiment with the link UI after 1.0 was my intention | 19:13.01 |
| Robin_Watts | sure. | 19:13.07 |
| tor8 | so revert that particular commit right after 1.0 :) | 19:13.12 |
| Robin_Watts | so I'd like to sort 692924, but other than that I think I'm happy to release. | 19:13.29 |
| tor8 | I have pushed an icon fix; can you double check that it works with VS2005? | 19:13.30 |
| Robin_Watts | Will do. | 19:13.36 |
| tor8 | right. seems fair to me. I rebased and pushed the fixes I had sitting on the 'unstable' branch. | 19:14.07 |
| | so I think we're in decent shape to tag 1.0 | 19:14.24 |
| Robin_Watts | I still get an error with mupdf.ico | 19:14.55 |
| | where did you push to? | 19:15.10 |
| | hmm. I did pull in your commit... | 19:15.26 |
| | so why isn't this working? | 19:15.52 |
| | Is that really a .ico ? | 19:17.46 |
| | I'm a tool. Ignore me. | 19:28.30 |
| | Yes, that builds fine now. | 19:30.20 |
| | tor8: Would you object to me removing the '.pdf' check in fz_open_document and moving the pdf case to the end? | 19:41.59 |
| | i.e. any file that doesn't match .cbz and .xps would be assumed to be a pdf ? | 19:42.17 |
| | I've pushed that fix as I think you suggested exactly that the other day. Revert it if you dare^H^H^Hisagree. | 19:48.16 |
| tor8 | Robin_Watts: no objection. | 19:55.38 |
| Robin_Watts | cool. | 19:55.46 |
| tor8 | Robin_Watts: heading to bed now, still jet lagged. ttytm. | 19:56.42 |
| Robin_Watts | Night. | 19:56.53 |
| | Forward 1 day (to 2012/04/20)>>> | |
IRC Logs