| <<<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 night | 06: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 result | 07: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.03 | 07: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 it | 07:57.09 |
| chrisl_away: if you do the git fetch --tags it should delete your local ones | 07: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 git | 08: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.03 | 08: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'nite | 08: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 correct | 08: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.h | 17: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 way | 17: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 well | 17: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 explicitly | 17: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.03 | 17: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 now | 17: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 well | 17: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 up | 17:12.42 |
chrisl | that doesn't surprise me | 17: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 branch | 17:13.45 |
| Robin_Watts: 5dd9cbf | 17:14.10 |
chrisl | Robin_Watts: the problem is also apparent on master, so it's not something specific to the branch | 17: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 64 | 17: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/version | 17: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 master | 17: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 earlier | 17:28.38 |
ray_laptop | chrisl: how do you see the TTF notdef problem ? | 17:29.52 |
chrisl | ray_laptop: empty boxes instead of "real" glyphs | 17: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 rectangle | 17:33.37 |
| Ugh, that's confusing: Vista 64 correctly shows "Ghostscript" in the title bar............. | 17:36.51 |
ray_laptop | chrisl: I see Asian glyphs | 17: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 ghostscript | 17: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 be | 17: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 bar | 17: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 candidate | 17:56.23 |
| Robin_Watts: DefWindowProc(W) seems to be the culprit for the title bar | 18: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, then | 18: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) feature | 18: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 reasonable | 18: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 | uhoh | 18: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.6 | 18:45.01 |
| er, when running, after successful compilation | 18:45.10 |
sags | The "Simple sample" from bug 691494 is one of them. | 18:45.25 |
chrisl | sags: okay, just a second | 18:46.16 |
henrys | htodd:what segfaults in the build process? | 18:46.40 |
htodd | no, it builds fine | 18:48.32 |
chrisl | sags: I don't see a problem on Linux | 18: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-gtk | 18:52.56 |
| henrys: I'm the maintainer | 18:53.12 |
| and I've tried macports | 18:53.31 |
| (not for ghostscript, but I couldn't get many packages building) | 18:53.54 |
sags | @chrisl: 32-bit | 18:54.04 |
henrys | htodd:which ghostscript release? | 18:54.14 |
htodd | 9.02 | 18:54.32 |
| it works fine on the upcoming release with the GM compiler/OS | 18: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=4 | 18:55.05 |
htodd | it works fine on i386 | 18:55.05 |
| could be a toolchain error on fink's part | 18:55.23 |
henrys | it would be interesting to see a debug build and a gdb backtrace | 18: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: 0x0000000000f15f20 | 18: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/man | 19: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 shot | 19: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 problem | 19: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 chrisl | 19:28.16 |
chrisl | henrys: I don't see how that would cause the problem, but I'll try it | 19:28.35 |
| henrys: nope, still wrong | 19: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 it | 19:41.51 |
htodd | ok | 19:41.54 |
| sorry, took my mom to lunch | 19:42.02 |
| jackhowarth: I just heard not to --disable-compile-inits | 19:42.58 |
| I'm going to try it | 19: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 channel | 19:44.05 |
htodd | whoops, wrong window | 19:44.13 |
| heh | 19:44.18 |
| at least it wasn't my password | 19: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 sense | 19:51.41 |
| chrisl: and I always have to double check the docs for the exit codes anyway | 19:52.15 |
| iirc, 0 means "forward" and 1 means "backward" (but I might be reversed | 19: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 gui | 19: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-picked | 19: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 | ah | 20:00.53 |
| I think the problem is yet another local library that's interfering with the system library | 20: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)>>> | |