| | <<<Back 1 day (to 2012/10/24) | 2012/10/25 |
| kens | Hmm I see we have an angstroms on teh cluster now | 11:46.46 |
| kens | wonders how to politely tell a cistomer they are using their own code incorrectly.... | 12:01.16 |
| Robin_Watts | kens: "I vouchsafe, that you sir, are a fuckwit!" works for me. | 12:53.19 |
| kens | I did say 'politely' :-) | 12:53.42 |
| | But its sorely tempting.... | 12:53.51 |
| paulgardiner | tor8, Robin_Watts: those commits we discussed yesterday (or the day before maybe) are updated on paulg/master | 14:07.30 |
| Robin_Watts | paulgardiner: Yeah. I'll get to them after I finish staring at this interpolation thing. | 14:07.52 |
| paulgardiner | great ta | 14:08.05 |
| tor8 | paulgardiner: typo in mucbz.c (you set run_page_contents twice) | 15:13.26 |
| paulgardiner | Oh ok. Anything else, or are you still looking? | 15:14.18 |
| tor8 | still looking. not found anything odd yet. | 15:14.33 |
| | well, there is the question of why we have the _shim functions in pdf_xref_aux ... I remember removing them in the other files. | 15:15.15 |
| | can you remember why I kept them there? | 15:15.24 |
| Robin_Watts | you removed them in favour of casting through void * ? | 15:15.52 |
| tor8 | Robin_Watts: correct | 15:16.36 |
| | I am a bit annoyed at the proliferation of pdf_run_* functions ... anyway to reduce the number? I'm sure half of them are probably unused... | 15:17.29 |
| paulgardiner | Some are static | 15:18.14 |
| tor8 | pdf_run_page seems pointless after that patch though | 15:19.36 |
| paulgardiner | Of the global ones, we definitely need fz_run_annot and fz_run_page_contents, and if we are to avoid changing loads of existing code, fz_run_page, but besides that... | 15:19.44 |
| tor8 | I know the ios app still calls it, but that should be fixed to call fz_run_page instead | 15:19.58 |
| | there are only two or three places that need fixing if we remove fz_run_page (or replace with what you call fz_run_page_contents) | 15:20.51 |
| paulgardiner | pdf_run_page... possibly. I suspected it was much used, but I didn't check. Yeah, I suppose few things go other than trhough fz | 15:21.01 |
| | fz_run_page is good for people that don't care about partial updates. | 15:21.49 |
| | If we take fz_run_page out then people will need to enumerate the annotations when rendering even if they don't want forms support. | 15:28.36 |
| tor8 | paulgardiner: all things *ought* to go through fz, I can change those that don't easily enough | 15:34.48 |
| | paulgardiner: yeah, as it is it's a nice convenience function | 15:35.23 |
| paulgardiner | Yes. I could take pdf_run_page out, although I'm not set up to quickly test the iOS build, so might be quicker for someone else as a follow up. | 15:36.34 |
| tor8 | paulgardiner: I'll do the follow up, don't worry | 15:36.53 |
| paulgardiner | Great thanks. I'' get rid of the typo though. Anything else? | 15:38.18 |
| tor8 | not at a glance, no, that's all | 15:42.59 |
| paulgardiner | Just fixing a typo and an unused var that the cluster showed up | 15:44.12 |
| | There, pushed to paulg. There are also a couple of commits on my partial_update branch that are ready to go, if you have time. | 15:48.28 |
| alexcher | mvrhel: Take a look at the bug 693398. Git bisect took me to your branch, but it doesn't build for me. | 15:51.08 |
| mvrhel | my branch? | 16:01.36 |
| | kens: did you have time to chat today? | 16:01.53 |
| kens | mvrhel, am afraid not. I'm about to go out for my daughter's riding lesson | 16:02.10 |
| | I will beback later and will try to catch up with you then | 16:02.22 |
| mvrhel | ok sounds good | 16:02.26 |
| kens | Otherwise it'll have to be tomorrow, I have more time then | 16:02.47 |
| | ANyway, goodnight all | 16:03.26 |
| alexcher | mvrhel: It's a branch where most commits are yours. | 16:11.46 |
| mvrhel | looks like the icc branch which is over 2 years ago | 16:12.24 |
| | I will see if I can get the crash to occur here | 16:13.04 |
| | I don't think the commit history is going to help with this issue | 16:14.21 |
| alexcher | mvrhel: what else is left? My main question is how did you compile this branch? | 16:18.24 |
| mvrhel | huh | 16:18.36 |
| | I am not going to go back to some branch from 4 years ago | 16:18.48 |
| | or 2 years aog | 16:18.56 |
| | ago | 16:18.58 |
| alexcher | mvrhel: OK | 16:19.12 |
| mvrhel | alexcher. what is left is to debug the current build as it fails | 16:19.42 |
| | with the file | 16:19.45 |
| | do you need me to do that or are you doing that? | 16:20.11 |
| | alexcher: I had thought that was what you were asking. sorry | 16:20.50 |
| alexcher | mvrhel: I'll try. | 16:20.57 |
| mvrhel | ok thanks | 16:21.01 |
| henrys | I just started following these prediction markets and I see an arbitrage opportunity, intrade vs. betfair, bet obama on intrade and romney on betfair. Strange there would be such a spread, but the numbers would guaranteed 5% on your money election day ... I must not understand something about these markets, that shouldn't happen. | 16:40.37 |
| miha | henrys: http://www.youtube.com/watch?v=yTCRwi71_ns | 16:43.38 |
| miha | eurotrash | 16:48.37 |
| Robin_Watts | gets Netgear ReadyNAS working. Nice piece of kit. Up to 4 drives, raided together for data protection (I have 2 currently). | 17:20.24 |
| | I can add new drives (as long as they are always at least as large as the current ones), and it'll automatically update everything so I get the extra capacity. | 17:21.18 |
| sebras | Robin_Watts: SW raid or HW raid? | 17:27.56 |
| Robin_Watts | sebras: No idea, but I don't think it matters in this instance :) | 17:28.26 |
| sebras | Robin_Watts: it's just that hw raid tends to require disks of the same size, and sw raid might have lower throughput. | 17:29.09 |
| | at least that is what I'm seeing on my desktop. | 17:29.24 |
| Robin_Watts | sebras: it does NOT require discs of the same size. | 17:29.26 |
| | and it's a NAS, so speed isn't the critical factor. | 17:29.36 |
| sebras | Robin_Watts: ok, good point. | 17:29.44 |
| Robin_Watts | Does DLNA, rsync, http, https, SMB, NFS etc. | 17:29.59 |
| | and I can configure it to backup where it will suck data across the network from shares on my other machines, I think. | 17:30.23 |
| | and most importantly, it was dead easy to setup :) | 17:33.56 |
| | mvrhel: ping? | 18:12.23 |
| mvrhel | Robin_Watts: pont | 18:12.49 |
| | pong... | 18:12.51 |
| Robin_Watts | Can I get you to decipher some code for me please? | 18:13.38 |
| | in gxiscale.c... | 18:13.45 |
| | initial_decode | 18:13.56 |
| | h == 1 | 18:14.11 |
| | sizeofPixelIn == 1 | 18:14.25 |
| | pcs->type->index == gs_color_space_indexed_Indexed | 18:14.38 |
| mvrhel | can you give me a line number please | 18:14.49 |
| Robin_Watts | not easily :( | 18:14.59 |
| | Search for: | 18:15.02 |
| | "indexed 8 bit color values, possibly a device indep. or" | 18:15.12 |
| | My file is heavily modified (but not in this area) hence line numbers will be way off. | 18:15.39 |
| mvrhel | ok I am at the comment | 18:16.03 |
| Robin_Watts | I reckon I've got 1 bit per sample data here. | 18:16.37 |
| | penum->bps == 1 | 18:16.50 |
| | so a few lines further on, you do: | 18:17.12 |
| | if (reversed) { | 18:17.25 |
| | pdata += (pss->params.WidthIn - 1) * dpd; | 18:17.38 |
| | dpd = -dpd; | 18:17.43 |
| | } | 18:17.45 |
| | Doesn't that offset by 8 times too much ? | 18:17.54 |
| mvrhel | I cant find that | 18:18.13 |
| Robin_Watts | 15 lines after the comment. | 18:18.37 |
| | oh, unless... | 18:18.51 |
| mvrhel | no if (reversed) found | 18:19.01 |
| Robin_Watts | OK, sorry. | 18:20.15 |
| | if (penum->matrix.xx < 0) | 18:20.22 |
| | sorry, in my version that's become if (reversed) | 18:20.36 |
| mvrhel | ok..... | 18:20.38 |
| Robin_Watts | It looks to me like all this code is assuming 1 BYTE per sample, not 1 bit per sample. | 18:21.42 |
| | and the comment might imply that too. | 18:21.59 |
| mvrhel | Robin_Watts: I believe all the data that is fed into this function is already 1 byte at lease | 18:22.11 |
| | otherwise it is not used | 18:22.16 |
| | we dont do gxiscale on 1 bit data | 18:22.25 |
| | if i recall correctly | 18:22.32 |
| Robin_Watts | Hmm. I have a case here where we do. | 18:22.53 |
| mvrhel | I thought those were checked for in the front end hold on | 18:23.15 |
| Robin_Watts | This file has a 1bpp indexed colorspace (which resolves to black or white) and has an inline image which specifies interpolation. | 18:23.40 |
| | BUT... we currently never interpolate it because it's rotated by 90 degrees. | 18:24.10 |
| mvrhel | there is a comment I made around line 212 about this function always getting a least 8 bits | 18:24.36 |
| | cant recall why I wrote that | 18:24.41 |
| | I recall we do something different for 1 bit data | 18:25.27 |
| | and 2 bit or 4 bet etc data is put in 8 bit prior to us running into gxiscale | 18:25.59 |
| Robin_Watts | So my code is showing this problem up, but it may not actually be my fault (though it still could be of course!) | 18:26.11 |
| | mvrhel: right... | 18:26.29 |
| | So, I've made a non rotated version of this file here. Let me see if we get into the same place. | 18:28.37 |
| mvrhel | good idea | 18:30.06 |
| Robin_Watts | We do indeed get into the same code. | 18:30.33 |
| mvrhel | well if that is the case. either a) there is a mistake in the logic that got you there, or b) there is a lot of work to do in the in interpolation code | 18:33.48 |
| Robin_Watts | Ah, the data IS 8 bit. | 18:33.58 |
| | in the portrait case at least. | 18:34.06 |
| mvrhel | oh | 18:34.11 |
| Robin_Watts | but bps == 1, indicates that it WAS 1bit at some point. | 18:34.21 |
| | Right, so let me go back to the landscape case and see what's going on. | 18:34.51 |
| | Sorry about this. | 18:34.57 |
| mvrhel | no worries. that area is confusing | 18:35.05 |
| | and I probably did not help the situation | 18:35.13 |
| | since it was the first area I poked around in when I started | 18:35.25 |
| Robin_Watts | mvrhel: OK, can I continue to bother you for a sanity check please? | 18:56.59 |
| | In gxidata.c line 106 | 18:57.13 |
| | That's where we do the unpacking. In this instance it's from 1 bit to 8 bit. | 18:58.07 |
| | A bit below that (line 123) we have a debug section that prints out the buffer returned. | 18:58.38 |
| | OK. Ignore me, I'll keep bashing. I'm getting source_x back as 3 and 1) I wasn't expecting that, and 2) it's cocking up the data pointer. | 18:59.57 |
| | Ah! | 19:03.43 |
| | in gxiscale.c at line 404, we do: const unsigned char *bdata = buffer + data_x * spp_decode * sizeofPixelIn; | 19:04.14 |
| | spp_decode = 3. | 19:04.24 |
| | I'm thinking that we shouldn't be multiplying by spp_decode in the indexed case ? | 19:04.39 |
| | And that solves it. | 19:07.31 |
| kens | mvrhel : ping | 19:47.03 |
| Robin_Watts | kens: I think I've driven him into hiding, sorry. | 19:53.28 |
| kens | I thunk he's avoiding me :-) | 19:54.07 |
| mvrhel | kens I am here but getting ready to head out | 20:05.23 |
| | kens: is tomorrow better | 20:05.37 |
| kens | tomorrow is alos goo | 20:07.30 |
| | good :-) | 20:07.38 |
| | I have more time late afternoon, its getting later here now | 20:07.54 |
| mvrhel | kens: lets go for tomorroe | 20:08.14 |
| | w | 20:08.16 |
| kens | OK see you then :-) | 20:08.22 |
| | I'll log off, goodnight Robin_Watts and anyone else still here | 20:08.42 |
| Robin_Watts | mvrhel: If you get a chance to look over the patch that is currently testing on the cluster, that would be great. | 20:13.44 |
| | (when my run finishes, click on "robin" and scroll down to the bottom) | 20:14.06 |
| | It's only a 2 line change. | 20:14.12 |
| mvrhel | Robin_Watts: that looks fine to em | 22:59.56 |
| | me | 22:59.58 |
| Robin_Watts | mvrhel: Thanks. | 23:43.49 |
| mvrhel | I am surprised we had no progressions | 23:52.50 |
| | guess that is why I never caught that one | 23:54.10 |
| | bbiaw | 23:54.19 |
| Robin_Watts | Oh balls. | 23:55.05 |
| | Everytime I fix one sodding problem, another one pops up :( | 23:55.16 |
| sebras | Robin_Watts: now you sound just like me. | 23:55.51 |
| | Robin_Watts: except you curse a lot less. ;) | 23:56.01 |
| | Forward 1 day (to 2012/10/26)>>> | |
IRC Logs