| | <<<Back 1 day (to 2013/03/12) | 2013/03/13 |
| robin_watts_mac | tkamppeter: so, for mupdf we have a viewer app - you can try that now. You've seen the android one, but there is a simpler one for linux/windows too. | 01:29.13 |
| | Part of the mupdf distribution is mudraw. That takes PDF -> bitmaps. | 01:29.40 |
| | We can tweak it to render in bands to make it work at high res in low memory etc - no problems there. | 01:30.27 |
| | To convert PDF -> Postscript, we could render to bitmap strips then wrap them up as postscript images. Would that be OK? | 01:31.42 |
| | adding CUPS raster to the list of bitmaps we produce shouldn't be hard. | 01:32.04 |
| | And can we wrap bitmaps up as PCL? Or do you want high level PCL stuff like paths/text etc? That can be done, but it's a larger job. | 01:32.43 |
| whutsup | . | 08:29.37 |
| | hello, anyone here? | 08:30.38 |
| kens | Yes, several people | 08:30.50 |
| whutsup | great, my first time using irc... so people using private chat or not chatting atm? | 08:31.37 |
| kens | Not chatting, many of the developers areew based in the UIS and are not awake at the moment | 08:31.59 |
| whutsup | I have just a little question about file conversion, extracted it with mupdf | 08:34.02 |
| | .ttf | 08:34.26 |
| kens | MuPDF might be difficult for me to comment on, I'm a Ghostscript developer. THe MuPDF develoeprs are currently onvacation in the US or not online yet (we just finished a staff meeting in FLorida) | 08:34.58 |
| whutsup | oh, right, it must be around 4:30 in the morning for u :) | 08:37.43 |
| kens | No, I'm in the UK, but two of the developers are taking extended time after the meeting for vacation, and the remaining one got home late yesterday after flying back | 08:38.16 |
| whutsup | for them :) | 08:38.18 |
| kens | By the way, this channel is logged and the developers read the logs, so feel free to ask questions even if nobody is here | 08:38.55 |
| | But you will either have to read the logs or stick around for an answer :-) | 08:39.15 |
| whutsup | yes, I checked after... thank you for the info... ok, I just wanted to know how to convert extracted files of .ttf type to any readable ones | 08:40.17 |
| kens | .ttf is a TrueType font, to convert that to a different font format will require a font editing tool, eg FontForge | 08:40.50 |
| whutsup | so the extracted file is just a font file?... I have this unreadable .pdf file that I was unable to convert by different converters to excel, so finally I used mupdf to extract whatever I could | 08:43.25 |
| kens | a .ttf is a font file yes, I'm not sure what else to expect | 08:43.47 |
| | Certainly MuPDF won't convert it to .xls or .xlsx | 08:44.06 |
| whutsup | yes, I was just trying anything to convert it to mybe something more readable | 08:45.34 |
| | ok, Il try something else then.... this info helped me a lot, thank you :)) | 08:47.28 |
| chrisl | kens: from you e-mail, I take it you mean gitpush.sh? | 09:37.08 |
| kens | Yes, that thing | 09:37.18 |
| | Not had a chance to look at it yet | 09:37.28 |
| | Its code Robin wrote to get around the Perl problem (IIRC) | 09:37.57 |
| chrisl | It *should* just work, then. gitpush.sh just echoes the command line options you give it to a temp file, they get pushed up to the interim repo (from where clusterpush.pl gets called). | 09:38.55 |
| kens | AH, well that should be easy, thanks ! | 09:39.21 |
| | I'll be testing it in a minute, going to check my zcolor.c changes now I've sanitised the white space | 09:39.41 |
| chrisl | NP, gitpush.sh is pretty simple - it's the logic at the other end that gets hairy | 09:40.02 |
| | kens: BTW, you should probably setup your git username etc on your laptop....... | 09:40.57 |
| kens | I rather thought I'd copied that, I guess not.... | 09:41.23 |
| chrisl | I think possibly the way Tor's original instructions work, it ends up writing your credentials to the git global config, rather than to the repo specific config | 09:42.34 |
| kens | THat's probably why then | 09:42.50 |
| | Wow, for seem reason gitpush is copying megabytes of data | 09:49.14 |
| chrisl | Have you done a gitpush since the devices directory was introduced? | 09:50.25 |
| kens | Yes, did one in Florida (well severl in fact) | 09:50.43 |
| | So far 26% copied 9.89 MB | 09:51.05 |
| chrisl | Oh, quite possibly that's why - you're last one was from a different repo? | 09:53.09 |
| kens | I don't know, I'm not concerned (yet), but it is taking a liong time :-( | 09:53.29 |
| | and now I get an rsync error.... | 10:04.26 |
| kens | tries whtout the pdfwrite option | 10:05.02 |
| | Yes, that works | 10:05.20 |
| | So its the use of 'pdfwrite' that is broken it seems | 10:05.29 |
| chrisl | That's odd. It may be that the clusterpush.pl that is used on casper needs updated - I had rather assumed that it would use the one in the "client" repo, but perhaps not. | 10:12.32 |
| kens | I don't know, I did do a git pul before doing the test though | 10:13.00 |
| chrisl | Oh crumbs - yes, it seems the gitbridge world holds it's own copy of clusterpush.pl - yuck :-( | 10:16.05 |
| kens | Ah, well tha'ts probably the problem then | 10:16.19 |
| chrisl | kens: when you get a chance, give the pdfwrite option another shot - I've put the updated clusterpush.pl in place | 10:18.52 |
| kens | OK I can do that now, I'm about to go out but my previous test is running so I can queue another | 10:19.20 |
| chrisl | Ta, I don't have gitpush setup, as I don't need it..... | 10:20.32 |
| kens | |Well, no rsync errors, so it looks good> I did get a (surprising) set of 'deleting gs/autom4te/...' and 'deleting tools/Acrobat2Tiff/...' messages | 10:21.03 |
| | I can see it on the dashboard now | 10:21.36 |
| | I'll let you know what the logs say when I get back, thanks chrisl | 10:21.56 |
| chrisl | The autom4te ones are from autoconf, I almost get the Acrobat2Tiff ones | 10:22.10 |
| kens | They are new to me.... | 10:22.26 |
| | maybe the gitpush script has been out of date for some time | 10:22.46 |
| | Have to go, back later | 10:23.05 |
| chrisl | have fun! | 10:23.09 |
| robin_watts_mac | Yes, the gitpush script uses its own copy of clusterpush.pl. | 11:03.53 |
| | It was easier that way as it has to work with mupdf and gs. | 11:04.17 |
| chrisl | robin_watts_mac: I was thinking of adding an extra repo, just to grab the latest clusterpush.pl from | 11:06.33 |
| robin_watts_mac | chrisl: could do. Can't think of a downside to that offhand, (other than the extra disc space) but... | 11:07.08 |
| chrisl | robin_watts_mac: our git repos aren't that big | 11:08.34 |
| | heading out - bbiaw..... | 11:11.07 |
| _ingsoc | Curious, but when I zoom into a PDF with MuPDF and drag to copy text, it is extremely slow and lags behind dramatically. Is this known? | 11:37.53 |
| tor8 | _ingsoc: we have a bug report about a slowdown, but I can't think of what's happened since last release because I'm not aware that we've changed anything in the GUI app. | 11:39.48 |
| _ingsoc | tor8: Thanks. :) Do you know where the bug report is? | 11:41.10 |
| | tor8: I've patched my copy of MuPDF to use the other clipboard, but I don't think that affects the slowdown. | 11:41.36 |
| tor8 | http://bugs.ghostscript.com/show_bug.cgi?id=693679 | 11:41.47 |
| _ingsoc | Ty. | 11:43.11 |
| | Hmm. That Arch Linux thread is from 2009. | 11:44.47 |
| henrys | chrisl:btw Xcode works fine with the directory restructure. | 13:50.41 |
| chrisl | henrys: cool, thanks for checking it. | 13:51.17 |
| kens | chrisl I'll have to talk to Marcos about the 'pdfwrite' option on the cluster. It works but still seems to run the rendering tests | 13:52.21 |
| chrisl | kens: yes, isn't that what he said it would do in the mail? | 13:52.47 |
| kens | I thought not, since tehre would then be no diffrence to a regular test | 13:53.05 |
| | let me check what he said | 13:53.17 |
| | Nope, he said it should only run pdfwrite & ps2write | 13:53.55 |
| chrisl | he mentions using "filter=ppm" which would be pointless if not producing ppm output | 13:54.00 |
| kens | Hmm, he said he's not using a filter | 13:54.16 |
| | ah 'can be combined with' a filter | 13:54.26 |
| | that's only an example | 13:54.32 |
| chrisl | I'd hope he'd use an example which would work, though.... | 13:54.57 |
| kens | I suspect he didn't think about it. | 13:55.08 |
| chrisl | I think it should still run fewer tests than a "normal" clusterpush | 13:55.20 |
| kens | It seemed identical to my previous (normal) test | 13:56.35 |
| | Both ran 76327 tests | 13:56.54 |
| henrys | kens:does our output pdf always have a date or something that changes each time? | 13:58.35 |
| kens | All PDF files have a creation date, and yesy it changes depending when it was created | 13:59.03 |
| henrys | I was just thinking we could speed up the pdfwrite stuff dramatically if we could md5 just the pdf. | 13:59.05 |
| | then presumably failing that we'd render the pdf and check the result. | 13:59.40 |
| kens | THat's what we do now | 13:59.50 |
| henrys | oh I thought is always rendered | 14:00.04 |
| chrisl | I didn't we md5'ed the PDF? | 14:00.10 |
| kens | we always render | 14:00.16 |
| chrisl | So we could possible skip the rendering | 14:00.29 |
| kens | Because there are variables in the metadata | 14:00.33 |
| chrisl | *Always*? | 14:00.43 |
| kens | When testing, we always render the PDF files because PDF files contain variable data (includign date and teim) in the metadata and therefore cannot be MD5'ed | 14:01.30 |
| | we also render ps2write otuput, possibly we could skip that | 14:01.52 |
| | Buit marcos treats pdfwrite and ps2write the same | 14:02.05 |
| henrys | right but presumably for testing we could "fix" that. | 14:02.07 |
| kens | henrys we could I suppose yes. THough it would mean adding yet another switch | 14:02.33 |
| henrys | well if the rendering pdf step is significant it could be worthwhile kens, I don't know about that though | 14:03.24 |
| kens | I don't know henrys you would have to ask Marcos. I can't see why it would NOT be significant though | 14:03.49 |
| chrisl | 'Course, you can't pipe the pdfwrte/ps2write output to md5 like the raster devices do | 14:04.31 |
| kens | chrisl no you can't, but you could MD5 it afterward, its probably faster than rendering | 14:04.52 |
| | In fact, as long as you aren't linearising the PDF you probably can MD5 it by piping to stdout | 14:05.32 |
| | You certainly should be able to with ps2write | 14:05.46 |
| | I don't *think* pdfwrite seeks through the PDF file any more, except for linearisation | 14:06.00 |
| henrys | well whoever has the first marcosw sighting can tell him to read the logs. | 14:06.16 |
| chrisl | It makes sense to write to a file, and md5 the file anyway - so it's there if the md5 has changed | 14:06.16 |
| kens | chrisl there is that, if the MD5 changed we would want to render the files, so that would save a step. I guess it depends how often the MD5 would fail | 14:07.40 |
| henrys | I've got everything ready for the PCI ssd we'll see if that helps Mac Pro out a bit. | 14:08.06 |
| kens | crosses fingers | 14:08.22 |
| henrys | marcosw_:we had some stuff for you just before you arrived see the logs. | 14:15.12 |
| marcosw_ | henrys: will do | 14:15.24 |
| kens | Marcos is up early today | 14:15.41 |
| henrys | hopes mac ox will allow him to have a symbolic link for his home login directory. | 14:16.40 |
| kens | knows Windows won't :-( | 14:17.06 |
| chrisl | henrys: an alternative is to use a point the OS to a different home directory for the user - on most Unix systems the path to the home directory is part of the "user" information. | 14:18.34 |
| henrys | I guess that would be nicer | 14:19.27 |
| chrisl | http://chris.pirillo.com/how-to-move-the-home-folder-in-os-x-and-why/ | 14:19.35 |
| henrys | chrisl: I rsync'd after logging and ssh'ing in. I think the folder copy is not a great idea, if you want a good copy. | 14:21.34 |
| chrisl | henrys: it was more the method of actually OS X to use the new location I thought was useful | 14:22.08 |
| henrys | right | 14:22.16 |
| tkamppeter | I have a problem building GS 9.07, see http://paste.ubuntu.com/5610821/ | 14:27.39 |
| chrisl | The omni driver is deprecated, you really should be building it in | 14:28.32 |
| tkamppeter | It is in the "omni" device which I could drop as no one uses it, but waht is going wrong here? Did Ghostscript's internal APIs change and now all drivers in contrib need to get updated? | 14:28.52 |
| kens | The API certainly has not changed | 14:29.15 |
| chrisl | It will be due to the elimination of globals - the file probably was changed, but never build | 14:29.50 |
| | s/build/built | 14:30.03 |
| | tkamppeter: why is the omni device being included anyway? | 14:31.46 |
| marcosw_ | henrys: there is a difference of opinion if it's better to use a symbolic link for the home directory or change the setting in the accounts preferences. I do the former because I'm used to having my home directory /Users/marcos | 14:32.27 |
| tkamppeter | chrisl, it was in for years, never caused problems, no one complained about it, and so it got forgotten inside the source. | 14:32.41 |
| henrys | marcosw_:good point - I think I'll stick with that. | 14:33.37 |
| tkamppeter | chrisl, as quick test I have replaced gomni.c by the one of GS 9.06 an GS 9.07 builds completely. So all the rest is OK, only gomni.c of 9.07 is broken. | 14:33.52 |
| chrisl | tkamppeter: you (or someone) must have added the configure option to include it in the last few releases because I removed it from the default build (because it doesn't work!). | 14:34.04 |
| | tkamppeter: gomni.c has been broken for a considerable time - just because it built, didn't mean it worked! | 14:34.45 |
| tkamppeter | chrisl, I see that there is a "--with-omni" in the ./configure command line of the Debian packaging, also did not cause any problems, no one complained, and so it got forgotten, you know. | 14:35.58 |
| chrisl | tkamppeter: that's a little worrying, given that the reason we remove devices from the default device list is to try to establish whether anyone is using it or not.... | 14:37.11 |
| tkamppeter | chrisl, and under the circumstance that it did not work for years and no one complained we have a proof that it is really not needed any more so that in the next release we can drop it altogether. | 14:37.14 |
| | chrisl, thanks, so I will remove the "--with-omin". | 14:37.37 |
| chrisl | tkamppeter: it's going to disappear completely from our sources in the near future, so...... | 14:37.50 |
| marcosw_ | kens: I did misunderstand what you wanted regarding the pdfwrite option to clusterpush. comparing the md5sums of the intermediate postscript and pdf files would be difficult. | 14:38.18 |
| | kens: As you pointed out pdf files have timestamps, but even only doing it for postscript files would require a significant change to the cluster system. | 14:38.54 |
| | kens: as it stands now the pdfwrite option to clustepush reduces the run times from ~21 minutes to ~11 minutes, so it's still with doing. | 14:39.36 |
| kens | marcosw this is 2 discussions :-) | 14:40.44 |
| | Firstly the 'pdfwrite' option doesn't seem to do anything different for me | 14:40.56 |
| | There was a problem using gitpush.sh which chris fixed for me. So by chance I had run 2 tests back to back, one nromal, one 'pdfwrite' | 14:41.33 |
| | THey both ran 66000 tests | 14:41.46 |
| | THen henrys brought up the idea of MD5 the PDF output instead of rendering them | 14:42.10 |
| chrisl | So maybe my "fix" didn't fix it at all..... | 14:42.13 |
| kens | chrisl possibly I did something wrong | 14:42.53 |
| marcosw_ | kens: the clusterpush.pl pdfwrite command should only run ~25,000 jobs. Let me check the logs for your clusterpush jobs to see if I can spot anything. | 14:43.59 |
| kens | marcosw its may last cluster push | 14:44.12 |
| tkamppeter | chrisl, thank you very much, without "--with-omni" GS 9.07 builds perfectly for me now. | 14:44.51 |
| chrisl | tkamppeter: cool. Can you communicate to the debian maintainer that? Also that when we remove a device, it's for a reason, and they should tell us if it causes them a problem? | 14:46.03 |
| marcosw_ | kens: right, it appears there is a bug in the email that get's sent out. It says "ran 76327 tests in 728 seconds on 19 nodes". I don't think the 76327 is correct, it can't run that many jobs in ~12 minutes. | 14:46.19 |
| kens | marcosw Well that makes me feel better :-) | 14:46.41 |
| marcosw_ | I'm running a clusterpush.pl pdfwrite filter=ppmraw now and the dashboard says 16013 jobs | 14:46.46 |
| kens | I had actually left the test running so I didn't measure the time myself | 14:46.55 |
| chrisl | marcosw_: the cpu time data suggests it ran all the tests | 14:49.03 |
| kens | THe times in the cluster reports are different chrisl | 14:49.31 |
| chrisl | oh, so the parts of the test that don't run get the value from the previous run? | 14:51.01 |
| marcosw_ | chrisl: that's it. | 14:51.21 |
| chrisl | Ah, okay | 14:51.28 |
| marcosw_ | it was a hack which I was going to come back and fix later, maybe I will when I fix the "ran 76327 tests in 728 seconds on 19 nodes" issue. | 14:52.00 |
| | kens: did you want the cluster to compare the md5sums of the pdfwrite/ps2write output directly for performance reasons or because you want to make sure it doesn't change? If you are concerned about performance running "clusterpush.pl pdfwrite filter=ppmraw.72" only takes ~5 minutes (and most of that is compiling). | 14:55.51 |
| kens | marcosw henrys thought that using MD5 might improve the performance, that's all | 14:56.21 |
| | It might make enough difference to bw worth cxonsidering for a full t=cluster test, btu I don't know | 14:57.10 |
| marcosw_ | as I said, it would, but not measurably, and dealing with the pdf timestamps would probably not be worth the effort (not to mention architectural changes to the cluster, i.e. we'd have to calculate and store md5sums for the last git commit for the pdf/ps intermediate files to be able to produce a comparison). | 14:58.13 |
| kens | marcosw fair enough, I shan't corry about it :-) | 15:01.00 |
| | worry* | 15:01.11 |
| tkamppeter | I have found a file on which GS 9.07 immediately segfaults: altona_technical_1v2_x3.pdf. Do you have the file in your repos or should I send it to you somehow. | 15:04.27 |
| kens | It sounds familiar | 15:04.41 |
| | Yes we have it, and it gets tested as part of a cluster run, so it works 'ordinarily' | 15:05.19 |
| chrisl | tkamppeter: works for me - what command line did you use? | 15:06.31 |
| kens | tkamppeter : you should open a bug report if you have a condition where it fails | 15:06.48 |
| tkamppeter | chrisl, kens: gs ~/altona_technical_1v2_x3.pdf | 15:06.53 |
| chrisl | tkamppeter: yep, works for me | 15:07.01 |
| tkamppeter | chrisl, kens, I also used: gs -sDEVICE=cups -r600 -dcupsColorSpace=1 -sOutputFile=../z ~/altona_technical_1v2_x3.pdf | 15:07.19 |
| kens | 1OS, word length, | 15:07.19 |
| | ? | 15:07.20 |
| tkamppeter | Both crash for me. | 15:07.26 |
| kens | OS is Ubuntu ? | 15:07.38 |
| tkamppeter | chrisl, kens: Raring of today, 64-bit. | 15:07.57 |
| chrisl | tkamppeter: both command lines work for me | 15:08.25 |
| kens | thnks, shared libraries ? | 15:08.59 |
| chrisl | It probably is, yes | 15:10.21 |
| tkamppeter | kens, chrisl, yes, shared libs, gdb backtrace here: http://paste.ubuntu.com/5610925/ | 15:10.27 |
| chrisl | Yep, well, there you go...... | 15:10.51 |
| kens | yes, little CMS | 15:11.08 |
| tkamppeter | kens, chrisl, I have forwarded it now to the guy who applied the patched to littleCMS. | 15:19.02 |
| kens | makes sense tkamppeter | 15:19.22 |
| chrisl | tkamppeter: there were patches to lcms2 that are needed by 9.07 *but* those stopped it building, not caused a crash. | 15:19.52 |
| kens | chrisl but those have been adopted now I thought ? | 15:20.25 |
| chrisl | kens: they are in Marti's repo, yes, but not in a release yet | 15:20.41 |
| kens | ah, ok | 15:20.48 |
| _schulte_ | any chance this could be committed to the mupdf git repo? http://sprunge.us/DUCj | 15:57.47 |
| | I find the signals to be useful, e.g., in scripts like the following... http://sprunge.us/WNIP | 15:58.20 |
| kens | _schulte_ : didn't you open a bug report for this ? | 15:59.36 |
| _schulte_ | nope, I can do that if it's preferrable | 15:59.57 |
| kens | THen I thinksomeone else did, just a moment | 16:00.09 |
| | and yes, bug reports set to 'enhancement' will mean things don't get lost | 16:00.32 |
| _schulte_ | alright, I can create one if there isn't one already | 16:00.53 |
| kens | Hmm maybe you brought it up on irc already ? I'm sure I saw this but I can't find it now. There's currently only one MuPDF on duty, the rest are on vacation, so whatever the decision is (and nothgin to do with me) it will be a few days before it gbets decided | 16:02.15 |
| _schulte_ | yea, I mentioned it on IRC yesterday, but saw no response | 16:02.28 |
| | sorry to spam it, just didn't want it to get lost | 16:02.37 |
| kens | Ah, the lack of response is due to people travelling back from our staff meeting or being on vacation | 16:02.47 |
| _schulte_ | alright, I'll add it to the bug repo as an enhancement | 16:03.01 |
| | thanks | 16:03.03 |
| kens | No problem, someone should get back to you at some point | 16:03.22 |
| henrys | is really having problems with Air Canada I wonder if this is an isolated problem or their customer service can really be this bad. | 16:27.33 |
| ray_laptop | marcosw: I didn't realize that Apple Preview had a distiller capability -- Whose PostScript is it ? | 16:58.59 |
| henrys | ray_laptop:adobe | 16:59.26 |
| ray_laptop | henrys: thanks. Wow, that must be lucrative for Adobe ! | 16:59.57 |
| kens | ray_laptop : I expect not | 17:00.45 |
| ray_laptop | except it means that Adobe only sells Acrobat for use on Apple to those that don't know they don't need it ;-) | 17:01.22 |
| kens | A former employer was dealing with Apple over that and would have ended up with the deal if an agreement could have been reached | 17:01.23 |
| ray_laptop | kens: Artifex was (sort of) in the running as well, but we had 'negotiation' problems, too. | 17:02.26 |
| kens | My former employer had gone right to the end and (we were told) was preferred by the AQpple team | 17:02.54 |
| | THat was when Ian and I visited Cupertino | 17:03.09 |
| | We saw OS/X running under Windows which was weird but interesting | 17:03.44 |
| ray_laptop | kens: that does sound weird | 17:04.07 |
| kens | We weren't allowed to talk about it, but I'm sure it doesn't matgter now | 17:04.50 |
| | Off now, goodnight all | 17:09.09 |
| ray_laptop | to fix a stack overflow bug, I am getting rid of the really large things that are stack based structures in clist_playback_band | 17:11.22 |
| | mvrhel_laptop: Have time for a question? | 17:25.24 |
| tkamppeter | chrisl, I succeeded to fix the LCMS2 patch and now GS 9.07 is stable for me. | 17:25.37 |
| mvrhel_laptop | ray_laptop: yes | 17:25.44 |
| chrisl | tkamppeter: oh, that's good. Do you know what the problem was? | 17:25.59 |
| ray_laptop | mvrhel_laptop: oh. nm. I was misreading something. | 17:26.45 |
| mvrhel_laptop | ok that was easy :) | 17:27.11 |
| ray_laptop | the file I am looking at has the BBox for all of the patterns in it set to [ 0 0 596 842 ], and one of the patterns draws stuff with two different patterns. so we end up with 3 levels deep clist_playback_band (two for pattern_clist) | 17:30.16 |
| tkamppeter | chrisl, no, only my patch is much larger than the patch from the LCMS2 repo which my co-worker had applied. Seems that some parts of your work did not make it to upstream LCMS2. Perhaps I e-mail you my patch and you can check it, see whether what upstream got is correct and what is perhaps too much in my patch. | 17:46.31 |
| chrisl | tkamppeter: as far an I am aware, all the changes we've made in LCMS2 are now in the upstream repo, but I can check it for you, sure | 17:48.39 |
| tkamppeter | chrisl, patch is in your mail now. | 17:49.12 |
| | chrisl, perhaps all this is upstream but the references I got do not contain all needed commits. | 17:49.41 |
| chrisl | tkamppeter: functionally, I believe there is only one commit missing from the upstream LCMS2 repo, and that is alexcher's fix for systems that lack an identifiable 64 bit integer type. A big chunk of the patch, I think, are performance improvements (specifically concerned with cacheing results) which *ought* to be functionally identical, but faster, than the current LCMS2 code - I'm not sure of their status. | 18:06.29 |
| | mvrhel_laptop: can we pass this up to Marti? http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=53e2990b | 18:07.50 |
| mvrhel_laptop | chrisl: do you want me to do that? | 18:20.05 |
| chrisl | mvrhel_laptop: I thought we'd agreed you'd be the "staging post" for LCMS2 fixes | 18:20.34 |
| mvrhel_laptop | ah. ok. I will handle it. | 18:20.53 |
| chrisl | mvrhel_laptop: thanks. Also, do you know what the status of the changes related to cmsxform.h is? It doesn't look like Marti has included those.... | 18:22.17 |
| mvrhel_laptop | chrisl; I will ask him in the email. | 18:22.49 |
| chrisl | Thanks | 18:23.20 |
| mvrhel_laptop | bbiab | 18:38.14 |
| ray_laptop | dang. the gx_device_tile_clip (part of the tile_fill_state) is 20024 bytes! I wonder how much it will kill our performance to allocate and free that ? | 18:40.53 |
| | thing is it is only used when the tile is masked | 18:41.12 |
| | I'll get a rough idea by running a regression before and after | 18:41.57 |
| | at least I've helped the stack depth a LOT. From about 128Kb down to about 40Kb for the two level nested clist patterns | 19:27.44 |
| | Holy Cow! The "crash.pdf" file for bug 693079 goes down to 4 levels of clist_playback_band before it finally gets down to a pure color it can fill with. | 19:54.49 |
| henrys | git://git.ghostscript.com/user/henrys/ghostpdl.git gives me an access denied - your repo works fine. I haven't used it in a long time, did something change? | 20:05.40 |
| | chrisl ^^^ | 20:06.30 |
| | tor8:ping | 20:18.40 |
| ray_laptop | I thought marcosw was only going to use aws instances when there were a lot of user jobs stacked up. Or is this just testing ? | 20:19.40 |
| henrys | he's experimenting with it | 20:19.56 |
| | ray_laptop:when is the last time you used your remote repos, does this work for you: git remote show git://git.ghostscript.com/user/ray/ghostpdl.git | 20:20.57 |
| | chrisl seems to have the only repo that works | 20:21.09 |
| | I wonder if the directory restructure is related. | 20:21.54 |
| ray_laptop | henrys: I get: fatal: remote error: access denied or repository not exported: /user/ray/ghostpdl.git | 20:21.59 |
| henrys | yeah that's what I get on mine too. | 20:22.23 |
| ray_laptop | hmm... I must not have run a user regression since the directory restruture. It is having to update 16893 objects :-( | 20:23.35 |
| | oh no! it looks like ALL of the aws machines are now enabled | 20:26.24 |
| | and I wanted to do a timing run to compare with my changes | 20:27.04 |
| | hmm... even though they are enabled, they don't seem to be starting | 20:29.22 |
| henrys | bbiab | 20:37.02 |
| tor8 | henrys: have you got a git-daemon-export-ok file in ~/repos/ghostpdl.git ? | 20:37.13 |
| ray_laptop | tor8: on casper ? | 20:41.55 |
| tor8 | ray_laptop: yes. you need a git-daemon-export-ok file in the bare repo to allow git:// protocol access | 20:42.24 |
| ray_laptop | tor8: nope just HEAD config description and packed-refs (and some directories) | 20:43.54 |
| | tor8: what goes in that file ? | 20:44.34 |
| | oh, it looks like it is 0 length. So I can just make it with touch | 20:45.54 |
| | (I looked at chrisl's) | 20:46.07 |
| chrisl_away | Erm, henrys's URL doesn't look right to me...... | 20:46.37 |
| ray_laptop | tor8: that fixed it! I just did: touch repos/ghostpdl.git/git-daemon-export-ok and now henry's "remote show" works | 20:47.16 |
| | henrys: see above | 20:47.47 |
| chrisl_away | ray_laptop: that gets you a read-only repo, though, that's not normally what we want | 20:48.01 |
| ray_laptop | chrisl_away: Oh. So what do I _really_ need ? | 20:48.31 |
| chrisl_away | ray_laptop: I use, for example, git clone chrisl@ghostscript.com:/home/chrisl/repos/ghostpdl.git | 20:49.15 |
| tor8 | using ssh you get write access, git:// is for read-only access (which is fine if you want to look at other's repos) | 20:50.02 |
| ray_laptop | chrisl_away: OK. Thanks. I'm sure henry will check the logs when he gets back | 20:50.06 |
| | chrisl_away: I see. so since you have 'export-OK' that means I can use the git:// protocol to read your remote repo | 20:51.08 |
| marcosw | ray_laptop: I'm just testing. I found that we can get a spot instance for $0.12/hour rather than a $1.00/hour. The spot instances are demand based, so in theory the price goes up and down, but it's been $0.12/hour for the last month. | 20:51.33 |
| ray_laptop | chrisl_away: and now everyone can read mine :-/ | 20:51.34 |
| | marcosw: cool 1/8 the cost. Still in 1 hour minimum increments I assume | 20:52.07 |
| marcosw | yes. | 20:52.19 |
| chrisl_away | ray_laptop: I can't access my repo using henrys's method above... e.g. git remote show git://git.ghostscript.com/user/chrisl/ | 20:52.26 |
| | I get the "fatal: remote error: access denied or repository not exported: /user/chrisl/ " error | 20:52.43 |
| marcosw | and because you have to request them differently they take an extra couple of minutes to come up (and can go away at anytime, assuming they need the instance for someone who is willing to pay more; they warn you about that in no uncertain terms). | 20:53.44 |
| chrisl_away | henrys: you probably want to use: git remote show (henrys@)ghostscript.com:/home/henrys/repos/ghostpdl.git | 20:54.41 |
| ray_laptop | chrisl_away: what are the extra ( ) around the username for. I get a shell error, but "git remote show ray@ghostscript.com:/home/ray/repos/ghostpdl.git" works OK | 20:56.34 |
| | have to go pick up my son from school. bbiab | 20:57.20 |
| chrisl_away | ray_laptop: the parentheses were meant to indicate that the username@ might not be required - I need it because my username on casper does not match my local username | 20:57.23 |
| ray_laptop | thanks, chrisl_away | 20:57.27 |
| | chrisl_away: I understand. since my username on msys is also 'ray' it also works for me with just: git remote show ghostscript.com:/home/ray/repos/ghostpdl.git | 20:58.34 |
| henrys | chrisl_away: this works fine for me git remote show git://git.ghostscript.com/user/chrisl/ghostpdl.git - not sure why anyway thanks for the @... | 20:58.45 |
| chrisl_away | henrys: yes, when I copied the command from above, it chopped part of it off..... | 20:59.32 |
| ray_laptop | henrys: you can "look" (readonly) at chris's repos but you have to use ssh for r/w | 20:59.37 |
| | henrys: git:// protocol is read only (is that correct, chrisl_away ?) | 21:00.16 |
| henrys | shouldn't be. | 21:00.29 |
| chrisl_away | henrys: yes it should | 21:00.51 |
| henrys | something is lurking chrisl's works and everyone else's doesn't | 21:00.53 |
| ray_laptop | henrys: seems like it should be. That's the mode that non-artifex people use to access our git repos | 21:01.13 |
| henrys | I thought they used http:// | 21:01.26 |
| ray_laptop | only we can push to it (using ssh) | 21:01.29 |
| henrys | okay so I want to push to my repository what do I set the remote to exactly? | 21:02.17 |
| ray_laptop | henrys: no, they can have a local git clone -- makes it easier to look at logs, etc. They just can't push (AFAIU) | 21:02.21 |
| | henrys: should be henrys@ghostscript.com:/home/henrys/repos/ghostpdl.git | 21:03.10 |
| henrys | thanks | 21:03.29 |
| ray_laptop | too many "henrys" in that I think ;-) | 21:03.41 |
| chrisl_away | henrys: git remote add <local name> henrys@ghostscript.com:/home/henrys/repos/ghostpdl.git | 21:04.09 |
| ray_laptop | henrys: and you can (probably) just use henrys@ghostscript.com/repose/ghostpdl.git | 21:04.44 |
| | s/repose/repos/ | 21:04.54 |
| chrisl_away | so I use 'git remote add personal henrys@ghostscript.com:/home/henrys/repos/ghostpdl.git' | 21:05.12 |
| | so I have a remote called "personal" | 21:05.24 |
| ray_laptop | one more time: henrys@ghostscript.com:repos/ghostpdl.git | 21:05.36 |
| chrisl_away | ray_laptop: you need the path: henrys@ghostscript.com:/home/henrys/repos/ghostpdl.git | 21:06.17 |
| ray_laptop | since the default CWD is /home/henrys/ when you go in under ssh | 21:06.37 |
| chrisl_away | ray_laptop: but think of scp, that requires the full path | 21:07.20 |
| ray_laptop | chrisl_away: git remote show ghostscript.com:repos/ghostpdl.git WORKSFORME | 21:07.21 |
| | also when I do scp I can assume that the paths are relative to ~ray | 21:07.48 |
| chrisl_away | ray_laptop: oh, I can't - I wonder if it's because I have mismatching usernames between the machines | 21:08.22 |
| henrys | chrisl_away: fix for you to review pushed, you may want to set things up differently. | 21:09.27 |
| | with respect to the trace device. | 21:10.20 |
| | but why don't you just fix your username? | 21:10.36 |
| chrisl_away | henrys: all my local machines use the same username, and I connect to those more often than I do casper. | 21:11.26 |
| | henrys: the trace device change looks fine - I didn't realise it wasn't in devs.mak to start with :-( | 21:11.55 |
| henrys | yes, puzzling | 21:12.18 |
| chrisl_away | Well, not first such oddity I've found - certainly won't be the last! | 21:12.56 |
| | So, if everyone is happy, I'm going to fade into the background again - not quite recovered from the return flight yet..... | 21:13.44 |
| henrys | good night | 21:14.06 |
| liar | how would i calculate x^(1/3) in postscript? | 23:43.22 |
| | Forward 1 day (to 2013/03/14)>>> | |
IRC Logs