| | <<<Back 1 day (to 2013/07/10) | 2013/07/11 |
| mvrhel_laptop | whew. I think I finally have this c# async crap figured out for interfacing to my winRT library for the windows phone. done for the night. hopefully I should be rendering with mupdf on windows phone by the end of the week. then it is just a matter of a bit of ui | 05:30.29 |
| chrisl | sebras: I think Robin_Watts has all the info he needs. I didn't go back and look at the poppler source again - I've been busy with other things | 06:30.39 |
| sebras | chrisl: yup, he mentioned this late last night. | 08:49.05 |
| chrisl | sebras: good, didn't want you wasting time on it | 08:50.09 |
| Robin_Watts | tor8: Are you going to push the pagetree stuff ,or should I ? | 09:39.17 |
| tor8 | Robin_Watts: go ahead | 09:45.56 |
| Robin_Watts | pushed. | 10:01.18 |
| deleet | Robin_Watts: is there no fragment support for mupdf on the android repo? just activities? | 10:21.42 |
| sebras | deleet: what do you mean by fragment support? | 11:08.31 |
| | deleet: is this something in the android framework? | 11:08.45 |
| Robin_Watts | eleet: indeed. | 11:29.04 |
| | deleet: indeed. | 11:29.09 |
| deleet | sorry went out for lunch | 11:29.31 |
| | sebras: yes, fragments are the preferred way of building a UI after 3.0 | 11:30.02 |
| | Robin_Watts: is this something you would be interested in? I could build it as I'll likely use it | 11:30.23 |
| Robin_Watts | deleet: I'm sure we would be interested, yes! | 11:30.40 |
| deleet | ok cool | 11:30.46 |
| sebras | deleet: ah, I'm still running 2.3.5. | 11:36.33 |
| deleet | sebras: fragments work, via the compatibility package, all the way back to API 4 | 11:38.48 |
| Robin_Watts | sebras: I'm around about there too on my phone, but the tablet is newer. The nook is older. | 11:39.12 |
| sebras | Robin_Watts: from a testing perspective that's a good spread to ensure coverage. | 11:42.27 |
| Robin_Watts | sebras: yeah. Helen has a newer phone too. | 11:42.49 |
| deleet | what's the nook's version? | 11:42.58 |
| Robin_Watts | 2.1 ish | 11:43.08 |
| | no multitouch. | 11:43.25 |
| deleet | ah, that kinda sucks | 11:43.40 |
| Robin_Watts | There is a hack to add multitouch, I think. | 11:44.02 |
| | patches the kernel. | 11:44.05 |
| | but I've not been brave enough to do that, partly cos I think we should add non-multitouch support. | 11:44.25 |
| | and indeed non touch support for TV devices (for when my gamestick is delivered) | 11:44.42 |
| | kens: You could run the file through gs with a breakpoint in the gs_rop_run stuff... | 11:54.52 |
| kens | Robin_Watts : I suppose, yes, but its still a 6 page file | 11:55.08 |
| | I figure henry can reduce that way faster than I can | 11:55.31 |
| Robin_Watts | I do not deny that a simplified file would be... simpler. :) | 11:55.37 |
| kens | I *think* I may have a solution for #694412 which gives at least one progression and not more than 2 regressions | 11:56.34 |
| | (2 files downloading to check the originals) | 11:56.44 |
| Robin_Watts | bug 694412 | 12:01.01 |
| kens | yes | 12:01.15 |
| Robin_Watts | (sorry, I can click bug 694412, but not #694412 :) ) | 12:01.31 |
| kens | Hmm, I thought ray said the other way around.... | 12:01.46 |
| Robin_Watts | # means channel. | 12:02.07 |
| kens | well, neither way does anythign for me, I need a URL | 12:02.32 |
| Robin_Watts | Ah, so this bug relates to the stroke/fill color stuff. | 12:02.47 |
| | kens: Or you need to use Chatzilla :) | 12:02.57 |
| kens | Yes, and it id making my head spin somewhat | 12:02.58 |
| | I did use Chatzilla, now I use Miranda | 12:03.14 |
| Robin_Watts | Does miranda do skype? | 12:05.44 |
| kens | No idea | 12:05.49 |
| | I would doubt it since its a chat client | 12:06.00 |
| Robin_Watts | "Skype plugin interface with the actual skype program." | 12:06.17 |
| kens | My current installation doesn't hav a skype plugin | 12:06.43 |
| Robin_Watts | I think you still need to install skype itself though. | 12:07.07 |
| deleet | Robin_Watts: people (myself included) quite like the new way of zooming in the new google maps (tap and hold, move finger up/down to zoom while holding) | 12:07.12 |
| Robin_Watts | kens, chrisl: Are either of you set up on skype yet? | 12:07.18 |
| kens | Nope | 12:07.23 |
| deleet | I think that would be a great idea to counter the lack of multitouch | 12:07.26 |
| Robin_Watts | deleet: paulgardiner and myself used to work on a piece of software that used tap-drag. | 12:07.52 |
| | you'd do a double click but not release the second click. drag that up/down to zoom. | 12:08.23 |
| deleet | pretty much yeah | 12:08.36 |
| Robin_Watts | That keeps both tap and drag free for other things like selection. | 12:09.04 |
| kens | Hmm,old code takes 4'19 seconds, new code takes 3.5 seconds | 12:10.52 |
| Robin_Watts | old being current, and new being current+your fix? | 12:11.27 |
| kens | yes | 12:11.31 |
| | speeds up by about 75 times | 12:11.42 |
| Robin_Watts | oh, 4 minutes 19 seconds ? | 12:11.55 |
| kens | indeed | 12:11.59 |
| deleet | that's what the ' stands for :P | 12:12.05 |
| Robin_Watts | I was just thinking that 4.19 -> 3.5 wasn't much :) | 12:12.12 |
| kens | :-) | 12:12.19 |
| Robin_Watts | deleet: I had my "kens keyboard" filter working :) | 12:12.23 |
| deleet | haha k | 12:12.31 |
| tor8 | kens, Robin_Watts: I've used the Skype plugin with Adium on macosx | 12:12.31 |
| kens | yep, could easily be a typo from me | 12:12.32 |
| tor8 | I wouldn't recommend doing the same with miranda, given how many bugs there were | 12:12.45 |
| | first of all you need to have skype open and logged in for it to work... | 12:13.01 |
| Robin_Watts | I like skype. | 12:13.08 |
| tor8 | and then messages would randomly *not* get passed through to the plugin | 12:13.08 |
| | Robin_Watts: do you use skype on windows or mac? | 12:13.21 |
| kens | Miranda appears to have a skype plugin | 12:13.24 |
| | 'limited support for skype' | 12:13.36 |
| tor8 | kens: the skype plugin API is buggy as hell, and requires skype to be running | 12:13.38 |
| Robin_Watts | of course it remains to be seen how efficiently ms can screw it up. | 12:13.52 |
| tor8 | so you may as well just use skype, since you've still got it open | 12:13.55 |
| Robin_Watts | kens: yeah. that was the thing I pasted above. | 12:14.00 |
| tor8 | Robin_Watts: skype on macosx tries to be "smart" about eliding time stamps | 12:14.11 |
| Robin_Watts | I use skype both on windows and mac (and I have it on android too) | 12:14.12 |
| kens | Robin_Watts : I didn't see yo uposted anything, sorry | 12:14.19 |
| | There's one that says it doesn't need teh skype client too | 12:14.42 |
| tor8 | so you only get time stamps when the "talker" changes... meaning if you get a new message five days later from the same person, it won't gave a time stamp on it | 12:15.02 |
| Robin_Watts | chrisl has a newish laptop, right? So he's probably got a webcam on that. | 12:15.07 |
| | tor8: ugh. | 12:15.18 |
| tor8 | Robin_Watts: actually, I think they may have fixed that very recently (like in the past week) but it was like that for *years* | 12:15.53 |
| Robin_Watts | tor8: So I have the code working to load hint table data. | 12:16.40 |
| | now I'm trying to figure out how to use it. | 12:16.56 |
| | I am considering having a 'preload' call that apps can make that will tell the underlying stream what areas of the stream will be required for a page. | 12:17.50 |
| | Being called for lunch. | 12:19.02 |
| kens | I wonder if Marcos fell of the net | 12:42.34 |
| | 6 nodes down | 12:42.44 |
| zeniko | Robin_Watts: ping | 14:14.05 |
| Robin_Watts | pong | 14:14.11 |
| | hi, welcome to #ghostscript :) | 14:14.20 |
| zeniko | so, I've got my casper account set up and am ready for the next steps | 14:14.35 |
| Robin_Watts | ok, so you primarily work on windows? | 14:15.02 |
| zeniko | yes, I'm currently pretty much Windows-only | 14:15.20 |
| Robin_Watts | ok, me too. | 14:15.32 |
| | So presumably you are set up using putty to get into casper? | 14:15.59 |
| zeniko | PuTTY and also the ssh shipping with msys git | 14:16.30 |
| Robin_Watts | ah, ok. I always had problems with the msys git ssh. | 14:16.46 |
| | but if it works for you, that's fine. | 14:16.54 |
| zeniko | took me a while figuring out where to put the authentication keys | 14:17.23 |
| Robin_Watts | so the way we work is that all make a 'repos' dir on casper in our home directory. | 14:17.30 |
| zeniko | done | 14:17.40 |
| Robin_Watts | and we clone from the main mupdf repo into that. | 14:17.46 |
| | I personally have it set up on my local machine so that the main mupdf repo is a remote called 'golden' and my personal repo is called 'origin'. | 14:18.18 |
| | The idea is that we "pull --rebase golden master" to get changes pulled in to our local copies. | 14:18.46 |
| | and we then publish that to origin master. | 14:19.01 |
| sebras | zeniko: hi'ya! | 14:19.15 |
| zeniko | sebras: hey'ya back! | 14:19.26 |
| Robin_Watts | Any change we make is then reviewed by at least 1 other person before we push it to golden. | 14:19.36 |
| zeniko | I don't suppose you're working on casper all the time, | 14:20.05 |
| Robin_Watts | zeniko: No, I work on my windows PC all the time. | 14:20.20 |
| zeniko | so you push/pull from home to your casper repo and from there to golden? | 14:20.45 |
| Robin_Watts | Or direct from my local (windows PC) repo to and from golden. | 14:21.12 |
| | but in general we stage through our personal repos on casper, yes. | 14:21.22 |
| | That's essentially where stuff goes for review. | 14:21.39 |
| | So it sounds like you've pretty much got that sorted out. | 14:22.05 |
| | The big thing left is our regression system. | 14:22.21 |
| zeniko | before we get to that: | 14:22.35 |
| Robin_Watts | ok. | 14:22.40 |
| zeniko | what's the read-write git URL for casper? | 14:22.47 |
| Robin_Watts | For me I have: | 14:23.05 |
| | origin robin@ghostscript.com:/home/git/user/robin/mupdf.git | 14:23.16 |
| | golden robin@ghostscript.com:/home/git/mupdf.git | 14:23.26 |
| sebras | zeniko: http://git.ghostscript.com/ if you click on any projects you will have the git urls at the top. | 14:23.37 |
| Robin_Watts | cluster regression@ghostscript.com:/home/regression/cluster/gitbridge/mupdf | 14:23.41 |
| | i.e. we don't use git:/ for read/write, we use ssh based connections. | 14:24.10 |
| chrisl_r61 | Robin_Watts: with gitbridge for the cluster, does that remove the need for the regression ssh keys, or not? | 14:24.33 |
| Robin_Watts | chrisl_r61: You need the regression ssh key to connect to the gitbridge. | 14:25.04 |
| chrisl_r61 | So, do you want me to put the cluster keys in place for zeniko? | 14:25.24 |
| Robin_Watts | It removes the need for rsync on the local machine :) | 14:25.26 |
| | chrisl_r61: The permitted command list will need editing yes. | 14:26.02 |
| | chrisl_r61: I can muddle through most stuff, but you'll probably be faster than me. | 14:26.55 |
| | zeniko: So are you happy with that? | 14:27.43 |
| chrisl_r61 | Robin_Watts: hmm, permitted command list? | 14:27.49 |
| Robin_Watts | We can all use the cluster_key to get into the regression account. | 14:28.13 |
| zeniko | Robin_Watts: yes, I managed to successfully clone from casper | 14:28.22 |
| Robin_Watts | but we are only allowed to run certain commands. | 14:28.25 |
| zeniko | except that in /home/git/user I'd need a symlink for your URLs to work | 14:29.02 |
| Robin_Watts | zeniko: OK, so the regression system. | 14:29.08 |
| | will add that now. | 14:29.12 |
| zeniko | thanks! regressions then... | 14:29.44 |
| chrisl_r61 | Robin_Watts, zeniko: I've out the regression ssh key in the right place..... | 14:29.52 |
| Robin_Watts | zeniko: symlink should be there. | 14:30.10 |
| | so, you'll need to copy /home/marcos/cluster_key to your local machine from casper. | 14:30.55 |
| | and you'll need to set up the cluster remote that I pasted earlier on your local repo. | 14:31.47 |
| | [just trying to find the notes I wrote about this] | 14:32.28 |
| zeniko | "cat: cluster_key: Permission denied" | 14:33.02 |
| Robin_Watts | zeniko: OK. I've mailed the instructions to you. | 14:34.36 |
| | Let me find you the bits you need. | 14:34.48 |
| | You can download the gitpush.sh script from here: http://git.ghostscript.com/?p=ghostpdl.git;a=tree;f=gs/toolbin/localcluster;h=55c26739494e6a3c4b37a67c4e45f95c8e5d4ac7;hb=0903afb23777cfee2cb2a5015990c174e6a54742 | 14:35.50 |
| | Those instructions are written from the point of view of people cluster testing ghostscript, but the principles are the same for mupdf. | 14:37.56 |
| | ok, ignore the cluster_key stuff before. I think that's not needed now. | 14:38.49 |
| zeniko | ssh regression@ghostscript.com fails with "Permission denied (publickey)" | 14:40.00 |
| Robin_Watts | ok, we need to add your key to the regression account too. | 14:40.44 |
| | Try now? | 14:43.12 |
| zeniko | as for gitpush.sh: I assume you're working inside git's bash console (not the cmd.exe one) | 14:43.27 |
| Robin_Watts | zeniko: Yes. | 14:43.39 |
| zeniko | ssh regression@ghostscript.com works now, thanks | 14:44.07 |
| Robin_Watts | Although if you set it up so that "git cluster" works, then I think that should work in cmd.exe if you have the paths set to make git work in cmd windows. | 14:44.36 |
| | So rather than: "git cluster pcl" as the instructions say, try "git cluster" | 14:45.04 |
| zeniko | I'll look into that, as I prefer the cmd.exe environment | 14:45.20 |
| Robin_Watts | zeniko: I recommend "Console 2" off sourceforge (make sure you get the beta version). Lets you have a single window up with lots of tabs in, so you can swap between cmd and bash etc easily. | 14:46.27 |
| | Also has sane cut and paste. | 14:46.44 |
| zeniko | for certain values of "sane" ;-) | 14:47.12 |
| Robin_Watts | 'saner' :) | 14:47.19 |
| | So, what does: "git cluster" say ? | 14:51.06 |
| zeniko | it's currently pushing something somewhere | 14:52.12 |
| | then "remote: You're not allowed to run 'rsync --server ...'" | 14:52.30 |
| Robin_Watts | right, that's the permitted commands thing. Let me look for that. | 14:52.49 |
| chrisl_r61 | Crap, my ssh terminal to casper keeps freezing - it's really p*ssing me off! | 14:53.53 |
| Robin_Watts | zeniko: Try again now ? | 14:54.55 |
| | Woo Hoo! | 14:56.04 |
| | OK. Bookmark this URL: http://ghostscript.com/regression/ | 14:56.15 |
| | That's the regression dashboard. | 14:56.26 |
| | Top left shows the list of cluster nodes, whether they are up or down, what they are doing etc. | 14:56.55 |
| | So at the moment they are running your mupdf test job. | 14:57.07 |
| | Under that you'll see the Job queue. Red jobs have run already. A green job is currently running, and if there were more jobs queued after yours they would be amber. (I like traffic lights) | 14:57.57 |
| | In fact, there you go, 2 new jobs have just been posted (the page should update for you every 20 seconds or so) | 14:58.19 |
| chrisl_r61 | just for illustration purposes ;-) | 14:58.33 |
| Robin_Watts | Whenever anything gets committed, we automatically queue test jobs. | 14:58.55 |
| | The cluster runs the jobs and keeps the md5 sums of the results. That way it can tell you which files change each time. | 14:59.35 |
| | If you click on a "passed" link, you'll get a new tab up with the details of which jobs changed etc. | 15:00.26 |
| zeniko | if there are changes, how do you figure out the details? | 15:01.08 |
| Robin_Watts | I'll get to that in a mo. | 15:01.21 |
| | For cluster jobs caused by commits you'll see the differences from the last test that ran. | 15:01.24 |
| | For user jobs you'll see 2 sets of differences; differences from the last commit based job that ran (what we call 'differences from baseline') and also differences from the last user job you ran. | 15:02.21 |
| | So, as you point out, this can tell you what files have changed, but not how they've changed. | 15:02.49 |
| | To see how they've changed, you can do "git cluster bmpcmp" | 15:03.03 |
| | That runs a new test, where it only tests the files that differed in the last non-bmpcmp test. | 15:03.31 |
| | and instead of generating md5 sums, it runs an old binary and a new binary and compares the bitmaps produced. | 15:03.49 |
| | And it produces a list of all those differences in an easy-to-read form in an html page. | 15:04.19 |
| | Which I will show you in a mo. | 15:04.35 |
| | So, continuing to look at the dashboard. | 15:04.52 |
| | Let's ignore the delta and logs and search things for now. | 15:05.31 |
| | In the bottom right there are the "User links:" | 15:05.56 |
| henrys | chrisl:I guess I had bad permissions somewhere ⦠I noticed the email just before bed, thanks for following up. | 15:06.19 |
| Robin_Watts | When your user job finishes, the green line will disappear. | 15:06.19 |
| | and the report will be available by clicking "zeniko" in the user links. | 15:06.49 |
| | bugger, said pooh. That's not working. | 15:07.19 |
| zeniko | another permission issue? | 15:07.42 |
| chrisl_r61 | henrys: np. It was the file ownership - the key file was still owned by Robin's user and group - and ssh is understandably picky about such things! | 15:07.46 |
| Robin_Watts | probably me not setting it up right. give me a mo. | 15:07.56 |
| chrisl_r61 | zeniko: did you get an e-mail saying the run had completed? | 15:08.55 |
| zeniko | chrisl_r61: not yet | 15:09.26 |
| Robin_Watts | OK, the emails.tab hadn't had zeniko added. | 15:10.58 |
| | so you can now get to the report on the web. | 15:11.13 |
| henrys | chrisl_r61:my lazy cp -pr ;-) | 15:11.14 |
| chrisl_r61 | ;-) | 15:11.21 |
| Robin_Watts | and next time you'll hopefully get a copy by email too. | 15:11.48 |
| zeniko | Robin_Watts: so no differences but a bunch of errors | 15:11.57 |
| henrys | whilst you are at it will you reenable hintak's account? | 15:12.05 |
| | chrisl_r61: ^^^ | 15:12.24 |
| Robin_Watts | zeniko; I think those reports are spurious because it's the first run. | 15:12.28 |
| | and hence there is no previous run to compare with. | 15:12.43 |
| chrisl_r61 | henrys: yeh, okay | 15:12.54 |
| henrys | I'm off have a good "rest of week" everyone | 15:13.01 |
| Robin_Watts | Now I'll need to set you up a bmpcmp password. | 15:13.06 |
| | henrys: have fun! | 15:13.09 |
| kens | Robin_Watts : aer you taking a note of all the things you've done to get zeniko working ? | 15:15.53 |
| Robin_Watts | kens: I wasn't. | 15:18.07 |
| kens | Might be useful for another occasion | 15:18.21 |
| Robin_Watts | zeniko: I've just mailed you a password that you'll need to use to get to the bmpcmp results. | 15:18.46 |
| | If you click on the "bmpcmp" link to the right of (say) kens, it'll ask you for a username and password. Just let your browser remember it. | 15:20.02 |
| zeniko | Robin_Watts: seems to work, I assume "The requested URL /~regression/zeniko was not found on this server." is expected without any bmpcmp runs | 15:20.29 |
| Robin_Watts | yeah. | 15:20.39 |
| | Let's use kens as an example of what you'll expect to see. | 15:20.57 |
| kens | Its fine to look at my last one | 15:21.00 |
| Robin_Watts | At the top the "0 1 2 3" is the list of pages of the results. We start on page 0 obviously enough :) | 15:21.46 |
| | Then we list each job tested. | 15:22.01 |
| kens | Because we're geeks :-) | 15:22.02 |
| Robin_Watts | for each job you will get 1 or more sets of 3 bitmaps. | 15:22.27 |
| | They are candidate/reference/diff | 15:22.44 |
| kens | Number 17 on there is an example of a regression | 15:22.46 |
| Robin_Watts | or new/old/diff if you prefer. | 15:22.52 |
| kens | number 23 is a progression | 15:23.06 |
| Robin_Watts | So looking at number 17. | 15:24.14 |
| | The green pixels in the diffs tell you where the changes were. | 15:24.24 |
| | but it's not immediately obvious exactly what has changed (at least to my crap eyes) | 15:24.47 |
| | so, if you hold ctrl down and roll the mouse pointer into and out of the leftmost image, it swaps with the middle image. | 15:25.18 |
| | hence you can 'blink' back and forth and spot differences. | 15:25.34 |
| kens | Not on Firefox | 15:25.35 |
| zeniko | kens: lucky I'm using Chrome, then ;-) | 15:26.19 |
| Robin_Watts | kens: yeah, ok, not on firefox on windows. | 15:26.23 |
| kens | :-) | 15:26.28 |
| | Worth mentioning, just in case | 15:26.33 |
| Robin_Watts | It works on macos on firefox and on chrome, and on every bloody other browser. | 15:26.44 |
| kens | Actually it doesn't work for me on Chrome either | 15:27.02 |
| Robin_Watts | Alternatively, roll the mouse pointer into the middle image and you get a zoom. | 15:27.09 |
| | kens: have you disabled javascript ? | 15:27.14 |
| kens | Not on Chrome, no | 15:27.21 |
| Robin_Watts | hmm. Works for me. | 15:27.35 |
| | You're holding ctrl down? | 15:27.41 |
| kens | Yes | 15:27.46 |
| | All I get is the popup of the candidate blah blah | 15:28.08 |
| zeniko | hm, works for me in Firefox (22) as well | 15:28.08 |
| kens | Not that it matters anyway | 15:28.49 |
| Robin_Watts | works for me in firefox too. | 15:28.57 |
| zeniko | as for the differences image: does bmpcmp distinguish between minor and major differences? | 15:29.29 |
| Robin_Watts | anyhow, leaving kens broken browsers aside for now... That's the bmpcmp page. | 15:29.33 |
| | zeniko: Yes, green and red colored differences. | 15:29.48 |
| | green is major I think, and red is minor. | 15:30.03 |
| | (There are a bunch of flags you can use to bmpcmp so it will do 'fuzzy' checking too, and that can affect the output, but let's not worry about that for now) | 15:30.51 |
| | On the last page of the results, we list any files that we tested but didn't find any differences in. | 15:31.42 |
| | Also, we have an index of all the tests, so if you're hunting for a particular one, you can find it there. | 15:32.09 |
| | hmm. the index takes you to the right page of the results at least. I should fix it to take you to the actual image. | 15:32.52 |
| zeniko | is there any way to download one such file so that you don't have to re-run the cluster while figuring out what might have changed in a commit? | 15:33.16 |
| Robin_Watts | zeniko: All our regression files live in SVN. | 15:33.45 |
| | Now you have access to casper, you have access to the svn repo with them in. | 15:34.10 |
| | A full svn checkout of the files is large. | 15:34.29 |
| | 54Gig or so, according to my windows PC. | 15:35.07 |
| zeniko | luckily, SVN allows partial checkouts - I've only got 10GB left to spare | 15:35.24 |
| Robin_Watts | Currently we have no nice way of getting a single file out. Possibly that's something I could add. | 15:36.01 |
| kens | I just pull the file I want from peeves | 15:36.19 |
| zeniko | where does the svn repo live on casper? | 15:36.39 |
| Robin_Watts | zeniko: see private message | 15:37.51 |
| | kens: not everyone has access to peeves. | 15:37.57 |
| kens | Hmm, I guess not | 15:38.04 |
| Robin_Watts | zeniko: In the short term, unless you particularly like wrangling svn, it may be easiest to just ask one of us to mail you a file. | 15:39.06 |
| zeniko | Robin_Watts: my irc client seems to have kept the private message to itself :-( | 15:39.15 |
| Robin_Watts | which irc client? | 15:39.31 |
| zeniko | Miranda | 15:39.38 |
| Robin_Watts | ah, ken is a miranda user. I use chatzilla personally. On chatzilla I get a new tab along the bottom. | 15:40.14 |
| kens | on miranda you get an icon in the main miranda window | 15:40.37 |
| Robin_Watts | actually, it's safe to paste these in here I think. | 15:40.46 |
| mvrhel_laptop | ugh this windows phone stuff is just a mess | 15:40.51 |
| kens | messages zeniko | 15:41.05 |
| mvrhel_laptop | I keep thinking I have everything figured out only to hit another wall | 15:41.11 |
| Robin_Watts | the "tests_private" files are found within the tests_private directory in the svn+ssh://regression@svn.ghostscript.com/var/lib/svn-private/ghostpcl repo | 15:41.25 |
| deleet | irssi > * | 15:41.44 |
| Robin_Watts | the "tests" files are found within the tests directory in the svn+ssh://regression@svn.ghostscript.com/svn/ghostscript repo. | 15:42.05 |
| | Ignore any source you see in those repos - it's very out of date. We use git now. | 15:42.22 |
| zeniko | kens: I get the blinking icon, but nothing else :-( | 15:42.29 |
| kens | click the icon | 15:42.39 |
| | right click I should say | 15:42.50 |
| | then choose message I think | 15:42.56 |
| | zeniko try messaging me | 15:43.27 |
| | right click kens in the list of nicks | 15:43.45 |
| zeniko | kens: selected "Message" and sent you one | 15:44.22 |
| kens | Yes I replied | 15:44.29 |
| | You don't get a new message window ? | 15:44.49 |
| | titled 'message session' | 15:45.02 |
| zeniko | still doesn't work... | 15:45.02 |
| kens | weird | 15:45.06 |
| | Its not vital, its not somethgin we use a lot | 15:45.53 |
| chrisl_r61 | kens: (sorry to intrude) given that I just pushed the fonts update, you *might* get some unexpected results from your clusterpush..... | 15:46.08 |
| kens | chrisl_away : I know, not to worry | 15:46.20 |
| | I know what I'm looking for in my output | 15:46.30 |
| chrisl_r61 | I just didn't want you to panic! | 15:46.38 |
| kens | :) | 15:46.43 |
| zeniko | Robin_Watts: so one cluster run takes just a few minutes? | 15:46.51 |
| Robin_Watts | zeniko: For MuPDF, yes. about 5 minutes. | 15:47.03 |
| kens | Depends on the selected configuration, MuPDF is much faster than GS | 15:47.11 |
| Robin_Watts | a mujstest run takes longer. | 15:47.15 |
| | pcl is 10 minutes or so. gs is 20+ | 15:47.29 |
| | a full "gs pcl xps ls" one is 40+ minutes | 15:47.44 |
| kens | Which is what I'm doing :-( | 15:47.56 |
| chrisl_r61 | I don't think there is an "ls" one, now, is there.... | 15:48.16 |
| kens | Its on the dashboard that way | 15:48.34 |
| Robin_Watts | chrisl_r61: There is, but it may not do anything :) | 15:48.44 |
| chrisl_r61 | Ah, true! | 15:48.55 |
| Robin_Watts | When it comes to picking which job to run next, the cluster takes queued user jobs first. | 15:49.11 |
| | (in preference to commit ones) | 15:49.24 |
| zeniko | and running 'git cluster' just tests the most recent commit on the current branch in my local repo? | 15:49.41 |
| chrisl_r61 | Okay, I'm going to find out what a double squash training session in this heat is like - if I don't return, think well of me........ | 15:50.05 |
| Robin_Watts | running "git cluster" does a "git stash" and pushes that up for testing. | 15:50.13 |
| | chrisl_r61: urk. have "fun". | 15:50.21 |
| chrisl_r61 | Hmm, I'll try...... | 15:50.34 |
| zeniko | that's convenient | 15:51.14 |
| Robin_Watts | just remember that if you have created new files and not git added them yet, they won't get sent. | 15:51.33 |
| | I get bitten by that every time, and I coded it! | 15:51.41 |
| zeniko | good to know, so better to commit first after all | 15:52.13 |
| | another question: is the jbig2dec repo two-way sync'd with the ghostpdl one? | 15:52.13 |
| Robin_Watts | zeniko: No. The jbig2dec one is produced *from* the ghostpdl one on a cron job. | 15:52.48 |
| | So we commit to ghostpdl and it magically appears a bit later in the jbig2dec one. | 15:53.16 |
| zeniko | so if henrys asks me to commit to jbig2dec, I'll have to work on ghostpdl | 15:53.47 |
| Robin_Watts | zeniko: yeah. | 15:54.02 |
| zeniko | does the sync'ing script also update the mupdf repo with an updated hash for jbig2dec when new commits are copied over? | 15:54.49 |
| Robin_Watts | Or prepare the commit on the jbig2dec repo and git format-patch it and pass it to one of us. | 15:54.54 |
| | zeniko: No, we need to do a new mupdf.git commit to update the submodule. | 15:55.20 |
| zeniko | so there's no easy way to test jbig2dec changes using mupdf on the cluster? | 15:55.56 |
| Robin_Watts | ooh, yeah, that might be tricky... | 15:56.47 |
| | Actually, there may be a way. | 15:57.26 |
| | Let me just check the cluster code. | 15:57.32 |
| | Right. If you use "git cluster", then you're reliant on git submodules to get the thirdparty libraries there, hence checking changes is hard | 15:59.06 |
| | If you use the rsync based method, then we transfer submodules with all their changes along with the source. | 15:59.37 |
| | There are 2 ways we could do that. | 15:59.59 |
| zeniko | Robin_Watts: would it work if I changed .gitmodules so that jbig2dec points at my own repo including additional changes? | 16:00.02 |
| Robin_Watts | it might. | 16:00.22 |
| | 1) we could set up a checkout of mupdf on casper, and you'd make changes there and trigger cluster jobs from that. | 16:00.53 |
| | that would require you to be happy to work on unix at least a bit. | 16:01.11 |
| | 2) you can install cygwin on your windows box, and we can set that up to trigger cluster jobs. | 16:01.36 |
| | http://ghostscript.com/~robin/HowToClusterPushOnWindows.txt has instructions for the cygwin based method. | 16:02.34 |
| | Do you have cygwin installed ? | 16:02.40 |
| zeniko | I used to, but now happily get by without it | 16:02.58 |
| Robin_Watts | yeah, I hear that. | 16:03.27 |
| zeniko | I'll try changing .gitmodules when I actually need testing jbig2dec and if that doesn't work we can always look into one of your two alternatives | 16:03.35 |
| Robin_Watts | fab. | 16:03.42 |
| zeniko | BTW: am I even allowed to push to ghostpdl proper at all? | 16:04.06 |
| Robin_Watts | zeniko: possibly not. There is some voodoo that needs doing with groups etc. | 16:04.37 |
| | We (the mupdf developers) have been trying a simple review thing (at least 1 other person must look at a commit before we push it) for a while now, and it seems to work well. | 16:05.57 |
| | Stops (most) stupid mistakes, and gets most of the niggling "I would have preferred the function to be called xxxx rather than yyy" type complaints out of the way early. | 16:06.44 |
| mvrhel_laptop | brb | 16:07.05 |
| zeniko | sounds reasonable | 16:07.08 |
| Robin_Watts | so there will always be someone else that needs to be involved and can do the push to golden for you. | 16:07.14 |
| | And we can sort out direct pushing later if we need it (probably need to check with henrys) | 16:07.37 |
| zeniko | henrys seemed to have asked something like that in bug 694125 | 16:08.06 |
| | but I'd be happy with posting git format-patch output for jbig2dec for the time being | 16:08.28 |
| Robin_Watts | zeniko: right. He'll be back on monday or tuesday I think, so we only need to cope til then. | 16:08.54 |
| zeniko | I won't be around next week, so there's no need to rush anyway | 16:09.35 |
| | last question: who's responsible for the 'Owner' name shown in git.ghostscript.com repositories? | 16:10.08 |
| Robin_Watts | you are, I think. | 16:11.36 |
| tor8 | zeniko: git config web.owner | 16:11.51 |
| | ahem, gitweb.owner | 16:11.59 |
| zeniko | tor8: thanks - and that even works with umlauts! | 16:14.45 |
| tor8 | I was a bit worried that gitweb might get encoding-confused | 16:15.35 |
| zeniko | tor8, Robin_Watts: I've had a few issues when merging your latest pagetree changes | 16:17.04 |
| Robin_Watts | zeniko: it was a fairly big rework. | 16:17.42 |
| zeniko | pdf_lookup_page_number used to return -1 for invalid objects, now it may return 0 (pointing at the first page) | 16:17.44 |
| | I've got at least one document (1172 from my collection) which has "/Parent null" and now leads to an unexpected throw which breaks its outlines | 16:19.15 |
| Robin_Watts | Well, /Parent null is a broken file, right? | 16:19.51 |
| | Having pdf_lookup_page_number return -1 seems fair enough. Let me look at that. | 16:20.11 |
| zeniko | "/Parent null" is not broken enough for Adobe Reader - it just ignores it | 16:20.27 |
| | also, I'd be fine with pdf_lookup_page_number throwing (it couldn't throw previously but now can anyway on cycles) | 16:21.00 |
| Robin_Watts | throwing would be neater, I suspect. | 16:21.34 |
| zeniko | its callers might need some adjustment then, though (maily the outline loading code in pdf-outline.c) | 16:21.42 |
| | please see the "SumatraPDF:" comments in https://code.google.com/p/sumatrapdf/source/detail?r=8285 for what I had to amend during the merge to prevent major regressions | 16:22.07 |
| Robin_Watts | I'm currently adding the ability to display files as they download. | 16:23.18 |
| | We use curl to fetch from an http source. | 16:23.25 |
| | If the file is linearized, we get the first page out quickly. | 16:23.41 |
| | If the file is linearized and the hint stream isn't broken and we can do byte requests, we get each page out quickly on demand. | 16:24.16 |
| | If the file is linearized and the hints stream is broken, we can get incomplete renderings for pages that will improve as things like fonts are downloaded. | 16:25.06 |
| | If the file isn't linearized, but we have byte requests, we can get pages out, but it can take a long time to read the xrefs (20%+ of pdf_reference17.pdf is xrefs). Once we have the xrefs, the pages come out quickly though. | 16:26.08 |
| | If the file isn't linearized and we don't have byte requests, you have to wait for the whole thing to download. | 16:26.45 |
| | haha, | 16:34.04 |
| | http://www.vogue.co.uk/ | 16:34.06 |
| | Open that website, and enter the konami code (up, up, down, down, left, right, left, right, b, a) and keep hitting a. | 16:34.42 |
| sebras | Robin_Watts: fatal: remote error: access denied or repository not exported: /user/zeniko/mupdf.git | 16:34.45 |
| | zeniko: or to you, if you know how to fix it. :) I never remember. | 16:35.20 |
| tor8 | touch git-daemon-export-ok | 16:35.40 |
| kens | Hmm, interesting way to enter debugger | 16:35.53 |
| Robin_Watts | kens broken browser strikes again. | 16:36.25 |
| kens | Chrome | 16:36.36 |
| | Firefox isn't running java on 6 of the sties linked from that one | 16:36.53 |
| Robin_Watts | works for me. You should see dinosaurs in hats. | 16:37.05 |
| kens | Nope | 16:37.09 |
| sebras | Robin_Watts: confirmed. | 16:37.18 |
| Robin_Watts | kens: What version of chrome have you installed? And what extensions? | 16:37.34 |
| kens | No extensions | 16:37.39 |
| Robin_Watts | I'm using 28.0.1500.71 m | 16:37.48 |
| zeniko | sebras: shoulnd't it be /user/zeniko/mupdf/.git (note the additional slash)? | 16:38.00 |
| kens | version is the same | 16:38.13 |
| Robin_Watts | zeniko: Depends if you made a bare repo or not. | 16:38.21 |
| sebras | zeniko: nope, git://git.ghostscript.com/user/sebras/mupdf.git works well. | 16:38.32 |
| zeniko | Robin_Watts: I've still got to figure out how to make a bare repo :-) | 16:38.45 |
| sebras | zeniko: but you need to enter tor8's command while in the repository file. | 16:38.52 |
| | zeniko: 16:35 < tor8> touch git-daemon-export-ok | 16:39.01 |
| kens | have to dash, night all | 16:39.06 |
| zeniko | sebras: better? | 16:39.44 |
| sebras | zeniko: eh.. repository directory (on casper). | 16:39.44 |
| tor8 | zeniko: we usually have bare repositories in $HOME/repos | 16:39.44 |
| Robin_Watts | zeniko: git clone --bare /home/git/mupdf.git mupdf.git | 16:39.52 |
| tor8 | otherwise it's annoying to set up pushing to them | 16:40.08 |
| Robin_Watts | tor8: Do you want to look at zenikos pagetree fixes? or shall I ? | 16:41.56 |
| tor8 | Robin_Watts: I'm about to head out for dinner. I'll look at them later if you're busy now. | 16:42.39 |
| zeniko | sebras: should work now | 16:43.15 |
| Robin_Watts | And wired.co.uk has the same thing (but dinosaurs in VR goggles etc) | 16:43.50 |
| tor8 | Robin_Watts: with the same speling eror in innited :) | 16:44.34 |
| sebras | zeniko: excellent, thanks! | 16:44.48 |
| Robin_Watts | And http://www.gq-magazine.co.uk/ | 16:46.04 |
| sebras | Robin_Watts: you have been reading the konami code page on wikipedia..? | 16:51.42 |
| Robin_Watts | sebras: No... | 16:51.50 |
| | tor8: I shall leave them to you to look at, as I want to push on with the progressive stuff for a bit more tonight. | 16:54.05 |
| zeniko | dinner's calling | 16:54.22 |
| | Robin_Watts: so thanks for the extensive walk through your infrastructure! | 16:54.25 |
| Robin_Watts | zeniko: No worries. | 16:54.31 |
| mvrhel_laptop | wtf. this managed code debugging is crap. | 17:16.20 |
| | I suspect I have an interface issue with my winrt library | 17:16.48 |
| ray_laptop | mvrhel_laptop: I have a couple of questions. Do you have a minute (or two) ? | 17:19.17 |
| mvrhel_laptop | ray_laptop: sure | 17:19.27 |
| | ray_laptop: let me help get kids out door to swim lessons first | 17:19.56 |
| | brb | 17:19.58 |
| ray_laptop | mvrhel_laptop: np. | 17:20.06 |
| mvrhel_laptop | ray_laptop: ok I am back | 17:26.45 |
| ray_laptop | mvrhel_laptop: thanks. | 17:26.53 |
| | I hope you haven't flushed GS from your little gray cells yet | 17:27.17 |
| mvrhel_laptop | yes. let me start that solution up | 17:28.31 |
| ray_laptop | mvrhel_laptop: First, the dev->icc_struct looks to me like it is all set up via put_params. Is that correct ? Thus if I do a get_params on a device, get a new device, and then put those params, the new device will have the correct icc_struct. Does this sound correct ? | 17:29.06 |
| mvrhel_laptop | ray_laptop: yes that sounds correct | 17:29.51 |
| | the only trick is if you had a device like the pdf14 device in the way | 17:30.18 |
| ray_laptop | OK. That's what I thought (and was hoping). | 17:30.28 |
| mvrhel_laptop | that is the only one that can and will change itself different than the real target device | 17:30.48 |
| ray_laptop | mvrhel_laptop:right. I am doing this on a device for rendering BEFORE any has been done, so the pdf14 device isn't active yet | 17:31.10 |
| mvrhel_laptop | that should all be fine then. | 17:31.25 |
| ray_laptop | mvrhel_laptop: now the 'gs_devn_params' ... | 17:31.38 |
| mvrhel_laptop | ugh | 17:31.46 |
| | if we were on the phone I would say, sorry, going though a tunnel now | 17:32.13 |
| ray_laptop | It has pdf14_separations -- is that also only set up during processing ? | 17:32.23 |
| | mvrhel_laptop: you could always kill your wifi ;-) | 17:32.50 |
| | mvrhel_laptop: I've got a page saved as a clist and I want to process it. So do I have to capture the devn_params and set them in the rendering device before doing the page? | 17:33.56 |
| | mvrhel_laptop: in particular the pdf14_separations. It looks like other things are handled by devn_get/put_params | 17:35.08 |
| mvrhel_laptop | I am trying to remember why we have pdf14_separations and separations in devn_params | 17:35.17 |
| | that is, why the two sets | 17:35.32 |
| ray_laptop | all the comment says is " The PDF 1.4 compositor may also have a different list of separations." | 17:36.34 |
| | mvrhel_laptop: but not WHY. | 17:37.04 |
| | mvrhel_laptop: the pdf14_compressed_color_list (which I am going to punt on) I understand since blending creates different colorants. | 17:37.41 |
| mvrhel_laptop | I am picturing a case where I am going out to tiffsep, and I have a portion of the doc that has spots in a transparency and a different portion that has different spots outside. I suppose then, that the pdf14 device really should care about the spots that occur in the transparency areas | 17:38.43 |
| ray_laptop | (I'm NOT going to support the compressed_color_list at all) | 17:39.00 |
| mvrhel_laptop | so I can see why you would want it | 17:39.02 |
| | ray_laptop: that is fine. I don't think we will be using compressed color list again | 17:39.29 |
| | let me look over the stuff referencing pdf14_separations | 17:39.58 |
| | hold on | 17:40.00 |
| ray_laptop | mvrhel_laptop: I would think we'd want the 'separations' to include all separations on the device | 17:40.32 |
| mvrhel_laptop | yes definitiely | 17:40.46 |
| ray_laptop | mvrhel_laptop: OK. take your time. | 17:40.46 |
| mvrhel_laptop | ray_laptop: but the pdf14_separations are only those seps that occur in the pdf14 device. so that we don't create a larger buffer than needed | 17:41.20 |
| | when we start rendering the transparencies | 17:41.57 |
| ray_laptop | mvrhel_laptop: Ah, OK. so it is a subset of the 'separations' ? | 17:43.07 |
| mvrhel_laptop | that would be my expectations | 17:43.40 |
| | so when pdf14_put_devn_params occurs the pdf14_separations are set | 17:44.47 |
| | and that appears to be the only time | 17:45.01 |
| | which is only called from devn_printer_put_params | 17:46.07 |
| | hmm I am a little confused by this | 17:47.16 |
| | devn_printer_put_params ends up calling pdf14_put_devn_params | 17:47.37 |
| | which makes me think the lists will be the same | 17:48.17 |
| ray_laptop | mvrhel_laptop: so, it looks like put/get pdf14_params handle this via (special) parameters, i.e., PDF14NumSpotColors" and "PDF14SpotName_..." | 17:48.44 |
| | mvrhel_laptop: but, if I am setting these params BEFORE starting the pdf14 compositor has been hooked in, then I won't be calling pdf14_put_devn_params | 17:50.51 |
| mvrhel_laptop | right | 17:51.12 |
| ray_laptop | mvrhel_laptop: oops. No, it looks like devn_printer_put_params always calls it. So it _should_ be set up by capturing the params and just playing them back. | 17:53.01 |
| | mvrhel_laptop: I guess I need to try it :-) | 17:53.11 |
| mvrhel_laptop | that is what is bothering me that it is always called. | 17:53.22 |
| | what happens when there is no pdf14 device | 17:53.32 |
| ray_laptop | mvrhel_laptop: well the element is always there in the gs_devn_params | 17:53.51 |
| mvrhel_laptop | ok. but the purpose of the separate pdf14 separations then, is simply to allow someone to use PDF14NumSpotColors and PDF14SpotName | 17:54.35 |
| | I have never tried that before | 17:54.47 |
| | I wonder if it even would work with the planar changes not to mention all the earlier work in tranparency | 17:55.10 |
| ray_laptop | mvrhel_laptop: this is what I think will happen... | 17:55.16 |
| | mvrhel_laptop: the pdf14_separations starts out NULL. Once the compositor is installed, when the device is popped, the params will be collected when pdf14_clist_get_param_compressed_color_list calls get_param_spot_color_names. Then this paramlist will be 'put' into the target_device | 18:00.16 |
| | mvrhel_laptop: so when a page is done (the pdf14 device will have been popped for the page) and the target device params will have been updated | 18:01.10 |
| mvrhel_laptop | ok | 18:02.37 |
| ray_laptop | mvrhel_laptop: so when I 'get' them when the page has been completed, they _should_ be there and my 'put_params' will set them into the devn_params (whether or not the pdf14 device is present) | 18:02.55 |
| mvrhel_laptop | sounds reasonable. you are the params expert around here. | 18:03.48 |
| ray_laptop | mvrhel_laptop: then on the PDF14_PUSH_DEVICE when we render the page, we will have the pdf14_separations all set up to be copied into the pdf14->devn.separations that the PUSH does (line 7259) | 18:04.35 |
| | mvrhel_laptop: yeah, but I just wanted to make sure and understand the reason for the extra gs_separations entry | 18:05.28 |
| | mvrhel_laptop: I have to help with the kids... Thanks. bbiab | 18:05.48 |
| mvrhel_laptop | ray_laptop: ok tty | 18:05.56 |
| | ttyl | 18:06.03 |
| | back to fun | 18:24.33 |
| | every call to my winrt library ends up throwing an exception, and there is no clear way to debug why | 18:31.39 |
| ray_laptop | mvrhel_laptop: I sympathize. I recall trying to debug windows printer device code. It took me a while to figure out the tricks. I'm sure MS has learned out to obfuscate better since then :-/ | 18:35.02 |
| mvrhel_laptop | yes. it is really bad | 18:35.23 |
| ray_laptop | mvrhel_laptop: I wonder if getting the MS Developer stuff would help. More of it is accessible online now, but there may be more source code and examples with the license | 18:36.49 |
| mvrhel_laptop | perhaps. I am going to take a break in a bit and then come back to it. sometimes that helps | 18:37.23 |
| | what I may end up having to do is simplify things a bit to get things working and then start adding in the complexity to see where things break | 18:38.39 |
| | ok. so a very simple winrt object works. | 18:48.31 |
| ray_laptop | mvrhel_laptop: not much of a break ;-) | 18:49.00 |
| mvrhel_laptop | stupid debugger needs some setup though to step from c# to c++ | 18:49.18 |
| | aha | 19:02.06 |
| | http://www.developer.nokia.com/Community/Wiki/C%2B%2B_support_from_Windows_Phone_8 | 19:02.08 |
| | so you cant debug the managed and native code at the same time when working with the phone | 19:02.34 |
| | what a bunch of crap | 19:02.40 |
| Robin_Watts | mvrhel_laptop: Pfft. | 19:02.46 |
| mvrhel_laptop | with the windows store app (non phone) you can | 19:03.04 |
| Robin_Watts | Can you run two instances of the debugger, one for the managed and one for the native? | 19:03.15 |
| mvrhel_laptop | not sure | 19:03.47 |
| | but it is hard to believe that they could not have made this a little easier | 19:04.01 |
| | luckily the winrt stuff (native) is already debugged. just need to figure out why I am having issues getting the interface to work | 19:07.04 |
| | yeah! got it working | 21:12.14 |
| | stupid winmd file confusion | 21:12.35 |
| | with the namespaces | 21:12.40 |
| | I have to have a separate VS project for the winRT dll for windows 8 and for windows phone | 21:13.11 |
| | even though they share the same files | 21:13.19 |
| | so the project names are different but the name spaces are the same. the winmd file name has to match the namespace but was set up based upon the project name | 21:13.56 |
| Robin_Watts | mvrhel_laptop: Great. | 21:14.42 |
| mvrhel_laptop | stuff like this drives me crazy | 21:14.51 |
| | there is no documentation about little things like this | 21:15.01 |
| | they have one example of sharing a winRT project amongst windows phone and windows 8 and it said nothing about this | 21:15.29 |
| | it still blows that you can only do native or managed code debugging, but that should not be the end of the world. just glad I did the windows 8 stuff first | 21:16.40 |
| | omg. the stupid file picker does not work in windows phone. it will only work for photos or for files that are in the windows store. but it will work in native code, so I have to add that call into the winrt library | 21:41.58 |
| | Forward 1 day (to 2013/07/12)>>> | |
IRC Logs