IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2011/07/16)2011/07/17 
ray_laptop Robin_Watts: I've tried SaGS' patches from 692347 and 692348 with 9.03 and it no longer crashes. I've (locally) committed the patches. Can I go ahead and push the commit to origin (even though chrisl_away already tagged "ghostscipt-9.03") ?02:06.42 
  and how do I move the tag to the new commit (chrisl had deleted the tag and re-tagged AFAIK)02:07.32 
mvrhel2 darn somehow in getting my rendering intent stuff working it broke something in transparency. very weird. time to call it a night06:43.46 
ray_laptop Robin_Watts: my git is confused (partly by the 'name space' issue I think). I did: git tag -d ghostpdl-9.03 and afterwards don't see the warning: refname 'ghostpdl-9.03' is ambiguous.07:19.37 
chrisl_away ray_laptop: that's the right result07:48.01 
ray_laptop chrisl_away: how do I get the repo to delete the tags as well ?07:51.07 
chrisl_away ray_laptop: you'll also need to do "git tag -d ghostscript-9.03". Then "git push origin refs/tags/ghostpdl-9.03" and "git push origin refs/tags/ghostscript-9.03"07:51.25 
ray_laptop chrisl_away: OK. Doing that.07:52.07 
  $ git push origin refs/tags/ghostpdl-9.0307:53.41 
  error: src refspec refs/tags/ghostpdl-9.03 does not match any.07:53.43 
  error: failed to push some refs to 'ray@ghostscript.com:/home/git/ghostpdl.git'07:53.45 
chrisl_away Oh, I got them mixed mixed, try: "git push origin :refs/tags/ghostpdl-9.03" 07:54.23 
ray_laptop chrisl_away: thanks. that seems to have it07:57.09 
  chrisl_away: if you do the git fetch --tags it should delete your local ones07:57.41 
chrisl_away ray_laptop: it does on my Ubuntu git, but on my Cygwin git, I need to update each tag manually - older version of git08:00.44 
  ray_laptop: Great! So you can now double check your branch is where we want want, and apply the tags to the revised code.08:01.02 
  ray_laptop: I need to get some breakfast and feed the cat.......08:02.18 
ray_laptop I am really frustrated by my git. I've gotten it confused:08:03.46 
  $ git co ghostpdl-9.0308:03.48 
  Switched to branch 'ghostpdl-9.03'08:03.49 
  Your branch and 'origin/ghostpdl-9.03' have diverged,08:03.51 
  and have 1 and 9 different commit(s) each, respectively.08:03.53 
  going to bed and will work on it tomorrow.08:04.01 
  g'nite08:04.04 
  I've gotten the 32-bit not crashing, but whatever I've got doesn't build 64-bit :-(08:04.40 
  g'nite...08:04.54 
chrisl_away ray_laptop: you're branch has commits that aren't on casper, therefore it has diverged from its origin, so the message is correct08:04.55 
  g'nite!08:05.12 
ray_laptop OK, moved my git back to ghostpdl (the --hard way) and made SaGS patches again and now the logg looks OK. Trying the customer release builds/installs before pushing the patch.16:57.20 
  I changed SaGS '348 patch a bit (got rid of the empty else; statements, added in { } around some multi-line if/else blocks and changed tabs to spaces)16:59.27 
