| <<<Back 1 day (to 2012/08/13) | 2012/08/14 |
kens | Morning robin_watts_fone | 08:00.44 |
robin_watts_fone | morning. | 08:01.25 |
| limited WiFi here... | 08:01.57 |
kens | I sw in the irc logs | 08:02.06 |
| saw* | 08:02.14 |
sebras | http://goo.gl/HRUr0 sometimes I'm a bit annoyed by people. :-/ | 09:16.32 |
kens | Ah, another troll | 09:24.34 |
paulgardiner | sebras: Did you manage to install that apk? Bother signed and unsighed worked for me, but I did need to explicitly uinstall the old version first because the old version was signed and not with the same key. | 09:27.14 |
sebras | paulgardiner: no I didn't but then again I never uninstalled the previous app. why did we change key? wouldn't this make it a problem for placing this on android market, google play or whatever it is called nowadays..? | 09:37.55 |
paulgardiner | It wasn't that we changed the key. I put up an unsigned version, and then when you had problems with it, I created a key just in case that was the problem. I don't have access to our proper key... or at least I'd need to ask someone where it is. | 09:39.32 |
sebras | paulgardiner: after uninstalling the new version installed without a hitch. :) | 09:44.57 |
paulgardiner | Ah great. :-) | 09:45.05 |
sebras | paulgardiner: one thing I have been thinking about though -- wouldn't it make sense to have the version-number show after the MuPDF title in the document list? | 09:46.00 |
| paulgardiner: right now, you can't know what version is being used. | 09:46.18 |
paulgardiner | Yeah, that sounds sensible too. | 09:46.40 |
sebras | paulgardiner: also I'm not sure that the fix introduced for the pagebar works well. | 09:47.08 |
| paulgardiner: when I'm sliding my finger along it in a pdf having just two pages I have to slide all the way to the right for it to change to the last page. | 09:47.40 |
| and that area is just a few pixels wide. | 09:47.53 |
paulgardiner | That's what I thought I'd just fixed | 09:48.11 |
sebras | now would have been a good time to have the version number to make sure that I had the right version installed. ;) | 09:48.36 |
paulgardiner | Yes, that does really confirm your point. | 09:49.08 |
sebras | I reinstalled the app just to make sure, but no the pagebar is still misbehaving. | 09:49.45 |
| and I know that I have the right app because it now reacts to the menu button! ;) | 09:50.27 |
paulgardiner | For me, on a 2 page doc, if I drag the bar, when I get more than half way, the bar shows the halfway position, then when I let go it goes the rest of the way | 09:50.32 |
sebras | nope. | 09:51.12 |
paulgardiner | Showing the halfway position isn't ideal, but I don't seem to have the problem of having to select a tiny area. | 09:51.36 |
| Can you get the thumb to the halfway point at all? | 09:52.44 |
| Which one are you using signed or unsigned? | 09:53.21 |
| They should be the same, but just in case. | 09:53.35 |
sebras | md5sum MuPDF.apk | 09:54.35 |
| 54a907fbbed5f060e7968d84c786f4fb MuPDF.apk | 09:54.36 |
| that one. :) | 09:54.42 |
paulgardiner | Hmmm. Just installed that one, and it works for me. How weird | 09:57.32 |
kens | different Android versions ? | 09:57.52 |
paulgardiner | kens: Yes, probably. That's going to be a pain to fix. | 09:58.37 |
sebras | kens: most likely. android 2.3.3 here.. | 09:58.46 |
| paulgardiner: I sent you a video exhibiting the problem I'm seeing. | 10:39.47 |
paulgardiner | thanks. I'll take a look. Is it any different at all? - because I did know of the problem as you originally described it. | 10:40.56 |
sebras | paulgardiner: no, no visibly so. | 10:41.20 |
| paulgardiner: if you'd like i could probably get a log from logcat if you print some debugging info. | 10:41.50 |
paulgardiner | sebras: I'll mull that over. It's difficult to think what to monitor. | 10:42.34 |
sebras | ok. | 10:43.31 |
| morning mr. andersson. | 10:55.53 |
tor8 | morning mr. rasmussen | 11:04.59 |
sebras | tor8: there is a zlib 1.2.7 released, maybe we ought to updated thirdparty with that as well before 1.1? | 11:17.22 |
tor8 | sebras: we already have | 11:22.58 |
sebras | tor8: right. I'm just in the process of updating to the new thirdparty so I misread. :) | 11:23.53 |
| dang it! I get linking erros with the latest android-ndk and mupdf: pdf_lookup_builtin_font+0x18): unresolvable R_ARM_THM_CALL relocation against symbol `strcmp' | 11:25.33 |
| but symlinking androids ld to ld.gold instead of ld.bfd solved that issue. | 11:31.08 |
paulgardiner | sebras: just watched your video. That is the current behaviour I see. As your finger moves from the left half to the right half of the bar, the display shows a transition from 1/2 to 2/2. If you let go from that point, the 2nd page will display. What is confusing is that the bar stays at half way (as though on page 2 of a 3-page document). | 11:37.58 |
| I think the mapping from finger position to page is now correct, but the way the bar displays is confusing. | 11:39.02 |
sebras | ah! it wasn't until now that I actually read the number above the bar. | 11:39.29 |
| I was too focused on the bar itself... | 11:39.40 |
paulgardiner | Yeah, but makes sense seeing as you were in bug-fix-checking mode rather than just using it. | 11:40.30 |
sebras | I think what is fooling me is that there are now three places on the bar where the indicator can be, despite it being for a two page pdf. | 11:41.43 |
paulgardiner | Possibly it would be better if I increased the bar resolution further for low-page-count documents. | 11:41.52 |
sebras | yes, and then snap to the closest indicator position for a page. | 11:42.49 |
paulgardiner | yep | 11:43.35 |
sebras | paulgardiner: if I have search results highlighted when pressing the search button those highlights are not removed, should they be? | 11:56.25 |
paulgardiner | They go as soon as you type. We selected that behaviour a while back for some reason I can't remember... not to say it's necessarily correct. | 11:57.40 |
sebras | ah... now I see. if I center-screen-click the toolbars will also disappear and the highlights remain. then it all makes sense. | 11:58.47 |
paulgardiner | sebras: I've uploaded another apk with the increased slider resolution and some other fixes. | 12:15.46 |
sebras | paulgardiner: 404 not found. | 12:19.26 |
paulgardiner | oh yeah. Different file name, but the directory it's in has indexing. | 12:20.46 |
sebras | got it. | 12:21.20 |
| well.. getting it. ever so slowly. ;) | 12:21.57 |
paulgardiner | My upstream adsl :-( | 12:22.31 |
| On the plus side, it was very quick for me to upload. :-) | 12:23.04 |
sebras | paulgardiner: as I said to Robin, you guys should move to .se where high-speed dsl is cheap. :) | 12:23.07 |
paulgardiner | Tempting. Very tempting. | 12:23.43 |
sebras | paulgardiner: http://bugs.ghostscript.com/show_bug.cgi?id=693275 http://bugs.ghostscript.com/show_bug.cgi?id=693276 | 12:25.49 |
paulgardiner | Oops. I didn't see that one. I saw the one about the inconsistent message and fixed that by fixing the message. | 12:26.49 |
sebras | paulgardiner: no worries. I just entered those bugs. | 12:27.42 |
| also I'm not sure I'm right in assuming that users want search wrap. | 12:28.16 |
| paulgardiner: the pagebar thing works well now. and the other bugs you fixed on paul/master seem to work well too. | 12:31.01 |
| tor8: I believe that there are some patches for you to merge when you have the time. | 12:31.22 |
paulgardiner | Brill. Thanks for checking them. | 12:31.24 |
sebras | paulgardiner: np. what else should I do on my vacation? ;) | 12:31.40 |
paulgardiner | tor8: I don't seem to have sufficient access to bugzilla to reassign bugs to me, and I think because they aren't assigned to me, I cannot mark them as fixed. | 12:44.55 |
sebras | tor8: what is mupdf policy on using 64-bit integers? | 12:51.20 |
tor8 | paulgardiner: oh... I'm not very clued in to how the bugzilla is set up | 13:12.20 |
| sebras: we don't do 64-bit ints :) | 13:12.42 |
| do we have a need for them? | 13:12.56 |
sebras | we do! | 13:13.34 |
paulgardiner | tor8: no worries. | 13:13.35 |
sebras | in fitz/filt_jbig2d.c and fitz/base_time.c | 13:13.55 |
chrisl | paulgardiner: you probably need to be added to an appropriate bugzilla group to get those rights - marcosw is your man for sorting that out | 13:14.02 |
sebras | and yes, we do need them for sha384/512. | 13:14.07 |
| I'm working on supporing the crypt for el8. | 13:14.20 |
| tor8: ^^ | 13:14.30 |
paulgardiner | chrisl: Oh ok thanks Chris | 13:14.44 |
chrisl | no | 13:14.49 |
| or even np - bad typgin day..... | 13:15.02 |
tor8 | sebras: right. | 13:16.28 |
chrisl | tor8: you might want to get the latest code from jbig2dec.git, there were some missing changes from the code that Robin pulled into thirdparty.zip | 13:17.11 |
sebras | paulgardiner: when I declare 64-bit int literals in visual c++, does it accept the normal ULL at the end or does it have to me ui64? | 13:17.54 |
tor8 | chrisl: so is thirdparty.zip up to date or in need of updating again? | 13:19.00 |
paulgardiner | sebras: sorry, don't know. | 13:19.13 |
chrisl | tor8: I only pushed the fixed the jbig2dec.git stuff this morning, so the current thirdparty.zip will be out of date | 13:19.53 |
tor8 | chrisl: right. I'll update the jbig2dec in thirdparty then. | 13:22.55 |
paulgardiner | sebras: not sure if this is related, but I've used rsa before and not needed 64bit ints. Things like openssl have apis that treat large ints as byte arrays... ignore me if that has no connection with what you are doing. | 13:23.01 |
tor8 | chrisl: how did you bring the commits over from ghostpdl? | 13:23.15 |
chrisl | tor8: in the main, I did "git format-patch ./jbig2dec/*", then did a little editing of the patch files, and "git am" in the jbig2dec directory. | 13:24.42 |
tor8 | chrisl: right. | 13:25.10 |
| I think if you have a newer git there's a "git subtree" command which is supposed to support that kind of workflow. my debian is too old so I haven't tried it myself. | 13:25.44 |
chrisl | Mine seems to be too old, too..... | 13:26.19 |
| tor8: the patch editing was just to remove the "ghostpdl/gs/jbig2dec" prefix from all the paths (and remove a couple of diffs where files outside jbig2dec had changed). | 13:26.49 |
sebras | paulgardiner: I have been thinking about that too. | 13:29.06 |
| paulgardiner: SHA-384 and SHA-512 ought to be able to compute using only 32-bit math. | 13:29.19 |
tor8 | chrisl: straight forward stuff, thankfully. | 13:29.48 |
sebras | paulgardiner: however the source of the SHA-256 used in mupdf uses 64-bit ints for SHA-384/-512. | 13:30.03 |
| paulgardiner: I'll start out with this and we'll have to refine it if it becomes a problem. | 13:30.18 |
paulgardiner | sebras: sounds like a plan | 13:30.34 |
chrisl | tor8: mostly, yes - there were some patches that didn't apply (hence today's update) - I'm not at all clear why, doing it manually, it looked to me like they should have applied cleanly | 13:31.05 |
| tor8: I'm not sure git subtree stuff gets us the syncing from ghostpdl to jbig2dec - it looks like it works the other way. | 13:33.42 |
paulgardiner | Off for a quick run. biab. | 13:35.52 |
| chrisl: I've not yet used git subtree yet, but I got the impression it worked both ways... assuming I'm understanding what you wish to do between ghostpdl and jbig2dec, which I possibly don't. | 14:55.04 |
chrisl | paulgardiner: like I said, I'm not sure - *all* the examples I've found have been cloning a repository (or part thereof) into a subtree of another repository. I've not found anything about taking a subtree of one repos, and having it replace the entire contents of another. | 14:57.13 |
paulgardiner | I think you can. You just develop the outer project freely making changes to the subdirectory, and any stage you can push just the changes in the subdirectory to the subtree branch. Again I may be misunderstanding what you need to do. | 15:00.10 |
| s/any/at any/ | 15:00.26 |
| merge I mean not push. And then you can push the subtree branch back to it's repo. | 15:01.08 |
chrisl | We want to take any commits from ghostpdl/gs/jbig2dec in ghostpdl.git and apply them to jbig2dec.git | 15:01.57 |
paulgardiner | Yep. You can do that. Really easily too from what I read. | 15:02.19 |
chrisl | Cool, have you got a reference I can read up on it? | 15:02.42 |
paulgardiner | chrisl: I read one particularly nice clear description. I'll see if I can find it. | 15:03.34 |
kens | good evenin robin_watts_mac | 15:03.58 |
robin_watts_mac | Evening | 15:04.11 |
paulgardiner | Hi Robin | 15:04.16 |
henrys | did we want to have a meeting this morning? | 15:04.29 |
| or evening | 15:04.37 |
kens | you know I feel sure you are excused meetings while on holiday | 15:04.38 |
paulgardiner | chrisl: Here's one source. Not sure if it was the one I thought was really clear: http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/ | 15:04.41 |
| henrys: I'm ready if we do. | 15:04.59 |
henrys | paulgardiner:reading report now, sorry didn't get to it yesterday | 15:05.41 |
robin_watts_mac | I just happened to make it back to the hotel at this time. | 15:08.17 |
| and my milkshake has just arrived :) | 15:08.50 |
paulgardiner | chrisl: my understanding is that you'd have a jbig2dec branch which you'd never checkout because doing so would give you just a jbig2dec working copy at the tope level. You interact wrth that branch only with subtree merges that know to map to the subdirectory where you have jbig2dec in your ghostpdl working copy. | 15:08.52 |
henrys | paulgardiner:do you know what machine is giving the strange results? | 15:09.12 |
chrisl | paulgardiner: thanks - I see I've got some reading to do....... | 15:09.24 |
henrys | It's easy enough to give you access to the machines if you want to see if it happens manually. | 15:10.08 |
paulgardiner | henrys: no I'll look but I repeated the test and got the same results. Would the distribution of jobs be consistent? | 15:10.22 |
robin_watts_mac | no. jobs are distributed onto random nodes. | 15:10.41 |
paulgardiner | results of the two tests looked identical | 15:11.00 |
robin_watts_mac | If you look in the results table, for each job there are 2 machine names given on each line. | 15:11.21 |
| One is for the machine it ran on LAST time, and one is the machine it ran on THIS time. | 15:11.39 |
paulgardiner | robin_watts_mac: where do I find the results table? | 15:13.26 |
robin_watts_mac | In the email that is sent out after each job ? | 15:13.42 |
henrys | robin_watts_mac:was helen's facebook comment inspired by some malta pool experience? | 15:13.50 |
robin_watts_mac | Or by clicking "paul" on the dashboard. | 15:13.55 |
| henrys: Yeah. A kid was whipped out of the pool yesterday VERY quickly by it's parents. | 15:14.18 |
paulgardiner | robin_watts_mac: I don't seem to have machine names. I don't have per-job info - just a list of ones that had differences | 15:15.41 |
robin_watts_mac | Hold on. | 15:16.13 |
henrys | robin_watts_mac:one of us can figure out the testing stuff you really should go enjoy your swimming pool ;0( | 15:16.37 |
robin_watts_mac | henrys: Pool is closed for cleaning. (Honest!) | 15:16.58 |
| paulgardiner: Look at the "Differences" line. | 15:17.15 |
| lines. | 15:17.18 |
| tests_private/pdf/forms/v1.3/09+20feature+20musical.mjs.ppmraw.72.0 mujstest x6 feet | 15:17.30 |
| So that test differed between the last 2 runs which were on x6 and feet. | 15:17.52 |
paulgardiner | That's overly polite. You mean "open your eyes!" :-) | 15:18.08 |
robin_watts_mac | I can't see any obvious pattern to the failing ones. | 15:19.47 |
henrys | tor8:anything for the meeting? | 15:20.10 |
paulgardiner | There's some with changes even though the two runs are on the same machine | 15:21.17 |
robin_watts_mac | If you rerun, do you get the same failing set ? | 15:22.15 |
henrys | robin_watts_mac:of course now I've been embarassed by the resolution fiasco, I could have sworn that worked. | 15:22.45 |
paulgardiner | I believe so, although I didn't properly verify it. | 15:22.50 |
| I could easily check. | 15:22.58 |
robin_watts_mac | henrys ? | 15:22.58 |
henrys | robin_watts_mac:which you warned me about yesterday. | 15:23.01 |
robin_watts_mac | henrys: So... he's saying that it's not the images he cares about the quality of, it's the line art. | 15:23.43 |
| So, why doesn't he render at 1200dpi, and use DownScaleFactor=32 and hence get 800dpi out? | 15:24.05 |
henrys | well that is something separate then the resolution now working. | 15:24.14 |
robin_watts_mac | 1200 is a multiple of 300, so (AIUI) everything will be correctly positioned. | 15:24.29 |
| and he'll get decent quality for lines etc. | 15:24.47 |
henrys | he has to render with the pjl resolution specified in the file for other device dependencies in pcl | 15:25.02 |
| sorry to interrupt, with a non forms thing. | 15:25.40 |
robin_watts_mac | So basically, the fact he's using PCL means that the output resolution has to be fixed? So there is nothing we can do? | 15:26.26 |
henrys | so I think I said something like mid october in the newsletter for the release, if that comes into question holler please. | 15:26.37 |
| the alpha release that is. | 15:26.44 |
robin_watts_mac | I have a non-forms mupdf thing. | 15:28.00 |
paulgardiner | henrys: yeah. That sounds fine. | 15:28.13 |
henrys | robin_watts_mac:right about the pcl. | 15:28.14 |
robin_watts_mac | I was playing with some code to add/delete pages from a document. | 15:28.36 |
| Updating a pages tree is HARD (especially hard to do in a way that leaves it consistent in the event of a memory failure). | 15:29.26 |
| So I thought about just regenerating the pages tree on a save. | 15:29.59 |
| That can still fail, but at least the representation of the file in memory isn't knackered. | 15:30.32 |
| That was it, really. Just checking that tor8 was happy with that approach. | 15:34.57 |
henrys | probably needs an sms | 15:35.09 |
robin_watts_mac | ok, never mind. I'm sure he'll read the logs. | 15:35.54 |
henrys | I will point him to it when he shows up. | 15:35.56 |
| anything else forms-wise | 15:36.22 |
| ? | 15:37.09 |
| adjourn? | 15:37.20 |
paulgardiner | Nothing more from me. | 15:37.42 |
robin_watts_mac | nor from me. | 15:38.41 |
henrys | robin_watts_mac:have a good time in Malta, dont' work a lot! | 15:39.19 |
| I was going to cancel the 9:00 PDT meeting today since we are missing at least 2 (in case kens wants to duck out early) | 15:41.26 |
kens | I'm not worried, can do meeting or not. I have nothign to bring up personally | 15:42.20 |
chrisl | henrys: the only thing I was going to bring up was doing a jbig2dec release - I'm inclined to just update the changelog, and version number, tag it, and let anyone interested pull it from git. Any thoughts? | 15:44.24 |
robin_watts_mac | chrisl: Check with shelly that he hasn't got any more fixes in the pipeline first? | 15:45.04 |
chrisl | robin_watts_mac: no, he's currently all out - which reminds me....... | 15:45.46 |
| sebras: ping | 15:45.52 |
henrys | chrisl:sounds good to me. | 15:46.13 |
chrisl | henrys: cool - we'll see who complains! | 15:46.28 |
robin_watts_mac | chrisl: Is it worth sorting the git submodules stuff and THEN doing a version? | 15:46.59 |
marcosw | hey, I'm on time for the meeting! | 15:47.26 |
henrys | he he and we canceled it. | 15:47.37 |
kens | and henrys decided to cancle it :-) | 15:47.41 |
chrisl | robin_watts_mac: I'd rather do it the other way round - in case we mess it up! | 15:47.53 |
robin_watts_mac | marcosw: It seems that Jill has signed for my camera - many thanks! | 15:47.53 |
| chrisl: Fair enough :) | 15:48.05 |
henrys | I did want to ask you something though marcosw. | 15:48.10 |
marcosw | anything else expected or is that it? | 15:48.13 |
chrisl | henrys: and we should probably close Bug 693050, too | 15:48.21 |
robin_watts_mac | marcosw: I'll look into the new customer bug about image interpolation when I get back - you may want to warn the company concerned that it will be at least a week. | 15:49.21 |
henrys | marcosw:just wanted you to look at 693269 | 15:49.39 |
marcosw | robin_watts_mac: are you out of town? | 15:49.45 |
henrys | I was wondering if handmade could make sense of the group 4 encoding I've attached. | 15:50.08 |
kens | robin_watts_mac : is on holiday in Malta marcosw | 15:50.21 |
marcosw | henrys: I've just download the g4 attachment. | 15:50.51 |
robin_watts_mac | marcosw: wot kens said. | 15:51.02 |
marcosw | Malta doesn't seem exotic enough for you. | 15:51.19 |
robin_watts_mac | mvrhel_laptop: And I thought my Wifi connection was dodgy... | 15:53.03 |
marcosw | henrys: re. bug 693269 do you know the dimensions of the g4 image? Alchemy needs to know the width, in pixels, in order to read a raw g4 stream. | 15:53.53 |
henrys | marcosw:let me check, if you want to head out I'll update the bug and you can look at it later. | 15:55.12 |
sebras | chrisl: yo! | 15:55.38 |
chrisl | sebras: hi. Were you able to dig out that PDF with the jbig2 data in it, with the "reuse bitmap" flag set? | 15:56.28 |
henrys | marcosw:one scanline is 7008 pixels. | 15:56.36 |
marcosw | I'll stick around for the meeting. | 15:56.46 |
| henrys: okay. let me try reading the stream. | 15:57.01 |
henrys | height = 4958 | 15:57.22 |
sebras | chrisl: oh, I forgot. I still have it here somewhere though. | 15:58.08 |
| chrisl: where do I send it once I have found it? | 15:58.28 |
chrisl | sebras: open a bug "missing functionality" and attach it to that, please (unless it's private?) | 15:59.16 |
henrys | mvrhel_laptop_:have you landed? | 15:59.38 |
| I guess not. | 15:59.47 |
marcosw | henrys: alchemy can't read the g4 data; reports "fax invalid code encountered" | 15:59.57 |
sebras | chrisl: I would consider it to be private. | 16:00.37 |
marcosw | I've added a note to the bug. | 16:00.45 |
sebras | chrisl: or rather -- I have no clue where I might have gotten it from. | 16:00.52 |
henrys | marcosw:I don't really know what else to do with the bug. I don't have any device or program that can understand the data. | 16:01.00 |
chrisl | sebras: okay, if you open a bug, and stick it in your user area on casper - would that be okay? | 16:01.47 |
sebras | chrisl: that's ok with me. | 16:01.57 |
chrisl | stick the file on casper, that is..... | 16:02.01 |
sebras | chrisl: got it. :) | 16:02.11 |
mvrhel_web | finally. had to go to the webchat. I have no idea why chatzilla keeps booting me off | 16:03.32 |
henrys | mvrhel_web:we decided not to have the meeting, ;-^ | 16:04.03 |
mvrhel_web | right. I see that from the logs | 16:04.15 |
marcosw | would sending the file to an HP DesignJet CP2500 help? It speaks HP-GL2. Of course if it can print the file I'm not sure what the next step would be. | 16:04.26 |
robin_watts_mac | mvrhel_web: Hows the halftoning ? | 16:04.31 |
henrys | marcosw:it would be interesting yes. | 16:04.49 |
mvrhel_web | henrys: so I am trying to get the fast thresholding stuff turned on for when we have non monochrome source data. for some reason it was disabled | 16:05.04 |
henrys | marcosw:it would probably give me the motivation to manually decode the file if it works. | 16:05.25 |
marcosw | mvrhel_web: we cancelled the meeting because I showed up on time, didn't want to break my streak of always being late. | 16:05.30 |
robin_watts_mac | Possibly the same issues as we just fixed? (as you suggested in your mail, I think) | 16:05.31 |
mvrhel_web | robin_watts_mac: and henrys: There is an issue with the levels that I am trying to step through | 16:05.38 |
robin_watts_mac | > vs >= ? or something more ? | 16:06.04 |
mvrhel_web | robin_watts_mac: yes. I think we are good with respect to the memory issue | 16:06.04 |
marcosw | henrys: I'll be home on Sunday; I'll email the customer letting them know not to expect anything until next week at the earliest. | 16:06.12 |
robin_watts_mac | fab. | 16:06.12 |
mvrhel_web | henrys: once I get this in place, I have a patch to test the clist hafltoning stuff | 16:06.41 |
| but I want to get all the halftoning cases working correctly first | 16:07.01 |
robin_watts_mac | sure. | 16:07.07 |
henrys | mvrhel_web:okay so you are saying the fast stuff only worked with gray contone source? | 16:08.00 |
mvrhel_web | marcosw: are any of those bugs from gemma going to end up with me or are they all heading to robin_watts_mac | 16:08.02 |
| henrys: apparently. it was disabled in the trunk for the other souces (e.g. rgb images) | 16:08.25 |
| I dont remember doing that | 16:08.57 |
| there was a case that robin had disabled that we worked on last week | 16:09.18 |
| but I had not realized all the cases with color images were disabled | 16:09.28 |
henrys | git history should tell. | 16:09.30 |
| but it may not be important. | 16:09.48 |
mvrhel_web | yes I will take a look at that to see. it was probably me though... | 16:09.48 |
| something new got pushed on my stack and that left... | 16:10.22 |
| the stack being my brain | 16:11.22 |
marcosw | I did have something for the meeting: I'm going to start enabling a bunch of additional automated regression emails; including the weekly regression tests (i.e. 32 bit mode), daily performance testing, testing of all devices, etc. So traffic to gs-regression@ghostscript.com is going to increase. | 16:11.22 |
mvrhel_web | marcosw: at some point, I want to add some color parameter setting tests | 16:12.35 |
| something simple | 16:12.50 |
| i.e. we don't need to run all the files | 16:12.59 |
marcosw | mvrhel_web: So far none of the Gemma bugs are yours. I | 16:13.20 |
alexcher | marcosw: How can I run these new tests before the commit? | 16:13.32 |
henrys | marcosw:okay by me.. | 16:13.35 |
robin_watts_mac | marcosw: ray asked the other day if he could use the filter=stuff to schedule tests on devices that weren't usually used. | 16:15.16 |
| I said no, because we wouldn't know what to test against. | 16:15.29 |
marcosw | mvrhel_web: the local test scripts on meters is what you want. If you'd like I can walk you through setting it up on irc when you are ready. | 16:15.44 |
chrisl | marcosw: "daily performance testing"? We already get performance data from each cluster run, do we need more? | 16:15.54 |
robin_watts_mac | But we could do a bmpcmp like thing where we run the old HEAD binary and compare it against the new binary just on a given device. | 16:16.05 |
marcosw | chrisl: that only summarizes the total, not regressions for individual files. | 16:16.18 |
mvrhel_web | marcosw: ok that sounds good. or maybe we can go over it during a bit of free time at the staff meeting | 16:16.25 |
robin_watts_mac | Maybe: clusterpush.pl gs device=bmp16m or something | 16:16.30 |
chrisl | marcosw: Oh, right, that would be good - cool. | 16:16.42 |
marcosw | mvrhel_web: the staff meeting is a good, assuming we don't run short of time :-) | 16:17.56 |
mvrhel_web | and then there is the issue that you are the last one there.... | 16:18.29 |
marcosw | alexcher: sorry, I think I forgot to do something for you related to documenting how to run the cluster scripts locally... | 16:18.34 |
| and the first to leave, since I can just drive home and don't need to wait for my flight... | 16:19.05 |
robin_watts_mac | ok. I'm going out of wifi range. talk to you all later... | 16:19.39 |
| .quit Pop! | 16:19.49 |
chrisl | alexcher: if all the cluster machines are setup to handle 32 bit builds, you can probably do a 32 bit clusterpush of Ghostscript by making a small change in autogen.sh | 16:20.24 |
marcosw | chrisl: I believe that 32 bit cluster runs work, the cluster knows which machines are able to do 32 bit builds. | 16:21.40 |
| I'm not sure about bmpcmp for 32 bit. | 16:21.59 |
chrisl | Why do we care about bmpcmp for 32 bit? | 16:22.39 |
| I mean, the bmpcmp exe can be 64 bit, and it will still be able to compare the output from a 32 bit gs | 16:24.20 |
kens | OK I'm off goodnight all | 16:25.30 |
marcosw | chrisl: it's not the bmpcmp binary that's an issue, but to make sure the bmpcmp job compiles the gs binary in 32 bit mode. | 16:30.43 |
chrisl | marcosw: is there now a way to prompt a 32 bit run with a clusterpush, then? | 16:31.55 |
marcosw | henrys: do you want me to look at the .rar archive that customer 190 has made available to download? | 16:31.56 |
tor8 | robin_watts_mac: (for the logs) regenerating the page tree on save is okay with me | 16:32.03 |
henrys | marcosw:if you have time, but if you don't get to it don't worry about it. | 16:32.36 |
marcosw | chrisl: yes. | 16:32.37 |
chrisl | Oh, great | 16:32.47 |
henrys | marcosw:that customer always uses -lRTL and the output won't make sense without it. | 16:33.27 |
marcosw | chrisl: not that I remember how :-) | 16:34.43 |
chrisl | marcosw: now I know about it, I can look it up for myself, when required...... | 16:35.16 |
marcosw | chrisl: I'm sure it's not documented and probably doesn't work. | 16:36.08 |
chrisl | My favourite kind of feature :-) | 16:36.35 |
dustin | Hi. I was just wondering if there is interest among gs developers in making ps2pdf able to accept multiple input files, and batch convert them in that way. | 16:46.45 |
chrisl | dustin: ps2pdf is just a wrapper script for the very simplest of uses - the recently released Ghostscript 9.06 supports batch conversion with the pdfwrite device | 16:48.40 |
dustin | Oh, cool. ps2pdf is just what I have used in the past and it surprised me today when I couldn't do batch conversion with it. Thanks for the info. | 16:50.41 |
chrisl | dustin: a warning, though, it's not totally trivial to do the batch conversion stuff - it's really aimed at people doing "server" implementations | 16:51.49 |
dustin | chrisl: So I guess what I'm looking for is a tool that I can use in a directory full of .eps where I can do something like: ps2pdf *.eps | 16:53.47 |
| Is there something packaged with gs that can do that? | 16:54.00 |
chrisl | dustin: no, there's nothing packaged with gs what can do that - I've always just written my own scripts for stuff like that..... | 16:55.02 |
| Hmm, it also looks like running pdfwrite in "server mode" isn't documented - that's a pain :-( | 16:56.48 |
dustin | chrisl: That's what I ended up doing as well. But I thought that it might be a common enough need that modifying ps2pdf to be able to do that might be considered. | 16:57.27 |
chrisl | dustin: it wouldn't be terribly hard to change ps2pdf to loop over a list of files - assuming it was kept sufficiently shell agnostic, I wouldn't have a problem accepting a patch. Although, the final decision would be with the pdfwrite maintainer (kens) who's finished for the day. | 17:00.57 |
dustin | chrisl: I would be happy to take a stab at said patch if kens is ok with it. | 17:04.56 |
chrisl | dustin: kens is usually around for "normal" office hours UK time, during the week. | 17:05.33 |
dustin | Thanks. | 17:06.57 |
henrys | bbiab | 17:15.56 |
sebras | tor8: yey, I have extensionlevel 8 encryption working on sebras/master. :) | 17:26.33 |
| tor8: I'll run it through sane/insane to make sure I haven't messed up too much. | 17:28.11 |
| tor8: the SHA-384/-512 algorithms are adaptations of those from Crypto++ files where you got SHA-256 from. all those files are released as public domain. | 17:29.23 |
| tor8: the rest of the patch is basically adaptations of zeniko's work. | 17:29.59 |
| yey, no regressions! :) | 17:40.16 |
| I'm looking for an old document -- Adobe technical note 5156. does anyone have an url? | 20:25.24 |
| tor8: and a small patch to adjust out of range testing of encryption key lengths. | 20:55.46 |
sebras | has too much head ache | 20:56.07 |
| see you tomorrow. | 20:56.13 |
tor8 | good night | 20:56.18 |
mvrhel_laptop | ok. I finally see the issue with the threshold array levels. | 22:01.41 |
| Forward 1 day (to 2012/08/15)>>> | |