| | <<<Back 1 day (to 2013/03/04) | 2013/03/05 |
| ray_laptop | Hi, Robin_Watts | 00:27.05 |
| Robin_Watts | hi | 00:27.10 |
| ghostbot | niihau | 00:27.11 |
| ray_laptop | Robin_Watts: the 'copy_planes' function has a 'plane_height' parameter, and the clist_copy_planes has an 'if (plane_height > 0) {', but the gxdevcli.h and the doc/Drivers.htm don't explain what plane_height is, and why it might ever be == 0 when the rheight is > 0 | 00:29.29 |
| | Robin_Watts: do you recall anything about this ? (question also for mvrhel) | 00:30.10 |
| Robin_Watts | ray_laptop: Right, so suppose I have a block of data that I want to write. | 00:31.35 |
| | that I want to copy_planes, I mean. | 00:31.48 |
| | My planar data might be 1024 wide x 1024 high x 8 planes | 00:32.28 |
| | but I might just want to copy_planes the top 256 x 256 area. | 00:32.51 |
| ray_laptop | Robin_Watts: by how many planes ? | 00:33.18 |
| Robin_Watts | so I give width = 256, height = 256, raster = 1024, plane_height 1024 | 00:33.18 |
| | all 8 planes. | 00:33.25 |
| ray_laptop | Robin_Watts: OK, so when, if ever, will plane_height be <= 0 ??? | 00:33.48 |
| Robin_Watts | plane_height = 0 => copy_mono, no ? | 00:34.01 |
| ray_laptop | Robin_Watts: why isn't plane_height == rheight for mono (one plane) ??? | 00:34.44 |
| Robin_Watts | plane_height == rheight would not mean 1 plane. | 00:35.30 |
| | plane_height is 'the number of rasters to move from a given pixel value in one component to get to the corresponding pixel value in the next component" | 00:36.15 |
| ray_laptop | Robin_Watts: OK, so plane_height is either 0 (a pathological case in which copy_mono should have been called) or >= rheight ??? | 00:37.29 |
| Robin_Watts | Yes. | 00:37.37 |
| ray_laptop | Robin_Watts: so plane_height < rheight is an error condition unless plane_height == 0 (just asking again a different way). | 00:39.02 |
| Robin_Watts | I think so, yes. | 00:39.27 |
| ray_laptop | The code in clist_copy_planes is still a bit confusing, then. if plane_height == 0, why can't we just call copy_mono and get rid of some duplicate code ? (when we can't even handle a single row) | 00:42.33 |
| Robin_Watts | See line 870. | 00:42.56 |
| ray_laptop | Robin_Watts: OK. | 00:43.20 |
| Robin_Watts | wooah. | 00:43.25 |
| | We've just said that plane_height is never zero currently. | 00:43.41 |
| | It's possible that we could rejig copy_mono to call copy_planes with plane_height == 0. | 00:44.18 |
| ray_laptop | Robin_Watts: not that I can see using 'grep -l copy_planes base/*.c' -- I don't see anybody calling it with 0 | 00:44.40 |
| Robin_Watts | with some jiggering around. | 00:44.40 |
| | ray_laptop: Right. No one ever calls it with 0. That's what we just agreed. | 00:45.12 |
| | but then you said: "if plane_height == 0, why can't we just call copy_mono and get rid of some duplicate code ?" | 00:45.38 |
| | and I said "wooah!" because plane_height is never 0. | 00:45.55 |
| ray_laptop | Robin_Watts: so the code to treat plane_height == 0 is just sort of 'premature optimization' to allow us to make copy_mono just call copy_planes ??? | 00:46.22 |
| Robin_Watts | It is quite possible that I started writing this code intending copy_planes and copy_mono to end up in the same block. | 00:47.10 |
| | (possibly I started modifying copy_mono) | 00:47.26 |
| | and when stuff got hairy, I split them out separately, so I could at least be sure that I didn't break copy_mono. | 00:47.47 |
| ray_laptop | Robin_Watts: I think i'll "simplify" it and get rid of the plane_height == 0 special treatment | 00:48.06 |
| Robin_Watts | Resolving the duplication by putting them back together would be nice. | 00:48.12 |
| | ok. | 00:48.15 |
| ray_laptop | Robin_Watts: since copy_mono doesn't pay any attention to num_components, and copy_planes has to | 00:48.41 |
| Robin_Watts | ray_laptop: Right. We could possibly common up the code, and use plane_height !=0 as the excuse for looking at num_components etc. | 00:49.28 |
| ray_laptop | Robin_Watts: I'd need a new function that I could send 'num_components' to, along with the other params. copy_mono would call the new function with 1 and copy_planes call it with num_components | 00:50.30 |
| Robin_Watts | right. | 00:51.01 |
| | but if you just wanted to make what was there now work, I'd understand :) | 00:51.14 |
| ray_laptop | Robin_Watts: or, as you said, use plane_height == 0 to tell us to ignore num_components | 00:51.25 |
| | Robin_Watts: but, of course, this only helps if we document WHY plane_height might be 0 and what it implies | 00:52.02 |
| | I guess I should have paid more attention when this stuff got put in :-/ | 00:54.28 |
| Robin_Watts | Hmm. I can't see any documentation for copy_planes at all. | 00:55.26 |
| | And why is copy_planes like copy_mono ? | 00:56.12 |
| ray_laptop | Robin_Watts: I think I mentioned that above (it should be in Drivers.htm, or at least in gxdevcli.h) | 00:56.25 |
| Robin_Watts | mono is 1 bit, right? | 00:56.27 |
| | yeah, I'm *sure* I wrote this. | 00:56.41 |
| ray_laptop | Robin_Watts: yes, mono is 1 bit. and there's a check at line 976 that looks like it might make us ignore num_components if plane_height == 0 | 00:58.15 |
| Robin_Watts | Ah! | 00:59.31 |
| | I think the fact that plane_height != 0 is the thing that determines whether we call copy_mono or copy_planes | 01:00.00 |
| ray_laptop | Robin_Watts: where is that ? | 01:00.24 |
| Robin_Watts | In the writing side look at 807 | 01:00.51 |
| | In gxclrast.c look at 2181 | 01:01.20 |
| | Does that make sense? | 01:06.25 |
| ray_laptop | Robin_Watts: so this looks like the reading side really never has a copy_mono -- just a copy_mono_planes | 01:07.02 |
| | with plane_height == 0 (in the reader) telling us to call copy_mono | 01:07.36 |
| Robin_Watts | The op that is sent is cmd_op_copy_mono_planes | 01:10.10 |
| ray_laptop | Robin_Watts: right. and the reader "splits" depending on plane_height (which is 0 if it came from copy_mono) | 01:11.00 |
| Robin_Watts | it was called cmd_op_copy_mono, but I think I renamed it when I repurposed it (added a plane_height) | 01:11.11 |
| | yes. | 01:11.15 |
| | I think I was struggling to find an unused clist code. | 01:11.37 |
| ray_laptop | Robin_Watts: right, but we still had clist_copy_mono laying around | 01:11.46 |
| Robin_Watts | Did we? | 01:11.58 |
| | sorry. | 01:12.16 |
| ray_laptop | Robin_Watts: other than as a simple function that called clist_copy_planes with plane_height == 0 | 01:12.24 |
| Robin_Watts | I still believe the writing is done in 2 separate functions. clist_copy_mono and clist_copy_planes | 01:12.39 |
| | They are superficially similar and would be nice candidates for merging, but I suspect the additional complexity introduced to cope with bpc and planes etc, means it's not a completely obvious win. | 01:13.52 |
| ray_laptop | Robin_Watts: Yes it is (since copy_mono has to worry about doign the cmd_set_color in each band) | 01:14.16 |
| | Robin_Watts: so I think I will just rip out the plane_height == 0 stuff from the writer | 01:14.46 |
| Robin_Watts | The "if (plane_height > 0)" in the writer is probably a red herring and should be removed. | 01:15.10 |
| | Is there plane_height ==0 stuff? | 01:15.18 |
| ray_laptop | Robin_Watts: and maybe for the nonce, add a DEBUG mode statement if clist_copy_planes is ever called with plane_height == 0 | 01:15.52 |
| Robin_Watts | right. | 01:16.14 |
| ray_laptop | Robin_Watts: the check in clist_copy_planes for plane_height > 0 (and subsequent duplicate code for when 'code < 0' that sees to try a different way to subdivide rheight | 01:17.31 |
| | gxclrect.c line 1000 or so | 01:18.00 |
| | (my code may differ w.r.t. exact line #) | 01:18.50 |
| Robin_Watts | Yes, that's a really ugly duplication. | 01:21.14 |
| | Just after the copy: label, we check to see if the whole thing will fit into a cbuf, and split it if it won't. | 01:21.53 |
| ray_laptop | Robin_Watts: right, and do the recursive split to single lines if even one row doesn't fit | 01:22.40 |
| Robin_Watts | yes. | 01:22.51 |
| | Then after we copy the first plane and write the command header, we write the subsequent planes... | 01:23.12 |
| ray_laptop | Robin_Watts: BTW, the loop after reducing re.height was already there | 01:23.19 |
| | Robin_Watts: and I've already changed to use 'data_bits_size' instead of cbuf_size | 01:23.53 |
| | the loop was line 1039 (I just never made it down that far in looking at the code) | 01:24.39 |
| Robin_Watts | Ah, right, the original splitting is NOT about ensuring that the compressed command fits in a buffer, but rather to do with ensuring that the decompressed data fits into data_size. | 01:24.53 |
| ray_laptop | that loops keeps plodding along until we reach re.yend | 01:25.23 |
| Robin_Watts | The splitting *after* the compression calls is to do with splitting if the compressed data didn't fit. | 01:25.25 |
| | What a horrible mess. | 01:25.43 |
| | I do worry that that code isn't correct. | 01:26.25 |
| ray_laptop | Robin_Watts: so you think that the compression code will be LARGER than the uncompressed code ? | 01:26.55 |
| | s/compression/compressed/ | 01:27.14 |
| Robin_Watts | I hope not, but I guess we have to consider that it's possible. | 01:27.21 |
| | What happens if we write the 0th plane (and the command header) and that fills up a cbuf, and then we write the next few planes, and they fail. It's too late to back out then, isn't it? | 01:27.50 |
| ray_laptop | Robin_Watts: I'd rather just have a loop and revert to compression = 0 | 01:27.58 |
| Robin_Watts | ray_laptop: I think that may be best. | 01:28.11 |
| | essentially, I think, if we get to the point of writing the first one, we are committed. | 01:28.36 |
| ray_laptop | Robin_Watts: the size limit is the UNCOMPRESSED data_bits size -- not what's in the cbuf (compressed or not). | 01:29.13 |
| | The uncompressed size is what is passed by the clist reader to the device's copy_planes call | 01:29.45 |
| Robin_Watts | The size limit that we enforce by the first splitting block (just after "copy:") yes. | 01:29.53 |
| ray_laptop | since that data _has_ to be uncompressed | 01:30.02 |
| Robin_Watts | yes. | 01:30.10 |
| | My point is that once we get to the stage of agreeing that, and we start calling cmd_put_bits on each plane, we can never then decide to split the buffer further. | 01:30.51 |
| | Do you agree ? | 01:30.57 |
| ray_laptop | that's part of the confusion that existed between data_bits_size and cbuf_size. It can actually be LARGER in the cbuf and that doesn't hurt (thanks to cmd_read_data_ | 01:31.10 |
| | Robin_Watts: I agree | 01:31.25 |
| Robin_Watts | hmm. We ensure that the uncompressed data < data_bits_size. | 01:35.03 |
| ray_laptop | Robin_Watts: yes | 01:35.16 |
| | Robin_Watts: for ALL planes | 01:35.31 |
| Robin_Watts | and by ensuring that we need to ensure that the (possibly) compressed (singular) plane data < cbuf_size. | 01:35.56 |
| | for all planes. | 01:36.07 |
| | IF we assume that the compressed data is never larger than the uncompressed data, we're fine, as long as data_bits_size <= cbuf_size | 01:36.53 |
| ray_laptop | Robin_Watts: no, each plane can be in a separate cbuf (we top up after each plane) and if a plane exceeds what is remaining in the cbuf, we just read it from the stream (sgets in cmd_read_data) | 01:37.17 |
| Robin_Watts | right, but in the worst case, we might only be working with a single plane. | 01:37.34 |
| ray_laptop | Robin_Watts: still OK | 01:37.49 |
| | if the compressed data is > the uncompressed data, we just write it and read it anyway | 01:38.23 |
| Robin_Watts | oh, so a planes compressed data can span more than one cbuf? | 01:38.25 |
| | brilliant. | 01:38.29 |
| | In that case the latter splitting loop can just be thrown away. | 01:38.39 |
| | much nicer. | 01:38.43 |
| ray_laptop | Robin_Watts: yes. That's why we didn't need the top_up_cbuf check/call before reading the first plane's data | 01:39.13 |
| Robin_Watts | ok. | 01:39.20 |
| ray_laptop | Robin_Watts: the later splitting loop, yes. We still need the split line loop for when re.height ends up == 0 and, of course, the outer loop while ((re.y += re.height) < re.yend) | 01:40.47 |
| Robin_Watts | technically the first split thing isn't a loop, it's a recursion, but otherwise I completely agree. | 01:44.14 |
| ray_laptop | Robin_Watts: right. And thanks | 01:44.44 |
| Robin_Watts | you're welcome, and once again, thank you for sorting out my broken code! | 01:45.04 |
| | I'm off to bed now, but if you need me to look at anything, I'll check the logs in the morning. | 01:45.23 |
| ray_laptop | Robin_Watts: well, the only thing broken (other than the confusing bits) was that the check for calling cmd_write_buffer didn't take re.height into account | 01:46.24 |
| | AFAICT | 01:46.36 |
| Robin_Watts | tor8: Morning. | 10:38.10 |
| | The internet is broken. Going to reboot the router. | 10:38.58 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=1b4b5fdfa6b74827631d42efd2a61226125f036b | 10:43.51 |
| tor8 | Robin_Watts: right. lgtm. | 12:02.55 |
| Guest4977 | need help : 'make prefix=/usr/local install' => '/bin/sh: 1: cc: not found' 'make: *** [build/debug/base_context.o] Error 127' | 12:29.55 |
| tor8 | Guest4977: install a c compiler | 12:35.45 |
| | what's your system? | 12:36.06 |
| Guest4977 | kubuntu | 12:36.16 |
| tor8 | Guest4977: install the "build-essential" package or maybe it's build-essentials | 12:36.41 |
| Guest4977 | thanks | 12:37.12 |
| Robin_Watts | tor8: Thanks. | 13:06.51 |
| | tor8: I'm going to look into malc_'s problem now. | 13:07.01 |
| | I think malc_'s problem is just that he's passing in the wrong rectangle. | 14:05.18 |
| | So the clip isn't set right. | 14:05.38 |
| tor8 | Robin_Watts: right. that sounds more plausible. | 14:24.30 |
| henrys | is the android eclipse guy a customer? | 14:39.51 |
| Robin_Watts | henrys: I don't think so. | 14:54.22 |
| | tor8: Now I've confused myself with malc_'s code. | 14:56.13 |
| | http://boblycat.org/~malc/ttest.c | 14:56.18 |
| | We expect the rect passed into fz_run_display_list to be the bounding box in output space. | 14:57.02 |
| | i.e. for each node in the display list, we map node->rect through the ctm, and then compare that to the rect. | 14:57.20 |
| | and on that basis, rect seems plausible in malc_'s code. | 14:57.32 |
| henrys | Robin_Watts:so the poicy is to boot them off support - I like kens boilerplate he sent out showing folks to bugzilla and IRC maybe we should just send that out for these people. | 14:57.54 |
| Robin_Watts | henrys: OK, I pulled him onto support because I felt that someone other than me should have visibility of the conversation. | 14:58.56 |
| | and my plan was to either ascertain whether he was a customer (or a potential customer) and then redirect him elsewhere. | 14:59.27 |
| henrys | oh I see nvm then | 14:59.38 |
| Robin_Watts | but he seems to be incapable of answering questions, so... | 14:59.40 |
| alexcher | tor8: I've encountered a strange piece of code in setdevicenspace() function. Why it's possible to take dict_index_entry( ..., 0, ...) and expect a predictable result? | 15:22.16 |
| kens | Does it work ? | 15:25.32 |
| | Its been years since I looked at that code, but it seems to work OK for me. | 15:26.10 |
| Robin_Watts | Why is that an unreasonable thing to do? The 0th entry of a dictionary seems a reasonable thing to look for, right? I mean, we're computer scientists, we count from 0, right? | 15:30.13 |
| chrisl | Postscript very clearly states the the order of entries in a dictionary is indeterminate........ | 15:32.14 |
| | Oh, and IIRC, GS allows the key/value arrays to be sparse, so a dictionary containing N entries does not necessarily have entries at indices 0..N-1 | 15:34.42 |
| kens | Hmm, that's not even my code actually, I think its Michael's | 15:37.05 |
| | and it only seems to operate on COlorants dicitonaries, so I bet its not well tested | 15:37.21 |
| | Umm, maybe it is my code, in fact | 15:38.11 |
| | In any event, it won't do anythign without a Colorants dictioanry# | 15:38.24 |
| chrisl | I think all it needs is to check if the object returned is valid (not an empty index), and if it's not, keep trying until it finds an valid ref | 15:39.18 |
| kens | To be honest, I'm not sure it *matters* what order we read fomr the dictioanry, as long as if we read all the indices they return valid stuff | 15:39.36 |
| | All the code seems to be doing is setting each entry one after the other,so the order is irrelevant | 15:39.52 |
| chrisl | Yes, but it *might* matter if we push a null object onto he stack, then try to do something with it | 15:40.04 |
| kens | You can't get here like that | 15:40.13 |
| | You would have to have a 5 erlement dictionary operand to setcolorspace with a DerviceN space | 15:40.31 |
| | possibly you could have an invalid space like that, but I think its checked at a higher level | 15:40.49 |
| chrisl | But nothing guarantees that index 0 contains anything other than a null object, even if later indices do have valid objects | 15:41.16 |
| kens | Well, I can't state that for sure, like I said, I'm not certain its my code. | 15:41.41 |
| | But the answer to Alex's question is that you can't expect a 'predictable' result, and you don't care | 15:42.02 |
| | The order doesn't matter | 15:42.09 |
| Robin_Watts | make a dictionary, push something into it, then push the 5 real things into it, then delete the first entry. Does the dictionary have a valid 0th object then ? | 15:42.27 |
| kens | We conswtrcut that dictioanry ourselves in the PDF itnerpreter I believe | 15:42.50 |
| | SO I don't think you can do that | 15:42.57 |
| | Well, modulo trying to break it | 15:43.08 |
| henrys | how can you talk about a 0th object in a dictionary, it is unordered? | 15:43.11 |
| chrisl | Even if you push 5 entries into the new dictionary, it doesn't guarantee the 0th entry will have anything in it | 15:43.20 |
| kens | henrys PS dicts are always unordered | 15:43.27 |
| | chrisl if we make the dict ourselves in C we cna make gurantees | 15:43.46 |
| | I'm not saying it is guaranteed mind you, just that it 'might' be | 15:44.03 |
| henrys | kens:I thought all dictionaries were unordered without more qualification. | 15:44.17 |
| kens | henrys all PS dicts are unordered. The point is that in this case we don't care about the order | 15:44.38 |
| | We just want to enumerate all the objects | 15:44.46 |
| chrisl | Well, if you use the "standard" functions, I think* dictionary contents are written using a hash, so empty entries are likely to occur | 15:45.08 |
| henrys | kens:I'm agreeing with you, that is why I'm asking Robin why asking for the 0th object is valid. | 15:45.11 |
| kens | henrys why would it not be valid ? | 15:45.26 |
| chrisl | kens: we don't (normally) write dictionary entries in simple, ascending order | 15:46.16 |
| kens | chrisl we don't care about the order. Yes I agree its possible there might be empty slots, but that (might) be taken care of elsewhere | 15:46.46 |
| | That's a reason for concern certainly, but the order matters not | 15:47.02 |
| chrisl | But the 0th slot can be empty - yes, the order is unimportant | 15:47.18 |
| kens | chrisl you and I are agreeing | 15:47.28 |
| chrisl | Good ;-) | 15:47.38 |
| kens | I 'suspect' we check in the colour space stuff ro null objects and invalid objects, but I am not certain | 15:47.54 |
| | But Alex's question was why this would be predictable, to which the answer is 'its not, and it doesn't magtter' | 15:48.27 |
| chrisl | Yes, that's true | 15:48.43 |
| alexcher | PDF dictionaries can have extra keys. | 15:48.48 |
| henrys | it could be invalid if you changed the implementation of the dictionary, and the client shouldn't depend on that. | 15:49.38 |
| | dictionaries should be accessed by keys | 15:49.54 |
| | but probably not worth arguing about... | 15:50.14 |
| chrisl | henrys: then why do we have a function call that takes an index? | 15:50.21 |
| henrys | because it's ghostscript | 15:50.51 |
| chrisl | I would guess, at the least, it's used for the "forall" operator | 15:51.14 |
| kens | So we will never change the implementation, therefore we are fine :-) | 15:51.22 |
| alexcher | chrisl: there's a matching finction that returns an index. | 15:51.24 |
| chrisl | alexcher: yeh, that's my point: it's clearly part of the dictionary implementation design that they be accessible by index, as well as key | 15:52.22 |
| henrys | yes but you are exposing the underlying implementation, suppose I want to redo dictionaries with a linked list. | 15:52.46 |
| | ? | 15:52.47 |
| | anyway let's continue with the day | 15:53.19 |
| kens | Then I suspect Ghostscript will break | 15:53.19 |
| chrisl | henrys: you'd rewrite the indexing code, too | 15:53.20 |
| | henrys: if you can only access a dictionary by key, how do you interrogate arbitrary dictionaries for their contents? | 15:54.40 |
| henrys | chrisl:an enumerator? | 15:56.44 |
| Robin_Watts | And what is an index if not a form of an enumerator ? | 15:57.04 |
| henrys | an index to me implies "order" dictionaries are classically "unordered" so using an index doesn't make sense to me. | 15:59.11 |
| chrisl | I don't see an enumerator would make any fewer assumptions about the implementation than an index does....... | 15:59.21 |
| Robin_Watts | When you enumerate across a dictionary, you impose an order. | 15:59.31 |
| | index or enumerator are isomorphic representations. | 16:00.11 |
| alexcher | chrisl: The architectural details are not that important now. The question is who will fix this piece of code. Git attributes it to Tor. We have a SEGV there. | 16:00.15 |
| paulgardiner | But indices are not ideal enumerators for linked lists. | 16:00.50 |
| kens | I can probably take it if nobody else will | 16:00.54 |
| Robin_Watts | alexcher: Probably git attributes it to tor8 because of the whitespace patches. | 16:00.54 |
| chrisl | alexcher: well, common sense says it's not tor8's area....... | 16:00.59 |
| Robin_Watts | git blame -w ? | 16:01.13 |
| chrisl | was about to type that, tooo | 16:01.25 |
| kens | I think its eihter me or Michael, so assignit to me since its PS | 16:01.49 |
| Robin_Watts | No, tor8 loves ghostscript. and the C/PS handling of colorspace objects in particular. I'm sure he'd love to do it. | 16:01.54 |
| alexcher | It's Ken's from 2008. | 16:02.34 |
| chrisl | henrys: anyway, there are *so* many places in GS that rely on being able to enumerate dictionary contents via index, if you decided to rewrite the dictionary representation, we'd all have a *lot* of work to do! | 16:02.55 |
| henrys | okay you guys can access your dictionaries with indexes and arrays with keys and whatever other stuff you need to do, let's get on with the MuPDF meeting. | 16:02.55 |
| mvrhel_laptop | henrys: I am here for the meeting | 16:03.17 |
| | keeping quite about any PS color stuff.... | 16:03.32 |
| henrys | mvrhel_laptop: I thought you'd forget, first time and all. | 16:03.37 |
| Robin_Watts | I'd forgotten, and I have no excuse. | 16:04.03 |
| henrys | paulgardiner: adobe reader does not support oval, line and arrow? | 16:04.13 |
| paulgardiner | Not on Android... at least not that I've discovered | 16:04.40 |
| | Not to say that we shouldn't implement them. | 16:04.58 |
| henrys | let's add them to the list because that is what was pointed out to me in Chicago as a feature of the competitor. | 16:05.44 |
| alexcher | kens: let me take this bug because I have everything set up already. | 16:05.45 |
| kens | ale | 16:05.53 |
| | xcher, well if you want it, that's no problem | 16:06.02 |
| paulgardiner | henrys: sure. Shall I continue with the ones that Adobe Reader supports first, or would it be good to move onto oval, line, arrow sooner? | 16:06.45 |
| henrys | no just add them on. | 16:07.03 |
| paulgardiner | okay good | 16:07.12 |
| henrys | mvrhel_laptop: do you have your stuff in a public branch? | 16:07.52 |
| mvrhel_laptop | henrys: it is in my repos on casper now | 16:08.14 |
| | in a branch | 16:08.26 |
| | called winRT | 16:08.30 |
| Robin_Watts | http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=shortlog;h=refs/heads/windowRT | 16:08.38 |
| paulgardiner | I good address bug #693664. It would be very easy now, and I'd considered doing it before it got reported | 16:08.40 |
| mvrhel_laptop | oh windowRT. I should have added an s in there or just done win | 16:09.05 |
| henrys | I'm sort of wondering about the commonality of this stuff across devices. Does it make sense for paulgardiner to look at it and see what can gathered together as common code.? | 16:09.24 |
| Robin_Watts | mvrhel_laptop: We can easily fix that. | 16:09.26 |
| | mvrhel_laptop: How much of what you have done is windows specific ? | 16:09.53 |
| | have you had to change anything within mupdf itself? | 16:10.04 |
| paulgardiner | henrys: I sort of have that in mind already, but there does seem to be a fair amount that needs to be OS specific | 16:10.27 |
| mvrhel_laptop | Robin_Watts: 99.9% of what I have in there is windows only. the only mupdf change I had was the c++ ifdef in the header files | 16:10.29 |
| henrys | paulgardiner: reading the bug | 16:10.43 |
| mvrhel_laptop | and I may be able to get rid of that | 16:10.44 |
| | Robin_Watts: lets change the branch name when we are in miami | 16:11.26 |
| henrys | paulgardiner: I think that's a good thing to fix and historically we have gotten good feedback from that user, fixing it might get him more involved in the project. | 16:11.50 |
| Robin_Watts | mvrhel_laptop: OK. | 16:12.07 |
| paulgardiner | henrys: okay. I'll sort that out | 16:12.08 |
| | The hooks to do so are already there really. | 16:12.23 |
| henrys | paulgardiner: you're good on bugzilla right - have all the permissions set up? | 16:12.38 |
| paulgardiner | Yes thanks | 16:12.51 |
| | At least I haven't run into any problems for ages | 16:13.13 |
| henrys | I don't think my iOS port agenda topic is going to be popular ... | 16:13.46 |
| | mvrhel_laptop: which competing apps are you looking at on windows mobile? | 16:14.43 |
| | there is a native solution for pdf right? | 16:14.58 |
| mvrhel_laptop | henrys: I was just looking at the one that comes with windows. yes the native one. | 16:15.07 |
| | I need to take a look at it again. | 16:15.18 |
| henrys | mvrhel_laptop: If you see anything that seems like a good feature please bring it up. | 16:15.44 |
| mvrhel_laptop | ok will do. henrys, I will bring the microsoft surface with me to the meeting | 16:16.05 |
| henrys | oh cool | 16:16.14 |
| | I haven't seen one live yet. | 16:16.25 |
| | paulgardiner: go ahead and assign that bug to yourself might as well have the complete experience ;-) | 16:17.19 |
| tor8 | henrys: please don't mention iOS ;) | 16:17.30 |
| mvrhel_laptop | the nexus devices are nicer | 16:17.31 |
| Robin_Watts | henrys: Is it worth more than one of us getting set up to develop for windows 8? | 16:17.45 |
| henrys | tor8:I knew that would get you out of lurking mode. | 16:17.52 |
| tor8 | henrys: :) | 16:18.07 |
| | careful, it might get me into raging mode... | 16:18.18 |
| henrys | IMHO paulgardiner should get set up on windows8 too and assist/review mvrhel_laptop | 16:19.51 |
| mvrhel_laptop | ok. but let me get the code into a non-embarrassing form before to many people poke at it | 16:20.51 |
| Robin_Watts | That would require us to get another copy of VS2012. mvrhel has a good way of getting them, right? Is it feasible for you to get a copy to bring with you to the staff meeting? | 16:20.59 |
| henrys | I think it is difficult to review (which you guys require) without being able to run/build the code. | 16:21.03 |
| paulgardiner | Sure. I have no device, but probably there are emulators? | 16:21.08 |
| mvrhel_laptop | the emulator is good in VS2012 | 16:21.25 |
| Robin_Watts | paulgardiner: You will need a Windows 8 installation. | 16:21.27 |
| paulgardiner | Eek! | 16:21.39 |
| henrys | in fairness to iOS the emulator is pretty good from what I can tell. | 16:21.49 |
| Robin_Watts | mvrhel_laptop: Can you use the emulator without breaking virtualisation ? | 16:21.49 |
| mvrhel_laptop | Robin_Watts: I can get another copy, but probably not before the staff meeting | 16:21.54 |
| Robin_Watts | henrys: other than it not running ARM code, sure. | 16:21.59 |
| mvrhel_laptop | Robin_Watts: yes, for the surface device, but not the phone | 16:22.22 |
| paulgardiner | Windows 8 under VMWare be okay? | 16:22.23 |
| henrys | have we really had that many issues where ARM code matters? | 16:22.31 |
| mvrhel_laptop | if you install the phone emulator, it installs hyper-v which will break vmware. you have to do some special set-ups to get vmware working again | 16:23.01 |
| Robin_Watts | henrys: Well, only if you want to actually test what you're running on the device. Testing code that runs on a completely different architecture is less than optimal. | 16:23.06 |
| | x86 is much faster at FP for example. | 16:23.13 |
| henrys | paulgardiner: also feel free to buy a device | 16:23.24 |
| mvrhel_laptop | I have also compiled the ARM code in VS2012 and ran that on the surface without any issues | 16:23.31 |
| paulgardiner | henrys: oh right. That would solve that one if needs be. | 16:23.51 |
| Robin_Watts | paulgardiner: When I used the preview windows 8 and MSVC 2012 preview it was under VMware and it was fine (but I didn't install the emulators) | 16:24.37 |
| henrys | paulgardiner: I assume you've don'e expense reports to miles. It's just a regular expense entry. | 16:24.40 |
| Robin_Watts | paulgardiner probably invoices expenses in a different way; just as another invoice. He, like me, has a company. | 16:25.21 |
| mvrhel_laptop | Robin_Watts: let me put in a request with another friend for the VS2012. He might get it this week. | 16:25.34 |
| paulgardiner | henrys: had no expenses to date, but I'm sure that'll be fine. | 16:25.38 |
| Robin_Watts | mvrhel_laptop: Fab. | 16:25.50 |
| henrys | I'm sure Robin_Watts can give you a form to use. | 16:26.22 |
| | paulgardiner: but how did you charge your trip? | 16:27.04 |
| paulgardiner | You mean the Miami flight? Haven't sorted that out yet | 16:27.40 |
| henrys | anyway best to keep meeting around 1/2 hour any other items? mvrhel_laptop? | 16:27.48 |
| mvrhel_laptop | no items from me. I am hoping to have search in place this week in the windows app | 16:28.26 |
| paulgardiner | I mean haven't sorted out the expense claim. The flight is booked of course :-) | 16:28.30 |
| henrys | paulgardiner: right let me email you an expense sheet you just fill it out and send it to Joanne, I think Robin_Watts' setup might be different. | 16:29.21 |
| paulgardiner | henrys: great. thanks | 16:29.35 |
| henrys | Robin_Watts: there are some rumors that apples may have arms soon - a strange sentence. | 16:30.33 |
| kens | armed fruit ? Only in hte US.... | 16:30.48 |
| Robin_Watts | The "Apple to buy ARM" thing has been around a while. | 16:30.58 |
| | I can't see it happening (famous last words) | 16:31.07 |
| henrys | yes but I'm talking about ARMs on laptops | 16:31.26 |
| Robin_Watts | oh, right. | 16:31.37 |
| henrys | kens:GMO | 16:31.58 |
| | trying to get the agenda out today, you guys do too much work, it takes forever to go through all this. | 16:42.39 |
| kens | :) | 16:43.09 |
| | I blame Paul RObin and Tor | 16:43.21 |
| henrys | well impenetrable ghostscript takes a longer time per change. I think that is a factor. | 16:44.43 |
| marcosw | henrys: is there an irc meeting today? | 16:45.27 |
| henrys | marcosw: yes I thought we'd cancel next week. | 16:45.49 |
| | instead of this week. | 16:46.09 |
| kens | Sounds good to me | 16:46.15 |
| marcosw | henrys: I'm going to be a bit late, I have to run now and will be back online at 9:15ish | 16:46.45 |
| henrys | okay | 16:47.01 |
| | wow ray_laptop nice to see smask gone. | 16:56.59 |
| mvrhel_laptop | yes. that is nice. | 16:57.11 |
| | what time does everyone get into miami? | 16:57.21 |
| ray_laptop | henrys: sure is. | 16:57.36 |
| kens | one moment I'll check | 16:57.38 |
| | 17:40 for us | 16:57.51 |
| ray_laptop | I get into MIA late (10:30pm EST) | 16:58.02 |
| mvrhel_laptop | ok I get in at 8:15 pm | 16:58.11 |
| henrys | early 4:50 pm | 16:59.08 |
| alexcher | 19:15 | 17:00.23 |
| henrys | meeting time - be prepared to discuss projects and bugs from last meeting next week. It seems like everything is moving along okay. | 17:00.48 |
| Robin_Watts | is picking up a car, so although we land at 17:40, by the time we've cleared immigration/collected luggage/car etc, it'll be 7 by the time we leave the airport I reckon. | 17:01.07 |
| henrys | chrisl:you said something about looking into font cache stuff and I didm' see any followup on that one. | 17:01.15 |
| chrisl | henrys: I haven't even started that - been busy with other stuff | 17:01.39 |
| henrys | okay | 17:01.50 |
| chrisl | I think we can do better than we currently do with the glyph cache, but it needs a chunk of uninterrupted time to study it | 17:02.28 |
| henrys | I am about 3/4 done with the agenda and it seems like very good progress as usual. (from the quarterly viewpoint) | 17:03.23 |
| chrisl | There have been no dissenting voices about the devices directory reorg, so I'm going to commit the change - unless someone shouts now | 17:04.40 |
| Robin_Watts | chrisl: wherefore contrib? | 17:05.01 |
| henrys | chrisl:I hurriedly checked something in so I wouldn't have to reorganize ;-) | 17:05.07 |
| chrisl | Robin_Watts: I've kept it separate from "devices" - no one shouted loudly enough (yet) to change my mind! | 17:05.41 |
| Robin_Watts | ok. | 17:05.50 |
| chrisl | henrys: luckily, git mostly "just works" with that kind of thing.... "only" the makefiles to fiddle | 17:06.34 |
| henrys | I think it will be a very nice change - I know it is a minor thing but just not having to look at that endless list of files in one directory ... | 17:07.06 |
| chrisl | Robin_Watts: that's kind of why I brought it up now - if people feel strongly about contrib, I won't be totally intransigent | 17:07.32 |
| Robin_Watts | Given that contrib is purely devices, my personal preference (a weak one) would be to have it in devices/contrib. | 17:08.26 |
| ray_laptop | chrisl: no, it seems most others were fine with leaving it orphaned at the upper level instead of with the rest of the device drivers ;-) | 17:08.27 |
| | chrisl: so, I won't push it. OK with me to commit as is | 17:08.49 |
| chrisl | Well, like I said in the e-mail, I feel having it stay where it is serves to reinforce that they are *not* our devices | 17:09.31 |
| ray_laptop | do we have to do anything with the VS projects | 17:10.06 |
| chrisl | ray_laptop: I've redone those, so the paths are correct | 17:10.24 |
| ray_laptop | chrisl: great! Thanks for thinking of it before I did (but I tend to just use ctags -R with gvim to navigate the sources) | 17:11.20 |
| | but I think others tend to do more with the VS debugger | 17:12.03 |
| Robin_Watts | The other idea which was mentioned on here, but not via emails was to flatten the structure a bit, so that GS/PCL/XPS etc all lived at the same level. | 17:12.36 |
| | chrisl indicated that that would make the gs commercial release harder to do. | 17:12.59 |
| chrisl | It would also be a *big* project to do "right" | 17:13.24 |
| henrys | chrisl:so git will do the right thing if somebody has committed a local change to say a device file that has moved? | 17:13.38 |
| Robin_Watts | Intrinsicly it would seem nicer to me to have the graphics lib separate from the individual languages, but not so much nicer that it's worth making chrisl's life hell. | 17:14.17 |
| chrisl | henrys: yes - so like kens's recent pdfwrite commits just pulled straight into my reorganised repo with no interventions from me | 17:14.22 |
| Robin_Watts | henrys: Yes. If you're going downhill, with a following wind, on a clear day. | 17:14.32 |
| henrys | ;-) | 17:14.48 |
| | hi marcosw:anything for the meeting? | 17:15.45 |
| chrisl | Robin_Watts: the big thing is the builds - IMHO, the "right" way to do it would be to properly incorporate the PCL/XPS(/SVG) builds into the Ghostscript build system - that would (I think) be quite a bit of work | 17:16.03 |
| marcosw | henrys: no, I don't think so. | 17:16.13 |
| henrys | marcosw:I looked at other's projects in advance of the meeting but I don't know what is going on with ECCN. | 17:16.39 |
| Robin_Watts | chrisl: Surely the right way to do it would be to split the library build out from the PS build? | 17:17.06 |
| chrisl | Robin_Watts: yes, that would be part of it, too...... | 17:17.29 |
| marcosw | henrys: me neither, I think I was probably supposed to do something. I'll check the email thread. | 17:17.44 |
| Robin_Watts | That way we'd have all the languages depending on a common lib build, rather than all rebuilding the same files. | 17:18.01 |
| henrys | chrisl:I don't know I've always imagined PCL and friends to be hooked up to a gs library. | 17:18.01 |
| ray_laptop | well, if bmpcmp can be trusted, the pdf transparency clist optimization is ready to go. It does concern me a bit that I had 25 differences from the regression run (all psdcmyk) and bmpcmp reports all with no differences | 17:18.16 |
| | Robin_Watts: mvrhel_laptop: any idea what might be specific to psdcmyk that could cause this ? | 17:19.06 |
| chrisl | henrys: but we don't build a gs "library" for the PCL/XPS builds | 17:19.06 |
| Robin_Watts | ray_laptop: Hmm. I'd be tempted to run at least one of those files manually on peeves. | 17:19.57 |
| mvrhel_laptop | ray_laptop: no idea off the top of my head. a valgrind check might be worthwhile | 17:19.57 |
| henrys | chrisl:well we could, that was my point. | 17:20.09 |
| ray_laptop | Robin_Watts: I was hoping to be able to avoid that ;-) (but I was thinking that I might have to resort to that) | 17:20.43 |
| chrisl | henrys: I had thought the the graphics library, and each interpreter would be built into a static library each, and then linked into exe with some "simple" top-level code | 17:21.14 |
| Robin_Watts | chrisl: yes. Sounds much nicer to me. | 17:21.34 |
| ray_laptop | the really strange thing is that the bulk of the changes are for transparency, several .PS CET files showed up with diffs (but also not with bmpcmp) | 17:22.05 |
| chrisl | My hope would be that would also make things like a functional language_switch easier to achieve | 17:22.09 |
| | Robin_Watts: ^^ | 17:22.20 |
| henrys | chrisl:yes that would be even better but it sounds ambitious. Having PCL, XPS etc just use the current ghostscript library would be a fairly easy change. | 17:22.26 |
| chrisl | henrys: on Unix, we don't normally build a gs library | 17:23.06 |
| henrys | chrisl:it's there are and it works right? | 17:23.32 |
| | the .so target? | 17:23.40 |
| chrisl | Yes, but that's a complete PITA to test and debug with | 17:23.56 |
| henrys | I do like your idea I just don't know if you can afford the pharmaceuticals associated with that project ;-) | 17:25.00 |
| | anyway I shall return to the agenda but be around for quite some time. Look forward to seeing you guys in Miami! | 17:25.49 |
| kens | Yes, see you all then, I need to go cook now | 17:26.07 |
| | Goodnight all | 17:26.16 |
| chrisl | henrys: if you add Robin_Watts suggestion about flattening the directory structure to the agenda, we can discuss the build implications in person - might be a little easier | 17:26.37 |
| henrys | will do. | 17:26.52 |
| Robin_Watts | henrys: I wasn't suggesting we use a sharedlib. | 17:27.35 |
| henrys | I already have gs directory restructuring on the agenda so that should trigger our memory well enough. | 17:27.42 |
| Robin_Watts | just a static one. | 17:27.44 |
| | but most importantly the job would be to get it so that it was a separate build step. | 17:28.09 |
| chrisl | Robin_Watts: that's the thing: at the moment, we don't have a static library build, except I think you added one for PCL? | 17:28.35 |
| Robin_Watts | Yes, but that was at the PCL lib level. | 17:28.56 |
| chrisl | Yeh, but nowhere else do we make a static lib | 17:29.21 |
| Robin_Watts | you may be right. | 17:29.49 |
| ray_laptop | chrisl: there is (or was) an msvclib make option | 17:30.34 |
| | that actually builds a static lib -- probably bit rotted, if it's even still there | 17:31.10 |
| chrisl | There have been a couple of a issues with command line length limits which are essentially unsolvable with the current approach, which would be solved by building components into static libs and then linking the appropriate combinations for executables | 17:31.25 |
| henrys | chrisl:so you envisions something like the the third party font scaler that has builds a lib for each subsystem. | 17:31.27 |
| chrisl | henrys: *eventually*, yes | 17:31.44 |
| henrys | the font scaler that shall not be named. | 17:31.46 |
| | makes sense | 17:32.23 |
| ray_laptop | henrys: oh, we aren't supposed to mention it by name here ? | 17:32.29 |
| henrys | prefer to be under their radar yes. | 17:33.01 |
| chrisl | henrys: as you said, my constitution may not handle doing everything all once....... | 17:33.38 |
| alexcher | Should we split bugs 693658 and 693659 into individual cases? I cannot reproduce 3/4 ot the reported problems. What was the command line used by the customer? | 17:37.44 |
| Robin_Watts | alexcher: My approach to the mupdf set of bugs was to run through them, attempting to confirm them. If I could confirm them, and easily fix it, I did so. If not, I spun out a bug. | 17:39.43 |
| chrisl | alexcher: given the nature of the problems, it probably needs the same code they tested with (as well as the command line, system type etc) to reproduce them reliably | 17:40.00 |
| | Do we know what Ghostscript version they tested? | 17:40.20 |
| Robin_Watts | alexcher: They told us the SHA they used, didn't they? | 17:40.21 |
| chrisl | It's not mentioned in the bug..... | 17:40.56 |
| Robin_Watts | 591a6e95b11f07611f612a691c7e06e169c1fe93. | 17:41.06 |
| henrys | I have it on the agenda but IMO it should be assigned back to marcos for divvying up. | 17:41.11 |
| | should I just go ahead and do that. | 17:41.24 |
| Robin_Watts | It was in their support mail of 21 Feb. | 17:41.28 |
| alexcher | What's SHA? | 17:41.29 |
| Robin_Watts | the git hash | 17:41.35 |
| chrisl | Robin_Watts: could you add that to the bug, please? | 17:41.55 |
| henrys | I just sent it back to Marcos | 17:43.11 |
| Robin_Watts | chrisl: done. | 17:44.04 |
| chrisl | Thanks - I don't see a command line mentioned either (my mail archive is pretty chaotic!) | 17:44.52 |
| Robin_Watts | yeah, I've been digging, and I can't see a command line either :( | 17:47.30 |
| | Let me mail them back and ask. | 17:47.46 |
| chrisl | Well, that's a irresistible deal: "Upgrade the whole trip to Premium Economy for GBP 1,895.00 extra per person" - er, thanks, but no thanks! | 17:49.40 |
| Robin_Watts | chrisl: Did they just ring you too? They called me and said "oh, my computer has just crashed..." | 17:51.20 |
| | Apparently the flight is "medium full", so we may get lucky and have some spare seats. | 17:51.53 |
| chrisl | Robin_Watts: no, I looked up the web site, on the off chance of getting a reasonable upgrade price..... | 17:52.06 |
| | Oh, I wonder if that was the phone call on my mobile I missed earlier | 17:53.20 |
| Robin_Watts | seat map makes it look chocka. | 17:53.34 |
| chrisl | Oh, great :-( | 17:53.53 |
| Robin_Watts | but they don't release some seats until the day, and all the extra legroom ones are always greyed out etc. | 17:56.19 |
| | malc_: ping | 17:57.17 |
| | malc_: I did some tests here, and we ARE culling text as we'd expect to be doing. | 17:58.05 |
| | so I looked at your test code and got very confused. http://boblycat.org/~malc/ttest.c | 17:58.28 |
| | Am I to assume that you were doing: ttest 256 and ttest 4096 and seeing more or less the same timings ? | 17:59.13 |
| mvrhel_laptop | bbiab | 18:02.44 |
| ray_laptop | well -- found a real bug that would cause indeterminate results. The problem is with sumatra/x_-_integer_overflow_in_fz_newpixmap.pdf. On a halftoned device we use image_render_mono_ht which uses the "color_cache", but only the first two elements have been filled in | 19:00.55 |
| | the values returned from the FlateDecode are outside the range 0..1 (0x41) | 19:04.02 |
| Robin_Watts | ray_laptop: Coo. | 19:06.20 |
| ray_laptop | Robin_Watts: not really. Looks really UGLY. I wonder if mvrhel_laptop knew something when he suggested valgrind ? | 19:09.44 |
| | The image_init_color_cache is using the index table data without clamping to 'hival' number of entries, then the color_cache is also used directly | 19:13.44 |
| | with no regard for out-of-range data (above hival) | 19:14.06 |
| Robin_Watts | just that valgrind is good for spotting indeterminisms. | 19:19.30 |
| ray_laptop | the spec calls for "if it is outside the range 0 to hival, it is adjusted to the nearest value within that range." | 19:19.31 |
| Robin_Watts | so can you add a clamping phase? | 19:19.42 |
| ray_laptop | Robin_Watts: rather than check on each pixel lookup, I think I'll just fill the cache with the correct value when it is initialized | 19:20.29 |
| Robin_Watts | has a gs stroking bug that involves undoing a previous fix :( | 19:20.35 |
| | ray_laptop: Right. | 19:20.38 |
| mvrhel_laptop | ray_laptop: great. glad you were able to track down the issue | 19:40.14 |
| ray_laptop | tempted to push the commit without a prior regression, but I always get burned doing that :-( | 19:57.21 |
| | I'm surprised we hadn't seen that more often, but I guess data outside the 'hival' range of an indexed colorspace is rare enough | 19:58.17 |
| Robin_Watts | Does that fix resolve all 25 of the differences ? | 19:58.22 |
| ray_laptop | Robin_Watts: first I am making the change to the master, since it is really unrelated to my other changes, then I'll apply it to my branch, and test that, so I'll let you know after a couple of regression runs. | 19:59.31 |
| Robin_Watts | ray_laptop: Perfect. | 19:59.41 |
| ray_laptop | darn, I forgot to do update of my master from origin before the run, so I may pick up some false diffs :-( | 20:02.04 |
| | what is it ? gitpush.sh abort ??? | 20:02.17 |
| Robin_Watts | yup. | 20:03.00 |
| | Then wait 1 minute before resubmitting a job (or until the dashboard shows it's aborted) | 20:03.36 |
| ray_laptop | oops. I just restarted | 20:04.13 |
| Robin_Watts | The dashboard shows it's OK, I think. | 20:04.43 |
| ray_laptop | looks like I squeaked by because all the servers got the Abort | 20:04.50 |
| Robin_Watts | The cluster checks for new jobs (which includes aborts) once a minute. | 20:05.13 |
| | so if you abort and reschedule, quickly the cluster can miss the abort. | 20:05.27 |
| | (hmm, extra comma in that sentence) | 20:05.41 |
| ray_laptop | bbiaw (after the 'master' run finishes), then I'll start my pdf14_clist_optimize run THEN push the master (so the run I'm most interested in gets started first) | 20:08.03 |
| Robin_Watts | ray_laptop: Right, but if you do that, the cluster won't have updated it's idea of what is "right". | 20:09.26 |
| | Better to let the cluster run the new master (so any indetermisms are gone from master), then when you run your pdf14_clist_optimise run, it'll be checked against the new correct thing. | 20:10.27 |
| ray_laptop | I _REALLY_ want to get this off my plate ! | 20:11.21 |
| | Robin_Watts: true, but the 'differences from previous clusterpush' will tell me, right ? | 20:12.14 |
| Robin_Watts | yes. Unless you need to run more than one job, in which case you'll wish you'd just done it the easy way in the first place :) | 20:12.57 |
| ray_laptop | I'm surprised that the problem file didn't show up indeterminate more often -- pbmraw is always run | 20:15.07 |
| Robin_Watts | Was the array on the stack ? | 20:15.38 |
| ray_laptop | Robin_Watts: no, it's allocated by PostScript | 20:16.06 |
| Robin_Watts | Given that Miles and Scott are doing AndDevCon in Boston in May (28-31st), I wonder if that's where our next staff meeting will be. | 20:17.29 |
| | Early june is abour right, yes? | 20:17.41 |
| ray_laptop | Oh, that's the one that mvrhel_laptop said he wasn't going to. | 20:18.52 |
| Robin_Watts | the show? or the staff meeting? | 20:19.16 |
| ray_laptop | They have his email wrong vhrel instead of vrhel | 20:19.33 |
| | the conference | 20:19.46 |
| Robin_Watts | Right. I keep getting messages from them too. | 20:19.59 |
| ray_laptop | "save $500" | 20:20.11 |
| Robin_Watts | yeah. | 20:20.16 |
| ray_laptop | about time to upgrade peeves to an i_3770. I wonder what speed alex_i3770 is ? | 20:21.25 |
| | that one, meters and inches are always the fastest | 20:21.59 |
| Robin_Watts | http://ark.intel.com/products/65719/ ? | 20:23.40 |
| Robin_Watts | will delay his cluster test til later. | 20:29.16 |
| alexcher | ray_laptop: it's standard i3770 with a separate disk for regression. | 20:32.02 |
| ray_laptop | alexcher: separate disk ? | 20:40.14 |
| | alexcher: sata HD or SSD ? | 20:40.35 |
| | guess I'll have a look at the differences with bmpcmp :-( at least the problem file showed up as a diff :-) | 20:42.34 |
| Robin_Watts | sorry ray, I was sure I aborted my job. | 20:49.49 |
| | Will I get in your way if I run a test now ? (after your bmpcmp ?) | 20:50.34 |
| ray_laptop | Robin_Watts: you were already running one | 20:51.20 |
| Robin_Watts | yes, the one that I thought I'd aborted. | 20:51.31 |
| | I've killed it now, so your bmpcmp can run. | 20:51.38 |
| | If I reschedule one after that will it be in your way. | 20:51.47 |
| | ? | 20:51.55 |
| ray_laptop | Robin_Watts: no, go ahead and run it. I am going to have lunch anyway | 20:51.58 |
| alexcher | ray_laptop: HDD 1gb | 20:52.07 |
| Robin_Watts | Thanks. | 20:52.09 |
| alexcher | ray_laptop: HDD 1TB | 20:53.08 |
| ray_laptop | I went ahead and queued up my pdf14_clist_optimize run also | 20:54.07 |
| | after I saw that yours was queued, Robin_Watts :-) | 20:55.04 |
| | such a small set of files for bmpcmp that "meters" finished them all before most other machines finished compiling | 20:56.13 |
| | and 'inches' is still building :-( | 20:56.32 |
| henrys | oh the time changes while we are in Miiami | 20:58.35 |
| ray_laptop | not good. tests_private/comparefiles/104-01.ps shows up with a cyan background with plank :-( | 21:08.21 |
| | wonder what that's about ? | 21:08.30 |
| | Robin_Watts: the mem_planar_fill_rectangle_hl_color is loading the color for the fill_rectangle color from pdcolor->colors.devn.values[], but the pdcolor->type is gx_dc_type_data_ht_binary | 21:33.44 |
| henrys | Robin_Watts: could you forward the agenda to paul I don't think he is on the "staff" mailing list. | 21:34.02 |
| | or I guess I'll just do it. nvm | 21:34.16 |
| ray_laptop | Robin_Watts: so it's picking up the address of the b_ht structure as a color. This AIN'T right. Is this yours or mvrhel_laptop's | 21:36.27 |
| | mvrhel_laptop: what do you think. BTW, I see it with -sDEVICE=plank and comparefiles/104-01.ps | 21:39.57 |
| | YAIC (Yet Another Indeterminate Case) -- depends on the address of stuff in memory :-( | 21:41.41 |
| | at this rate, I'm not making any progress on putting in bugs -- just finding ones already there :-( | 21:42.23 |
| gandaro | mupdf-v8.exe is probably the version that supports JavaScript? | 22:53.36 |
| | I have translated the MuPDF main page already, when you have time (and I have surveyed it once again), I will send it to you | 23:25.25 |
| | or translate the rest of the page | 23:25.44 |
| | but it's late, I have to go to bed, ;) | 23:25.58 |
| ray_laptop | I went ahead an pushed my fix for image_init_color_cache since it was obviously wrong and the file I found it with is fixed. I may just open a bug for 104-01.ps | 23:46.40 |
| | unless I can find a quick fix. It is also quite broken, but rare in the real world -- not many people use the 'erasepage' feature to paint other than white | 23:47.41 |
| | Forward 1 day (to 2013/03/06)>>> | |
IRC Logs