| | <<<Back 1 day (to 2015/01/29) | 20150130 |
| vimmonkey | Can u specify ICC profiles with ghost scripts during conversions? | 00:36.30 |
| | http://www.ghostscript.com/doc/9.07/GS9_Color_Management.pdf WOW that was burried int the documentation lol | 00:40.13 |
| mvrhel_laptop | vimmonkey: yes | 00:40.39 |
| | lots of flexibility when it comes to color management in ghostscript | 00:41.03 |
| vimmonkey | -sDefaultGrayProfile, -sDefaultRRGBProfile, -sDefaultCMYKProfile and -dOverrideICC | 00:41.03 |
| | -sOuputICCProfile too (typed these in so someone goolign can find the answer =) | 00:41.32 |
| rayjj | vimmonkey: and -dUeFastColor (reverts to pre-icc type color conversion) | 01:12.24 |
| | vimmonkey: and -dUeFastColor=true (reverts to pre-icc type color conversion) | 01:12.39 |
| vimmonkey | rayjj: hm, thanks. i'm working with illustrator files⦠and i just noticed that the blacks are marked as "spot colors" in illustrator. When i use gs they come out as a greyishâ¦was thinking it was a ICC profile, not sure though. I'll try -dUseFastColor | 01:14.09 |
| rayjj | vimmonkey: if you are used to "old" (pre 9.00) gs, then -dUseFastColor might be closer to what you want | 01:15.27 |
| vimmonkey | erm, s/spotcolors/processcolors/g. I am using 9.2. Erm, basically the issue I'm working around is when the -dUseCIEColor is specified, it takes around 8-9 seconds.. without the option its under a second. | 01:16.32 |
| | erm sorry, using 9.05 | 01:16.49 |
| rayjj | vimmonkey: I'd have to check when UseFastColor got added. just a sec. | 01:18.37 |
| | vimmonkey: it was commit 592047 Tue Dec 6 12:52:31 2011, so it would be in the release that following Feb 2012, which was the 9.05 release -- you should be OK | 01:21.19 |
| vimmonkey | hm i'll try it | 01:21.44 |
| rayjj | vimmonkey: and for "fast" approximate colors, don't use -dUseCIEColor | 01:22.01 |
| | mvrhel_laptop: please correct me if I mis-stated :-) | 01:22.37 |
| vimmonkey | yeah, imagick defaults to using that value <_< | 01:22.50 |
| rayjj | vimmonkey: by "approximate" colors, it means using the old approach for CMYK->RGb rather than using an ICC profile | 01:23.31 |
| vimmonkey | yeah, if i use UseFastColor i lose my grays (which are black in the illustrator file....) | 01:25.30 |
| | again it's a process color, so not sure what that means, got to read up more on printing and stuff <_< | 01:25.49 |
| rayjj | vimmonkey: do you mean that the grays are white ? | 01:26.20 |
| rayjj | isn't sure what "lose my grays" means | 01:26.44 |
| vimmonkey | ermâ¦bascially my black colors in illustrator are turning really light grey, whites are fine. i think this might be image magick though, one second have to run p-trace and get the command it's using again | 01:27.59 |
| rayjj | vimmonkey: BTW, are you starting with an Illustrator PS file or PDF file ? | 01:28.08 |
| vimmonkey | *strace | 01:28.09 |
| | rayjj: erm..it's a .ai file, but theres an option in illustrator which saves the document as a pdf more or less, and then incodes all the ai stuff into the pdf document | 01:29.59 |
| rayjj | vimmonkey: right, new Adobe apps (Illustrator and other CS apps) have PDF as the native format | 01:30.40 |
| | at least it's more "portable" than the PS was | 01:30.56 |
| vimmonkey | yeahâ¦and dis regard everything i said earlier. i think gs is working fine, i forgot my php script was using imagick and not gs⦠| 01:31.34 |
| | so my colors are being modified by imagick <_< | 01:31.46 |
| rayjj | vimmonkey: for PDF, I'm not sure what imagemagick uses, I know it uses gs for PS input | 01:32.15 |
| vimmonkey | yeah, ghost script looks like it's working fine, it's some imagick settings that are wrong <_< my bad, sorry for wasting your time | 01:33.20 |
| | ok, i need to take a break | 01:35.10 |
| | thanjks again for your help guys =) | 01:35.15 |
| kens | chrisl do we create man pages for Unix systems ? | 10:20.11 |
| chrisl | kens: erm, sort of... | 10:20.50 |
| kens | Oh, that's unfortunate. | 10:20.57 |
| | THe one for 'ps2ps' ? | 10:21.18 |
| chrisl | I guess so.... | 10:21.34 |
| kens | Can I modify it ? | 10:21.40 |
| | And where do I find it ? :-) | 10:21.50 |
| chrisl | It's in gs/man/ps2ps.1 | 10:22.25 |
| kens | OK I'll have a poke, thanks | 10:22.33 |
| chrisl | You can modify it. I don't know nroff, so whenever I change them it's monkey see/monkey do...... | 10:23.06 |
| kens | OMG well I guess removing bits should be easy | 10:23.22 |
| | Hmm, the ps2ps in there doesn't seem to mention LanguageLevel | 10:24.11 |
| | Oh no, there it is. | 10:24.17 |
| chrisl | Erm, that whole section is b*llocks..... | 10:25.00 |
| kens | I removed the reference to LanguageLevel and said 'The output is level 2 DSC 3.0 conforming PostScript.' | 10:25.39 |
| chrisl | It says "Normally the output is allowed to use PostScript Level 2 or Level 3 constructs, but the -dLanguageLevel=1 option restricts the output to Level 1" | 10:26.31 |
| kens | Yeah I deleted all of that | 10:26.40 |
| | And replaced it | 10:26.44 |
| chrisl | But that's never been true...... | 10:26.56 |
| kens | Nope, not ever, I don't know who wrote it | 10:27.06 |
| chrisl | It clarifies why so many people have been using -dLanguageLevel=X though | 10:27.36 |
| kens | I guess it does. I'm also removing the section on pswrite.... | 10:27.57 |
| | Well, the whole .SH BUGS section in fact | 10:29.01 |
| chrisl | Don't forget to the change the date and the gs version before you commit it | 10:29.52 |
| kens | I'm doing both | 10:29.59 |
| chrisl | Ta | 10:30.04 |
| kens | And also checking if we even ship an 'eps2eps' script | 10:30.08 |
| chrisl | We do - dumb idea :-( | 10:30.41 |
| kens | apparently we do, who knew ? | 10:30.44 |
| | But not a ps2eps.... | 10:31.39 |
| | So is there any way I can look at the actual output ? | 10:34.46 |
| | On Linux obviously | 10:34.54 |
| chrisl | Er, possibly...... | 10:35.06 |
| kens | I can live with a 'no' :-) | 10:35.19 |
| chrisl | I can't remember how you get it formatted like a man page | 10:35.46 |
| kens | I'll have a google | 10:36.00 |
| chrisl | Ah, it looks like if you do into the man directory, and do "man ./ps2ps.1" it's show you | 10:36.36 |
| kens | OK let me try that | 10:36.49 |
| kens | launches VM | 10:36.58 |
| chrisl | Yeh, that does it | 10:37.21 |
| kens | Great I'll let you know in a second | 10:37.32 |
| | Well it looks OK to me, I'll commit it | 10:39.15 |
| chrisl | Well that's, um, weird..... | 10:46.37 |
| kens | ? | 10:46.40 |
| chrisl | clusterpushing with the CFF versions of the fonts, I get segfaults in ps2write..... | 10:47.16 |
| kens | :-( | 10:47.27 |
| | I can look into it if you like | 10:47.36 |
| chrisl | But when I debug it, it's actually handling a type 3 font | 10:47.56 |
| kens | Err yeah that's odd | 10:48.04 |
| | Is they type 3 based off a built-in font or something ? | 10:48.16 |
| chrisl | Not that I can see, no | 10:48.52 |
| kens | is confused then.... | 10:49.06 |
| chrisl | In fact, the Type 3 font only seems to have one glyph..... | 10:49.55 |
| kens | Well I've just finished the man pages stuff, so if you push it to your repository I cna take a poke | 10:50.38 |
| chrisl | There's a branch in my repo called "cff-fonts-experiment", that's got the fonts, and some Postscript changes needed for them to work "properly" | 10:51.52 |
| | The test file I'm looking at is: 14-02.PS | 10:52.19 |
| kens | OK give me a minute. I may come back asking for Git help butI *think* I know how to do this.... | 10:52.22 |
| chrisl | "git fetch chrisl" should get the stuff from my repo | 10:53.53 |
| kens | Yeah done tha,t I was having trouble getting the branch cheked out, turns out I can't spell fotns | 10:54.48 |
| | Quick clean and rebuild.... | 10:55.09 |
| chrisl | Strange, fotns isn't that hard to spell.... | 10:55.12 |
| | ;-) | 10:55.17 |
| Robin_Watts | I oftsn get fonst wrong. | 10:55.44 |
| kens | twiddles thumbs impatiently | 10:56.31 |
| chrisl | My spilling is usual quote good, it's my tipping that I straggle with | 10:58.33 |
| kens | 'Allo 'Allo ? | 10:58.51 |
| chrisl | I does rather smack of that, doesn't it? | 10:59.25 |
| kens | OK build done and I grabbed the test file, let me see | 10:59.38 |
| | GPFs in cos_stream_add for me | 10:59.51 |
| | Way down deep from doing a fill | 11:00.20 |
| chrisl | It wasn't there for me, but it sounds a similar area | 11:00.32 |
| kens | pdev->streams is borked | 11:00.37 |
| | In fact, pdev is NULL | 11:01.00 |
| chrisl | For me it went bang in cos_release() | 11:01.07 |
| kens | Hmm, it sort of sounds like a memory problem of some kind | 11:01.29 |
| | dev is OK when the fill takes place, it obviously gets stomped on | 11:01.58 |
| chrisl | It sounds like a real problem that's just been exposed by doing things a bit differently.... | 11:02.48 |
| kens | Maybe not | 11:02.54 |
| | The device is actually stored in the cos stream object | 11:03.05 |
| Robin_Watts | valgrind show anything useful? | 11:03.05 |
| kens | And its wrong in there (ie null) | 11:03.15 |
| chrisl | valgrind doesn't give much more information - invalid read size 8 then segfault | 11:04.11 |
| kens | The composite object referenced by the stream is not valid, that's the basic problem | 11:04.42 |
| | I think I need to look at the stream_open to find out why | 11:04.57 |
| chrisl | kens: there's no major rush, the CFF or OTF, or whatever, won't be going out in the March release! | 11:05.46 |
| kens | Its a reasonably convenient time to look, its this or the /Pattern colour space..... | 11:06.08 |
| | OK when we complete the CharProc accumulation we close an 'aside' and set the current stream back to the 'saved' stream. However, thestream we go back to appears to be broken in some way, I'm not sure why yet. | 11:38.30 |
| | It looks like something is definitely overwriting pdev->strm, it always has hte same value, when we get to the error point, and that's not possible with address space randomisation. So something must be overwriting it. Sadly it gets changed a *lot*, so this may take a while. | 11:58.27 |
| | Err, no, that;s nonsense :-( | 12:00.18 |
| | Back to square one. | 12:00.33 |
| | lunch, bbiab | 12:11.25 |
| henrys | kens: I was foolling around with the otf's not sure what font type I should use for pdfwrite - declaring them truetype for the graphics library is okay because freetype sorts it out but pdfwrite wants something different. Do you know off the top of your head. Don't spend time on it, I can look if you don't know. | 14:29.57 |
| kens | pdfwrite is happy (or shold be) with *any* type supported by PostScript | 14:30.25 |
| | Of course, if you use TrueType all sorts of fallbacks and heuristics will come into force | 14:31.06 |
| | because PostScript doesn't support TrueType directly | 14:31.20 |
| Robin_Watts | do otfs (with cff outlines) count as truetype in that statement? | 14:32.05 |
| kens | Almost certainly, yes | 14:32.19 |
| henrys | kens: I'm using otf's with cff outlines and am trying to figure out what value in the enumeration font_type in gxftype.h I should be setting. | 14:32.35 |
| chrisl | I doubt pdfwrite ever have seen an otf with CFF outlines before...... | 14:32.54 |
| Robin_Watts | Could pdfwrite be made to recognise otfs with cff outlines as cff? (and would there be a benefit to doing so) ? | 14:33.15 |
| kens | I'm sure pdfwrite will never have seen such a thing. In PostScirpt it would be either a type 2 or a type 42, in PDF it would be a type 1c | 14:33.38 |
| | Robin_Watts : its not pdfwrite, it just looks at what the graphics library presents it with. As CHris and I keep sayign, you can't do TrueType in PostScript, so you get compromises | 14:34.13 |
| henrys | kens: so if I add an otf with cff outliines to the gs fontmap use it and create pdf what is put out? | 14:34.28 |
| kens | I suspect pdfwrite doesn't understand the font its been handed by the graphics library | 14:34.31 |
| | henrys I have no idea | 14:34.38 |
| chrisl | henrys: all else being equal, you'll get a PDF with a Type1C font in it | 14:35.02 |
| kens | But my answer will (as always) be that OpenType and TrueType are not directly supported by PostScript, so anything we choose to do is an extension to the language and inherently unsupported | 14:35.08 |
| | SO if it doesn't work, then we *may* fix it, or we may not | 14:35.28 |
| Robin_Watts | kens: Right, except the current plan (which I thought you and chrisl had signed up to) was that we would be using otfs with cff outlines as our standard fonts. | 14:36.12 |
| kens | henrys you cna try ft_encrypted2 | 14:36.12 |
| | Robin_Watts : We said we would make it work, we never said it *did* work | 14:36.27 |
| chrisl | Robin_Watts: If you load an OTF/CFF via the fontmap, the PS front end makes it into a Type 2 font, so that's what pdfwrite sees | 14:36.48 |
| Robin_Watts | Right, so it might not be supported now, but it could be. | 14:36.49 |
| kens | We cna make it work by stripping off the OTF and loading it as a CFF | 14:36.57 |
| henrys | I'll look at it. Don't make a fuss about it just yet. | 14:37.46 |
| kens | chrisl so why is Henrys having problems ? A type 1c should emerge I'd have thoguht. Also I thought you tried this on the cluster. While I know ps2write threw a fit, didn't pdfwrite work ? | 14:37.46 |
| chrisl | kens: henrys isn't working through the PS interpreter | 14:38.07 |
| kens | Ah, so this is PCL input with pdfwrite. | 14:38.24 |
| chrisl | Yes | 14:38.28 |
| kens | Light dawns. | 14:39.01 |
| chrisl | So the graphics library gets a font labelled as being Truetype, but it really isn't, it's OTF | 14:39.06 |
| kens | OK well pdfwrite will have no idea what to do with that. | 14:39.19 |
| chrisl | As henrys points out, the way the FAPI code works, that will just work, but high level devices, probably not | 14:39.50 |
| kens | In order to handle it it needs to be one of the font types available that we already handle. In short you need to strip the CFF out of the OTF and pass it as a type 2 | 14:40.04 |
| rayjj | chrisl: as build master, when you have a chance, can you have a look at http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=9bcd6f76dcb6d25c90b6c273b1e9c6b0082bb53f | 14:40.49 |
| henrys | chrisl: I did some comparisons with courier the new fonts look good against the truetype we have now. Looks like your results. | 14:41.20 |
| rayjj | chrisl: as you can see, I fixed the problem with needing pdfwrite | 14:41.42 |
| chrisl | rayjj: when tried the minimal build, I got a missing symbol "update_spot_equivalent_cmyk_colors", do your makefile changes fix that? | 14:42.44 |
| henrys | rayjj: the email response is pretty high priority ini the scheme of things. | 14:43.01 |
| chrisl | henrys: I'm actually very surprised at how few rendering differences there are between the Type 1 and CFF versions | 14:45.43 |
| kens | henrys we can probably handle the font in pdfwrite by defining a new font type (eg 52) which is a TrueType with CFF outlines. pdfwrite can then simply pull the CFF out and use it. It will not be totally trivial though. I htink this will have implications for ps2write also as it will need to convert the CFF back to type 1 | 14:46.33 |
| chrisl | s/TrueType with CFF/OpenType with CFF | 14:47.16 |
| henrys | kens: oh yeah I didn't even think about pswrite | 14:47.21 |
| | well courier is a dull beast we'll see with the others. | 14:48.14 |
| Robin_Watts | henrys: When you get a mo, can we speak on the skype sot room please? no hurry | 14:49.34 |
| chrisl | I'd expected just the fact that the interpreters are *completely* different would result in more significant rendering diffs | 14:49.48 |
| kens | chrisl yes sorry, was too busy looking at the problem | 14:50.55 |
| chrisl | kens: we bitched at henrys for it, so..... :-) | 14:51.36 |
| kens | henrys we do already have code in ps2write to handle CFF fonts (I think) because we can get those in PDF input. Its just a case of making sure it all works. There's plenty of work to do to get this all working properly. | 14:51.58 |
| chrisl | We can get CFF input from PS, too....... | 14:52.31 |
| henrys | HA we should go back to the TT option for internal fonts ;-) .... | 14:52.54 |
| | less work | 14:53.11 |
| chrisl | henrys: less work for who? It would be at least a couple of weeks (plus a bug tail) for me | 14:53.34 |
| henrys | joking ... | 14:53.52 |
| chrisl | henrys: sorry, getting a bit punch drunk from the font arguments! | 14:54.38 |
| henrys | Robin_Watts, chrisl: is there some way to run the cluster without testing pdfwrite at all? I know my current code segv's with pdfwrite but I'd like to see all the glyph changes with the raster devices. I only get one page of output when I do a bmpcmp I think that's because all the crashes in pdfwrite get me over some limit but not sure. | 15:05.45 |
| Robin_Watts | henrys: You run the cluster job as normal. | 15:06.10 |
| | Then when you call bmpcmp add -filter=ppmraw | 15:06.19 |
| henrys | Robin_Watts: yeah that's what I did. | 15:06.47 |
| Robin_Watts | and that will filter the failed jobs so that bmpcmp only tests ppmraw ones. | 15:06.52 |
| | I *thought* the limitation to 1000 jobs happened after the filtering rather than before. | 15:07.10 |
| chrisl | I did it the other way - I filtered the normal cluster run, then did the bmpcmp | 15:07.15 |
| Robin_Watts | chrisl: Does -filter work on the normal cluster run? | 15:07.34 |
| chrisl | Seems so, yes | 15:07.43 |
| Robin_Watts | only wrote that code. | 15:07.43 |
| | Cool! | 15:07.47 |
| | So henrys, try that? | 15:08.01 |
| henrys | wiat it's fixed nvm. | 15:08.03 |
| chrisl | Robin_Watts: I couldn't get bmpcmp to do both filter *and* take the fuzzy parameters | 15:08.16 |
| Robin_Watts | chrisl: hmm, ok. | 15:08.28 |
| chrisl | Robin_Watts: I meant to look into it, but have been rather distracted | 15:08.57 |
| henrys | is there some sort of delay with bmpcmp? cause I swear I only had one page of output when I first got the report now I have all the pages? | 15:09.02 |
| kens | You had a cahed version, you sometimes need to clear out the cache manually | 15:09.24 |
| | Or force a page reload | 15:09.31 |
| Robin_Watts | henrys: Yes. The creation of the html happens 'in the background' after the cluster job ends. | 15:09.33 |
| | hence it can take a couple of minutes to run through. | 15:09.49 |
| henrys | Robin_Watts: thanks that's what it was then. | 15:09.50 |
| Robin_Watts | np. It's all held together with duck tape and spit, you know. | 15:10.10 |
| henrys | chrisl: courier differences are in my bmpcmp | 15:10.20 |
| chrisl | Robin_Watts: And don't forget the bits of string..... | 15:10.33 |
| henrys | TT vs CFF | 15:10.34 |
| Robin_Watts | chrisl: We don't have budget for string... | 15:11.05 |
| chrisl | Robin_Watts: I thought we got some bits of string free with the amazon subscriptions | 15:11.55 |
| | henrys: it looks like PCL is going to need some massaging for this work fully | 15:13.52 |
| henrys | chrisl: euros in a different postion. | 15:14.25 |
| chrisl | And a few other glyphs either different or missing | 15:14.43 |
| henrys | it isn't that bad though. I thought it would be worse. | 15:15.12 |
| chrisl | It may simply mean experimenting to find the right encoding to use | 15:15.29 |
| kens | I always expected there would be *some* work to do. I'm a bit surprised the encoding is different to the type 1 version though | 15:16.42 |
| | D'oh, this is the CFF vs TT isn't it, so an Encoding difference isn't surprising | 15:17.02 |
| chrisl | Yeh, actually, the encoding might be an issue - only 255 glyphs available...... | 15:18.15 |
| henrys | but the rendering is pretty close | 15:18.15 |
| kens | chrisl I thought PCL was only 8-bit, sop presumably 255 glyph positions ie enough ? | 15:18.44 |
| henrys | PCL supports 16 bit character | 15:19.34 |
| kens | Oh, well that vould be a problem then | 15:19.41 |
| | Should be doable though, if we treat the OTF as a TT | 15:20.13 |
| henrys | PCL converts everything to a unicode short through it's internal symbols sets then uses that to index the font. | 15:20.53 |
| | a few exceptions to that but | 15:21.31 |
| | bbiab | 15:22.28 |
| kens | I guess we can use the 3,0 CMAP to go from a Unicode code point to a glyph, I'm just not sure with CFF outlines how we go from a GID to a CharString. Probably we don't have to, CFF CharStrings use integers for the keys as I recall, so I imagine the CHarString uses the same GID as is in the CMAP | 15:22.41 |
| | I'm not sure how this is going to work with pdfwrite, we'll probably end up with lots of fonts defined | 15:23.04 |
| | Shouldn't be any worse than with TT fonts though | 15:23.24 |
| vimmonkey | rayjj: forgot to mention, i ended up using -dUseCIEColor and switching the device type to pngalpha, that sped up generation by order of of magnitueds ( ~ 8 seconds to < 1 second) | 15:33.06 |
| | (was defaulting to pam device) | 15:36.23 |
| | erm..was set to pam device | 15:36.43 |
| kens | chrisl its definitely a memory corruption problem with ps2write. I see that data in a stream structure is being overwritten in pdf_set_charproc_attrs while capturing a CharProc. When we finish the charproc and return back to the previous stream state, it has been corrupted, next time we try and write something to that stream, it crashes. | 15:40.01 |
| chrisl | kens: is that stuff subject to relocation? | 15:40.33 |
| kens | I'm really not sue | 15:40.43 |
| | I cna say that the stream hasn't been relocated in the interim | 15:41.02 |
| | I don't think streams are relocatable | 15:41.46 |
| | Actually yes,these streams *are* relocatable | 15:42.47 |
| | Which is interesting..... | 15:43.16 |
| | I'm not certain that these are enumerated | 15:43.27 |
| chrisl | First thing to check would be if there is actually a gc run in there | 15:44.02 |
| kens | Hmm, any easy way to do that ? | 15:44.14 |
| chrisl | I usually put a breakpoint in the garbage collector code...... | 15:44.50 |
| kens | THere's an awful lot taking place between teh allocation of the top level streams and the time we get to the problem. | 15:45.18 |
| | But if you can give me a name ? | 15:45.25 |
| chrisl | I think I usually use gs_gc_reclaim() | 15:46.13 |
| kens | OK let me try that | 15:46.19 |
| | That breakpoint never gets hit, I guess no GC | 15:47.18 |
| chrisl | So hopefully a simple watch point will be a good hint at the problem | 15:48.18 |
| kens | Well, tha's how I discovered where the memory was being overwritten | 15:48.43 |
| chrisl | So, you could add -Z@ and the watchpoint, and that would indicate if and where the memory is being spuriously freed | 15:49.44 |
| Robin_Watts | kens: This is where I make my obligatory plug for memento. | 15:50.10 |
| kens | Robin_Watts : I've only just proved it was a memory problem | 15:50.29 |
| | Its taken quite a bit of digging to get this far | 15:50.41 |
| Robin_Watts | When you run and you detect that it's overwritten, check globals.sequence | 15:50.51 |
| | That will tell you how many malloc/free events have happened. | 15:51.01 |
| kens | It'll be a lot | 15:51.10 |
| Robin_Watts | Then you can run again with a breakpoint in Memento_inited | 15:51.16 |
| | and in Memento_breakpoint. | 15:51.27 |
| | When the first breakpoint goes off, Alt-Shift-Q and call Memento_breakAt(whatever that number was) | 15:51.49 |
| | That will run and stop you at the memory event before the overwrite. | 15:52.11 |
| | hopefully you can then step through usefully. | 15:52.20 |
| kens | chrisl after digging back to the vector device, the stream in question defintiely is relocatable, and it has proper enumeration and such like. | 15:52.48 |
| | Robin_Watts : I'll try that in a bit. | 15:53.01 |
| | I'll need to rebuild with memento and I'm going to guess that the problem will either go away or move somewhere else, meaing I get to debug it all over again | 15:53.32 |
| Robin_Watts | kens: maybe, yes. | 15:54.20 |
| kens | I'll find out in a minute or two | 15:54.29 |
| chrisl | I'd have tried the -Z@ approach first - it will almost trivially eliminate the possibility of erroneously freed memory, and doesn't slow everything down massively | 15:55.36 |
| kens | I;'m not familiar with -Z@ what does t do ? | 15:56.01 |
| chrisl | Writes bit patterns to newlly allocated, freed and garbage collected memory | 15:56.31 |
| rayjj | chrisl: sorry -- I was running the kids to school and getting coffee. Yes, the addition of $(GLOBJ)gsequivc.$(OBJ) to translib_ fixes that. I tried it with --with-drivers=ppmraw,pgmraw,pbmraw and it builds and now runs | 15:56.32 |
| kens | chrisl yes I just read the docs | 15:56.39 |
| rayjj | chrisl: that may only work with debug builds | 15:56.54 |
| kens | OK so I can try that afterwards, I still have all the breakpoints in place for finding the memory location to trigger on | 15:57.08 |
| Robin_Watts | In this instance I wasn't pimping memento for its memory checking facilities so much as being a way to easily get you to 'stopped in the debugger just before it crashes' | 15:57.16 |
| chrisl | rayjj: as kens is debugging, I assume he's using a debug build..... | 15:57.18 |
| rayjj | kens: so you have a debug build, right | 15:57.30 |
| kens | Oddly enough, yes :-) | 15:57.33 |
| chrisl | rayjj: your commit all looks good to me | 15:57.56 |
| rayjj | chrisl: OK. | 15:58.02 |
| | henrys: that commit was to allow me to build a minimal gs for the ROM footprint, related to the email. I'm trying to collect the data in the background while pursuing cust 532's issue which is a current P1 customer (not a potential P1) | 15:59.44 |
| | henrys: I will get the email out as soon as I have runs that I can trust | 16:00.21 |
| henrys | rayjj: great. | 16:01.01 |
| kens | well memento threw a totally differnt problem, unrecoverable error, non stack trace | 16:01.18 |
| | SO back to -Z@ | 16:01.26 |
| rayjj | chrisl: BTW, the comment about "Fix some (probably not all) dependencies" is because I suspect there are some other devices that have broken dependencies if built alone. Maybe someone (marcosw?) can cycle through doing builds with only a single device for all devices to see what else is broken | 16:06.17 |
| | if marcosw doesn't get around to it, I might set up a job to crank through that after the higher priority work is done | 16:07.05 |
| | kens: sometimes -Z@$? (usually escaped as: -Z@\$\? ) helps as well. -Z? validates pointers and may turn up "object not in any chunk" problems | 16:12.47 |
| chrisl | rayjj: I do have dependencies on my to-do list..... | 16:13.29 |
| rayjj | chrisl: OK. thanks. I'll go back to ignoring it then, as I mostly have over the last many years ;-) | 16:15.58 |
| vimmonkey | Can you specify larger writes? ie only 1 4096 bytes are written out at a time... | 19:30.03 |
| rayjj | vimmonkey: sorry, I don't understand the question (maybe something hasn't posted to the logs yet before I signed back in) | 19:31.30 |
| vimmonkey | rayjj: oh, it's a new issue, was using strace and saw a bunch of writes and each writing out 4096 bytes, was wondering if I could write more data at a time | 19:32.42 |
| Robin_Watts | vimmonkey: That's just buffered IO. | 19:35.14 |
| | what device? | 19:35.18 |
| rayjj | vimmonkey: why? it doesn't (IME) help performance | 19:37.20 |
| Robin_Watts | vimmonkey: In general, most devices output in whatever blocksize is most convenient for them. | 19:37.54 |
| | This goes into an OS buffer, and when it fills that buffer the OS writes it out in a lump. | 19:38.35 |
| | as ray says, writing 4K at a time is NOT going to be bottleneck, I'm sure. | 19:39.10 |
| vimmonkey | Robin_Watts: ah ok, my bad | 19:41.56 |
| Robin_Watts | np. | 19:42.09 |
| vimmonkey | rayjj: for the file write it was taking around ~0.7 seconds, was just wondering if it was possible to trim thigns down | 19:43.05 |
| Robin_Watts | vimmonkey: Which device? | 19:43.44 |
| vimmonkey | 0.846691 open("/tmp/magick--nYFbVF0-00000001", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4, another 0.8 seconds here⦠here | 19:43.50 |
| | vimmonkey: was using png16m | 19:43.55 |
| | erm, Robin_Watts was using png16m | 19:44.03 |
| Robin_Watts | The writing in 4K lumps is not going to be a problem. | 19:44.10 |
| | The device may be writing out in smaller lumps than that though. | 19:44.22 |
| | (almost certainly is) | 19:44.26 |
| vimmonkey | hm, this one vector artwork file I have takes around 5.499 file to convert, was just trying to trim things down. I am on 9.05 | 19:47.06 |
| Robin_Watts | vimmonkey: PDF or PS as input? | 19:47.54 |
| vimmonkey | Robin_Watts: it's a pdf | 19:48.04 |
| Robin_Watts | and you want a bitmap out? | 19:48.15 |
| | I'd be tempted to try mupdf. | 19:48.21 |
| vimmonkey | Robin_Watts: hm ok, i'll give it a shot. | 19:49.11 |
| Robin_Watts | it's less powerful than gs (no color management), but it's possibly a better bet for this job. | 19:49.23 |
| | and you'll get AA for free. | 19:49.35 |
| rayjj | vimmonkey: how many pages ? | 19:49.35 |
| vimmonkey | vimmonkey: it's just one..like i mentioned it's an illustrator file, and im using the pdf portion of it | 19:49.52 |
| | (erm mentioned yesterday) | 19:49.59 |
| rayjj | vimmonkey: and what resolution ? | 19:50.00 |
| | what size png ? | 19:50.27 |
| vimmonkey | 1 second, i'll give you the exact command =). ty for your help... | 19:50.51 |
| | gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/tmp/magick--nYFbVF0-%08d -fslow | 19:51.40 |
| rayjj | if it's low res then mupdf (as Robin says) is probably faster. If it's a large bitmap (high res) then gs -dNumRenderingThreads=3 might be faster (if it is large enough to go to be using a display list / clist) | 19:51.45 |
| | vimmonkey: oh, AlphaBits, yep -- try mupdf | 19:52.07 |
| Robin_Watts | rayjj: Or maybe gs using the downscaler. | 19:52.26 |
| rayjj | vimmonkey: and MaxBitmap=500m is not going to be using the clist | 19:52.44 |
| vimmonkey | ah..yeah i'm hacking away at a image magick delegate file (the ~5seconds i qutoed is just the ghost script portion, got the command by runnign the php script and using ps) | 19:53.48 |
| rayjj | Robin_Watts: vector data is probably pretty sparse, so downscaling processes a lot of raster that just painting vectors probably doesn't | 19:53.57 |
| Robin_Watts | rayjj: yes... but it's illustrator so there could be gradients etc. | 19:54.20 |
| rayjj | Robin_Watts: mupdf, once again, IME, is much faster on gradients than gs | 19:54.47 |
| | Robin_Watts: and gradients in the scaled up bitmap (prior to downscale) are going to be painful | 19:55.15 |
| vimmonkey | hm, the -dNumRenderingThreads=3 stripped out 2 seconds, so around 3.3 now ..i'll try mupdf now | 19:55.36 |
| Robin_Watts | vimmonkey: How long does: gs -sDEVICE=png16m -r900 -dDownScaleFactor=3 -o out%d.png in.pdf take ? | 19:55.36 |
| rayjj | vimmonkey: note in the command line from Robin_Watts, there is *no* -dGraphicsAlphaBits=4 -dTextAlphaBits=4 (the downscaling does that) | 19:56.54 |
| | vimmonkey: and Robin_Watts' command line will probably benefit from -dNumRenderingThreads=3 | 19:57.26 |
| vimmonkey | 5.10user 0.02system 0:05.14elapsed 99%CPU (0avgtext+0avgdata 19216maxresident)k | 19:57.57 |
| | 0inputs+1896outputs (0major+5299minor)pagefaults 0swaps | 19:57.57 |
| | (without the -dNumberRenderingThreads) | 19:58.12 |
| rayjj | vimmonkey: note it's not NumberRenderingThreads, but -dNumRenderingThreads=3 | 19:59.05 |
| Robin_Watts | So the downscaler is faster than alphabits ? | 19:59.20 |
| rayjj | sounds like it's about a wash | 19:59.42 |
| vimmonkey | gs -sDEVICE=png16m -r900 -dDownScaleFactor=3 -o out%d.png -dNumRenderingThreads=3 -fslow | 19:59.49 |
| Robin_Watts | 5.1 vs 5.5 | 20:00.10 |
| vimmonkey | erm 1 sec | 20:00.14 |
| | ~ 4.817 user | 20:00.35 |
| | i might do some pre processing to the artwork file actually to speed things up to ..but , alright mupdf time heh | 20:01.02 |
| rayjj | vimmonkey: strange that the user time is less -- I expect -dNumRenderingThreads=3 elapsed to be less | 20:01.15 |
| vimmonkey | yeahâ¦. | 20:02.00 |
| rayjj | vimmonkey: unless you get billed per CPU cycle, you don't care about user time :-) | 20:02.01 |
| vimmonkey | lol | 20:02.09 |
| rayjj | vimmonkey: what was the elapsed gs time with downscaling and multiple threads ? | 20:03.07 |
| vimmonkey | erm 1 sec | 20:06.15 |
| | time gs -sDEVICE=png16m -r900 -dDownScaleFactor=3 -o /tmp/out%d.png -dNumRenderingThreads=3 -fslow | 20:07.36 |
| | real 0m4.847s | 20:07.48 |
| | user 0m5.248s | 20:07.48 |
| | sys 0m0.072 | 20:07.48 |
| | this is odd..installed mupdf-tools w/ debian but mudraw isn't in my path hehâ¦. | 20:08.24 |
| Robin_Watts | mupdf-tools is a different package. | 20:08.43 |
| | mupdf-tools is stuff like mutool (or pdfclean, pdfextract etc if it's an old version) | 20:09.11 |
| | You want mupdf | 20:09.16 |
| vimmonkey | ah, yeah i installed mupdf, and have access to mupdf, but it ants to use X and i don't have it on this box | 20:10.42 |
| | let me rad the man page... | 20:10.46 |
| Robin_Watts | Try pdfdraw ? | 20:11.05 |
| | debian might be VERY old. | 20:11.12 |
| | vimmonkey: Probably easiest to just build it from source. | 20:11.33 |
| vimmonkey | yeah pdfdraw exists | 20:11.57 |
| rayjj | vimmonkey: and the gs elapsed time with -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dNumRenderingThreads=3 was 3.3 sec ? | 20:12.00 |
| vimmonkey | rayjj: i'll run again | 20:12.24 |
| Robin_Watts | vimmonkey: If it's that old, speed/quality will not be as good as it is these days. | 20:12.42 |
| vimmonkey | Robin_Watts: yeah, i had arch on the system but when i was setting it up realized maintainence was going to be really high lol.. | 20:13.23 |
| rayjj | we're always interested in which of our products is better ancient gs or wet behind the ears mupdf ;-) | 20:13.34 |
| vimmonkey | lol | 20:14.27 |
| rayjj | mupdf is not even a teenager yet. gs is almost 30 | 20:14.39 |
| vimmonkey | dang, didn't know mupdf was related to ghost script, sorry | 20:14.56 |
| Robin_Watts | mupdf is easy to build from source. There is a single .tgz with all the dependencies in. just unpack it and "make build=release" | 20:14.58 |
| | vimmonkey: Not related. Just flatmates :) | 20:15.09 |
| | with the same cleaners :) | 20:15.24 |
| rayjj | vimmonkey: they are both products developed/maintained/supported by Artifex Software | 20:15.29 |
| | and some folks work on both (if forced to) | 20:15.56 |
| vimmonkey | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/tmp/out.png -fslow -dNumRenderingThreads=3 | 20:16.49 |
| | real 0m3.970s | 20:17.15 |
| | user 0m3.884s | 20:17.15 |
| | sys 0m0.076s | 20:17.15 |
| rayjj | vimmonkey: -dNumRenderingThreads=3 AFTER the -f slow will have no effect, AFAIK | 20:17.23 |
| vimmonkey | oh.. ok | 20:17.39 |
| | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/tmp/out.png -dNumRenderingThreads=3 -fslow | 20:18.19 |
| rayjj | vimmonkey: but, as I said, I expect that with -dMaxBitmap=500000000 NumRenderingThreads won't have any effect | 20:18.22 |
| vimmonkey | real 0m3.960s | 20:18.31 |
| | user 0m3.880s | 20:18.31 |
| | sys 0m0.072s | 20:18.31 |
| rayjj | vimmonkey: OK, that makes sense. Now leave out -dMaxBitmap=500000000 | 20:18.53 |
| vimmonkey | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/tmp/out.png -dNumRenderingThreads=3 -fslow | 20:19.26 |
| | real 0m3.744s | 20:19.34 |
| | user 0m4.028s | 20:19.34 |
| | sys 0m0.016s | 20:19.34 |
| | better ... | 20:19.36 |
| | still had to try drawpdf heh | 20:19.51 |
| | then building a new version from source | 20:19.57 |
| rayjj | vimmonkey: and one last thing, try -sDEVICE=ppmraw -o /dev/null | 20:20.01 |
| vimmonkey | ok | 20:20.11 |
| Robin_Watts | gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -r900 -dDownScaleFactor=3 -sOutputFile=/tmp/out.png -dNumRenderingThreads=3 -fslow | 20:20.21 |
| rayjj | (get rid of -sOutputFile... | 20:20.30 |
| mvrhel_laptop | Robin_Watts: ping | 20:20.39 |
| Robin_Watts | pong | 20:20.44 |
| rayjj | we are keepng vimmonkey busy :-) | 20:20.52 |
| vimmonkey | i don't mind being a interactive shell =) lol | 20:21.11 |
| mvrhel_laptop | do you have any idea what sort of "font information" the customer wants mpudf to provide in the email about the dot net stuff? | 20:21.24 |
| Robin_Watts | mvrhel_laptop: Not a clue. | 20:21.39 |
| mvrhel_laptop | Robin_Watts: :) | 20:21.43 |
| | ok | 20:21.44 |
| rayjj | The ppmraw device will tell you how much time is spent compressing the bitmap to PNG | 20:21.45 |
| Robin_Watts | I think we need to ask exactly what he wants to know. | 20:21.52 |
| mvrhel_laptop | ok I will reply | 20:22.00 |
| Robin_Watts | cos it may not be readily available from the fz_font. | 20:22.06 |
| vimmonkey | Robin_Watts: for your command, ime gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -r900 -dDownScaleFactor=3 -sOutputFile=/tmp/out.png -dNumRenderingThreads=3 -fslow | 20:22.08 |
| mvrhel_laptop | right | 20:22.12 |
| vimmonkey | real 0m4.843s | 20:22.19 |
| | user 0m5.272s | 20:22.19 |
| | sys 0m0.044s | 20:22.19 |
| | rayjj: let me try yours now.. | 20:22.25 |
| rayjj | vimmonkey: OK, so downscaling to a 300 dpi image is slower than GraphicsAlphaBits for your file. Sort of what I expected | 20:23.04 |
| vimmonkey | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=ppmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/dev/null -dNumRenderingThreads=3 -fslow | 20:23.52 |
| | real 0m1.241s | 20:23.59 |
| | user 0m1.368s | 20:23.59 |
| | sys 0m0.020s | 20:23.59 |
| rayjj | vimmonkey: and FYI, -Z: will print out OutputPage start and end times. The OutputPage start tells you how much time was spent writing the clist | 20:24.02 |
| | vimmonkey: OK, so of the 3.9 seconds, all but 1.4 seconds is spent doing the png compression. Not much room for improvement | 20:24.53 |
| vimmonkey | time pdfdraw -o /tmp/out.png slow | 20:25.17 |
| | real 0m0.226s | 20:25.17 |
| | user 0m0.212s | 20:25.17 |
| | sys 0m0.012s | 20:25.17 |
| | o.o | 20:25.19 |
| rayjj | since PNG compression is done in the main thread and doesn't benefit from multiple CPU's | 20:25.25 |
| | vimmonkey: add -r300 to be equivalent | 20:25.46 |
| vimmonkey | ah | 20:25.50 |
| | sysadmin@designerimagecreator2:/var/www/unified/public/images/headstoneEditor2/uploaded$ time pdfdraw -o /tmp/out.png -r 300 slow | 20:26.02 |
| | real 0m2.651s | 20:26.02 |
| | user 0m2.516s | 20:26.02 |
| | sys 0m0.128s | 20:26.02 |
| | ha, disregard file paths =P lol | 20:26.20 |
| rayjj | more believable, and also what we expect | 20:26.23 |
| vimmonkey | hm that is a bit better though | 20:26.55 |
| rayjj | since AA is part of mupdf (mudraw == pdfdraw) and it works in RAM more, it's closer to just the PNG time | 20:27.35 |
| fredross-perry | Hello. Tryng to push to a newly-created repo, and Iâm getting âremote error: access denied or repository not exported:â | 20:27.36 |
| vimmonkey | i'm using it as image masks, so throwing in -g actually is a bit quicker | 20:27.36 |
| fredross-perry | thoughts? | 20:27.40 |
| vimmonkey | oh and bmp is actually a lot faster, so i don't need to go with png =) | 20:28.11 |
| | time pdfdraw -o /tmp/out.bmp -r 300 -g slow | 20:28.20 |
| | real 0m0.889s | 20:28.20 |
| | user 0m0.844s | 20:28.20 |
| | sys 0m0.040s | 20:28.20 |
| rayjj | vimmonkey: gs has -sDEVICE=pnggray if that's really what you want | 20:29.01 |
| | that'll be closer to pdfdraw with -g | 20:29.25 |
| | vimmonkey: and if you don't need png, pgmraw is the fastest | 20:29.52 |
| vimmonkey | not sure if image magick can understand pgmraw... | 20:30.08 |
| | bmpmno is actually quite quick! | 20:30.14 |
| rayjj | it sure ought to | 20:30.17 |
| vimmonkey | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=bmpmono -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/dev/null -dNumRenderingThreads=3 -fslow | 20:30.23 |
| | real 0m0.464s | 20:30.30 |
| | user 0m0.452s | 20:30.30 |
| | sys 0m0.012s | 20:30.30 |
| | i'll try pgmraw | 20:30.40 |
| rayjj | vimmonkey: it'll be about the same I expect | 20:30.55 |
| vimmonkey | time gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=pgmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sOutputFile=/dev/null -dNumRenderingThreads=3 -fslow | 20:31.16 |
| | real 0m1.517s | 20:31.23 |
| | user 0m1.824s | 20:31.23 |
| | sys 0m0.016s | 20:31.23 |
| fredross-perry | oh, I think I have it. using https:// instead of git:// | 20:31.40 |
| vimmonkey | fredross-perry: ah, yeah i generally use https.. (not for ghost script, but other repos) | 20:32.23 |
| rayjj | vimmonkey: bmpmono is *NOT* gray shade. it's the equivalent to pbmraw (1-bit) bmpgray is 8-bit gray (for soft masks) | 20:32.29 |
| vimmonkey | oh.. | 20:32.34 |
| | yeah bmpgray is about 1.5 seconds =) | 20:32.55 |
| rayjj | and pgmraw or bmpgray will probably be faster with -dMaxBitmap=500000000 | 20:33.02 |
| vimmonkey | actually, with -dMaxBitmap its ~400ms slower heh | 20:34.16 |
| rayjj | so, still, mudraw/pdfdraw is < 0.9 sec, and gs equivalent is (best case) 1.5 seconds to a gray image. | 20:34.41 |
| vimmonkey | yeah =) | 20:34.48 |
| | thanks for all the help! i really really appreciate it | 20:34.59 |
| rayjj | vimmonkey: there you go. Have fun | 20:35.01 |
| | vimmonkey: and it's another data point for us | 20:35.14 |
| vimmonkey | ha, i'm surprised you care about older versions, like i said I'm on 9.05 for gs | 20:35.53 |
| | erm pdfdraw dosen't have a âversion thing | 20:36.44 |
| | *argument | 20:36.49 |
| | says mupdf copyright 2006-20012 @ button heh | 20:37.00 |
| | *@ bottom of man page | 20:37.06 |
| | btw, do you guys take donations? | 20:43.12 |
| Robin_Watts | fredross-perry: hi. | 20:43.14 |
| | You can't push to your git repo on casper using http: or git: | 20:43.38 |
| | You want something like: git remote add golden fred@ghostscript.com:/home/git/mupdf.git | 20:44.27 |
| | git remote add oriigin fred@ghostscript.com:/home/fred/repos/mupdf.git | 20:44.42 |
| | So you'll be using ssh. | 20:45.01 |
| fredross-perry | I tried that, but now I get âPermission denied (publickey). | 21:12.32 |
| | fatal: Could not read from remote repository.â | 21:12.33 |
| | I suspect I need to tell my system, or git, about how to use SSH? | 21:13.23 |
| | heading out... | 21:25.08 |
| catgetsdown | I may be looking at the wrong area but for nothing programmers, it is really difficult to figure out which one of those files to download for your program? I have an Android tablet that I was hoping to use your product on but I can't figure out which file to download. Thank you | 21:43.24 |
| Robin_Watts | fredross-perry: hey. | 23:45.29 |
| | you still here? | 23:45.33 |
| fredross-perry | yes, back now | 23:45.38 |
| Robin_Watts | ok, so first off, we need to arrange that your system knows about how to ssh to ghostscript.com | 23:45.56 |
| | We set up a private/public key pair, right so you can ssh in? | 23:46.18 |
| | If you go to the command line and do: ssh fred@ghostscript.com: do you get in ? | 23:46.51 |
| fredross-perry | yes I do. | 23:47.01 |
| Robin_Watts | OK. so git remote -v and paste it here. | 23:47.21 |
| | (assuming it's not huge) | 23:47.28 |
| fredross-perry | goldengit@ghostscript.com:fred/home/git/qt-gsview.git (fetch) | 23:48.02 |
| | goldengit@ghostscript.com:fred/home/git/qt-gsview.git (push) | 23:48.02 |
| Robin_Watts | Not git@ghostscript.com. fred@ghostscript.com | 23:48.22 |
| fredross-perry | no. But I can try that, should I? | 23:48.38 |
| Robin_Watts | git remote rm golden | 23:48.56 |
| fredross-perry | ok, then⦠| 23:49.14 |
| Robin_Watts | git remote add golden fred@ghostscript.com:/home/git/qt-gsview.git | 23:49.22 |
| | actually, even that's not right. | 23:49.54 |
| | git remote add golden fred@ghostscript.com:/home/fred/repos/qt-gsview.git | 23:50.07 |
| fredross-perry | yes I think I had that before. Then when I âgit push goldenâ I get the error. | 23:50.26 |
| Robin_Watts | do git fetch golden | 23:50.42 |
| fredross-perry | same error | 23:51.38 |
| Robin_Watts | what error, exactly. | 23:51.47 |
| fredross-perry | Permission denied (publickey). | 23:55.49 |
| | fatal: Could not read from remote repository. | 23:55.49 |
| Robin_Watts | Ok, paste git remote -v again | 23:56.05 |
| | I can clone from that repo. It's empty, but I can clone it. | 23:57.47 |
| | so the repo itself is set up fine (for fetching from at least). | 23:58.06 |
| | It's either going to be you having the remote wrong, or you having the ssh setup wrong. | 23:58.22 |
| | If you can ssh in with: ssh fred@ghostscript.com: at the same command prompt that you are failing to git fetch from then that suggests that ssh is picking up the correct key when called directly, but not when called through git. | 23:59.39 |
| | That would make me wonder what version of ssh git is calling. You're on a mac right? | 23:59.56 |
| | Forward 1 day (to 2015/01/31)>>> | |
IRC Logs