| | <<<Back 1 day (to 2011/07/15) | 2011/07/16 |
| ray_laptop | I saw Robin_Watts' comment about Crystal RIP. If it is a package we can get (even if we have to buy it), then we get the access to their source to see whether or not they conform to GPL | 05:13.06 |
| tor8 | Robin_Watts: ping | 09:10.06 |
| kens | I'd be surprised :-) | 09:10.24 |
| tor8 | oh, is he not working on saturdays for once? ;) | 09:11.09 |
| kens | Bit early I'd think. | 09:11.23 |
| tor8 | ahhh! I'm not used to being here this early either :) | 09:11.41 |
| kens | Still got guests, huh ? | 09:11.56 |
| tor8 | yeah, until tuesday | 09:12.06 |
| kens | Fun, fun, fun.... | 09:12.15 |
| tor8 | anyway, I just found out that google code finally added support for git | 09:12.29 |
| kens | Is that good ? | 09:12.38 |
| tor8 | so we could set up a code mirror there to reduce bandwidth on casper | 09:12.48 |
| | and as an extra backup | 09:12.57 |
| kens | Hmm, well that would be useful maybe | 09:13.00 |
| tor8 | it was an idea, just wanted to hear the other git head's opinion on it :) | 09:15.16 |
| kens | Try again in an hour or so I'd guess | 09:15.35 |
| Robin_Watts | pong | 09:37.30 |
| | ray_laptop: I think the only way to get Crystal RIP is to buy printing hardware. | 09:38.16 |
| | tor8: A code mirror might be interesting as a backup | 09:39.13 |
| | but bandwidth from git on casper is insignificant I suspect. | 09:39.28 |
| sebras | tor8: for all projects? | 10:51.16 |
| | tor8: does code.google.com support gitweb or similar? I only read the headline yesterday I didn't try it... | 10:52.25 |
| tor8 | sebras: it's an option for hosting along with svn and mercurial. haven't played with the web view, so can't say what it's like. | 10:57.09 |
| sebras | tor8: webview is what I was worried about. | 11:01.20 |
| | tor8: gitweb on casper is quite handy some times. | 11:02.26 |
| tor8 | the google code svn web view is pretty bad, it only shows the first X files in a project | 11:03.26 |
| Robin_Watts | Actually, I'm not sure I see any benefit to it at all. | 11:05.41 |
| | With git we've all got backups effectively. | 11:05.50 |
| | and the bandwidth usage isn't an issue. | 11:05.57 |
| | Unless it's giving us something extra, what's the point ? | 11:06.09 |
| Robin_Watts | runs | 11:07.23 |
| tor8 | Robin_Watts: publicity, visibility, more google juice? | 11:22.44 |
| | it's the only thing that remains I can think of | 11:22.56 |
| | since we can't use the google code issue tracker (which is really good btw) | 11:23.10 |
| sebras | tor8: I was just thinking about that.. | 11:23.21 |
| | tor8: would you prefer to use that to bugzilla at casper? | 11:23.34 |
| | tor8: imho the issue tracker over at sumatrapdf is working rather well. | 11:24.09 |
| tor8 | yeah, but we can't... customer files need to be kept private. mind you, sumatrapdf ran out of quota for attachments as well. | 11:24.46 |
| sebras | tor8: true enough, though I believe they fixed the quota problem somehow (haven't asked them about it). | 11:26.08 |
| ManDay | tor8: ping? | 13:40.25 |
| Robin_Watts | hey mvrhel2 | 15:21.07 |
| mvrhel2 | hi Robin_Watts | 15:21.39 |
| Robin_Watts | Just committing my planar changes to the patternaccumulator. | 15:22.17 |
| mvrhel2 | ok great | 15:22.30 |
| black_warlock | hello | 15:31.24 |
| | can somvbody help me to setup mirc to play a sound if sombody types my name ? | 15:31.48 |
| | plox | 15:31.57 |
| sags | Hi all | 15:49.53 |
| | Can anybody tell me if "cups\libs\configwin.h" is used only by the Windows build? (I guess yes.) But "base\lcups.mak"? | 15:51.19 |
| chrisl_away | sags: configwin.h is only used on Windows, yes. | 15:55.47 |
| sags | @chrisl_away: And lcups.mak? 'Cause the cups files are currently the source of *LOTS* of warnings in the Windows build. I think I got rid of those, but I had to change these 2 files and don't know if this breaks other platforms or not. | 15:58.48 |
| chrisl_away | sags: Unless you actually need to debug cups issues on Windows, why not just disable the cups stuff altogether? | 15:59.38 |
| sags | Well, not sure how. And in general I prefer a 'pure' build. If something goes wrong, I know it's not because of my local changes. | 16:00.58 |
| | (Currently I'm investigating why Windows GS crashes all over the place.) | 16:01.56 |
| chrisl_away | sags: if you look in psi/msvc.mak and remove $(DD)cups.dev from the DEVICE_DEVS* settings, that should prevent it building. | 16:02.18 |
| | erm, building cups, that is. | 16:02.25 |
| sags | Ah, the DEVICE_DEVS, thanks! | 16:03.35 |
| | But if it's to stay with local changes, I'll stay with those in lcups.mak and configwin.h. | 16:04.09 |
| chrisl_away | sags: what crashes are you investigating? We found one on Friday in the current master and happens when there are registry entries for GS to read. | 16:04.44 |
| sags | One of the problem is 'crash if GS_* entries not set'. I already have a patch for it. | 16:05.56 |
| | Another is GS crashing when called from GSView and changing the display resolution. GSView stop GS and restarts the page with new parameters. There GS crashes. | 16:07.01 |
| chrisl_away | I just didn't want you chasing issues that one of us was already looking at. | 16:07.45 |
| sags | A third is that I cannot compile (VS2003) because wmemset() is not found. This one I solved too (without disabling the utf8). | 16:08.08 |
| chrisl_away | sags: it's the UTF8/Unicode changes causing the crash reading from the registry :-( | 16:09.09 |
| sags | Yes, I know,I patched that. | 16:09.47 |
| chrisl_away | Ah, you might want to try to mention that to Ray, he was investigating yesterday - we're trying to get a support release out for a customer, and that was the latest of *many* issues that came up! | 16:11.36 |
| sags | But the most concerning is the 2nd problem. GS is dereferencing a pointer to freed memory (the fill with 0xDD is for freed memory, I think) from the library context. (Don;t have that source opened right know.) | 16:11.40 |
| chrisl_away | Sounds like something isn't being cleared when GS shuts down. What happens if you run with -Z@? | 16:13.28 |
| sags | Don't know, haven't tried -Z@. Now I was trying to reduce the huge list of warnings... | 16:14.55 |
| chrisl_away | Past experience says you're probably just extending the list of warnings on other platforms! | 16:15.45 |
| | sags: another thing you might want to do is look at what's been done on the ghostpdl-9.03 branch - quite a few colour related crashes have been fixed on there, but we're not totally sure whether they will be the final fix, hence only being on the branch. | 16:16.40 |
| sags | @chrisl_away: About the test with -Z@: it just crashes. cannot see stdout/ stderr (from GSView) in this circumstance. | 16:18.03 |
| | @chrisl_away: About the warnings: I think "lcups.mak" is wrong on any platform. It intends to include the system "string.h" at some point, but does not manage to. | 16:19.19 |
| chrisl_away | sags: I think the problem is that cups includes it's own string.h, but I'm not sure. It's all a bit of a hack to let Windows developers investigate cups related issues, it's not meant for "real" use. | 16:21.21 |
| sags | @chrisl_away: Yes, it has its own "string.h" to do some magic, but that doesn't seem to be a substitute for the system "string.h". It tries to include the latter via cups "string.h" -> cups "config.h" -> system <string.h>. | 16:25.24 |
| chrisl_away | sags: well, I don't work on cups, and I didn't do the source code integration on ghostscript for it. From what you say, the cups source is wrong, and that's not ours. | 16:27.07 |
| sags | It depends. The problem comes from "lcups.mak" compiling the cups files with "-Icups\libs\cups". Without this option, it seems it does include the system "string.h". | 16:29.33 |
| chrisl_away | Does it even build, then? | 16:30.39 |
| sags | On Windows, yes (without that -I and with some other changes in the 2 files I mentioned). And with warnings -= 200. On other platforms, don't know. | 16:32.00 |
| | Is tkamppeter the one to decide on cups issues? | 16:33.03 |
| chrisl_away | It was actually Ken that got it build into GS on Windows, might be best to talk to him - although I doubt he'll remember much about it. | 16:34.01 |
| tkamppeter | I cannot say anything about building the CUPS part under Windows. I only work with Linux. | 16:34.57 |
| sags | @tkamppeter: Ok, thanks. | 16:35.38 |
| chrisl_away | sags: doing a GS build using the cups source fails without the "-Icups\libs\cups" | 16:37.20 |
| sags | @chrisl_away: There are some other small changes needed, simply removing that -I is not enough. Maybe it's better I open a bug report with what I have now. But it will take some time (me + GIT doesn't really compute, plus I'm slow at explaining stuff in writing). | 16:40.53 |
| | Wold it be useful to do the same with the GS_* registry problem? | 16:41.47 |
| | (If its already doneor nearly done, it wouldn't be...) | 16:42.09 |
| chrisl_away | sags: yes that would be best. And the GS_* registry would be great - I don't know if Ray made progress on it, and I haven't seen him on here today. | 16:42.54 |
| | sags: the only thing is, I'm not sure how keen we'd be to have changes in the *cups* sources. Personally, I feel the cups device should not be in the default Windows build at all. | 16:43.56 |
| | ray_laptop: sags was here a minute ago, and reckoned he had fixes for the registry reading crash. | 17:00.00 |
| ray_laptop | chrisl_away: yes, I saw the logs | 17:53.12 |
| Robin_Watts | How did my unicode changes break that? | 17:56.03 |
| | We're still an ASCII app, and I don't think I changed what was written/read from the registry. | 17:56.40 |
| chrisl_away | ray_laptop: I'm thinking maybe we just disable it for 9.03? | 17:57.26 |
| ray_laptop | really strange stuff going on. The build I did using the release script dies, but the build of the git co ghostscript-9.03 works | 17:57.34 |
| | it's in a section that is specific to WIN32 (the 64-bit build worked) | 17:58.14 |
| chrisl_away | Robin_Watts: I guess we'll find out what the problem is when sags posts his patch. | 17:59.14 |
| Robin_Watts | we don't define UNICODE right ? | 17:59.51 |
| chrisl_away | In what context? | 18:00.09 |
| Robin_Watts | as a C #define. | 18:00.16 |
| chrisl_away | Don't know, I haven't seen in the makefiles, but that's no guarantee | 18:00.37 |
| Robin_Watts | If we define that, then it'll try and read/write unicode for the registry etc. | 18:00.43 |
| | We never usually define it. | 18:00.48 |
| chrisl_away | ray_laptop: you probably don't have any GS_* entries in the 64 bit view of the registry - hence 64 bit not crashing. | 18:01.19 |
| Robin_Watts | Windows has this crap thing where you have Function blah and that has blahA and blahW versions, and it picks between the two based on whether UNICODE is defined. | 18:01.35 |
| chrisl_away | Robin_Watts: I don't see a UNICODE define in there. | 18:02.38 |
| | ray_laptop: what do you think about disabling the UTF8/UNICODE code to get 9.03 done? | 18:03.46 |
| ray_laptop | chrisl_away: I just started looking at it. The build works with the straight 'archive'. | 18:10.44 |
| | Changing to 'Artifex' next | 18:10.58 |
| | (basically stepping through the customer release process manually to see where it breaks, building each time) | 18:12.21 |
| chrisl_away | ray_laptop: IIRC, the registry entries are under GPL Ghostscript. So if running the script, you remove the GPL, the registry entry won't be found, we won't read it, and get to the crash point. | 18:13.03 |
| ray_laptop | chrisl_away: the registry entries for the GPL release are under GPL Ghostscript. The changes to "Artifex" are /supposed/ to change to Artifex Ghostscript | 18:14.26 |
| | I'm having a look with regedit... | 18:14.41 |
| chrisl_away | ray_laptop: that's what I mean: the straight git checkout will be looking for GPL Ghostscript, which maybe doesn't exist? But the Artifex release will be looking for Artifex Ghostscript. | 18:15.56 |
| mvrhel2 | chrisl: I still need to get some changes in the 9.04 release with respect to rendering intent and also there is a issue that relates to device gray mapping to pure K in a CMYK device that I want to get in as there have been complaints/requests for this | 18:15.59 |
| | chrisl_away: ^^ | 18:16.07 |
| ray_laptop | chrisl_away: since I _did_ the install, the registry entries for Artifex Ghostscript _should_ be there | 18:16.34 |
| chrisl_away | ray_laptop: yes, and it's reading *those* that causes the crash. The GPL entries *aren't* there, so we get never get to the code that crashes. | 18:17.30 |
| | mvrhel2: I know, I'm not saying don't commit anything, just that we start being a bit more conservative, and only commit stuff we really need for the release. | 18:18.16 |
| mvrhel2 | gotcha | 18:18.30 |
| ray_laptop | chrisl_away: sorry - I was misunderstanding your point -- I thought you were saying the problem was when the registry entries were NOT present | 18:18.43 |
| chrisl | realises he's not kidding anyone with that "_away" nonsense..... | 18:18.58 |
| | ray_laptop: I *think* it's when we find the registry entry that the problem occurs. | 18:19.23 |
| | ray_laptop: hmmm, RegQueryValueExW is returning ERROR_MORE_DATA, but returns a required length of zero - weird...... | 18:29.40 |
| ray_laptop | chrisl: is that when you have a registry key, or not | 18:39.58 |
| chrisl | ray_laptop: I'll need to double check, but it was when trying to read GS_OPTIONS which the installer doesn't create. | 18:41.01 |
| | ray_laptop: that's a key that doesn't exist in my registry. I do have GS_LIB which it reads correctly and successfully. | 18:43.12 |
| ray_laptop | so why does it (9.03) work for me with an 'off the shelf' build ? | 18:43.45 |
| | chrisl: are you seeing a crash at all when it gets that ERROR_MORE_DATA ? | 18:44.13 |
| chrisl | ray_laptop: yes. We try to allocated the required "zero bytes" and then try to access the zero length string, I think. | 18:44.52 |
| | ray_laptop: sorry, getting my terminology wrong: they *key* exists, but the *name* doesn't. I wonder if that is triggering the problem. | 18:46.31 |
| ray_laptop | so it sounds like a fairly simple thing to fix -- treat that condition (ERROR_MORE_DATA with required len == 0 as key not present) | 18:48.25 |
| | but I wonder how this used to work | 18:48.47 |
| chrisl | ray_laptop: I wonder if the behaviour of RegQueryValueExA and RegQueryValueExW differ in this subtle and annoying way...... | 18:49.48 |
| | ray_laptop: changing gp_getenv_registry() as you describe above results in the running 32bit executable for me. | 19:02.04 |
| | Robin_Watts, ray_laptop: I think this is a bug in RegQueryValueExW() | 19:11.51 |
| sags | I've just opened bugs 692347..692349. The one with the registry values in "utf8 mode" is the 2nd one. | 19:16.39 |
| | I didn't yet post the my patch for the cups warnings, I have to see what's the reason for 3 of the files to be copied to %OBJDIR% and compiled from there. | 19:18.04 |
| chrisl | sags: thanks, I'd just reached the same conclusion about the registry values, but your patch is rather more comprehensive than what I tried. | 19:21.28 |
| sags | @chrisl: Thanks. | 19:22.10 |
| chrisl | sags: I'd guess that the files that get copied to BJDIR% are platform specific (probably Windows or everything else) so the makefile copies the appropriate one to where it can be found - just guessing though. | 19:22.37 |
| | ray_laptop: see Bug 692348 for sags's proper fix for the registry issue. | 19:23.46 |
| sags | "Proper fix"? I hope. I do not feel comfortable posting a patch so soon after I wrote the code... | 19:24.48 |
| | @chrisl: I'll investigate the idea of cups files being copied because they are platform specific. At 1st glace, they're not, all are just copied from $(LIBCUPSSRC), the same directory all others are compiled from. | 19:27.57 |
| chrisl | sags: The md5.c clashes with a another filename, so it gets copied and renamed to avoid the clash | 19:29.21 |
| sags | Maybe there's something with the include path, that is these 3 may need different headers. But I think only config.h is platform-specific. | 19:29.43 |
| chrisl | I'm guess the same is try of the others. | 19:29.44 |
| sags | @chrisl: Ah, that could be the reason. But I kept the changed *.OBJ name, even I used the *.C source from its original directory. This solves the conflicts in %OBJDIR% without copying the files. | 19:31.51 |
| | s/even/even if/ | 19:32.09 |
| chrisl | Okay, that'll work, yes. | 19:32.29 |
| | I don't see an immediate reason for util.c though. | 19:33.56 |
| sags | @kens (for when you will read the logs): Do you remember the reason for copying 3 cups *.C files (md5.c, snprintf.c, and util.c) to %OBJDIR% and compiling them from there? (I do understand why copying configwin.h -> %OBJDIR%\cups\config.h, that does not create problems.) | 19:35.22 |
| | @chrisl, about the possible bug in RegQueryValueExW(): there's no bug there, the code does "if ((rc == ERROR_MORE_DATA) || (wp == NULL))". "wp == NULL" (which means "get me the buffer size") takes the same path as "rc == ERROR_MORE_DATA" (which means "buffer too small"), and does so independent of the value returned by RegQueryValueExW() - including the error cases. | 19:45.18 |
| chrisl | sags: ah, okay, cheers | 19:46.42 |
| sags | By. | 19:46.55 |
| chrisl | c ya - too late...... | 19:47.21 |
| mvrhel2 | one would think rendering intent would be rather simple. but with the level of control that some one which is control of it for RGB image, graphic, text, CMYK image, graphic and text it was a bit of pain. in particular high level images through the clist. I think I finally have it all | 20:27.43 |
| | s/some one/some want/ | 20:28.01 |
| | and with that push I am done for a bit... bbiaw | 20:46.55 |
| Robin_Watts | Wooah. Why are we calling RegQueryValueExW ? | 23:05.21 |
| | We're an ascii app, not a unicode one. | 23:05.35 |
| | Everything is utf8 encoded, so everything should be stored as ascii, right? | 23:05.59 |
| | I'll look at the patch tomorrow to try and understand what's been discovered. | 23:06.52 |
| | Oh, right, we convert from utf8 and then store in unicode registry values. | 23:15.25 |
| | Forward 1 day (to 2011/07/17)>>> | |
IRC Logs