| | <<<Back 1 day (to 2012/04/11) | 2012/04/12 |
| mvrhel | thanks Robin_Watts | 01:24.29 |
| | this file is terrible with full soft masks with patterns | 02:51.49 |
| | all of which are full page of course | 02:52.01 |
| chrisl | ppd: I saw your comment on the Ubuntu bug tracker - just a thought: did you re-enable the KIR/Smoothing option in the driver when you tested GS @ 300dpi? Also, AIUI, changing the dpi in the CUPS dialogue changing the *printer* mode, but not how Ghostscript is called, unless Till has tied the two together with the latest update. | 06:41.09 |
| ppd | chrisl: hi. I enabled KIR yes. it's only the image on the page that looks a bit "rough" | 06:42.47 |
| chrisl | ppd: Hmm, it is still a little odd - I seem to remember the "bare" 300dpi file you tested came out okay (it was the ones with the PPD settings that looked poor, IIRC)? | 06:45.02 |
| ppd | chrisl: let's just try... wait a minute | 06:46.22 |
| chrisl | ppd: FWIW, if you want an idea of the quality you *should* get, do something like: "gs -sDEVICE=pnmraw -r300 -o output.pnm output.ps" and view output.pnm in gimp. | 06:48.05 |
| ppd | chrisl: that's super fast AND quality is almost perfect | 06:48.08 |
| chrisl | ppd: so, what did you change for that test? | 06:48.31 |
| ppd | chrisl: I netcatted the 300dpi uncompressed you attached to the bug report one | 06:49.08 |
| | chrisl: takes as long as the cups 300dpi one but quality is way better | 06:49.22 |
| chrisl | ppd: Hmm, well, I think we can say that the culprit isn't Ghostscript, then! Can you upload the 300dpi and 600dpi cups PS for me to look at? | 06:51.36 |
| ppd | chrisl: certainly. Just a sec | 06:51.59 |
| mvrhel | good night all. getting close to finding my hopefully last issue in this sep planar stuff | 06:53.50 |
| kens | night mvrhel | 06:54.05 |
| mvrhel | night kens | 06:54.10 |
| ppd | chrisl: http://www.linergy-gmbh.de/evince_cups_300dpi.ps and http://www.linergy-gmbh.de/evince_cups_600dpi.ps | 06:58.06 |
| | chrisl: both printed from evince with KIR on and ecoprint off | 06:58.17 |
| chrisl | ppd: OKay, so the resolution setting is now having an influence on the GS command line - that's good...... | 07:08.05 |
| | ppd: would you mind giving this a try? http://www.ghostscript.com/~chrisl/evince_cups_300dpi-p600dpi.ps | 07:09.50 |
| ppd | chrisl: naah. let's stop now... just kidding... wait a sec | 07:10.22 |
| | chrisl: very nice. blazingly fast and output looks good | 07:13.30 |
| chrisl | ppd: So, that was your 300dpi output, but with the printer set to 600dpi..... | 07:14.06 |
| ppd | chrisl: the font is a tiny bit uglier than with the original 600dpi one, but that's "ok" for the speed increase | 07:14.39 |
| chrisl | ppd: yes, the problem is that "tiny bit uglier" could easily end up being unacceptable for Chinese, Japanese etc glyphs. | 07:15.45 |
| ppd | chrisl: well that's what the printer has the 600 dpi or the 1200dpi setting for right? 300dpi is the lowest but fastest mode | 07:16.31 |
| chrisl | ppd: yes, and my feeling is that the current CUPS that Till has put up is doing the right thing. | 07:17.48 |
| | ppd: so at 600dpi and 1200dpi we *are* still slower than the old poppler output, *but* with good reason. | 07:19.10 |
| ppd | chrisl: yeah. but only slower like double the time. but not anymore 15 minutes vs. 3 seconds | 07:19.55 |
| chrisl | ppd: sure which is great - really, just now, I'm clarifying for my own benefit where we stand, so I can answer the next person who queries us. | 07:20.48 |
| ppd | chrisl: that's really acceptable so far. the only thing I don't get is why the kyocera prints a 300dpi image worse at a 300dpi printing resolution than with the printing resolution set to 600dpi | 07:21.26 |
| kens | hops chrisl will write this down somewhere, I've completely lost touch with the findings | 07:21.26 |
| | ppd I guess it does some kind of interpolation/anti-aliasing when upsampling | 07:21.52 |
| chrisl | ppd: that may be where the Smoothing setting comes into play - I'm not going to worry about it, too much...... | 07:22.26 |
| | kens: after all this, the answer to anyone who asks is actually quite simple: the old poppler code *always* flattened transparency at 300dpi. With the new Ghostscript workflow, we're flattening transparency at the native resolution of the printer (or something related to it!). Hence the GS output may be a bit bigger, and a bit slower, but the quality will me better, and we'll *better* match... | 07:25.31 |
| | ...when comparing flattened transparent, and purely opaque areas. | 07:25.32 |
| kens | Fair enough. So its slower, but feel the quality :-) | 07:26.06 |
| chrisl | kens: yeh - tbh, I doubt many people will notice the increase in print time we're seeing, so I'm hopeful the subject won't arise. | 07:27.48 |
| ppd | chrisl: to sum it up: If I really wanted my old behaviour I'd render the postscript to 300dpi and then let my printer upscale it to 600dpi? | 07:34.53 |
| chrisl | ppd: yes, exactly. I've no idea if that's possible with the current CUPS setup, though. | 07:35.35 |
| | ppd: this basically comes down to that "rule of thumb" I mentioned yesterday about anything >HWRes/2 being pointless for contone images - *but* once you have text involved, things are more complex. | 07:36.53 |
| ppd | chrisl: maybe tkamppeter has an idea for further tweaking. but the average user would just print at a higher resolution | 07:37.44 |
| chrisl | ppd: the problem is: what if you have a two page document: the first page is like yours, with a logo in one corner with a little transparency, the second page is just plain text - if we flatten transparency at something other that printer resolution, the text on the two pages will look different. | 07:40.10 |
| ppd | chrisl: yes. that would always be a very specific and customized setting | 07:41.05 |
| | chrisl: would be nice if this option existed however | 07:41.18 |
| | chrisl: but that's cherry picking. I'm so glad this printer finally has acceptable performance | 07:41.49 |
| chrisl | ppd: it actually gets worse, because the way PDF transparency works, we could actually have flattened transparency in one area and "normal" opaque marks in a another area of the *same page* | 07:42.26 |
| | ppd: actually, it might be worth seeing if tkamppeter_ would be amenable to an enhancement request to allow "decoupling" of the *printer* resolution from the Ghostscript (transparency flattening) resolution - applications like Acrobat and Illustrator offer exactly that setting in similar situations. | 07:44.28 |
| ppd | chrisl: that sounds like a feature worth considering | 07:48.12 |
| chrisl | ppd: I think it probably is - but as I say, Till is the man on that one. | 07:53.05 |
| Robin_Watts | So most of the mupdf indetermisms are down to the macpro. | 10:03.44 |
| naveen_ | Hi Robin, I'm able to render pdf using byte array..thanks for the help...I have a question for you. | 11:06.01 |
| | Are links supported in muPdf? | 11:06.26 |
| Robin_Watts | naveen_: Some types. | 11:06.38 |
| | Internal links should work. | 11:07.03 |
| | External links have the hooks there, but don't currently do anything. | 11:07.33 |
| naveen_ | They are not working for me on android.Do I need to set any parameters for that? | 11:07.40 |
| Robin_Watts | What is your specific use case? | 11:07.46 |
| naveen_ | internal links | 11:07.52 |
| | I want table of content links to work.. | 11:08.09 |
| Robin_Watts | That's odd. I have to take my wife to the station and run some errands now. | 11:08.24 |
| | but I will be back in a couple of hours, sorry. | 11:08.32 |
| naveen_ | ok..thats fine...will talk after you are back | 11:08.51 |
| Robin_Watts | Internal links certainly work for me in, say, the pdf reference manual. | 11:08.55 |
| | paulgardiner: You about? | 11:09.02 |
| | paulgardiner updated the android app recently, so he may be able to answer some questions in my absence. | 11:09.58 |
| naveen_ | ok..will contact him.. | 11:10.51 |
| | Hi paulgardiner | 11:12.21 |
| Robin_Watts | Oh, we used to have a toggle button to turn links on and off. | 11:12.39 |
| | and tor8 just disabled it - I wonder if he left links broken? | 11:12.49 |
| paulgardiner | Oh. Hi naveen_ Robin_Watts | 11:12.52 |
| Robin_Watts | I'll have to check when I get back, sorry! | 11:12.54 |
| naveen_ | ok.after you come back plz let me know how to toggle them on.. | 11:13.30 |
| pabix | Hello. Using MuPDF. I found a bug and I think it should be great if it could be fixed before release. | 11:14.46 |
| | in short: all calls to tmpfile() can fail if user has no write permissions on the root directory. | 11:15.23 |
| | Example: I try to open the pdf file that can be found on c:\users\bm\desktop\git-trees\mupdf\toto.PDF with MuPDF or Mudraw | 11:16.46 |
| | there is a call to tmpfile() in the jpeg_open_backing_store function | 11:17.08 |
| | tmpfile() as specified in http://msdn.microsoft.com/en-us/library/x8x7sakw.aspx tries to create a file in the root directory. | 11:17.41 |
| | I have no writing rights on C:\ => failure. | 11:17.54 |
| | if you want to reproduce that, use this particular PDF file and put a breakpoint at jmemansi.c line 144. | 11:19.19 |
| paulgardiner | naveen_: internal link following has been inhibited in the android app. If you were to uncomment Line 209 of MuPDFActivity.java then they should work again. | 11:21.24 |
| pabix | sorry, the link address is http://cran.r-project.org/doc/contrib/Guirreri-EconometRia.pdf | 11:22.22 |
| naveen_ | thanks paul..will do it.. | 11:23.44 |
| pabix | added bug 692985 related to it. | 11:27.10 |
| naveen_ | Hi Robin,as I'm passing the pdf byte array to render pdf, I'm getting "java.lang.OutOfMemoryError" errors when i try to open pdf files of size >= 10 MB | 12:43.11 |
| Robin_Watts | naveen_: OK, that doesn't entirely surprise me. | 12:44.05 |
| naveen_ | Is there any other way to get fz_stream other than using "fz_open_memory"? | 12:44.22 |
| Robin_Watts | naveen_: Without extending the current code, no. | 12:44.41 |
| | but it is easy to extend. | 12:44.44 |
| | We need to understand what is causing the OutOfMemoryError. | 12:44.57 |
| | paulgardiner: So, we should uncomment 209 in master, right? The ios app does internal link following, right? | 12:45.39 |
| naveen_ | I'm getting this OutOfMemoryError when i try to allocate the memory for byte array | 12:45.40 |
| | I did that Robin..and links are working now.. | 12:46.02 |
| Robin_Watts | Right, so maybe android has a limit for the size it will let you have a byte array. | 12:46.58 |
| naveen_ | yes i too assume that.. | 12:47.16 |
| paulgardiner | Robin_Watts: I'd have thought so, but I don't know why Tor disabled it. There were two independent changes: one disabling the link button, and another disabling link following. It doesn't look accidentlal. | 12:48.00 |
| Robin_Watts | paulgardiner: I believe the intention is that we should follow what the ios app does. I'll check that out in a mo. | 12:48.23 |
| | naveen_: So, we need to find a different way to do this. | 12:48.45 |
| | I'm guessing that you don't want to make a plaintext PDF temporary file in the device file system for security reasons ? | 12:49.10 |
| naveen_ | thats correct.. | 12:49.24 |
| Robin_Watts | So, there are 2 ways of working here. | 12:50.33 |
| | 1) Do a smarter stream that can read from the file and decrypt it on the fly. | 12:50.51 |
| | 2) Find a way around this size limit. | 12:51.05 |
| | 1 would be appealing, but the fact we need to seek within the file is problematic. | 12:51.40 |
| | I'm not familiar with AES encryption. Is it packetised in any way? | 12:51.57 |
| | (i.e. can we safely break the file into pieces and then unencrypt parts of them without reference to the others?) | 12:52.22 |
| naveen_ | We can unencrypt parts of file without previous reference but we need to know the part number....I currently have a streamer that streams the decrypted data through sockets.Is it possible to pass this stream to muPDF? | 12:53.27 |
| Robin_Watts | naveen_: An fz_stream is a simple interface, which we can implement any way we like. | 12:54.39 |
| | All we need is to be able to seek to a given point, and read a given number of bytes from that point onwards. | 12:55.05 |
| naveen_ | currently my streamer does that... | 12:56.01 |
| Robin_Watts | If your streamer in C or java? | 12:56.13 |
| | s/If/Is/ | 12:56.21 |
| naveen_ | it is in java but communication is through sockets.. | 12:56.28 |
| Robin_Watts | I think doing this via sockets would be problematic. | 12:57.02 |
| | How much code is it? Would it feasible to rewrite it into C ? | 12:57.19 |
| naveen_ | it is not feasible to write it in c...as I have other media types(audio/video) which also gets the data from the same streamer.. | 12:58.15 |
| Robin_Watts | (I have no idea of your background here. I am a C/machine code programmer, with a small amount of java experience) | 12:58.45 |
| | I'm not suggesting that we dump the java version that works through sockets. | 12:59.16 |
| | I'm suggesting that we take the core decryptor, port that to C, and wrap that in an fz_stream. | 12:59.46 |
| naveen_ | ok...I can port the decryptor to C... | 13:00.31 |
| Robin_Watts | In the version of MuPDF that you have now, that works for small PDF files, are you using the socket based decryptor? | 13:00.41 |
| naveen_ | yes.. | 13:00.53 |
| Robin_Watts | OK, so if you port the decryptor to C, it would be dead easy for us to make it all work. | 13:01.38 |
| | Just to be 100% clear here, if I say "seek to half a meg into the file, and give me the next 4K of data", it doesn't need to decrypt the first half meg of the file first, right ? | 13:02.16 |
| naveen_ | it doesn't need to decrypt the first half meg of file...in this will muPDF directly read from the encrypted file? | 13:03.22 |
| Robin_Watts | naveen_: Yes. | 13:03.36 |
| naveen_ | thats great... | 13:04.02 |
| Robin_Watts | Whenever mupdf wants to read data it will call you, you will decode the relevant section of data, and return it. | 13:04.12 |
| | It may be worth adding some caching, but we can talk about that after we get something working. | 13:04.33 |
| naveen_ | ok...so what/where are the changes that I need to make now? | 13:05.25 |
| Robin_Watts | So... have a look at stm_open.c | 13:05.53 |
| naveen_ | I have it opened.. | 13:06.19 |
| Robin_Watts | fz_new_stream is the central creation function. | 13:06.41 |
| | That's called with a void *state (private state to your stream implementation), a read function, and a close function. | 13:07.12 |
| naveen_ | ok.. | 13:08.02 |
| Robin_Watts | If you look at fz_open_fd in the same file, you'll see it being called. | 13:08.19 |
| naveen_ | yes I see it | 13:08.48 |
| Robin_Watts | We should really pass the seek function too - but currently, probably for historical reasons, we don't. We poke the seek function in later (again see fz_open_fd) | 13:09.17 |
| | So, all this is easy to replace... the key bits where the complexity will live will be in your replacements for read_file, close_file and seek_file. | 13:10.04 |
| | The existing definitions for those are pretty obvious. | 13:10.33 |
| | I'd imagine that you'd clone those functions and change the read to be 'read then decrypt' etc. | 13:11.22 |
| naveen_ | so these are the functions called when rendering pdf....is it enough to override these methods or do I need to do any other changes? | 13:12.58 |
| Robin_Watts | All file access goes through those. | 13:13.13 |
| | So just override those, and we should be OK. | 13:13.25 |
| naveen_ | Ok..I'll do that and let you know the status | 13:14.21 |
| Robin_Watts | Fab. Any problems, please don't hesitate to come back with more questions. | 13:14.37 |
| Robin_Watts | grabs some lunch. | 13:14.56 |
| naveen_ | Thanks for all the help Robin....Also can you give me the contact of the person I need to contact to get the licensing quotation? | 13:15.27 |
| kens | scott.sackett at artifex.co | 13:21.36 |
| | .com | 13:21.39 |
| Robin_Watts | naveen_: Yeah, what kens said. | 13:47.12 |
| henrys | mvrhel:do you know any reason why gx_trans_pattern_fill_rect doesn't check any error codes? That sort of came up in my last commit thought I'd check with you before fixing it. | 15:44.57 |
| | or I can just leave it for you, I left an "NB" in the last commit | 15:46.02 |
| mvrhel | henrys: it should have checked the code. hold on phone | 15:46.18 |
| Robin_Watts | henrys: I looked at the mupdf "indetermisms", and found something interesting. | 15:46.44 |
| | http://ghostscript.com/cgi-bin/showdeltas.cgi?report=e6b8d0c6b1809e012da290202108f1ac76153774&project=mupdf | 15:46.49 |
| | If you click on "macpro" at the bottom, it'll highlight all the tests that ran on the macpro. | 15:47.15 |
| | You'll see that almost all of the failures were down to being on the macpro. | 15:47.34 |
| | And the other two are on 'feet'. | 15:47.52 |
| | Can I get a login to macpro please, so I can do some experiments ? | 15:49.08 |
| henrys | you have one. | 15:49.24 |
| kens | While you're there , can yo figure out why 34_all.ps and fr4iends crash on the macpro ? | 15:49.36 |
| Robin_Watts | henrys: OK, in that case, where is macpro please? (What IP address/domain name ?) | 15:50.02 |
| henrys | marcos sent out an email with all the host names I always have to search for them. | 15:50.36 |
| | the email subject is Dynamic DNS henry-artifex.homeip.net | 15:52.31 |
| mvrhel | henrys: if you are right there and able to fix it then please do | 15:52.33 |
| Robin_Watts | henrys: Thanks. | 15:52.43 |
| henrys | mvrhel:I'll give it a go. | 15:53.23 |
| Robin_Watts | henrys: That mail probably predates me changing email systems; could you forward it to me please? | 15:53.25 |
| | Anyone object to me adding the cluster machines into the ghostscript.com domain? | 15:53.42 |
| | so macpro.ghostscript.com would point at henry-artifex.homeip.net etc | 15:53.56 |
| | peeves is already there, as is spectre. | 15:54.58 |
| henrys | sent and fine by me respectively | 15:55.17 |
| Robin_Watts | Thanks. | 15:55.20 |
| henrys | I haven't tried the name recently. | 15:55.41 |
| Robin_Watts | I seem to be in. | 15:57.19 |
| henrys | probably a math think like marcosw discovered with gs on the macpro | 15:59.07 |
| | s/think/thing | 15:59.15 |
| Robin_Watts | henrys: Yes. I'm just wondering if it's a specific function at fault (like hypot or something) or whether it's a compiler difference. | 16:00.10 |
| | The former may be workaroundable. | 16:00.19 |
| marcosw | Robin_Watts: you won't be able to create DNS entries for any most of cluster machines (i7, i7a, i7b, x6, miles, etc.) since they all use NAT. | 16:02.02 |
| Robin_Watts | marcosw: Right. | 16:02.12 |
| marcosw | I think peeves and macpro might be it :-) | 16:02.31 |
| | spectre is just the gateway, it's not a cluster node. | 16:03.01 |
| Robin_Watts | I can't resolve spectre.ghostscript.com | 16:03.40 |
| | but I can't immediately see why. | 16:03.50 |
| | Oh, because alexes dyndns is out of date. | 16:05.19 |
| henrys | marcosw:there should be bugs for kens crashes on the macpro. Are there? | 16:06.12 |
| marcosw | I wasn't aware of them. These showed up in recent commit cluster jobs? | 16:07.17 |
| henrys | 34_all.ps he said. | 16:07.50 |
| kens | No these have been going on for some time | 16:07.53 |
| | 32_all 33_all and 34_all always seg fault on the cluster if (and only if) the macpro runs them | 16:08.10 |
| marcosw | http://bugs.ghostscript.com/show_bug.cgi?id=692707 | 16:08.56 |
| kens | Oh, and apparently 35_all.ps as well | 16:09.01 |
| marcosw | only mentions 33_all.ps, but presumably (hopefully) it's the same bug in all of them :-) | 16:09.24 |
| kens | I think it must be | 16:09.36 |
| | The one you're pointing at says its a pdfwrite problem 9according to the back trace) but I see it on rendering too | 16:10.11 |
| marcosw | http://bugs.ghostscript.com/show_bug.cgi?id=692684 may be related as well. | 16:10.31 |
| kens | That's the one | 16:10.45 |
| marcosw | looking at the recent cluster emails it only seg faults during pdfwrite: | 16:11.15 |
| | tests_private/ps/ps3cet/34_all.PS.ps.ppmraw.300.0 macpro Seg_Fault | 16:11.21 |
| | tests_private/ps/ps3cet/35_all.PS.ps.ppmraw.300.0 macpro Seg_Fault | 16:11.22 |
| kens | Hmm, I thought it was doing it in rendering too, maybe not. | 16:11.35 |
| marcosw | tests_private/ps/ps3cet/34_all.PS.pdf.ppmraw.300.0 macpro Seg_Fault | 16:11.35 |
| | (and apparently ps2write). | 16:11.49 |
| kens | If this is the case, teh work I'm doing now may fix it as a side-effect | 16:11.50 |
| | ps2write is effectively pdfwrite ;-) | 16:12.04 |
| Robin_Watts | finds it hard to believe that macpro doesn't have git... | 16:12.07 |
| henrys | /opt/local/bin/git | 16:12.35 |
| marcosw | Robin_Watts: /Users/marcosw/bin/git | 16:12.41 |
| | which is l a link to /opt/local/bin/git | 16:13.03 |
| henrys | Robin_Watts:if you have a problem debugging let me know someone else had to be added to a special group or something - I can't recall the details. | 16:13.31 |
| marcosw | you can't run gdb on a mac without the correct permissions. | 16:14.03 |
| | Starting program: /Users/marcosw/a.out | 16:14.16 |
| | We need authorization from an admin user to run the debugger. | 16:14.16 |
| | This will only happen once per login session. | 16:14.16 |
| | Admin username (marcosw): | 16:14.17 |
| | Don't ask me how you do it without making the user as Admin (which also allows them to run sudo). | 16:15.01 |
| henrys | I did it for ray_laptop | 16:15.23 |
| Robin_Watts | Gah. My startup shell isn't bash. | 16:16.14 |
| | oh, it is bash, but it doesn't read bashrc | 16:16.42 |
| | Ah, profile. | 16:17.44 |
| kens | Time to be off, goodnight all | 16:19.40 |
| Robin_Watts | Night kens. | 16:19.47 |
| henrys | marcosw:try gdb now | 16:20.20 |
| marcosw | w00t! | 16:20.39 |
| henrys | okay robin_watts should be good too. | 16:21.02 |
| Robin_Watts | Thanks. | 16:21.06 |
| marcosw | not that I need to run gdb on your machine, I usually just ssh to my iMac and debug there. | 16:21.10 |
| henrys | are the crashes reproducible on the imac? | 16:21.43 |
| Robin_Watts | Hmm. I was assuming that macpro would give different results to my mac. I should check. | 16:21.52 |
| | I get the same md5 sums on my mac as the macpro, which differ from peeves. | 16:32.38 |
| | Oh wow. If I pdfclean the file, I get different results. | 16:36.54 |
| marcosw | henrys: actually in this case 33_all.PS does not seg fault on my iMac. | 16:50.48 |
| Robin_Watts | We should consider the idea that those files might be corruptly checked out on the macpro? | 16:54.11 |
| | (not that that excuses a SEGV, but...) | 16:54.28 |
| henrys | marcosw:but it readily reproduces on the macpro - it isn't peculiar to the clusters? | 17:00.05 |
| marcosw | henrys: the seg fault is independent of the cluster. | 17:02.42 |
| | this problem has been around for ~5 months. why the sudden interest? | 17:03.08 |
| henrys | I thought we had fixed this, must have been something else I'm thinking of. | 17:03.37 |
| | it should have a bug report though right? | 17:04.10 |
| marcosw | http://bugs.ghostscript.com/show_bug.cgi?id=692707 | 17:04.25 |
| henrys | oh okay ... | 17:05.16 |
| marcosw | I just tried with -Z? on Linux and get this: GPL Ghostscript GIT PRERELEASE 9.06: ./psi/ilocate.c(541): Reference to free object 0x2da7618(12), in chunk 0x2d03bd0! | 17:07.21 |
| | which is the same error you see on the macpro with -Z?, so hopefully the same problem as the seg fault. | 17:09.03 |
| | memento reports an issue as well: Attempt to free block 0x0x407aef0:(size=10898848,num=1610637312)Segmentation fault | 17:09.59 |
| henrys | so nothin' to do with the macpro that's good ... sort of. | 17:22.12 |
| mvrhel | yes! | 17:23.10 |
| | finally | 17:23.12 |
| | got this pattern transparency stuff working on this crazy file | 17:23.36 |
| marcosw | Have you guys tried <http://mozilla.github.com/pdf.js/web/viewer.html>? I've been playing with it by uploading various PDF files and it works much better (and faster) than I would have expected. | 17:23.39 |
| mvrhel | now to clean up a bit and try a clusterpush | 17:23.45 |
| henrys | yeah I was somewhat surprised. | 17:24.05 |
| mvrhel | need to head out for a bit. brb | 17:25.26 |
| | argh conflicts now | 17:33.49 |
| | gxp1fill.c | 17:34.00 |
| ray_laptop | marcosw: you've been busy with closing resolved bugs !!! | 17:34.28 |
| mvrhel | strange rebase claimed there were conflicts but I dont see any | 17:35.01 |
| | a tricky merge though | 17:35.09 |
| marcosw | yes, decided to clean up the resolved but not closed list. | 17:35.20 |
| ray_laptop | marcosw: have you tried the mozilla viewer on the PDF_17_FTS files ? | 17:36.02 |
| henrys | mvrhel:my changes shouldn't be difficult to merge with. | 17:36.24 |
| ray_laptop | those were quite challenging | 17:36.25 |
| marcosw | not yet. just uploaded various files that customers had sent us as problematic over the last few weeks. Many of them rendered correctly. | 17:36.37 |
| mvrhel | git seems to be very confused for some reaqson | 17:36.49 |
| ray_laptop | mvrhel: git st -u should show you the conflicted fiules | 17:36.51 |
| henrys | I'm just about to make another change to that file ;-) | 17:37.41 |
| mvrhel | oh I see the file just fine ray_laptop | 17:38.14 |
| | but when I go in to edit it doesnt show any conflicting parts | 17:38.32 |
| ray_laptop | mvrhel: are there other versions of that file in base (different suffixes) ? | 17:39.34 |
| mvrhel | hold on | 17:40.01 |
| ray_laptop | it's been a while since I encountered it, but I thought it didn't actually change your file, but made other copies | 17:40.31 |
| mvrhel | ugh | 17:42.48 |
| ray_laptop | mvrhel: try: git ls-files -u (from git merge --help) | 17:43.09 |
| | according to the help: For conflicting paths, the index file records up to three versions: stage 1 stores the version from the common ancestor, stage 2 from HEAD, and stage 3 from MERGE_HEAD | 17:43.36 |
| marcosw | ray_laptop: some of the PDF_17_FTS files work, many produce error messages. | 17:44.37 |
| mvrhel | I need to install msysgit to figure this out | 17:46.32 |
| | this branch has touch so many areas of the code it is getting hard to manage | 17:46.51 |
| henrys | mvrhel:are you merging or rebasing? | 17:47.23 |
| mvrhel | I am trying to rebase | 17:47.32 |
| | but for some reason, it claims that your changes conflict with my changes in the file | 17:47.57 |
| | but when I go in to edit the conflicts it does not show any | 17:48.11 |
| | so I mark it as resolved | 17:48.25 |
| henrys | then you do git --rebase continue | 17:49.36 |
| mvrhel | hold on | 17:49.46 |
| henrys | sorry git rebase --continue | 17:49.59 |
| mvrhel | yes. I am installing msysgit right now so that I can try that | 17:50.36 |
| | TortoiseGit says | 17:51.43 |
| henrys | if you do fix a conflict you have to "add" it | 17:51.45 |
| mvrhel | hint: after resolving the conflicts, mark the corrected pathshint: with 'git add <paths>' or 'git rm <paths>'hint: and commit the result with 'git commit' | 17:51.48 |
| | this should not be this hard | 17:52.35 |
| henrys | yeah you would think this should be a simple merge - my change only affected a few lines. | 17:53.58 |
| Robin_Watts | mvrhel: Is it because you've got something odd stored in the index ? | 17:55.05 |
| mvrhel | Robin_Watts: how would I know this | 17:55.31 |
| Robin_Watts | with msys git you do git diff --cached | 17:55.50 |
| | That shows you what is ready to be committed. | 17:56.03 |
| mvrhel | I would tell you why it is but I dont want to curse | 17:56.05 |
| | ok finally have msysgit | 17:56.51 |
| | let me try from here | 17:56.55 |
| | ok so I am in my tiffsep branch | 17:57.49 |
| | according to msysgit | 17:57.53 |
| | now, how to rebase... | 17:58.04 |
| | I have been using tortoise git for too long | 17:58.17 |
| henrys | do you want me to hold off on my next change to the file? | 17:58.30 |
| mvrhel | if you would | 17:58.48 |
| | just until I get this figured out | 17:58.53 |
| | ok. so msysgit says there is a conflict also | 18:00.09 |
| | in gxclip2.c | 18:00.16 |
| | ok I had the craziest phone call ever | 18:12.23 |
| | listen to this one | 18:12.27 |
| | an indian guy from NY called me to tell me that my windows 7 computer was infected | 18:13.00 |
| henrys | maybe he's remotely logged in ;-) | 18:14.10 |
| mvrhel | apparently my wifes computer has some little program that windows security failed to catch and so it was pinging their server over and over | 18:14.13 |
| | they called like they were officially from microsoft and wanted to "help" me with the issue | 18:14.37 |
| | how they got the phone number is the odd thing though | 18:14.53 |
| | I played along for awhile until they wanted their technician to take control of the computer | 18:15.22 |
| | I wonder how many people do this | 18:15.34 |
| henrys | that does sound odd. | 18:17.41 |
| mvrhel | very | 18:18.06 |
| Robin_Watts | Is that a new scam for you? | 18:18.57 |
| | We've been getting it for years :( | 18:19.07 |
| mvrhel | really? | 18:19.11 |
| | ok. so I marked the conflict as resolved | 18:19.30 |
| Robin_Watts | Yeah. I tell them they need to talk to my dad, say I'll get him, and leave the phone on the side. | 18:19.38 |
| mvrhel | now do I do git rebase --continue | 18:19.46 |
| | Robin_Watts: I am going to do that next time | 18:20.26 |
| | http://answers.microsoft.com/en-us/windows/forum/windows_7-security/please-read-dont-fall-for-phony-phone-tech-support/e5576f0a-827e-4fc0-a4b1-707add212065 | 18:21.24 |
| | ok the continue seemed to work | 18:22.31 |
| | henrys: you are good to go | 18:22.50 |
| | thanks for waiting | 18:22.57 |
| henrys | np | 18:24.23 |
| mvrhel | thanks for everyones help in getting me over this weird conflict git issue | 18:30.12 |
| ray_laptop | well, that one was easy (at least for Windows) bug 692707 was just some dangling pointers after an error caused us to free an array. Doing clusterpush | 18:33.36 |
| | I'm getting good at backtracking from those ilocate errors. I'll write up the method in an email to tech since it is fresh in my mind | 18:34.36 |
| henrys | thanks ray_laptop | 18:38.32 |
| marcosw | ray_laptop: your clusterpush didn't work on the macpro, the rsync of the source from casper failed. I'll run it manually to verify that your fix takes care of the macpro crash. | 18:51.22 |
| ray_laptop | marcosw: I hadn't committed my patch -- maybe the gitpush didn't pick it up :-( OOPS | 18:52.07 |
| marcosw | you are doing a clusterpush right now, I presume to test the fix? | 18:52.28 |
| | anyway, the macpro is getting a mysterious rysnc error: | 18:52.44 |
| | rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-40/rsync/main.c(1400) [generator=2.6.9] | 18:52.45 |
| ray_laptop | marcosw: but if the manual rsync takes care of it let me know | 18:52.46 |
| | I am going to do a commit (to my local repo) and retry the gitpush | 18:53.15 |
| marcosw | Apparently you created a directory in the tree with permissions that confuse the macpro: rsync: opendir "/Users/marcosw/cluster/users/ray/ghostpdl/ray.ssh" failed: Permission denied (13) | 18:54.02 |
| | Since I don't have sudo priv. on the macpro I couldn't delete the directory, however I could mv it to /tmp :-) | 18:55.11 |
| ray_laptop | marcosw: wonder why that hadn't shown up before -- I haven't logged into the macpro in YEARS | 18:56.50 |
| | marcosw: OK to retry the gitpush ? | 18:57.23 |
| marcosw | sure. | 18:57.31 |
| | actually I don't know how that directory was created, it was owned by henrys and created on June 30 2011. | 18:58.24 |
| ray_laptop | retrying the gitpush | 18:58.44 |
| | bbiab | 18:58.49 |
| marcosw | ray_laptop: my test of your previous clusterpush still crashed on the macpro, but I'm a bit confused as to which code I actually built and ran, so this may be a false positive. | 19:01.03 |
| ray_laptop | Wow! In hadn't realized there were so many segfaults happening. I don't see how my change could have caused those. Have they been around for a while ? | 19:01.06 |
| marcosw | for ~6 months, but only the the macpro | 19:01.28 |
| henrys | I must have been moving his keys from casper to the create his account and didn't delete it I should remove them but I don't see anything in /tmp, marcosw? | 19:02.17 |
| ray_laptop | marcosw: look in psi/zcharx.c line 118. If it is setting the x_widths and y_widths to NULL then that's the new code. | 19:02.18 |
| | I have to run an errand, I'll check the results later. | 19:02.57 |
| | i have to wait for mvrhel's ckuster test anyway | 19:04.02 |
| mvrhel | sorry... | 19:04.10 |
| marcosw | that was weird, my internets fell over because my switch needed to be rebooted. it's an unmanaged switch so that took me a big to figure out. | 20:11.18 |
| | rayjj: the seg fault still happens on the macpro, even with penum->text.x_widths = penum->text.y_widths = NULL; | 20:12.45 |
| mvrhel | Robin_Watts: you still around? | 20:22.41 |
| | marcosw: you around? | 20:28.14 |
| marcosw | mvrhel: yes | 20:29.06 |
| mvrhel | I would like to get the weird issue resolved with the bmpcmp of psdcmyk output. look at the first pair on my bmpcmp output. are the source images that were used to created these found on one of the cluster machines or are they deleted? | 20:29.49 |
| Robin_Watts | I am around | 20:31.01 |
| mvrhel | oh hi Robin_Watts. see above | 20:31.13 |
| marcosw | the images are on one of the cluster node and on casper | 20:31.14 |
| mvrhel | so, to find the psdcmyk output from 051_Font_report.pdf.psdcmyk where do I look | 20:31.51 |
| | or are these not the images | 20:32.03 |
| | is it the output from bmpcmp that is there | 20:32.13 |
| marcosw | on casper in ~regression/cluster/bmpcmp | 20:32.17 |
| | why are all the images upside down? Are you in Australia? | 20:32.33 |
| mvrhel | that is a good question too | 20:33.02 |
| marcosw | oops, never mind. the images are not on casper, just on the node that ran the test. | 20:33.29 |
| | Let me figure out which node that was and I'll email you the images. | 20:33.50 |
| mvrhel | ok. thanks | 20:33.57 |
| Robin_Watts | The output bmpcmp images are on casper, obviously. | 20:33.58 |
| marcosw | If it would help I can copy the images to casper in the future. | 20:34.07 |
| Robin_Watts | marcosw: SLOW... | 20:34.20 |
| mvrhel | no, this is a special case | 20:34.24 |
| marcosw | so my i7 ran the 051_Font_report.pdf.psdcmyk.72.0 file | 20:35.33 |
| | okay, I've put the two files in ~marcos on casper. | 20:36.53 |
| | Robin_Watts: it wouldn't be too slow for these files, they are only 72 dpi and gzip pretty well. | 20:38.32 |
| Robin_Watts | but in general it would | 20:38.43 |
| marcosw | the nodes could check the size of the bitmap and only upload the small ones (it does that already for the bmpcmp generated files). | 20:39.51 |
| | Robin_Watts: there appears to be an issue with the psd code in bmpcmp, opening the files in photoshop doesn't show the vertical black lines (it does show vertical orange lines for the new__* image, but not regularly spaced). | 20:43.25 |
| | do you handle the bpp==40 case? | 20:44.21 |
| Robin_Watts | marcosw: ? | 20:44.49 |
| marcosw | yes | 20:44.56 |
| Robin_Watts | oh, right, I see. | 20:45.04 |
| | When I tested it locally, bmpcmp worked fine on these files. | 20:45.18 |
| | I'll grab them from ~marcos tomorrow and try again. | 20:45.43 |
| mvrhel | hmm marcosw: where did you put the files? | 20:56.30 |
| | I dont see them in ~marcos | 20:56.39 |
| marcosw | on casper in ~marcos | 20:56.46 |
| | let me double check | 20:56.49 |
| | no, they are there. | 20:57.43 |
| mvrhel | hmm | 20:58.04 |
| marcosw | you want me to put them in ~mvrhel on casper? | 20:58.46 |
| mvrhel | well hold on | 20:58.58 |
| marcosw | cp'd them to ~mvrhel | 20:59.45 |
| mvrhel | So I dont see a single file that is *.psd in /home/marcos on casper | 20:59.50 |
| | or in mvrhel for that matter | 21:00.11 |
| | oh I am on casper3 | 21:00.22 |
| | is this a different machine? | 21:00.30 |
| Robin_Watts | casper == casper3 | 21:01.06 |
| mvrhel | ok then what is the issue | 21:01.15 |
| marcosw | they aren't called .psd, they just end in .72.0 | 21:01.44 |
| mvrhel | oh there they are | 21:01.46 |
| Robin_Watts | baseline__tests__Ghent_V3.0__051_Font_report.pdf.psdcmyk.72.0 | 21:01.53 |
| mvrhel | I need new glasses | 21:02.09 |
| | is what its called | 21:02.12 |
| | sorry | 21:02.20 |
| | I think I need to take a break | 21:02.40 |
| | bbiaw | 21:02.46 |
| marcosw | I have to run to a doctor appointment, getting an epidural for my herniated disc. bbiaw. | 21:02.50 |
| mvrhel | ouch! | 21:02.58 |
| Robin_Watts | ow! | 21:03.18 |
| | Forward 1 day (to 2012/04/13)>>> | |
IRC Logs