| | <<<Back 1 day (to 2013/04/21) | 2013/04/22 |
| Robin_Watts | Can you get 32bit Windows 8? | 10:24.31 |
| | Yes you can. | 10:25.03 |
| kens | Hmm good question. I think so yes | 10:25.05 |
| Robin_Watts | so... it looks to me like they still refer to 32bit, and 64bit as Win32 and x64. | 10:38.05 |
| kens | yes probably, consistency of nomenclature isn't a MS strong point | 10:38.34 |
| | nowadays windows 32 runs on the wow64 layer | 10:39.22 |
| Robin_Watts | kens: Yes, but in windows 8 for "windows store apps" (or metro, or tifkam or whatever), you don't have the WIN32 APIs. | 10:40.47 |
| kens | Yes, true | 10:42.11 |
| Robin_Watts | kens: Was it you that added the Debug-cups stuff to the gs projects ? | 10:59.13 |
| kens | Umm, possibly | 10:59.21 |
| Robin_Watts | the visual studio projects I mean. | 10:59.26 |
| kens | Maybe.... | 10:59.31 |
| | I don't recall for sure | 10:59.38 |
| | I added the C code :-) | 10:59.49 |
| Robin_Watts | I've just spotted some "Debug-cups" directories, and "x64/...." stuff. | 10:59.56 |
| kens | I'm happy if you need to change it | 11:00.15 |
| Robin_Watts | It would be more in keeping for them to build into debugcups{64,}obj I think. | 11:00.37 |
| | In trying to get this thing working for Raed, I'm currently experimenting with cloning the solution into a winrt directory. | 11:01.40 |
| | and I could make them all build into debugrt{,64,arm}obj etc | 11:02.20 |
| kens | Like I said, its no problem to me if you change it, I honestly don't recall if I made the VS changes | 11:02.36 |
| Robin_Watts | OR... we could bite the bullet and make EVERYTHING build into obj/{release,debug,memento,prof}/win,rt}/{32,64,arm}/ etc which would scale more nicely | 11:03.51 |
| kens | Both are good for me, maybe you shoudl talk it over with chrisl as the build maintainer | 11:06.51 |
| Robin_Watts | indeed. chrisl? | 11:16.47 |
| | I don't have massive strong feelings either way, it's just it feels wrong that we're exploding objects into more and more 'top level' dirs. | 11:17.52 |
| kens | lunches | 11:21.18 |
| chrisl | Robin_Watts: Personally, I think it's an unnecessary complication - we could do away with the "*bin" directories, and just put everything in "*obj". That would reduce the number of directories we create, and make gs more consistent with ghostpdl...... | 11:40.27 |
| Robin_Watts | chrisl: The problem with that is that we'd then end up with a directory with thousands of obj files, plus various dlls and exes. | 11:41.14 |
| | and the users would never know what they needed to copy out. | 11:41.27 |
| | At the moment, if I do a full build, we end up with: {,debug,mem,prof}{,64}obj | 11:42.45 |
| chrisl | Robin_Watts: so? | 11:43.03 |
| Robin_Watts | and soon I can imagine it will be {,debug,mem,prof}{,rt}{,64}obj | 11:43.15 |
| chrisl | "clean" should delete them all, too | 11:43.21 |
| Robin_Watts | oh, sorry, and there is a cups in there too. | 11:43.29 |
| | chrisl: yeah, it just feels like bad form to expand them all into top level dirs. | 11:43.57 |
| chrisl | Robin_Watts: I'm not too bothered, I just don't like too many levels of directories - next someone will want "obj/x64/debug/memento" or something | 11:46.00 |
| Robin_Watts | obj/ARCH/CONFIG seems vaguely reasonable. Doesn't linux have a standard for this? | 11:46.58 |
| chrisl | Yeh, we should use the libtool stuff - but I'm *never* going near that!! | 11:47.30 |
| | Robin_Watts: why don't you see what people think at the IRC meeting tomorrow? | 11:49.16 |
| Robin_Watts | sure. | 11:49.27 |
| chrisl | I guess opting for everything under "obj" would mean the tiff-config (and any other configure results) could go in there, too..... | 11:50.24 |
| | Robin_Watts: FWIW, on Linux/Unix systems, to prevent polluting the source tree, you're supposed to be able to run the configure script from outside the source tree, and build into totally different directory - but, of source, ours don't work like that | 11:52.12 |
| Robin_Watts | of source :) | 11:52.33 |
| chrisl | Oops, how Freudian | 11:52.47 |
| kens | Oh great, got to add high level patterns ot the HPGL interpreter too :-( | 11:54.30 |
| pgogna | Hello Everyone, can anyone help me with zoom in muPDF? | 13:25.06 |
| tor8 | help how? | 13:25.27 |
| pgogna | I am trying to make content width to zoom feature in muPDF library. The issue is I am trying to find out how to achieve this feature. What I would like to achieve is that if user double tap on the page than the level of zoom is based on the element on which user double tap. | 13:26.43 |
| tor8 | is this the android app? | 13:27.03 |
| pgogna | both android and ios | 13:27.11 |
| Robin_Watts | pgogna: OK, that's slightly involved. | 13:27.48 |
| tor8 | the current code on both android and ios calculate the zoom factor to "fit to screen" | 13:27.52 |
| | getting it to work as fit-to-width would not be a good fit with the horizontal page flipping way the apps currently work | 13:28.26 |
| Robin_Watts | Essentially you'll need to add code to detect the double tap, to open a text extraction device, to run the page through the text extraction device, and then calculate the bbox from the returned data for each line, and see whether your click intersected with it. | 13:29.06 |
| tor8 | I would start by rejigging the page layout to be continous scroll vertically instead of paged horizontally | 13:29.10 |
| | once you have that working, supporting fit-to-width would be trivial | 13:29.23 |
| Robin_Watts | If it did, then you need to adjust the zoom level/centring to match. | 13:29.30 |
| tor8 | (oh, I may have just misunderstood what you asked) | 13:29.55 |
| pgogna | @tor8: I think you are right, you misunderstood me :) | 13:30.30 |
| tor8 | double tapping to zoom in on a particular feature would be a bit more involved in one way, but a lot easier in that you don't have to rejig the entire ui layout :) | 13:30.36 |
| | detecting a "feature" is non-trivial | 13:30.46 |
| Robin_Watts | pgogna: tor8: If I'm understanding correctly, he wants to be able to double click on a paragraph (say) and have the page zoom in so that the page is zoomed in to fit the paragraph in the width. | 13:30.54 |
| tor8 | you could as robin just said run it through the text extraction device and use the block level elements in the fz_text_page structs to zoom in on | 13:31.10 |
| pgogna | Robin said it right !!! | 13:31.25 |
| Robin_Watts | I've seen that kind of behaviour in some android browsers, I think. | 13:31.34 |
| tor8 | Robin_Watts: don't we already have the bboxes for blocks and lines in there? | 13:31.38 |
| Robin_Watts | tor8: We probably do, yes. | 13:31.49 |
| tor8 | Robin_Watts: the built in pdf viewer on ios has taht feature | 13:31.50 |
| | it's quite handy actually | 13:31.55 |
| Robin_Watts | pgogna: All the building blocks are there for it. | 13:32.15 |
| | Do you like lego? | 13:32.25 |
| tor8 | Robin_Watts: and once we get the images in the page structures as well, that'd make it even better :) | 13:32.26 |
| pgogna | We made an app similar to lego on iOS called "LaserPegs". | 13:32.58 |
| tor8 | Robin_Watts: paulgardiner: I was talking to sebras over lunch and he brought up some things which could be done more elegantly in the android app with the reflow stuff | 13:33.06 |
| | in the reflow mode we disable a lot of buttons, and the pinch to zoom gestures doesn't feel like a perfect fit | 13:33.28 |
| | I suggested to change the toolbar in reflow mode to add a + and - zoom buttons to change the text size instead | 13:33.52 |
| Robin_Watts | tor8: at some point we need to think about zooming without multitouch and/or without touch at all. | 13:34.35 |
| pgogna | Robin, can you do it for me? I will buy you beers? :) | 13:34.36 |
| paulgardiner | Yeah, that might be better, although I wonder if pinch to zoom doesn't feel right just because performance is so lumpy. | 13:34.55 |
| Robin_Watts | pgogna: No, sorry, not in the short term. | 13:34.59 |
| tor8 | paulgardiner: performance is spotty, and the page doesn't stay put if you zoom out | 13:35.14 |
| pgogna | Could you give me little bit more instructions on how shall I get started? If you could write some bullet points for me with file name etc, it will help muPDF alot. | 13:35.57 |
| Robin_Watts | pgogna: So, I'm assuming your a competent android/ios dev? | 13:36.51 |
| | s/your/you're/ | 13:37.01 |
| pgogna | YEs. | 13:37.09 |
| Robin_Watts | So you can handle the detecting of the double click. | 13:37.12 |
| | The MuPDF specific bits then... | 13:37.21 |
| pgogna | Yes, I will get event on double click easily in both platform. | 13:37.33 |
| Robin_Watts | you need to call: fz_new_text_device to make the text device. | 13:37.43 |
| | See apps/mudraw.exe for code that does this. | 13:37.53 |
| | Then you need to fz_run_display_list(dev, ...); with the display list for the page. | 13:38.27 |
| | You'll see calls like that throughout the code to do the rendering. | 13:38.46 |
| | That will leave you with details of where all the text etc on the page is in terms of blocks/lines/spans. | 13:39.13 |
| tor8 | this is basically the same set of calls that happens when you do a text search or copy/select | 13:39.42 |
| Robin_Watts | You can see various examples of code to handle these blocks/lines/spans by looking in the mupdf source for where we output to text or html etc. Or as tor8 says, where we handle text search etc. | 13:40.23 |
| | You get the bbox from that data, and recalculate the zoom details from that. | 13:41.02 |
| | OK? Hopefully that should be enough to get you started. | 13:41.29 |
| pgogna | Wow, thanks Robin and tor8. You guys are wonderful. | 13:42.13 |
| | This will help for sure | 13:42.18 |
| | Can I get your email ID in case I am stuck? | 13:42.32 |
| Robin_Watts | pgogna: Let us know what you come up with. We'd like to see it if you get it working. | 13:42.52 |
| | pgogna: Your best bet is to come talk to us here. We're here all day, every day :) | 13:43.12 |
| | pgogna: What timezone are you in? | 13:43.54 |
| pgogna | Wonderful, thanks for all the inputs. I will come back later. Thank you once again. | 13:43.56 |
| Robin_Watts | Morning mvrhel_laptop | 14:00.30 |
| mvrhel_laptop | morning Robin_Watts | 14:00.36 |
| Robin_Watts | Do you know anything about winmd files? | 14:00.41 |
| mvrhel_laptop | Robin_Watts: the only thing that I know is that they are generated with dll's for winrt cross language use | 14:01.38 |
| Robin_Watts | mvrhel_laptop: Right. I've seen docs that say they are generated from C++ or C# when you link dlls. | 14:02.21 |
| mvrhel_laptop | which reading your email, I see you already know | 14:02.27 |
| Robin_Watts | but nothing saying about C. | 14:02.29 |
| mvrhel_laptop | right. a C interface is going to have to wrapped up as C++ | 14:02.56 |
| Robin_Watts | and my experiments suggest that they don't appear for the gs dll even with the /WINMD /WINMDFILE:blah entries. | 14:02.59 |
| | right, so what I put in my mail sounds sane? | 14:03.09 |
| mvrhel_laptop | yes. it all sounds sane to me | 14:03.37 |
| Robin_Watts | fab, thanks. | 14:03.48 |
| | I imagine that Raed's next question will be "Can you wrap it up as C++ for me?" :( | 14:04.10 |
| kens | Bet on it ..... | 14:05.03 |
| Robin_Watts | actually, his next email is here. And if what he says is true, that's a pain. | 14:05.28 |
| | So... you can't ever use C DLLs any more? | 14:05.43 |
| mvrhel_laptop | Robin_Watts: no you can use them | 14:05.51 |
| | just not calling from a C# app | 14:06.02 |
| Robin_Watts | According to his latest email, he has a C/C++ dll called X.dll. | 14:06.29 |
| | and he wants to call GS.DLL from that | 14:06.36 |
| mvrhel_laptop | Robin_Watts: I have to go and help get kids out the door. If you want I will take a look at this morning | 14:06.45 |
| | I need a break from this color monitoring stuff | 14:06.59 |
| Robin_Watts | mvrhel_laptop: Thanks. | 14:07.10 |
| mvrhel_laptop | bbiab | 14:07.29 |
| Robin_Watts | mvrhel_laptop: There is a commit on my repo that creates appropriate VS2012 build files that may be helpful. | 14:14.53 |
| | tor8: ping | 14:23.59 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=2ea11eace69fe5a2d88f374a253a3deb05804f2d | 14:24.32 |
| henrys | Robin_Watts:simple fix to review in my repo, you've been in this code recently and may want to do it differently. | 14:43.07 |
| Robin_Watts | looks | 14:44.29 |
| | henrys: I like the fix. I think the commit message makes it sound like "it's not really a problem, but we'll fix it anyway", when it is really a problem. | 14:46.30 |
| henrys | how do you avoid frequent push --force to the review repos? if you push something, then rebase against master/origin the local commit changes and git sees the review commit as a different commit. | 14:47.06 |
| Robin_Watts | henrys: I push -f to the review repos all the time. | 14:47.32 |
| henrys | Robin_Watts:okay on -f and I'll edit the commit message a bit. | 14:47.56 |
| | thanks | 14:49.30 |
| Robin_Watts | paulgardiner: ping | 15:34.18 |
| henrys | I'm a little fuzzy on the fuzzing ⦠alexcher says in 693890 there are no segv's or valgrind issues, why is that a resolution? Aren't we supposed to figure out why the address sanitizer reported a problem and either fix it or say it is a false positive due to blah blah... | 15:37.58 |
| kens2 | I suspect many are already fixed due to valgrind work | 15:38.30 |
| henrys | kens2:well then I'd it to say "probably fixed can't reproduce" reassign to marcosw, but I guess marcosw can check it when he does "verified close" | 15:41.57 |
| | s/I'd/I'd expect/ | 15:42.12 |
| kens2 | We can't really check these, other than saying 'does not seg fault now' anyway | 15:42.33 |
| henrys | kens:oh probably am fuzzy, I thought you needed the address sanitizer to create the crash and marcosw was the only person using that tool. | 15:43.35 |
| Robin_Watts | henrys: no. address sanitiser is like valgrind. | 15:44.09 |
| | The SEGVs they have reported will SEGV just in a normal vanilla run. | 15:44.31 |
| kens2 | yes, they supplied the files that go wrong | 15:44.58 |
| henrys | Robin_Watts: thanks that is the source of my confusion | 15:45.03 |
| kens2 | the files have been 'fuzzed' I guess, they are damaged in odd ways | 15:45.09 |
| henrys | got it yes, sorry. | 15:45.44 |
| Robin_Watts | so my plan with image extraction was to take the image data and put it out into 'data' urls within the html file we produce. | 15:45.44 |
| henrys | I'm unfuzzed | 15:45.51 |
| Robin_Watts | but it turns out that there is a maximum length for data URLs :( | 15:46.03 |
| ray_laptop | marcosw: I have a question about the "killed: timeout" messages on my last regression run. It looks like there is a job that did "return: 0" but then there was a "killed: timeout" line followed by a line with "timeoutFail: too many timeouts" | 16:42.25 |
| marcosw | ray_laptop: "killed: timeout" means that the job was terminated because it took longer than 5 wall minutes to run. | 16:43.00 |
| ray_laptop | marcosw: note that the job BEFORE the last one in the list also had a 'killed: timeout' message, without a 'return: 0', so presumably that one _did_ get killed | 16:43.29 |
| | marcosw: but I am seeing the killed: timeout AFTER the return: 0 | 16:44.28 |
| marcosw | I'm looking at the email that you were sent and don't immediately see the killed: timeout that also says return: 0. Do you have the test name: | 16:44.31 |
| | ? | 16:44.32 |
| ray_laptop | marcosw: ===tests_private__comparefiles__Bug692139.pdf.pbmraw.300.0=== | 16:45.24 |
| | is one of the cases that has this sequence. They stand out because they are not psdcmyk | 16:46.15 |
| marcosw | right. that is odd. Let me check the log file from the machine to see how that happens. | 16:46.20 |
| ray_laptop | marcosw: thanks. Not urgent. there are 282 psdcmyk jobs that I can look at in the meantime :-) | 16:47.08 |
| | strange thing is I've tried about 6 of those cases on my windoze builds and they all seem to complete fairly quickly. I'm moving over to peeves to see what I can reproduce | 16:49.07 |
| marcosw | I think it's caused by a race condition. When a node has too many timeouts and is about to report this to the cluster master the remaining jobs are killed, even though they were just launched. These are included in the list of timed out jobs, which should be considered a bug. In the case of the file you referenced it apparently finished running while other jobs were being killed, so it finished before it could be killed. | 16:51.01 |
| alexcher | henrys: Current format of fuzzing errors is not particularly convenient. The files often fail on my system in a different way than it was reported. I'd rather have the files arranged by the Valgrind warnings similar to other Valgrind bugs. Since the warning always precedes SEGV, analysis of Valgrind warning should be sufficient. | 16:53.37 |
| marcosw | ray_laptop: just tried the following command line on my i7 cluster node and it does time out: | 16:54.50 |
| | ./gs/bin/gs -sOutputFile=/tmp/test.psd -dMaxBitmap=10000 -sDEVICE=psdcmyk -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER ~/cluster/tests/Ghent_V3.0/041_White_OP.pdf | 16:54.51 |
| | head runs the file in less than 1 second. | 16:55.00 |
| ray_laptop | marcosw: I'm testing my patched version which forces BGPrint=true by default | 17:05.10 |
| | so, I should be able to reproduce it on peeves as well. | 17:05.48 |
| marcosw | ray_laptop: yes, should be a problem on peeves as well. Is it not? | 17:06.11 |
| ray_laptop | marcosw: haven't tried yet. I was on phone calls (two in a row). | 17:06.51 |
| marcosw | Just tried it on peeves, it locks up: ~marcos/cluster/users/ray/ghostpdl/gs/bin/gs -sOutputFile=/tmp/test.psd -dMaxBitmap=10000 -sDEVICE=psdcmyk -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER ~/cluster/tests/Ghent_V3.0/041_White_OP.pdf | 17:08.15 |
| ray_laptop | marcosw: but thanks for the explanation -- that make sense | 17:08.21 |
| | marcosw: thanks. I'll take it from here. Ahh. I got it to fail on Windoze. Much easier (for me) to debug here. | 17:11.35 |
| marcosw | gtg, giving lab presentation in 15 minutes | 17:13.36 |
| mvrhel_laptop | ray_laptop: do you have a second? | 17:31.11 |
| | I found a very strange issue in the high level image code | 17:31.36 |
| | as I step through to make sure my color monitoring stuff works | 17:32.09 |
| ray_laptop | mvrhel_laptop: on the phone, then I have to run an errand, sorry. | 17:36.10 |
| | I'll call you when I get back | 17:36.19 |
| mvrhel_laptop | ray_laptop: ok. I am trying to find my phone | 17:38.48 |
| | kids were playing with it and now it is missing and battery is likely dead :( | 17:39.01 |
| | as when I call it there is no sound in the house | 17:39.09 |
| | ah found it | 17:45.14 |
| henrys | marcosw:I guess I volunteered for all the 32 bit warnings somehow, why didn't we break these out by owner? | 17:46.04 |
| | oh he left | 17:46.22 |
| ray_laptop | mvrhel_laptop: has happened to both my wife and I as well. The downside of a smartphone (that has games on it) | 17:51.43 |
| mvrhel_laptop | so it appears that we never allowed 16 bit image data to be done as a high level image | 17:58.55 |
| | 12bit was ok | 17:59.12 |
| | but no 16 bit | 17:59.15 |
| | simple to fix | 17:59.33 |
| | but a bit surprising to find this | 17:59.41 |
| | ok. had to add some fuzziness in the tolerance for what is neutral in the cmyk and rgb case | 18:27.08 |
| | or rather allow a looser tolerance than strictly r=g=b | 18:27.36 |
| | clist playback needs to turn off the monitoring.... | 18:31.24 |
| | I will leave that part for ray_laptop | 18:32.47 |
| | a bit more testing then I will push this | 18:33.25 |
| | ok unpacking issues with lab data of course | 18:38.52 |
| | off to the tire store for a tire repair. will be online there | 18:50.11 |
| tor8 | Robin_Watts: it's / its mixup in the commit message | 20:01.34 |
| | Robin_Watts: otherwise the multi-threading store issues patch LGTM | 20:02.27 |
| | Robin_Watts: patch on tor/master for makefile pkg-config | 20:02.56 |
| mvrhel_laptop | ok. finally doing a cluster push to test the color monitoring. seems like forever since I did a clusterpush | 23:32.56 |
| Robin_Watts | mvrhel_laptop: Did you have any thoughts on the winmd stuff? | 23:35.57 |
| mvrhel_laptop | Robin_Watts: I got caught up in my monitoring stuff. so no. I am hoping to get to that tomorrow | 23:36.33 |
| Robin_Watts | ok, thanks. | 23:36.47 |
| mvrhel_laptop | ok. a little confused in linux | 23:46.15 |
| | trying to run ./autogen.sh and it errors out with source directory already configured; run "make distclean" there first | 23:46.51 |
| | where is "there" | 23:46.55 |
| | Robin_Watts: any ideas? | 23:47.35 |
| | hmm that is why my cluster push failed too | 23:48.26 |
| | is the build broken? henrys? | 23:48.38 |
| | all seems fine with the commits so something is wacked with my checkout | 23:50.05 |
| henrys | mvrhel_laptop:chrisl sent email about that. try git clean -f -x -d if you have not created new files in the repo | 23:51.16 |
| mvrhel_laptop | ok. I can do that first and then perhaps apply my patch. I do have one new file | 23:51.50 |
| | ok that deleted a bunch of tiff stuff | 23:52.10 |
| | ok and that fixed the autogen issue. thatnks henrys! | 23:52.39 |
| henrys | np | 23:52.46 |
| | Forward 1 day (to 2013/04/23)>>> | |
IRC Logs