| | <<<Back 1 day (to 2015/03/23) | 20150324 |
| Robin_Watts | tor8: For the logs: There is a new version on robin/merge_csi with an alternative approach to the resource handling that I prefer. | 01:18.59 |
| | Identical results. | 01:19.11 |
| KunMyt | Hi everybody, when i read pdf by buffer, the topbar function only copy text, i using MuPDF for android. help me plz! | 08:34.42 |
| kens | You're probably too early for anyone to help with MuPDF programming, however your query is in the logs and someone will respond when they are online, probably in a couple of hours. | 08:35.41 |
| KunMyt | @kens tks, | 08:36.26 |
| tor8 | Robin_Watts: yeah, that's the other option I thought about using but resisted (since it meant passing resource dictionaries to some of the ops) | 09:47.30 |
| | it's probably the best solution in the long run though | 09:47.36 |
| Robin_Watts | tor8: Yeah, you mentioned it the other day. It's the way that feels right to me. | 10:07.11 |
| tor8 | Robin_Watts: Yeah. Let's go with that. | 10:07.31 |
| Robin_Watts | I need to test for leakage before we commit it though. | 10:08.01 |
| tor8 | some of the refcounting looked strange | 10:08.17 |
| | you don't keep when you first store it in the structs, but when you push/pop the gstates it gets kept and dropped | 10:08.36 |
| | the 64-bit changes, you changed fz_buffer and the mallocs to use size_t | 10:09.10 |
| Robin_Watts | I did. | 10:09.23 |
| tor8 | but I don't see any change for the overflow check | 10:09.44 |
| | the UINT_MAX should be SIZE_MAX | 10:10.21 |
| Robin_Watts | ok, ta | 10:10.51 |
| tor8 | in the printf, you use "%Zd" and "%zu" ... wouldn't it be more foolproof if it were just %Z and %z? | 10:13.02 |
| Robin_Watts | tor8: That's what I had originally. | 10:13.20 |
| tor8 | ah, but you ran into the __printflike warning system? | 10:13.35 |
| Robin_Watts | If I do that, then all the format strings warn on unix. | 10:13.39 |
| | yeah. | 10:13.41 |
| tor8 | bah. | 10:13.47 |
| Robin_Watts | This way, we have an (almost) C99 compliant printf. | 10:14.02 |
| tor8 | %lld %lu? | 10:14.13 |
| Robin_Watts | %lld and %llu | 10:14.27 |
| tor8 | isn't 'long int' the same as 'size_t' on 64 and 32-bit platforms? | 10:14.30 |
| | lld would be for fz_off_t and other 64-bit known entities | 10:14.44 |
| Robin_Watts | tor8: long int = int on 64bit windows. | 10:14.50 |
| tor8 | and %lu for size_t | 10:14.57 |
| | oh, rubbish :( | 10:15.00 |
| Robin_Watts | fz_off_t can be 64bit on a 32bit machine. | 10:15.21 |
| | That's why we need a new length specifier for it. | 10:15.32 |
| tor8 | yeah, which is why I suggested lld (long long d) | 10:15.34 |
| | but we still have the problem of size_t | 10:15.52 |
| Robin_Watts | but it can also be 32bit. | 10:15.55 |
| | C99 says z for size_t | 10:16.05 |
| | The only 'dodgy' one is Z. | 10:16.17 |
| tor8 | MSVC use %Iu and %Id for size_t | 10:16.26 |
| KunMyt | Hi everybody, when i read pdf by buffer, the topbar function only copy text, i using MuPDF for android. help me plz! | 10:16.33 |
| jogux | in some of the iOS stuff, clang just gives up and suggests you add a explicit widing or narrowing cast to fix various printf issues. | 10:16.36 |
| | KunMyt: I don't understand most of that sentence. which top bar function? what did you expect it to do? and this works if pdf is read from a file? | 10:17.31 |
| tor8 | right, and fz_off_t depends on MUPDF_LARGE_FILE_SUPPORT #define? | 10:17.45 |
| Robin_Watts | tor8: it does. | 10:17.51 |
| tor8 | would it be possible to always use large file support, or will that break everything for everyone? | 10:18.17 |
| KunMyt | jogux: i read by buffer, i lost last stage and more funtion as Underline, Draw, ... | 10:18.40 |
| jogux | KunMyt: you are missing some buttons from the top bar? | 10:19.46 |
| KunMyt | jogux: yes, | 10:19.56 |
| Robin_Watts | I can only imagine they must be disabled for some reason. | 10:20.42 |
| jogux | KunMyt: and if you read the pdf file a file instead the buttons are there? | 10:20.54 |
| tor8 | #define FZ_FMT_OFF "%lld" vs "%ld", but that makes all printf format strings ugly | 10:21.28 |
| | so better as we have it then, I guess | 10:21.36 |
| Robin_Watts | tor8: Indeed. | 10:21.39 |
| tor8 | now that I understand the why it's easier to swallow :) | 10:21.57 |
| KunMyt | jogux: yes, the button appear on topbar | 10:22.01 |
| Robin_Watts | The alternative is to upcast every fz_off_t to an int64_t before printing. | 10:22.07 |
| tor8 | another alternative is to use 64-bit fz_off_t independent of largefile support | 10:22.28 |
| jogux | KunMyt: I'd imagine Robin is probably right then, the code is deliberately disabling them. | 10:22.34 |
| tor8 | but that feels even more awkward | 10:22.42 |
| Robin_Watts | tor8: But that expands all the xref tables. | 10:22.45 |
| tor8 | ouch. yeah, that could get nasty. | 10:23.00 |
| KunMyt | jogux: i'm not change something, i just add buffer for file when getData | 10:23.42 |
| tor8 | Robin_Watts: bah, we have (but don't yet use) %q and %( for string printing. that'll also run afoul of the __printflike stuff once we start using it | 10:24.38 |
| Robin_Watts | tor8: Yes, but it's worth the pain, I think. | 10:24.58 |
| tor8 | but I'll worry about that when it happens | 10:25.02 |
| Robin_Watts | Likewise the ones for rect, point, and matrix. | 10:25.07 |
| tor8 | could do %qs and %(s or something like that | 10:25.29 |
| | ah, yes. those didn't register when I was looking through the list. worth the pain. | 10:25.54 |
| jogux | KunMyt: I can't immediately see anything in the code that does this. PaulGardiner might know when he appears online. It might be worth you sharing a diff of what you have changed in the mupdf code. | 10:27.09 |
| tor8 | jogux: KunMyt: a wild guess here, but could it be because it knows there's no underlying file to save the changes? | 10:28.01 |
| KunMyt | jogux:how i can share for you, post here or use email | 10:28.21 |
| Robin_Watts | KunMyt: Which icons specifically are disappearing ? | 10:28.26 |
| jogux | to8: that was my suspicion, but I can't find the code that does it (though I'm not overly familiar with Android) | 10:28.41 |
| | KunMyt: if you put the diff into pastebin.com then share the url here that would be best. | 10:28.58 |
| KunMyt | Robin_Watts: only show Copy icon, every icon lost | 10:29.09 |
| Robin_Watts | On the top bar, I have: "Links, reflow, search, More" | 10:29.14 |
| | There is no copy icon. | 10:29.19 |
| | Once you hit 'more' you get 'close, print, copy, annotate' | 10:29.49 |
| | and on the annotate menu you get: "close" and then 4 anotation options. | 10:30.23 |
| KunMyt | Robin_Watts: yes, onCreate i change http://pastebin.com/wxNsMT9s | 10:31.54 |
| Robin_Watts | KunMyt: I can't afford the time to go digging into this at the moment. I'm neck deep in stuff. | 10:32.51 |
| KunMyt | Robin_Watts: i just add method convert pdf to byte[] and read it by buffer | 10:32.57 |
| Robin_Watts | sorry. | 10:32.58 |
| | (You're a free user, not a supported customer, right?) | 10:33.23 |
| KunMyt | Robin_Watts: yes, i free user.... | 10:33.36 |
| Robin_Watts | right. Sorry, but we are desperately trying to put all the pieces back together for a release at the moment... | 10:34.20 |
| KunMyt | Robin_Watts: ok, i'm waitting for next release, Thank you! if you have free time, plz check problem for me. | 10:35.36 |
| Robin_Watts | KunMyt: I am confused by your report though. | 10:35.58 |
| | The initial topbar you get should have the title of the file, then "links, reflow, search, more". | 10:36.21 |
| | If none of those items appear, then I don't see how you can get to the 'more' menu to see the copy icon. | 10:36.55 |
| KunMyt | i'm don't know why | 10:37.45 |
| jogux | KunMyt: can you take a screenshot? | 10:38.00 |
| KunMyt | wait a few minute | 10:38.19 |
| Robin_Watts | tor8: OK, memento is showing leaks. | 10:39.27 |
| | in "Don't pass interpreter context to pdf_processor opcode callbacks" | 10:39.50 |
| | specifically pdf_xobjects are being leaked. | 10:40.16 |
| | previous commit does not leak. | 10:41.40 |
| KunMyt | jogux: screenshot :http://upanh.biz/image/ZagT | 10:42.36 |
| Robin_Watts | KunMyt: And that's what you see when you first start the app up? | 10:43.37 |
| | You haven't clicked anything at this point? | 10:43.43 |
| KunMyt | i have click on More button | 10:44.31 |
| Robin_Watts | Oh, ffs. | 10:44.37 |
| kens | Incase anyone else is having trouble, bmpcmp isd not working for me, all the results are 'bmpcmp: /dev/fd/62: Unrecognised image type' | 10:46.18 |
| Robin_Watts | kens: I have been seeing that too, but not for all results. | 10:46.39 |
| | I assumed that it was something I'd broken :) | 10:46.47 |
| kens | I only have 3 results.... | 10:46.49 |
| | I've tried 3 times and had teh same result in each case | 10:46.59 |
| Robin_Watts | I wonder what machine has run the tests... | 10:47.30 |
| kens | I couldn't tell for certain | 10:47.44 |
| Robin_Watts | Run it again, let me watch the dashboard carefully. | 10:48.18 |
| kens | OK one moment | 10:48.25 |
| | OK its off, I'll watch too | 10:48.37 |
| | Oddly the report also comes back with some other errors like 'cp: cannot stat...' and .gzip:.... No such file or directory' | 10:49.54 |
| | The gzip errors match the bmpcmp problem fiules | 10:50.24 |
| Robin_Watts | I suspect one of the cluster nodes is borked. Possibly a full HD due to the release testing? | 10:50.27 |
| kens | It seems likely to me | 10:50.36 |
| Robin_Watts | Looks like i7 to me. | 10:50.52 |
| kens | i7 is at least one of the node used | 10:50.54 |
| Robin_Watts | So let's disable i7 and try again. | 10:51.00 |
| kens | OK I'll turn it off and try again | 10:51.02 |
| Robin_Watts | I've already turned it off. | 10:51.17 |
| kens | Yeah fortunately I saw :-) | 10:51.26 |
| | looks like kilometers won this time | 10:52.32 |
| Robin_Watts | leagues. I think. | 10:54.41 |
| kens | Yeah seems to be | 10:54.51 |
| | kilmeters said it was 'starting cluster job' but I think it may have been lying | 10:55.06 |
| Robin_Watts | "starting cluster job" comes before "fetching source from kens", I think. | 10:55.28 |
| kens | COuld be :-) | 10:55.39 |
| Robin_Watts | And the bmpcmp is working. | 10:55.45 |
| kens | yeah seems OK this time, thanks! | 10:55.53 |
| Robin_Watts | so we'll leave i7 turned off until marcos arrives. | 10:55.55 |
| | np. | 10:55.59 |
| tor8 | Robin_Watts: makefile dependencies are broken for mupdf/pdf/name-table.h | 11:01.22 |
| Robin_Watts | tor8: Are they? I thought I had them working :( | 11:01.47 |
| tor8 | make -j10 fails | 11:01.55 |
| | source/pdf/pdf-xref.c:557:9: warning: comparison of unsigned expression < 0 is always false | 11:02.05 |
| | scripts/../source/fitz/stream-open.c:73:8: warning: comparison of unsigned expression < 0 is always false | 11:02.16 |
| jogux | oh, KunMyt left. but I reckon his problem is this like in MuPDFActivity.java: Iif (core.fileFormat().startsWith("PDF") && core.isUnencryptedPDF() && !core.wasOpenedFromBuffer()) | 11:04.46 |
| | {..} else { mAnnotButton.setVisibility(View.GONE); } | 11:04.47 |
| Robin_Watts | I lost all interest in his problem when it became clear that he couldn't give a coherent bug report despite direct questions. | 11:05.37 |
| jogux | I guess the likelyhood is that even if he changes that the core will fail to cope when you click save though. | 11:05.38 |
| tor8 | Robin_Watts: shouldn't the name-table header be part of 'make generate' and live in $(GEN)? | 11:06.13 |
| Robin_Watts | tor8: Please feel free to tweak the makefiles as you see fit. | 11:06.40 |
| | The only problem I can forsee is that cmapdump etc will depend on name-tables.h | 11:07.07 |
| tor8 | Robin_Watts: hm, no, name-table.h is part of the public API so we can't hide it in generate/ | 11:08.11 |
| | which makes me feel we should add the generated name-table.h to the git | 11:08.38 |
| jogux | Robin_Watts: tbf I don't think English was his first language :) | 11:19.04 |
| | Robin_Watts: I also vaguely suspect for what he's trying to do he's going to ultimately need a commercial license... | 11:19.52 |
| Robin_Watts | tor8: could do, but it's a shame. | 11:20.28 |
| | jogux: yes. | 11:20.32 |
| | tor8: OK, it's SMask xobjects that are being leaked. | 11:24.41 |
| tor8 | Robin_Watts: hm, in stream-open.c, next_file | 11:25.41 |
| | we ignore the size_t n input argument, then reuse the variable to store the return value of fread | 11:26.03 |
| | but fread returns a signed int | 11:26.07 |
| Robin_Watts | tor8: Want to make me a patch to fix it, and I'll squash it in. | 11:26.51 |
| | ? | 11:26.55 |
| tor8 | oh wait, no, fread returns a positive int forces us to check ferror() for errors | 11:26.57 |
| | a change on how FILE* works as opposed to file descriptors | 11:27.13 |
| | Robin_Watts: I'll patch them up | 11:27.21 |
| Robin_Watts | tor8: That'll make it harder for me to get them into this branch. | 11:27.38 |
| | a fix commit would be easier. | 11:27.43 |
| tor8 | I mean, I'll make patch commits and let you handle them | 11:28.25 |
| | I'm working on top of your branch for these fixes | 11:28.33 |
| Robin_Watts | tor8: ah, cool, thanks. | 11:28.44 |
| tor8 | tor/csi has a makefile fix for the name table files | 11:28.51 |
| | fread doesn't set errno :( | 11:29.16 |
| | I'm not convinced of the FILE* commit yet, could we hold off on that one for a while? | 11:30.36 |
| | lunches | 11:30.43 |
| Robin_Watts | sure. | 11:30.44 |
| | Though I think that moving to FILE *'s rather than fd's is a good move. | 11:31.10 |
| | tor8: OK, I have a fix for the SMask leakage online. | 11:48.30 |
| | When is the meeting today? at 2 or 2:30 UK time? | 13:26.16 |
| kens | I think 14:30 ? | 13:26.24 |
| Robin_Watts | cool. | 13:26.29 |
| tor8 | meeting in one or two hours? | 13:31.43 |
| Robin_Watts | 1 | 13:33.38 |
| | If you're happy with my alternative resource fix, and the softmask object leak fix we can squash those two into 'Don't pass' and push that much ? | 13:34.42 |
| tor8 | Robin_Watts: go for it! | 13:35.15 |
| | clang barfs on %Zd as well... maybe we should just scrap the printflike warnings and use plain %Z and %z as you first did | 13:36.24 |
| Robin_Watts | tor8: Given that we have it working, going for something as much like C99 as possible seems best to me. | 13:40.52 |
| | OK, so next commit is the names one. | 13:44.52 |
| | Did you want to try an alternative formulation of that? | 13:45.06 |
| tor8 | I do want to try using global objects for that and the null/true/false ones | 13:51.27 |
| | okay, we'll still need to disable the printflike warnings though :( | 13:51.49 |
| rayjj | good morning, all | 14:04.52 |
| | I *think* we are going to have a meeting. It's been so long, I'm out of the habit | 14:12.05 |
| | I'll find out for sure in 18 minutes :-) | 14:12.27 |
| Robin_Watts | marcosw1: i7 is failing bmpcmps. We've disabled it from the cluster. | 14:28.07 |
| kens | no henrys means no meeting I guess | 14:30.12 |
| marcosw1 | Robin_Watts: i7 had a drive failure and I decided I'd take the opportunity to move from Ubuntu 10.04 to 14.10 by starting from scratch. i'm still missing some packages... | 14:31.26 |
| fredross-perry | Is Hanry away? | 14:32.32 |
| kens | Should be back afaik | 14:32.42 |
| Robin_Watts | texts henry. | 14:36.32 |
| henrys | ha sorry about that | 14:37.14 |
| kens | :) | 14:37.35 |
| mvrhel_laptop | morning | 14:37.47 |
| Robin_Watts | Morning. | 14:37.51 |
| henrys | really freshly out of bed! | 14:38.12 |
| chrisl | Still recovering from the travelling? | 14:38.45 |
| kens | Hmm tha't sodd, 10 files started timing out | 14:39.21 |
| henrys | chrisl: no I'm fine ... just had the idea I'd sleep a little longer ... ;-) | 14:39.22 |
| chrisl | henrys: sounds like a good plan ;-) | 14:39.52 |
| mvrhel_laptop | So I am still plugging away at gsview. Planning this week to see if I can replicate the issues that ken was seeing on windows 7 and making a simpler interface to create image files, similar to the export feature on Acrobat pro. Should have another one for testing by the end of the week | 14:40.05 |
| | Plus I need to follow up with the color customer on one item | 14:40.20 |
| kens | I'll give it a try when its ready, I'll try and test out Fred's 32-bit Linux binary today | 14:40.35 |
| mvrhel_laptop | thanks kens | 14:40.44 |
| henrys | I did want to say a few things about the trip and I'll do that on skype at the hour if you want to hear that stuff. | 14:41.00 |
| mvrhel_laptop | cool | 14:41.07 |
| chrisl | wonders if his skype client still works....... | 14:41.42 |
| fredross-perry | re: the 32-bit binary - you may fine one or more shared libs missing. I built it on Fedora, and it runs fine. I ran it on Mint and itâs missing libssl, and others. | 14:41.51 |
| henrys | I know about the gs release ... mupdf? tor8? | 14:42.02 |
| kens | I'l be running on Fedora | 14:42.04 |
| fredross-perry | ok | 14:42.17 |
| mvrhel_laptop | has anyone run it on ubuntu? | 14:42.29 |
| kens | Kind of an old version, btu it has a decent amount of stuff installed | 14:42.33 |
| Robin_Watts | kens: What laptop do you have? (vaguely looking. Interested in ones with swappable batteries) | 14:42.39 |
| chrisl | Mint is effectively Ubuntu, but I'll try it when I get time | 14:42.48 |
| kens | Err, one from PC Specialist | 14:42.48 |
| mvrhel_laptop | ok | 14:42.53 |
| Robin_Watts | henrys: tor and I almost have mupdf back together again :) | 14:42.56 |
| kens | Robin_Watts : Dell do one with a backlit keyboard, I'd still like that myself | 14:43.06 |
| henrys | Robin_Watts: good timing. | 14:43.14 |
| Robin_Watts | We should have a release candidate before the end of the week. | 14:43.17 |
| henrys | fredross-perry, mvrhel_laptop: we never talked about this but should we do a debian package or something that installs deps? | 14:45.28 |
| kens | Hmm, so I'm missing libpng as a shared library | 14:45.32 |
| fredross-perry | I can look into that. | 14:46.13 |
| kens | I'm just isntalling it now | 14:46.26 |
| | Oh, it says I already have it, but not libpng.so.16 it seems | 14:46.40 |
| henrys | should mupdf require that? | 14:47.00 |
| kens | gxview this is | 14:47.05 |
| jogux | supplying a linux binary that's not statically linked sounds like it would be fraught with problems. :-S | 14:47.13 |
| Robin_Watts | yeah, can't we statically link everything ? | 14:47.28 |
| chrisl | We can't statically link glibc | 14:47.41 |
| kens | I admit libpng being shared was a surprise | 14:47.47 |
| rayjj | jogux: yeah, but some distros are really keen on dynamically linked libs | 14:47.52 |
| jogux | rayjj: then let them package it :-) | 14:48.03 |
| henrys | rayjj: that's irrellevent here | 14:48.08 |
| chrisl | I doubt we'll make inroads into the Linux world with a binary anyway | 14:48.31 |
| rayjj | chrisl: probably not | 14:48.45 |
| Robin_Watts | distros will want to build themselves. | 14:49.00 |
| henrys | chrisl: you might be right but I think for the first release we should try. | 14:49.10 |
| Robin_Watts | but for supplying an installer, statically linked sounds like the right move to me. | 14:49.16 |
| rayjj | Robin_Watts: yeah, with who knows what libs :-( | 14:49.18 |
| chrisl | If we really want to, we'll have to package up deb and rpm packages | 14:49.29 |
| | And unless we keep it (A)GPL few distros will consider it | 14:49.57 |
| rayjj | I'm all for statically linked apps. It avoids a lot of screwy problems | 14:50.08 |
| | the old gsview was Aladdin, right ? (AFPL) ? | 14:50.53 |
| tor8 | henrys: I expect a late mupdf release this spring. | 14:51.03 |
| chrisl | rayjj: yeh, and no Linux distro has included it | 14:51.18 |
| tor8 | we've got several big changes in the pipe just committed and I want to let the dust settle a bit first | 14:51.28 |
| kens | Looks like I have lioobpng12 | 14:51.35 |
| Robin_Watts | chrisl: zlib, pnglib, freetype, lcms, etc should all be static, IMHO. | 14:51.36 |
| henrys | we still have 4 blockers all belonging to rayjj for ghostscript release. Are those marked properly? | 14:51.47 |
| kens | Or even libpng12 | 14:51.48 |
| | henrys I think not | 14:52.02 |
| | IIRC at least one is XPS | 14:52.07 |
| henrys | blockers for the next release now? | 14:52.14 |
| rayjj | oh, I've been working on cust 532 issues and haven't looked | 14:52.16 |
| chrisl | Robin_Watts: I don't know where those dependencies are coming from | 14:52.16 |
| jogux | possibly from qt? (gsview uses qt iirc?) | 14:52.48 |
| henrys | chrisl: they could be qt | 14:52.53 |
| chrisl | I thought we'd decided only the one "blocker" was actually a blocker? | 14:52.55 |
| | And rayjj committed the agreed work-around for that | 14:53.19 |
| fredross-perry | could be Qt since it uses PNG files for icone | 14:53.20 |
| | *icons* | 14:53.31 |
| kens | I'm not getting anywhere fast with libpng, Fedora insists that I have the latest version, but I don't think I do. I'd have to go and fetch it manually and rebuild | 14:54.12 |
| chrisl | kens: you've probably got the most recent version available on your distro | 14:54.42 |
| kens | Yeah that's what I suspect | 14:54.49 |
| | Or at least the latest available for this version of Fedora | 14:55.00 |
| chrisl | It does *seems* that Qt can be statically linked, at least on some platforms | 14:55.01 |
| kens | TBH this is the sort of thing I exepcted for a Linux binary | 14:55.35 |
| rayjj | I just added the comment and downgraded bug 695771 (commit 949e2de694cb5464a26794b7679d8f74ad2fe02b) | 14:55.35 |
| fredross-perry | I could just run the set of required libs to ground, and supply them in the installer, in a folder adjacent to the app. Already doing that for the Qt libs themselves. | 14:55.36 |
| kens | It would make my life easier, certainly | 14:55.52 |
| henrys | jogux: the distros package ghostscript and won't take our packaging. The issue is updating shared libraries for important security fixes. | 14:56.26 |
| jogux | nods at henrys | 14:56.39 |
| henrys | we either have to do static or a package that checks for dependencies. | 14:58.09 |
| | anything else for this meeting. I apologize for being late and barely awake... | 14:58.46 |
| fredross-perry | Qt can be statically linked, but Iâm not sure that creates an executable with no deps | 14:58.51 |
| henrys | fredross-perry: a few is fine clib for example. | 15:00.42 |
| chrisl | It's not practical to statically link glibc | 15:01.06 |
| Robin_Watts | yeah, even if we could, we shouldn't. | 15:01.21 |
| fredross-perry | I am going to look into static linking next, but keep with the installer approach for now. | 15:01.30 |
| marcosw1 | I prefer static; I just upgrade from Ubuntu 10.04 to 14.10 and much of the code I built and installed from source (i.e. ImageMagick, gnuplot, xli, ...) had to be recompiled because the version numbers of the libraries had changed (i.e. libtiff.so.4 -> libtiff.so.5). | 15:01.41 |
| chrisl | fredross-perry: the ideal would be a monolithic Qt library against which the executable was linked, but that's almost certainly not practical | 15:02.40 |
| fredross-perry | Iâll see what other Qt devs are doing. | 15:03.11 |
| henrys | fredross-perry: good idea | 15:03.42 |
| Robin_Watts | So, are we swapping to skype now? | 15:03.43 |
| chrisl | fredross-perry: I suspect to get that it would mean building Qt, and we shouldn't have that as a necessary part of the build! | 15:03.55 |
| henrys | Robin_Watts: yes to skype, I just want a cup of coffee so I'll be a minute | 15:04.17 |
| marcosw1 | sigh. after dealing with a disk failure last week, a failure of the replacement disk, now I'm getting kernel errors related to disk i/o ("ata1.00: failed command: READ FPDMA QUEUED" and "ata1: hard resetting link") | 15:04.51 |
| | I guess it's time to stop using seagate, like everyone else (too bad, I like the ssd/hd hybrid and I don't think anyone else makes one). | 15:05.48 |
| fredross-perry | Not sure I agree with that, ias long as what to do is well-documented. And I think building Qt is the way its done. | 15:05.56 |
| henrys | for those that didn't hea I was going to talk about the trip on skype. | 15:06.20 |
| | s/hea/hear | 15:06.29 |
| jogux | marcosw1: :-( is that all the same machine? | 15:06.34 |
| chrisl | fredross-perry: it shouldn't be required to build the entire gui toolkit just to build an app | 15:06.50 |
| Robin_Watts | chrisl: If fredross-perry has to make a static Qt lib that he can drop into the build in order to make an installer for statically linked binaries, that seems fine to me. | 15:06.55 |
| | As long as other people can still build the thing without needing that. | 15:07.07 |
| henrys | skype is a spinning ball you guys must've talked a lot ;-) | 15:07.38 |
| fredross-perry | if the Qt licence allows it. | 15:07.51 |
| jogux | fredross-perry: errr. good point. | 15:08.10 |
| | fredross-perry: doing it your dll shipped alongside way may still work and fix the issue though? | 15:08.31 |
| | possibly one huge dll with qt and all the deps? | 15:08.44 |
| | (Qt is LGPL iirc) | 15:08.55 |
| marcosw | jogux: yes, but Iâve the two previous failures are clearly the disk themselves, i.e. one of them makes strange noises and the other one no doesn't spin. | 15:09.18 |
| jogux | marcosw: nasty :( sounds unlucky | 15:09.48 |
| fredross-perry | Right now I am installing the Qt libs aongside (app is linked with -rpath). Adding more libs to the alongside works just fine. So itâs just identifying the minimum set of libs. | 15:09.55 |
| rayjj | marcosw: just curious, but what brand/type disks ? | 15:10.10 |
| chrisl | marcosw: if you are using seagate, you get no sympathy from me! | 15:10.16 |
| Robin_Watts | rayjj: sounds like seagate momentus XT? | 15:10.26 |
| marcosw | chrisl: I know. | 15:10.34 |
| | guess Iâll look into bcache⦠| 15:10.52 |
| rayjj | I've got seagate hybrid 1Tb on peeved | 15:10.53 |
| jogux | fredross-perry: I presume it's essentially most of the qt deps excluding libc | 15:11.06 |
| Robin_Watts | I have a 750Gig one in my macbook. | 15:11.13 |
| rayjj | but they're in a RAID-5 so at least I'm somewhat protected | 15:11.24 |
| jogux | hybrid is, imho, not worth it anymore, 1TB SSDs are well into affordable category. | 15:11.45 |
| fredross-perry | yes, I think so. | 15:11.51 |
| marcosw | i had a 2tb seagate hybrid fail on my other machine (x6) three weeks ago, but no drama. started seeing SMART warnings, ddâd the data to a spare drive and swapped it in less than a day. | 15:12.04 |
| rayjj | jogux: that's what I have on my laptop | 15:12.12 |
| marcosw | jogux: I canât live with 1 TB. All of my machines have 4 TB (2x2TB SSHDs). | 15:12.36 |
| | speaking of which, i moved both scones and muffins to SSDs but toast has too much stuff. | 15:13.32 |
| | any thoughts if we need the mailserver VM? Itâs really big and growing. | 15:13.48 |
| jogux | growing significantly? | 15:13.59 |
| | I think we're technically routing mail through it, but don't really need to. | 15:14.14 |
| | there was some big hiccup with email recently, btw last night I got about 200 emails from ATS ranging back at least a few weeks | 15:14.39 |
| marcosw | jogux: that was because all the mail is routed through my i7 and that was the machine with the sequential double disk failure. | 15:15.16 |
| jogux | ahhhhhhh :-S | 15:15.26 |
| marcosw | the mailserver VM is 550G. | 15:17.17 |
| jogux | I think lots of stuff falls down without it - it's also the primary LDAP machine for all the machines I think. (and I did actually need to get some data from it not so long back.) | 15:18.13 |
| | fredross-perry: I'd imagine we should also being very careful to complly with the LGPL, so make sure to keep an archive of all the source you built QT etc from, remember to include the LGPL text in the final archive, etc... | 15:20.19 |
| fredross-perry | yes | 15:23.38 |
| marcosw | jogux: the directory /opt/zimbra/logger is 131G and /opt/zimbra/store is 97G. Is zimbra still being used for anything? | 15:24.24 |
| jogux | marcosw: just the mail and the ldap :-) | 15:25.44 |
| Robin_Watts | tor8: come to skype... | 15:26.47 |
| marcosw | must be a different zimbra the, google suggests itâs a collaboration platform. | 15:26.49 |
| kens | 20 minutes struggling to reset my Skype password, and now it wants to install updates..... | 15:27.23 |
| jogux | marcosw: marketing ;-) | 15:27.24 |
| | marcos: it's email and IM | 15:27.35 |
| | marcosw: that is the right one you've found | 15:27.44 |
| marcosw | most of the space seem to be taken up by undeliverable mail for people who no longer work for picsel. | 15:29.32 |
| | is it keeping them for logging or just in case the account comes back online? | 15:29.54 |
| jogux | for us, the former. | 15:31.27 |
| marcosw | maybe iâll move toast to an SSD but keep some of the larger VMs (i.e. mail) on spinning media⦠| 15:35.27 |
| jogux | sounds okay. on our toast, used an SSD for / but had all the VMs on a spinny disc. | 15:37.07 |
| chrisl | marcosw: Can you put individual directories onto spinning disks, and the main VM on SSD? | 15:37.35 |
| marcosw | I can get all of the VMs on a 1TB SSD except for the mail server | 15:38.28 |
| jogux | that sounds fine to me | 15:40.10 |
| tor8 | Robin_Watts: could we please stop using skype? | 15:51.44 |
| | I've gone through three machines trying to find a skype installation that works | 15:51.57 |
| | the one that starts, can't connect to Skype headquarters | 15:52.20 |
| Robin_Watts | tor8: I can't think of anything else that would do the job and be less of a pain. | 15:52.34 |
| chrisl | tor8: you need Windows ;-) | 15:52.57 |
| tor8 | chrisl: Robin_Watts: in that case, henry should pay for a dedicated skype laptop running windows... :/ | 15:53.36 |
| rayjj | just run it on a tablet | 15:53.53 |
| jogux | it works nicely on OS X too | 15:53.54 |
| Robin_Watts | Joseph manages to run skype all day on a mac with no problems. | 15:53.56 |
| marcosw | chrisl: skype on mac actually works quite well, not sure why microsoft allows that. | 15:54.03 |
| jogux | and, yeah, the iPad client is pretty usable too | 15:54.09 |
| tor8 | I don't own a mac... | 15:54.12 |
| jogux | albeit sucks battery iirc. | 15:54.19 |
| tor8 | but I guess my iPad could work? | 15:54.26 |
| rayjj | marcosw: probably because it pre-dated the acquisition | 15:54.32 |
| marcosw | you can run windows in a VM :-) | 15:54.33 |
| rayjj | a windows VM on an ipad ??? | 15:55.06 |
| | that's just wrong | 15:55.30 |
| tor8 | marcosw: well, the linux skype client seems to have stopped working. I guess it's too old or some crap like that. | 15:55.36 |
| jogux | MS is pretty cross-platform these days. it's a bit scary. | 15:55.38 |
| rayjj | their trying to take over the world (again) | 15:55.58 |
| jogux | there's even a beta of the new office for Mac that almost brings feature parity with windows office. | 15:55.59 |
| chrisl | I do wish the Linux Skype client was a little less sh*t..... | 15:56.39 |
| rayjj | hurray! tor8 finally got skype working | 15:56.50 |
| tor8 | wow, is skype supposed to have a big fat ad-banner over half the screen!? | 15:57.23 |
| | rayjj: safely quarantined in a windows xp VM | 15:57.42 |
| rayjj | tor8: good plan | 15:57.54 |
| Robin_Watts | tor8: If your screen is sufficiently small :) | 15:58.01 |
| tor8 | Robin_Watts: it's a VM in as tiny a window as I can get away with ;) | 15:58.34 |
| Robin_Watts | tor8: OK, so as far as I can tell merge_csi tests out on the cluster properly now. Phew. | 15:59.06 |
| henrys | tor8: perhaps a chromebook is a bit underpowered for a full time developer ;-) | 15:59.10 |
| chrisl | tor8: I wonder if it would run on wine..... | 15:59.19 |
| Robin_Watts | Did you have some fix commits? | 15:59.20 |
| | http://www.dell.com/uk/p/xps-15-9530/pd?oc=cnx9525#secondaryContent | 15:59.30 |
| marcosw | henrys: speaking of the cluster, is there a reason your macpro is disabled as a cluster machine? Itâs nice to have a non-linux box in the mix. | 16:00.22 |
| henrys | marcosw: no I didn't do it. | 16:00.38 |
| rayjj | I did it because someone said the disk was full and henrys was out of town | 16:01.08 |
| | but then I forgot to re-enable it | 16:01.21 |
| | henrys: please go ahead and add it back in | 16:01.37 |
| Robin_Watts | rayjj: done. | 16:01.57 |
| rayjj | Robin_Watts: thanks | 16:02.02 |
| | back to regular work... | 16:02.31 |
| | (optimizing clist code for customer 532) | 16:02.52 |
| tor8 | Robin_Watts: makefile fix, and pdf_obj rework on tor/csi | 16:04.21 |
| Robin_Watts | grabbing those now, ta. | 16:04.45 |
| | I can't see the latter... | 16:05.18 |
| tor8 | Robin_Watts: ah, sorry. need to force push. | 16:08.16 |
| | Robin_Watts: try now. | 16:08.24 |
| Robin_Watts | tor8: Ta. | 16:08.37 |
| tor8 | the makefile commit needed some revising; the one you got just before was broken | 16:08.47 |
| Robin_Watts | right. | 16:09.03 |
| tor8 | I ran into one issue with the global pdf_obj_name tables; I had to change the char n[1] to a char * | 16:09.27 |
| | but I still alloc only one chunk for non-standard names (I just alloc enough to hold the string the struct, and point the char* to that) | 16:09.58 |
| | so we waste 4 or 8 bytes per name, but I don't think that's going to be huge | 16:10.09 |
| Robin_Watts | tor8: ick. | 16:10.22 |
| | You also changed pdf_namecmp | 16:10.33 |
| | if (a == b) return !a; | 16:10.40 |
| tor8 | basically obj->n = ((char*)obj) + sizeof(pdf_obj_name) | 16:10.41 |
| Robin_Watts | has become if (a == b) return 0; | 16:10.47 |
| | the point is that NULL should not compare equal to NULL. | 16:10.58 |
| tor8 | null compares equal to null if you use pdf_objcmp | 16:11.50 |
| Robin_Watts | null == null, but NULL != NULL, IIRC. | 16:12.07 |
| | PDF 'null' objects compare equal, but pdf_obj's that happen to be NULL never compare equal to anything. | 16:12.56 |
| tor8 | Sorry, bad habit of all lowercase typing bit me there. NULL == NULL as well. | 16:13.04 |
| | we don't have NaN behaviour for NULL objects | 16:13.20 |
| | though I don't think it matters either way, nothing we do should rely on that behaviour | 16:13.43 |
| Robin_Watts | In pdf_objcmp... if (!a || !b) return 1; | 16:14.11 |
| tor8 | ... after if (a == b) return 0; | 16:14.29 |
| Robin_Watts | Bah. That bits hidden off my diff :) | 16:14.53 |
| | ok, | 16:15.39 |
| tor8 | personally, I'd change pdf_namecmp to pdf_name_eq and invert the return value | 16:16.44 |
| | makes for easier code everywhere we use it | 16:16.59 |
| | or just 'obj == PDF_NAME_Foo' but that might bite us if we decide to go back on any other implementation | 16:17.37 |
| Robin_Watts | tor8: I think we sort using pdf_namecmp in the dictionary sorting stuff. | 16:17.39 |
| tor8 | Robin_Watts: no, that just uses a hardwired strcmp | 16:18.02 |
| Robin_Watts | tor8: Does namecmp resolve ? | 16:18.12 |
| tor8 | given that we *know* dictionary keys are names | 16:18.15 |
| | ah, yes. it does, and that's why we need it! | 16:18.28 |
| | if the a == b test fails, it does a pdf_resolve_objcmp | 16:18.40 |
| Robin_Watts | right. | 16:18.48 |
| tor8 | how do you feel about pdf_name_is or pdf_name_eq? it's an easy search/replace job if we want it | 16:19.28 |
| Robin_Watts | I would prefer pdf_name_eq to pdf_name_is. | 16:19.58 |
| | As long as we aren't sorting using it, then I think I prefer that. | 16:20.11 |
| tor8 | done :) | 16:20.48 |
| | let me just make sure it still works! | 16:21.19 |
| mvrhel_laptop | I will be out for a bit. need to help out at school | 16:22.38 |
| tor8 | Robin_Watts: okay, namecmp rename on tor/csi | 16:26.02 |
| Robin_Watts | tor8: I dislike the extra pointer. That really bothers me. | 16:33.51 |
| | There must be a nice way around that. | 16:34.01 |
| | And is this going to cause problems on DLLs on windows? | 16:34.20 |
| | This will be slower than my version, I suspect. | 16:36.11 |
| | load register with small integer value (which is what mine ends up doing) is always going to be less effort than load register with pointer to global data (which is what yours does) | 16:37.25 |
| | It seems that we're trading a minor aesthetic point for extra memory use, problems on windows, and (potentially) slower speeds. | 16:46.48 |
| | There *is* a way around the extra memory use. | 16:48.56 |
| | I can't see a way around the problems with windows DLLs. | 16:49.16 |
| | tor8: Actually, what was the global static data problem again? | 16:54.07 |
| | the windows DLL thing? | 16:54.17 |
| henrys | marcosw: can you create a bug for the ghostpcl customer problem and I'll look at it. I was hoping tiffscaled would work for that but it doesn't, sigh. | 17:07.41 |
| marcosw1 | henrys: will do | 17:09.57 |
| kens | night all | 17:13.56 |
| Robin_Watts | tor8: Urgh. | 17:17.20 |
| | Every call to pdf_dict_get now resolves to a pdf_dict_gets. So we're strcmping like mad again. | 17:17.53 |
| henrys | ugh I think norberts problem is a real bug... the interactions just dawned on me, now to fix it. double ugh... | 17:41.59 |
| Robin_Watts | tor8: The more I look at this commit, the less I like it. | 17:49.42 |
| tor8 | the strcmp'ing could be gotten rid of | 18:02.36 |
| | we could make the pdf_obj_name data live in the array, and then we could compare pointers for < and > | 18:03.12 |
| | and whether they are in the array at all | 18:03.22 |
| | else fall back to a strcmp | 18:03.29 |
| | Robin_Watts: ^ | 18:03.46 |
| Robin_Watts | tor8: I've just got rid of the extra pointer here. | 18:03.59 |
| tor8 | how did you manage that? | 18:04.09 |
| Robin_Watts | I'll put the commit up in a mo. | 18:04.18 |
| tor8 | windows DLLs have problems exporting non-functions | 18:04.55 |
| Robin_Watts | tor8: From what I just googled, windows DLLs can export global variables, but you get one set of global vars per process. | 18:05.35 |
| tor8 | the pointer magic that you used bothers me, what is the guarantee do we have that the allocator won't use that range? | 18:05.36 |
| Robin_Watts | Between 1 and 200? | 18:05.45 |
| tor8 | right, so there should be no problem? | 18:05.49 |
| Robin_Watts | I know we run on some small OS, but you find me one that lets us access zero page :) | 18:06.17 |
| tor8 | Robin_Watts: I know it's extremely unlikely, but it still bothers me :) | 18:06.28 |
| Robin_Watts | You generate a PDF_NAME_TABLE array, that has pointers to all the objects in, right? | 18:08.43 |
| tor8 | yeah. I'd be perfectly happy to put the data in the array, and the objects point to inside the array | 18:09.02 |
| | that would let us have sorted pointers for the standard names | 18:09.38 |
| Robin_Watts | The objects could all be #define PDF_NAME_BLAH ((pdf_obj *)PDF_NAME_TABLE[2]) | 18:09.43 |
| tor8 | that's also a possibility | 18:10.02 |
| | then there's only one global to worry about exporting as well | 18:10.29 |
| Robin_Watts | Yes. | 18:10.34 |
| | Let me try and work towards that. | 18:10.46 |
| tor8 | okay. and if this doesn't come to any good, I'm not going to gripe too loudly about your first solution | 18:11.09 |
| Robin_Watts | Even if it does come good, I prefer my solution :) | 18:11.26 |
| tor8 | but I do like being able to dereference the pdf_obj pointers in gdb and have actual objects at the end | 18:11.28 |
| Robin_Watts | tor8: yeah, I get that. | 18:11.34 |
| marcosw | sigh, turning off ncq didnât help. so Iâm giving up on seagate and setting up a HGST drive. | 18:12.12 |
| Robin_Watts | Ah... tor8, you know that you won't be able to look at the content of a pdf_obj * any more, right? | 18:32.38 |
| | pdf_obj * will tell you the type, but not the contents thereof. | 18:32.55 |
| | (in gdb, I mean). | 18:33.22 |
| | You'll need to do something like: call print_obj(x) | 18:33.39 |
| henrys | marcosw: yes you are right, additional information for the customer in the bug | 18:35.24 |
| marcosw | henrys: so uncommenting the define DEVICE_RES_PATTERNS makes it similar to what the customer wants? | 18:37.22 |
| Robin_Watts | OK, tor8. 2 commits on the end of robin/merge_csi | 18:37.56 |
| | The first removes the extra pointer. | 18:38.06 |
| | The second puts everything into a single array. | 18:38.17 |
| | but the cost for doing that is that I have to expose the definition of pdf_obj to the world. | 18:38.38 |
| | Currently it's as 'pdf_obj_internal' which I'm not a massive fan of. | 18:39.11 |
| | On balance, I still prefer my commit, given that you're desired goal of being able to print objects in gdb has already been lost. | 18:39.43 |
| henrys | marcosw: I've only verified it uses a higher resolution pattern on the HP. with your command line I doubt it would matter since you said 300. Do you have their command line? | 18:39.49 |
| Robin_Watts | s/you're/your/. bah. | 18:39.53 |
| henrys | marcosw: I thought tiffscaled was used by the customer but not sure. | 18:40.10 |
| marcosw | henrys: the example tiff file they sent is 72 dpi, so presumably thatâs waht the they are using | 18:40.18 |
| | iâll ask the customer | 18:40.26 |
| Robin_Watts | urm.. | 18:42.02 |
| | getting tiffscaled to output at 72dpi would be tricky | 18:42.14 |
| marcosw | 288/4 ? | 18:42.32 |
| Robin_Watts | And rendering PCL at anything other than a multiple of 300 is doomed to failure, right? | 18:42.52 |
| henrys | Robin_Watts: yeah I think I saw 200 dpi and assume 600 and downscale 3. | 18:42.53 |
| marcosw | yeah, so why is 72 tricker with tiffscaled than with any other device? | 18:43.16 |
| Robin_Watts | 200 would make sense. 75 would make sense. 72... not so much. | 18:43.18 |
| marcosw | 300/72!=int(300/72) | 18:43.24 |
| Robin_Watts | marcosw: Rendering PCL at anything other than a multiple of 300dpi is doomed to failure on ANY device. | 18:44.00 |
| marcosw | the comparison raster file the customer sent is fax resoluton (204x198, or something like that). | 18:44.01 |
| | Robin_Watts: youâd think so, but it generally works fine. | 18:44.24 |
| Robin_Watts | henrys: I have no beverage available to splutter all over the keyboard at this point. Would you might doing the honours? | 18:44.49 |
| | s/might/mind/. | 18:44.59 |
| | Jeez, fingers betraying me today. | 18:45.11 |
| marcosw | of course some pcl files donât work but Iâve seen plenty of PostScript files that only work at a particular resolution. | 18:45.11 |
| Robin_Watts | marcosw: AIUI, you *can* get PCL that works at any resolution, but really, you'd be mad to rely on it. | 18:45.46 |
| | And if the customer was rendering at such a strange resolution and was getting bad results, we'd generally just say "don't do that, it's not supported". | 18:46.22 |
| tor8 | Robin_Watts: yeah. this is getting hackier and hackier :( | 18:47.06 |
| Robin_Watts | (Of course, my knowledge of PCL is minimal - I'm going by the memory of what Henry told me, so I'm quite prepared to be told that I'm wrong) | 18:47.09 |
| tor8 | let's go with your version (but please do take the pdf_name_eq patch) | 18:47.24 |
| Robin_Watts | I will gladly take that patch. | 18:47.33 |
| tor8 | Robin_Watts: one thing I noticed, a few inconsistencies in the PDF_OBJ__LIMIT comparisons | 18:47.50 |
| henrys | we really want to using 600 and downscale 3 - that is consistent with the tiff they sent which says resolution 204x196... Not sure how Robin_Watts got that but close enough... | 18:47.55 |
| Robin_Watts | (and I've already taken a couple of stylistic fixes from your one) | 18:47.56 |
| tor8 | you use <= in a few places that should be < | 18:48.05 |
| | or vice versa | 18:48.08 |
| Robin_Watts | tor8: will check, ta. | 18:48.16 |
| marcosw | Robin_Watts: being the customer has another product that does support this and produces output he likes would you like to take bets on their response? Youâve been hangning around with Ken too much, he feels we should fail to read any PDF file that is out of spec, never mind what everyone else does. | 18:49.00 |
| Robin_Watts | marcosw: My memory from discussing this with Henry was thinking that it was probably possible to support this properly, but it would involve reevaluating some design decisions made right back at the start of the PCL interpreters development. | 18:50.43 |
| henrys | marcosw: no the solution is tiffscaled. | 18:51.14 |
| Robin_Watts | henrys: How I got 204x198 ? | 18:51.15 |
| henrys | Robin_Watts: that's what the customer sent, I'm guessing it's from your device. | 18:51.41 |
| Robin_Watts | Ah, right. | 18:51.53 |
| henrys | Robin_Watts: argh don't know how the customer got that you get 200x200 in the current code. | 18:52.53 |
| Robin_Watts | henrys: right :) | 18:53.06 |
| | tor8: Where is the pdf_name_eq patch? | 18:54.12 |
| | D'Oh. trypewriting, sorry. | 18:54.55 |
| henrys | marcosw: also right next to where that define is they can hardwire the pattern resolution to 600 instead of 300 and not use the #define. That might be best for them ... | 18:57.30 |
| marcosw | okay, will let them know. | 18:57.54 |
| tor8 | Robin_Watts: you found it? | 19:04.39 |
| Robin_Watts | tor8: Yup. testing now. | 19:05.05 |
| | bugger. stuff broke. | 19:05.47 |
| tor8 | :( | 19:06.02 |
| Robin_Watts | It'll be something silly. I'll find it. | 19:06.17 |
| | tor8: found it. | 19:42.06 |
| | So, let me look for <= | 19:42.36 |
| | tor8: OK, latest version on robin/master | 19:52.33 |
| | just retesting now for sanities sake. | 19:52.41 |
| | I believe everything should be ready to go now, except for the last one (FILE * stuff) that you said you wanted to think about some more. | 19:55.10 |
| | tests passed. | 20:05.27 |
| rayjj | I reduced the number of large pattern reads from 560 down to 74 (on J10 page 2 when the BandHeight is 128 and there are 40 bands at 600 dpi). It was a lot less painful than I thought | 20:22.47 |
| | now to run a regression test on it | 20:23.05 |
| tor8 | Robin_Watts: a few warnings remain | 20:56.56 |
| | lseek64 is not defined | 21:02.13 |
| | something wrong with the header define magic | 21:02.22 |
| | Robin_Watts: everything up to and including 'Update our printf to cope with various useful extensions' LGTM | 21:05.00 |
| | the MUPDF_LARGE_FILE_SUPPORT is broken on my linux | 21:05.08 |
| | I'll see what I can do about that tomorrow | 21:05.17 |
| | Forward 1 day (to 2015/03/25)>>> | |
IRC Logs