| | <<<Back 1 day (to 2018/05/24) | 20180525 |
| kens | chrisl got a minute ? | 08:25.06 |
| chrisl | kens: Yeh | 08:25.26 |
| kens | I was about to close bug #693628 because Till declined to do anythign about it. | 08:25.41 |
| | Firstly; any objection ? Did you want to look into it ? | 08:25.52 |
| | Secondly; looking through the bug reports, it seems to me that any CUPS bugs assigned to Till are essentially being ignored, totally. | 08:26.23 |
| | So I'm thinking we should discuss this next week in SFO | 08:26.39 |
| chrisl | I'm good with closing 693628 | 08:26.44 |
| | We could drop devcups :-) | 08:27.07 |
| kens | Is there any point in us keeping a CUPS component and pretending that we can/will do anything about such reports ? If Till won't take them on, I'm inclined to tell people to report problems to the CUPS team | 08:27.20 |
| | I see 13 open reports assigned to Till going back 7 years | 08:28.51 |
| chrisl | The thing is, in general, I rarely expect Till to actually fix any of them, but I'd hoped he'd confirm and narrow down the problem, before passing it to one of us | 08:29.11 |
| kens | Absolutely yes | 08:29.20 |
| | But he's ignoring them completely | 08:29.29 |
| | Which doesn't help anyone | 08:29.45 |
| | So I think it would be better if we told people who have a problem with the CUPS device to report it to the CUPS team and get them to liaise with us | 08:30.08 |
| | If nothing else, it gets the bug report on *their* system, where they may actually pay attention to it | 08:30.33 |
| chrisl | Alternatively, see if they want to nominate someone other that Till to have the responsibility | 08:30.37 |
| kens | That's a reasonable point too | 08:30.47 |
| | Shall I add it to the agenda ? | 08:30.56 |
| | For some dfiscussion ? | 08:31.01 |
| chrisl | Yes, I think so. | 08:31.01 |
| kens | Right will do thanks | 08:31.05 |
| chrisl | At the very least, one of us should see where Till stands on the situation. Simply ignoring issues is really bad form | 08:31.52 |
| kens | Indeed :-( | 08:32.03 |
| chrisl | So... the coverage stuff on casper is using up 12Gb, and seemingly hasn't been updated since January 2017..... | 08:35.35 |
| kens | I don't know when the coverage stuff runs. | 08:35.54 |
| | Bugger the Twiki just rejected my edits | 08:36.03 |
| chrisl | Well, never, but the look of it | 08:36.08 |
| kens | "Content update is rejected due to an invaliid crypt token" | 08:36.35 |
| | WTF does that mean ? | 08:36.40 |
| chrisl | No clue | 08:37.17 |
| kens | Well used 'edit' instead of 'raw edit' and now its happy | 08:37.50 |
| chrisl | I wonder if you had a stale cookie from before the migration | 08:38.27 |
| kens | Seems odd, but it must be something like that | 08:38.41 |
| | Actually, I block cookies :-) | 08:38.52 |
| | But yeah maybe something lile that | 08:39.03 |
| chrisl | Okay, not cookie - crypto token | 08:39.22 |
| emendelson | Quick question: I have an application that creates a PCL file named #LPT1.ASC, and the application then uses GhostPCL (under Windows) to convert that file to #LPT1.PDF. In the latest version "#" seems to have special meaning in option handling, so the file never gets converted. I've tried various ways of getting the file converted (including redirection, which creates a partial PDF). Is there any way to get a file named "#.. | 12:11.15 |
| | If necessary, of course, I'll change the application or continue to use an earlier version of GhostPCL, but I hope that someone might know an ingenious alternative. One reason I'm asking is that I don't have any control over which GhostPCL version the user installs to work with my application. | 12:12.31 |
| chrisl | emendelson: I'm not aware that we've changed anything on that front - but I may be wrong | 12:16.27 |
| kens | I seem to recall we use # on the Windows build to substitute for '=' | 12:16.29 |
| | Something to do with batch files mangling the = under the Windows command shell | 12:17.00 |
| chrisl | Hasn't that been the case for a long time | 12:17.02 |
| | ? | 12:17.04 |
| kens | Yes, a very long time indeed | 12:17.14 |
| | Mind you, that is for Ghostscript, not GhostPCL, its possible its a new change for GhostPCL | 12:18.37 |
| | I might have needed it when I added all the PJL processing for pdfmarks in PCL | 12:18.51 |
| | If it is that, I added i back in February 2016, so still not exactly a recent change | 12:20.24 |
| | Just tried here: | 12:24.24 |
| | gpcl6win32 -sDEVICE=pdfwrite -sOutputFile=\temp\#out.pdf \ghostpdl\pcl\exampels\owl.pcl | 12:24.24 |
| | Output file came out as #out.pdf | 12:24.32 |
| | -sOutputFile=#out.pdf works too | 12:25.19 |
| emendelson | Hmmm.... OK. Let me experiment with this. The application is the vDos DOS emulator, which has a command-line for PCL6.exe (the old name) coded inside. It worked perfectly with 2017 versions of gplc6win32 (built without a separate DLL and renamed pcl6.exe). If I've got this wrong, I apologize for time-wasting. | 12:46.03 |
| kens | Well, all I can really do is try what I think you are doing, if it works then there's not a lot I can say :-) | 12:46.40 |
| | Note that I'm using the DLL version of gpcl6win32.exe | 12:47.14 |
| emendelson | Wait - the problem is that the INPUT file is named #LPT1.PDF. The problem is not with an output filename that begins with #, but with an input filename that begins with #. | 12:47.15 |
| kens | Ah, that wasn't clear ot me | 12:47.35 |
| emendelson | I experimented with both the DLL and non-DLL versions. | 12:47.39 |
| kens | Let me try that | 12:47.41 |
| | Well when I try that it just disappears off up its own fudnament | 12:48.37 |
| | My guess is that its reading the # as an = but lets see. | 12:48.54 |
| | Well \temp\#owl.pcl works | 12:49.33 |
| emendelson | That's what happens with me, I think. The vDos program launches pcl6.exe, and an empty minimized window gets created. If I click on the minimized window on the taskbar, it opens up as blank, and I can close it. But nothing gets created. | 12:49.38 |
| kens | #owl.pcl doesn't | 12:49.39 |
| emendelson | Sorry - I was responding to the "disappears" post | 12:50.10 |
| kens | Yeah | 12:50.16 |
| emendelson | Yes, the problem seems to be when the path (in this case, the bare filename) begins with #. | 12:50.41 |
| kens | So one solution would be to use a fully qualified path | 12:51.03 |
| | Drat I'm going to have to do a rebuild, my binary is out of date wrt my source code | 12:51.35 |
| chrisl | Or just .\#owl.pcl | 12:52.00 |
| kens | Yes that should probably be OK | 12:52.13 |
| | I'm still curious as to what's going on though | 12:52.23 |
| | arg_next is going into an infite loop | 12:54.10 |
| emendelson | I'll raise this with the author of vDos and check. But is it possible that this can be made to work again in the next version of GhostPCL? | 12:54.22 |
| kens | Maybe.... | 12:54.30 |
| | I cna't tell yet, don't know what's happening exactly | 12:54.40 |
| | But it may be that we needed to treat '#' specially for some other reason, as I sugegsted above | 12:55.00 |
| emendelson | Well, I hope this turns out to be a useful report, whatever happens. | 12:55.07 |
| kens | # appears to introduce a comment | 12:56.12 |
| | And this does not seem to be new behaviour | 12:56.20 |
| | So I think GhostCL is just waiting for input on stdin which is why its in a loop | 12:56.58 |
| | The code in question hasn't changed since it was imported fro our previous source code repository back in 2011 | 12:59.52 |
| emendelson | OK, this is very strange: My build of 9.22 works perfectly with vDos. 9.23 produces the reported behavior. | 13:01.08 |
| kens | Well, if you want to debug it, the code is in ghostpdl/base/gsargs.c, line 272: | 13:01.47 |
| | if (c == '#' && eol) { | 13:01.47 |
| | do { | 13:01.47 |
| | c = get_codepoint(f, &astr, pal, pas); | 13:01.47 |
| | } while (!(c == 0 || is_eol(c))); | 13:01.47 |
| chrisl | Did the wchar to utf8 stuff get used in ghostpcl only more recently? | 13:02.05 |
| kens | Now there's a problem with that code anyway, because get_codepont returns -1 not 0, so it never exits the loop | 13:02.25 |
| | chrisl I don't remember when that was done, give me a minute | 13:02.36 |
| | git blame says 2011 for main_utf8 | 13:04.21 |
| | Done by Robin_Watts which seems reasonable | 13:04.52 |
| | Thoguh I'm unconvinced by the date | 13:05.00 |
| chrisl | So: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commit;h=33701ac07115cb2f634a40ab73a5c127ca870ad8 | 13:09.34 |
| | But I doubt that made it into the release | 13:09.45 |
| | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commit;h=193e3b87bc711d30be0c2c41f6b3e61f49c92b22 | 13:10.08 |
| kens | That one could be the change | 13:10.43 |
| | Its in the right area | 13:10.52 |
| chrisl | So a couple things have changed around there recently | 13:10.55 |
| kens | Neither look wholly convincing. | 13:11.40 |
| | I can't easily check out either though, since I'm on a branch with uncommited work and I don't really want to stash it | 13:12.01 |
| | emendelson : If you want someone to look at this, you'll need to raise a bug report | 13:12.40 |
| emendelson | kens, I'll do exactly that, today. Thank you! I suppose the report should simply say that GhostPCL stalls when the input path begins with "#"? | 13:14.23 |
| kens | Soemthing like that will do | 13:14.34 |
| emendelson | OK. Thank you again for confirming this. | 13:14.53 |
| kens | You can quote the date and time of the discussion in the IRC log too if you like, whoever looks at it will have soemthing to reference then | 13:14.59 |
| emendelson | Will do. | 13:15.06 |
| | kens, as you suggested, I've reported the problem with input paths that start with "#" : https://bugs.ghostscript.com/show_bug.cgi?id=699379 | 14:26.09 |
| kens | OK thanks, I can't promise when anyone will look at it, but at least it shouldn't get lost now | 14:26.43 |
| HenryStiles | kens: stalls? as in infinite loop | 14:26.47 |
| kens | yes infinite loop | 14:26.59 |
| | It reads a # as a comment | 14:27.06 |
| | Looks for c=0 but it never gets it, because c is -1 when it runs out of data | 14:27.23 |
| | So it just goes round and round and round.... | 14:27.30 |
| emendelson | I didn't know what was causing the stall, and I know that doctors don't like patients to make diagnoses... | 14:27.33 |
| | But I've changed the heading to say "infinite loop"... | 14:28.46 |
| kens | Not a problem, its easy enough to see the fault | 14:29.01 |
| HenryStiles | kens: reproducible in gs as well, you probably know that :-) | 14:34.36 |
| kens | No I didn't know that, I hadn't check.... | 14:34.56 |
| | checked | 14:34.58 |
| | But since its in gs_args, I can't say it surprising | 14:35.11 |
| | Its not at all clear to me why we treat '#' as a comment is this something to do with the @file syntax ? | 14:35.33 |
| chrisl | That would make sense, yes | 14:35.53 |
| | Forward 1 day (to 2018/05/26)>>> | |
Log of #ghostscript at irc.freenode.net.