chrisl ray_laptop: I hate to say it, but there is another problem :-(17:02.58 
  Using gswin32.exe, the ASCII window title is being interpreted as wide chars, and we end up with nonsense glyphs being used.17:04.05 
Robin_Watts crumbs :(17:04.36 
  we were walking a fine line between being an ASCII and a Unicode application.17:04.57 
  Has the UNICODE define been made?17:05.26 
chrisl Robin_Watts: it gets worse, just converting it to a wchar_t array doesn't work, either. The only way I've got it to work is to #define UNICODE when we include windows.h17:05.43 
  er, see above.....17:06.01 
Robin_Watts chrisl: Don't do that.17:06.01 
chrisl Well, it don't work any other way17:06.12 
Robin_Watts If you make the UNICODE define then it has implications (I think) for how wide chars are delivered to the app.17:06.39 
ray_laptop chrisl: I just noticed the nonsense in the title bar as well17:06.46 
Robin_Watts We never used to get nonsense in the title bar.17:06.59 
  and indeed, I don't here on master.17:07.20 
ray_laptop Robin_Watts: 32-bit build ?17:07.33 
Robin_Watts yes.17:07.37 
  Is this a 64bit problem only ?17:07.47 
chrisl Robin_Watts: but something else "behind the scenes" is going on which prevents a wide char string being correctly passed into CreateWindowW() even calling that explicitly17:07.53 
ray_laptop Robin_Watts: I am seeing it on the 'installed' 32-bit 9.03 (with SaGS' patch)17:08.09 
Robin_Watts Just checking here.17:08.37 
  I know that the way we ended up calling CreateWindow was slightly delicate.17:09.09 
ray_laptop chrisl: since the 32-bit build doesn't crash now, I'll push SaGS patch to 9.0317:09.30 
chrisl ray_laptop: okay. Did find the 64 bit build problem you mentioned?17:10.02 
ray_laptop chrisl: I think my local stuff was honked up. Building 64-bit now17:10.39 
Robin_Watts Right. We call CreateWindowW, and we pass in the title as chars,17:11.04 
ray_laptop chrisl: it just finished -- 64-bit OK as well17:11.10 
Robin_Watts not wchars.17:11.10 
  There was a reason that was OK.17:11.14 
chrisl ray_laptop: great!17:12.26 
ray_laptop BTW, the 64-bit title bar is also honked up17:12.42 
chrisl that doesn't surprise me17:12.53 
Robin_Watts Where is sags patch ?17:13.28 
  an, ray just pushed it.17:13.42 
ray_laptop Robin_Watts: I just pushed it to the ghostpdl-9.03 branch17:13.45 
  Robin_Watts: 5dd9cbf17:14.10 
chrisl Robin_Watts: the problem is also apparent on master, so it's not something specific to the branch17:15.19 
Robin_Watts chrisl: Well, that's odd.17:15.35 
  because gswin32.exe gives me a perfectly readable window title.17:15.50 
chrisl Robin_Watts: Windows version?17:16.03 
Robin_Watts Windows XP 32bit.17:16.09 
ray_laptop I'm running Win7 6417:16.20 
chrisl I'm using Windows7 64 also, aha!17:16.35 
  Robin_Watts: what visual C are you using?17:18.14 
Robin_Watts VS2005.17:18.21 
chrisl Okay, me too. So, looking like a Widows vesion difference.....17:18.52 
  s/vesion/version17:18.59 
Robin_Watts I dislike the fact that sags has changed free(wp) into: if (wp) free(wp);17:19.09 
  free(NULL); is defined in the C standard as being fine.17:19.21 
  and it's certainly find under msvc.17:19.30 
chrisl Robin_Watts: I have a habit of doing that, too. I've worked on a couple of platforms where freeing NULL went bang.17:20.35 
Robin_Watts But he's altering windows specific files.17:20.48 
  it's just extra noise in the source files.17:21.09 
chrisl I realise Windows is okay, but it's habit - we can always tidy it up before it goes into master17:21.15 
Robin_Watts but anyway...17:21.36 
  if you can find an invocation that works for your version of windows, let me know, and I can test it here.17:21.52 
chrisl Robin_Watts: the only way I could get it to work was to both change it to a wchar_t string, *and* define UNICODE when we include windows.h in dwtext.c - like you, I'm not terribly keen on that.17:22.49 
ray_laptop I installed the 32-bit on an XP mode Virtual PC and the title bar looks OK.17:23.05 
henrys wishes we had windows regression testing.17:25.27 
chrisl Hmm, for me on "real" XP 32 bit, it's still screwy, in a different way (TTF notdef glyphs, except for a "t").17:25.42 
  henrys: for *this* problem, unless we were paying someone to test "manually", regression testing wouldn't have helped.17:27.08 
henrys oh I'm catching up I thought I saw a compilation failure earlier17:28.38 
ray_laptop chrisl: how do you see the TTF notdef problem ?17:29.52 
chrisl ray_laptop: empty boxes instead of "real" glyphs17:31.17 
ray_laptop chrisl: doing *what* ?17:31.29 
chrisl ray_laptop: In the title bar, where it should say "Ghostscript"17:31.49 
  ray_laptop: In the title bar I see five outline rectangles then a "t" then another outline rectangle17:33.37 
  Ugh, that's confusing: Vista 64 correctly shows "Ghostscript" in the title bar.............17:36.51 
ray_laptop chrisl: I see Asian glyphs17:40.51 
chrisl ray_laptop: on which Windows version?17:41.19 
  ray_laptop: so far, in the title bar, I have Windows7 64 showing Asian glyphs, Windows XP 32 showing notdefs, and Windows Vista 64 show "Ghostscript", all with the same executable.17:43.09 
ray_laptop chrisl: and my Windows XP SP3 (Virtual PC) shows ghostscript17:45.21 
chrisl So, my Vista 64 install has Chinese language packs installed, so that might have an influence.17:45.59 
  ray_laptop, Robin_Watts: on you systems that show "Ghostscript" correctly in the title, any Asian languages installed?17:46.27 
Robin_Watts no.17:46.38 
chrisl hmm, theory go bang :-(17:46.52 
  Not that it matters too much, I suspect if it works on Windows7, it'll work on the others, too.17:47.37 
  Robin_Watts: that patch I had that shows the title bar correctly (can't recommend using it, though!): http://pastebin.com/QHuGb3xV 17:50.27 
Robin_Watts I think having UNICODE defined while including windows.h has potential to bite us, because it changes the meanings of lots of functions.17:52.17 
chrisl That's why I'm not actually putting it forward as a real fix. I've no idea what the side effects might be17:53.01 
Robin_Watts The latter part of your fix isn't enough ?17:53.31 
chrisl No, then I get just a "G" in the title bar17:53.54 
Robin_Watts That must mean that some OTHER function being called in that file is changing too. What other functions are there in that function that don't specify A or W ?17:54.14 
chrisl In dwtext.c? GetModuleHandle() looks like a candidate17:56.23 
  Robin_Watts: DefWindowProc(W) seems to be the culprit for the title bar18:05.55 
Robin_Watts Ah.18:08.32 
  Right. It's vital we call DefWindowProcA, I think.18:08.57 
  otherwise we open ourselves to potentially getting different window proc entries called with unicode input.18:09.33 
chrisl Robin_Watts: So, there's no way to get the title text correct, then18:10.13 
Robin_Watts Not immediately that I can see.18:11.05 
henrys chrisl:the display device has no customer impact that I know of can we release with this as a known defect?18:14.20 
chrisl henrys: Either that, or disable the UNICODE stuff for 9.03 - I'm not fussy either way.18:15.01 
henrys I assume it is not just the text title but any message box would have the same issue right?18:15.55 
chrisl henrys: I would think any message box that we initiate, yes.18:16.30 
henrys Robin_Watts:unicode off or known problem?18:17.33 
ray_laptop For 9.03, I prefer just disabling Unicode (and seeing if all is OK). Cust 850 won't care since it is a new (unrequested) feature18:22.42 
chrisl henrys, ray_laptop: Okay, I'll vote with Ray: we should disable it for 9.03 - unless Robin_Watts has a strong objection (I'm now concerned it might have affected other things we haven't noticed).18:28.12 
henrys sounds reasonable18:28.29 
  we wanted the customer to have it by their monday morning right?18:29.16 
chrisl If possible.....18:29.36 
sags Hi all.18:39.28 
henrys hey sags how are you?18:40.19 
sags Is there a problem with TextAlphaBits > 1, known, present only on the ghostscripc-903 branch?18:40.24 
henrys uhoh18:40.40 
chrisl sags: what sort of problem?18:40.45 
sags Glyphs have some white lines on them, as if there are highlights or something. Also imperfections of the contours.18:41.38 
chrisl There's nothing that I'm aware of on the 9.03 branch that should affect that area of the code.18:42.33 
sags Well, I'll open a bug then and put there the image I obtain?18:43.20 
chrisl Is this on all files (with text)?18:43.36 
sags I guess yes, but I have not tried with many files.18:44.34 
htodd any Mac OS X gs developers around? I see a segfault when compiling on x86_64 10.618:45.01 
  er, when running, after successful compilation18:45.10 
sags The "Simple sample" from bug 691494 is one of them.18:45.25 
chrisl sags: okay, just a second18:46.16 
henrys htodd:what segfaults in the build process?18:46.40 
htodd no, it builds fine18:48.32 
chrisl sags: I don't see a problem on Linux18:48.45 
htodd henrys: see my second line. when running gs from the command line, I get "Segmentation Fault, Exit 139"18:49.27 
sags I'm an Windows. Then I'll open a bug a put the screen capture there. I don't have any patch for it, and no idea what the cause could be.18:50.05 
  s/a put/ and put/18:50.18 
henrys htodd:I use the same architecture and have had no problems, are you just running configure with no options?18:51.01 
  htodd:most folks use macports - do you have some reason for building it yourself, not that there is any reason it shouldn't work.18:52.14 
chrisl sags: are you using 32 bit or 64 bit Windows?18:52.47 
htodd --mandir=%p/share/man --disable-compile-inits --disable-cups --disable-gtk18:52.56 
  henrys: I'm the maintainer18:53.12 
  and I've tried macports18:53.31 
  (not for ghostscript, but I couldn't get many packages building)18:53.54 
sags @chrisl: 32-bit18:54.04 
henrys htodd:which ghostscript release?18:54.14 
htodd 9.0218:54.32 
  it works fine on the upcoming release with the GM compiler/OS18:54.56 
chrisl sags: okay, I've just tried it on 64 bit Windows, and I don't see a problem with the pnmraw device TextAlphaBits=418:55.05 
htodd it works fine on i38618:55.05 
  could be a toolchain error on fink's part18:55.23 
henrys it would be interesting to see a debug build and a gdb backtrace18:56.37 
htodd running in gdb with a normal build sees the backtrace start in MemoryOpen, and "Program received signal EXC_BAD_ACCESS, Could not access memory.18:58.08 
  Reason: KERN_INVALID_ADDRESS at address: 0x0000000000f15f2018:58.11 
sags I have opened bug #692350 "Highlights on glyphs with TextAlphaBits > 1 on gs903 branch"and attached the screenshots.19:02.36 
chrisl sags: i do see the problem.19:03.26 
henrys htodd:I am trying to reproduce without the mandir because configure: error: expected an absolute directory name for --mandir: %p/share/man19:05.35 
  I imaging that is not important 19:06.00 
chrisl htodd, henrys: maybe try a build without --disable-compile-inits?19:06.52 
henrys I'd like to try and reproduce it as htodd sees it first.19:09.25 
  9.02 has the icc search problem but mine doesn't crash it errors out.19:11.40 
chrisl henrys: It's just that problem seemed to be very unpredictable, I thought it might be worth a shot19:12.45 
henrys chrisl:yeah there was some uninit stuff going on with that also right?19:13.49 
  htodd:so 9.03 works for you?19:14.20 
chrisl henrys: I lost track totally of everything that went on with those problems....19:14.51 
henrys I am sure compile inits will fix the problem but it probably is not what the op wants.19:16.24 
  chrisl:another regression?19:16.53 
  from sags?19:17.01 
chrisl Sort of. It's very confusing - I think it may be a problem that's been fixed somehow in master. I'm not sure it's only a text problem19:18.03 
henrys htodd:I'm afraid you cannot use compile inits off with 9.02 I am sort of curious why you crash and I error out but I have other stuff to do. Feel free to create a bug if you get the gdb and backtrace going.19:22.52 
  probably need 31cb1ff ... Fix for Bug 692303, antialiasing problems.19:27.35 
  that was to chrisl19:28.16 
chrisl henrys: I don't see how that would cause the problem, but I'll try it19:28.35 
  henrys: nope, still wrong19:29.39 
henrys hmmph? bisect? I don't see anything else that really sticks out as missing.19:35.37 
  and related.19:35.52 
chrisl I'm bisecting now - it's confusing because it's backwards......19:36.02 
  ah, henrys, did you mean a1ee78?19:37.11 
henrys oop yes I did I got the log comment right ;-)19:41.38 
chrisl henrys: yes, with the right commit (a1ee78) it does fix it19:41.51 
htodd ok19:41.54 
  sorry, took my mom to lunch19:42.02 
  jackhowarth: I just heard not to --disable-compile-inits19:42.58 
  I'm going to try it19:43.11 
chrisl henrys: we'll need to make sure that Ray gets the message to pull that fix in, or leave the last of the release gubbins to me (my) tomorrow morning.19:43.48 
henrys htodd:you're probably want to write jackhowarth on a different channel19:44.05 
htodd whoops, wrong window19:44.13 
  heh19:44.18 
  at least it wasn't my password19:44.24 
ray_laptop chrisl: maybe you can alias git bsf (bisect forward) "git bisect good" and similarly, "bsb" for 'bad' -- or whatever you prefer as aliases that make more sense19:51.41 
  chrisl: and I always have to double check the docs for the exit codes anyway19:52.15 
  iirc, 0 means "forward" and 1 means "backward" (but I might be reversed19:52.51 
chrisl ray_laptop: the problem was that bisect is meant to work backwards to find what broke something, whilst I wanted to work backwards to find what fixed something, so "good" and "bad" were reversed.19:53.18 
  ray_laptop: but henrys was right about the fix, just wrong about the commit to pull in. So we need to pull in a1ee78 *and* define WINDOWS_NO_UNICODE in the CFLAGS.19:54.28 
henrys chrisl:somehow I read off the child commit in the gui19:56.10 
chrisl henrys: Not a problem, it was a good suggestion - I just should have paid more attention to the comment you pasted versus the one when I cherry-picked19:57.38 
  And I missed sags, I really want to thank him for catching this one.19:58.28 
  ray_laptop: I have the anti-aliasing fix pulled in, and I can commit the disabling of UNICODE on Windows in a minute or two, should I do so, or are you doing it?20:00.24 
htodd ah20:00.53 
  I think the problem is yet another local library that's interfering with the system library20:01.12 
cryptopsy how can i convert pptx to something i can manipulate ith gs?21:13.00 
 Forward 1 day (to 2011/07/18)>>> 
ghostscript.com
Search: