| <<<Back 1 day (to 2021/03/08) | Fwd 1 day (to 2021/03/10) >>> | 20210309 |
jhabjan | Hi there, not sure if you remember me but I'm author of Ghostscript.NET (.net wrapper for Ghostscript) (https://www.nuget.org/packages/Ghostscript.NET/) | 09:38.06 |
artifexirc-bot | <KenSharp> My memory is awful, but not quite that bad 🙂 | 09:38.26 |
| <KenSharp> Good Morning Josip | 09:38.38 |
jhabjan | I'm getting complains that my wrapper is not working with the latest Ghostscript version, gsapi_init_with_args returns -100 | 09:39.59 |
artifexirc-bot | <KenSharp> Can you reproduce it ? | 09:40.13 |
| <KenSharp> -100 is a 'fatal error' which basically means its probably not PostScript or PDF and often points to a problem in the arguments | 09:40.49 |
jhabjan | last wrapper release I did was when Ghostscript was 9.22 | 09:41.51 |
| I tested it with 9.27 and it works properly | 09:42.01 |
artifexirc-bot | <KenSharp> Well that's nearly 2 years old now and yes, we changed stuff | 09:42.28 |
| <KenSharp> Becuase of security concerns (actual genuine exploits) | 09:42.39 |
jhabjan | [0]: "-sDEVICE=display" | 09:42.51 |
| [1]: "-sDisplayHandle=0" | 09:42.51 |
| [2]: "-dDisplayFormat=198660" | 09:42.52 |
| [3]: "-dDOINTERPOLATE" | 09:42.52 |
| [4]: "-dGridFitTT=0" | 09:42.53 |
| [5]: "-dMaxBitmap=1g" | 09:42.53 |
artifexirc-bot | <KenSharp> arg[0] must be something which is not critical to the arguments list. Putting the name of your application or something in there would be normal. Putting the device in there means that ti will be ignored. | 09:44.17 |
| <KenSharp> Not having a device selected is the sort of thing that could lead to a fatal error | 09:44.33 |
| <KenSharp> I'm assuming of course that this is the argument list you are passing to the Ghostscript API | 09:45.17 |
| <KenSharp> However this has not changed since 9.27 as far as I am aware | 09:45.27 |
| <KenSharp> Translating your args into a command line I get | 09:46.53 |
| <KenSharp> \ghostpdl\debugbin\gswin64c -sDEVICE=display -sDisplayHandle=0 -dDisplayFormat=198660 -dDOINTERPOLATE -dGridFitTT=0 -dMaxBitmap=1g reduced.pdf | 09:46.54 |
| <KenSharp> And that works for me with a PDF file I happened to have lying around | 09:47.07 |
| <KenSharp> FWIW removing the -sDEVICE=display also works, because the display device is the default on Windows | 09:48.10 |
jhabjan | https://i.ibb.co/W051KN2/ss-x1-20.png | 09:49.36 |
artifexirc-bot | <KenSharp> Well that looks reasonable, and the command line equivalent works for me | 09:50.20 |
jhabjan | strange | 09:50.26 |
| I still get -100 | 09:50.29 |
artifexirc-bot | <KenSharp> Can you try using gswin64c with the command line I gave above ? To see if that works for you | 09:51.19 |
jhabjan | yep, sec | 09:52.32 |
| that works | 09:54.42 |
| (from command line) | 09:54.47 |
artifexirc-bot | <KenSharp> OK so its something to do with using the API | 09:54.52 |
jhabjan | yep | 09:55.00 |
artifexirc-bot | <KenSharp> I'm following through in a debugger here | 09:55.13 |
| <KenSharp> I see that the command line has added a -dDisplayResolution=96 | 09:56.37 |
| <KenSharp> Let me just pastebin a screenshot of what I see | 09:56.55 |
jhabjan | I've saw that in your API docs and tried it out, it didn't help | 09:59.33 |
artifexirc-bot | <KenSharp> https://ibb.co/Z2StYDs | 09:59.53 |
| <KenSharp> Wow that's all blurry | 10:00.10 |
| <KenSharp> Oh, its OK in Chrome, just blurry in Brave | 10:01.17 |
| <KenSharp> Anyway, that's what I see the command line app passing in, and it returns a code of 0 | 10:01.31 |
jhabjan | I see, I'll try to debug a bit more | 10:01.59 |
artifexirc-bot | <KenSharp> I need to head out for a run, back in an hour or so and I'll see if I can get further then. | 10:02.31 |
jhabjan | no worries, ta | 10:02.50 |
artifexirc-bot | <KenSharp> back, with coffee | 11:02.50 |
chrisl | Not sure about "-sDisplayHandle=0" | 11:08.49 |
artifexirc-bot | <KenSharp> Seems to work | 11:09.00 |
| <KenSharp> Not sure what it does mind | 11:09.06 |
| <KenSharp> I'm just trying to use NuGet to pick up Ghostscript.NET | 11:09.22 |
chrisl | That should be the pointer to the display structure with the callbacks etc. | 11:09.33 |
artifexirc-bot | <KenSharp> Hmm well that doesn't sound good | 11:09.45 |
chrisl | I'm just thinking that display device was one of the things that's changed recently - amongst other things, tightening up validation and error checking | 11:10.38 |
artifexirc-bot | <KenSharp> True | 11:11.00 |
| <KenSharp> If I can install the package I may be able to actually debug it.... | 11:11.15 |
chrisl | I doubt I can "help" further than that... | 11:11.53 |
artifexirc-bot | <KenSharp> Not to worry, let me fiddle with this for a while and see where I get | 11:12.09 |
| <KenSharp> There must be some way I can install this thing, I just need to find the right runes | 11:12.25 |
chrisl | Failure to open the initial device will result in a fatal error return | 11:13.25 |
jhabjan | I found the problem | 11:13.41 |
artifexirc-bot | <KenSharp> That's the sort of thing I was thinking of yes, which is why I thought setting the device in arg[0] might have been the problem | 11:13.53 |
jhabjan | DISPLAY_VERSION_MAJOR 3 | 11:14.01 |
| I had to extend my display callback | 11:14.17 |
| as you introduced display_adjust_band_height and display_rectangle_request | 11:14.31 |
| but.. now run into other issue | 11:14.48 |
artifexirc-bot | <KenSharp> Right, that's what @chrisl was saying | 11:14.54 |
jhabjan | (e:/test.pdf) (r) file runpdfbegin | 11:14.58 |
chrisl | Well, that was a mistake: https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=364a3883326b90bf078d488909ba3203450da3d3 | 11:15.00 |
jhabjan | returns -9 | 11:15.02 |
artifexirc-bot | <KenSharp> OK well Ghostscript now runs -dSAFER by default. | 11:15.15 |
| <KenSharp> So you cna' tjust 'run' arbitrary files off disk. | 11:15.24 |
| <KenSharp> You either need to specify the file as permitted to read using --permit-file-read=.... or you need to set -dNOSAFER. We **really** don't reccoment setting -dNOSAFER | 11:15.55 |
chrisl | https://ghostscript.com/doc/9.53.3/Use.htm#Safer | 11:16.27 |
artifexirc-bot | <KenSharp> This is the security problems I alluded to earlier | 11:17.01 |
jhabjan | yep, with -dNOSAFER works | 11:17.45 |
artifexirc-bot | <KenSharp> Seriously, don't do that | 11:17.55 |
| <KenSharp> Use --permit-file-read instead | 11:18.02 |
jhabjan | at which point do i run --permit-file-read? | 11:18.23 |
artifexirc-bot | <KenSharp> -dNOSAFER is fine for a quick test of coure | 11:18.26 |
| <KenSharp> --permit-file-read is a command line parameter | 11:18.41 |
chrisl | Using the API, you might want to use gsapi_add/remove_control_path() instead: https://ghostscript.com/doc/9.53.3/API.htm#add_control_path | 11:18.55 |
artifexirc-bot | <KenSharp> So it needs to go as one of the args in init_with_args | 11:19.00 |
| <KenSharp> Oh that's a good point | 11:19.07 |
chrisl | But you should read the SAFER doc link I put above, since it is also relevant to the API calls | 11:20.15 |
jhabjan | this now works: https://i.ibb.co/6gmVs7L/ss-x1-21.png | 11:23.32 |
chrisl | So, as long as you only process one file per Ghostscript "instance", that is fine | 11:24.26 |
| BTW, that should be probably be "950" rather than "952" | 11:25.06 |
jhabjan | cool, yep | 11:25.28 |
| this .NET wrapper has 816768 downloads so far and people were getting slightly frustrated with this problem which I didn't had time to fix earlier. | 11:25.38 |
| thank you for your help | 11:25.57 |
chrisl | Sorry we were forced into making incompatible changes :-( | 11:26.21 |
jhabjan | no worries, good thing it's sorted now | 11:27.30 |
chrisl | I have to step away from the keyboard - but I'll be back in 40 minutes or so, if you have more questions and Ken can't answer.... | 11:28.40 |
jhabjan | btw.. some links in your api docs are broken.. like https://ghostscript.com/doc/base/gdevdsp.h | 11:39.55 |
artifexirc-bot | <KenSharp> Where is that linked from ? | 11:40.55 |
| <KenSharp> OK api.htm | 11:41.18 |
| <KenSharp> I don't think that should be a URL really. | 11:41.51 |
| <KenSharp> It certainly isn't going to work from the website, and its obselete in that case | 11:42.19 |
| <KenSharp> Should be in devices, not base | 11:43.00 |
jhabjan | https://i.ibb.co/ZLRgM43/ss-x1-22.png | 11:43.22 |
| click on gdevdsp.h | 11:43.38 |
artifexirc-bot | <KenSharp> Yeah like I said, its in API.htm, and its obselete the file has moved, but I don't relly think its a great idea to have that as a URL anyway, because I can't see any way its going to work on the website | 11:44.15 |
| <KenSharp> and in develop.htm as well | 11:45.11 |
| <KenSharp> I guess I'll fix the ones in the HTML files | 11:45.39 |
| <KenSharp> Its a relative path so maybe it does work on the website | 11:46.04 |
jhabjan | cool | 11:46.26 |
artifexirc-bot | <KenSharp> I've pushed the doc fix to Git, I'm not sure how long it takes for that to be reflected in the 'current' documentation on the website, depends on a cron job IIRC. | 11:55.44 |
chrisl | These have been links forever, looks like I just missed a few after moving the device sources | 11:56.12 |
artifexirc-bot | <KenSharp> If you see more, feel free to fix them 🙂 | 11:56.45 |
| <KenSharp> Or shout at me and I'll sort it if you're busy | 11:57.05 |
chrisl | gdevdsp.h is the only one I see | 12:01.12 |
artifexirc-bot | <KenSharp> Yeah I had a good look through and in develop.htm and I couldn't see anything obviously wrong | 12:01.29 |
chrisl | I did grep stuff..... | 12:01.49 |
artifexirc-bot | <KenSharp> Yeah I was grepping | 12:02.46 |
chrisl | And the website is updated now | 12:03.03 |
artifexirc-bot | <KenSharp> Oh that was quick | 12:03.09 |
chrisl | Just lucky, IIRC, it's every hour | 12:03.34 |
artifexirc-bot | <KenSharp> Fortunate timing 🙂 | 12:03.46 |
| <KenSharp> Seems to work | 12:04.04 |
chrisl | "toolbin/displaydevice_test.c" doesn't seem to exist any more.... | 12:05.33 |
artifexirc-bot | <KenSharp> I don't recall that one at all | 12:05.49 |
chrisl | It's linked at the bottom here: https://www.ghostscript.com/doc/current/API.htm#display | 12:06.20 |
| We should also probably review psi/dmmain.c for any residual usefulness | 12:07.44 |
artifexirc-bot | <KenSharp> Git reckons Robin added that line to api.htm on 16 June 2020 | 12:08.20 |
| <KenSharp> Which kid of indicates its relatively new, and ought to be there 😦 | 12:08.55 |
chrisl | I must have forgotten to intall the psychic git plugin..... | 12:09.28 |
artifexirc-bot | <KenSharp> I'm just wondering if it ever got committed | 12:10.14 |
chrisl | I doubt it | 12:10.30 |
artifexirc-bot | <KenSharp> I think you're correct | 12:10.40 |
| <chrisl> @Robin_Watts ping! | 12:10.45 |
| <KenSharp> I see nothing in git log that looks like it | 12:10.49 |
| <Robin_Watts> @chrisl pong | 12:11.09 |
| <chrisl> You added a link in API.;htm to toolbin/displaydevice_test.c | 12:11.32 |
| <Robin_Watts> I did. And it's probably now apitest. | 12:11.48 |
| <Robin_Watts> Will fix. | 12:11.56 |
| <chrisl> Thanks | 12:11.59 |
| <Robin_Watts> Done. Thanks for spotting that. | 12:14.40 |
| <chrisl> @Robin_Watts Well, someone spotted my earlier mistake, so I felt it necessary to pay forward the favour 😉 | 12:16.15 |
| <Robin_Watts> @chrisl @KenSharp I'm doing the cluster items assigned to me from the quarterly meeting. One of them is 'subclass testing'. | 12:48.06 |
| <Robin_Watts> I figure I'll do a standard gs run weekly with -dFirstPage=1 added in. | 12:48.25 |
| <Robin_Watts> Any objections? Suggestions etc? | 12:48.40 |
| <chrisl> N-up? | 12:48.59 |
| <Robin_Watts> You want a separate N-up run? | 12:49.15 |
| <Robin_Watts> Or you're suggesting using -sNupControl=1x1 ? | 12:49.35 |
| <Robin_Watts> I'm amenable to either/both. | 12:50.22 |
| <chrisl> Well, isn't that "normal"? I just meant that N-up is probably something that warrants testing, and it happens to use subclassing | 12:50.47 |
| <chrisl> I think FirstPage/LastPage is a good idea to test because of how much we expect it to be used | 12:51.19 |
| <Robin_Watts> yes. The question is, do we want to test an N-up invocation that makes no changes to the output (so we can compare it to the trunk), or do we want an N-up invocation that actually does something? | 12:51.36 |
| <chrisl> I'd expect a request for 1x1 not to trigger the n-up code | 12:52.41 |
| <Robin_Watts> I'm not sure it's that smart 🙂 | 12:52.58 |
| <Robin_Watts> -dFirstPage=1 shouldn't really trigger the first/last page stuff, but it does. | 12:53.14 |
| <Robin_Watts> I suspect that a -dNupControl=1x2 run is probably sensible. | 12:54.09 |
| <chrisl> All things being equal, I'd say we should do 1x1 and compare to "normal", and maybe 1x2 compared to the last 1x2 run, but I'm wary about overloading the cluster, and you | 12:54.47 |
| <Robin_Watts> I swallowed my pride and disabled the coverage tests. | 12:55.17 |
| <Robin_Watts> So we should have lots of leeway on the cluster now. | 12:55.26 |
| <chrisl> And Luratech? | 12:55.33 |
| <Robin_Watts> Just this very second 🙂 | 12:56.05 |
| <chrisl> Ah, it just occured to me because it's still on the dashboard.... | 12:56.28 |
| <chrisl> We could remove the gsview links from the dashboard, too | 12:56.56 |
| <chrisl> Anyway, point is, I think we need a test that exercises the N-up functionality | 12:57.59 |
| <Robin_Watts> Yup. I'll sort that. | 12:58.34 |
| <KenSharp> I think FirstPage is perhaps more useful, since it tests turning it off. But I haev noted before (I think) that the erasepage optimisation subclass device already tests subclassing without any action from us. Not that I'm averse to more testing | 13:00.11 |
| <KenSharp> I'm pretty sure Nup 1x1 does turn the device on, similarly to FirstPage=1 turns on the flp device | 13:00.52 |
| <Robin_Watts> @KenSharp What test would you like for First/Last page? | 13:01.06 |
| <Robin_Watts> I think, given that this stuff all pauses when people run user/git tests, we can basically load up the cluster as much as we like now. | 13:01.38 |
| <KenSharp> Well just setting FirstPage=1 turns it on. And if it's a PDF file the PDF interpreter will disable it. So that tests all of it really. | 13:02.00 |
| <Robin_Watts> ok. | 13:02.07 |
| <KenSharp> I do agree with Chris that it would be nice to test the Nup device, I'd be happy with say 2x2 but any combination is ggod from my POV. Maybe 1x2 is better since it scales differently | 13:03.05 |
| <chrisl> @Robin_Watts How painful would it be to allow "auto" tests to be scheduled as "mid-priority" jobs? (I'm thinking of release testing, and and other "custom" tests that aren't triggered by a cron job) | 13:04.33 |
| <Robin_Watts> @chrisl It would be awkward, cos everything assumes a priority. | 13:05.13 |
| <Robin_Watts> I can temporarily pause git jobs though with a 1 line hack. | 13:05.27 |
| <chrisl> Last release, it took over two days to run a complete a set of release tests. And I don't think manually hacking the cluster is a good solution, long term | 13:06.37 |
| <Robin_Watts> If you look in the top of clustermaster.pl, there is a commented out section that just exits if $pri == 1. | 13:06.38 |
| <Robin_Watts> I could make that check for 'RELEASE_TESTS_IN_PROGRESS' file or something? | 13:07.17 |
| <chrisl> Or we could ban mupdf developers from pushing 6 months of commits at one time? | 13:08.19 |
| <Robin_Watts> Impossibru! | 13:08.45 |
| <KenSharp> We could always ask people not to push stuff I guess | 13:09.21 |
| <chrisl> I kind of dislike that - it feels like going to back to doing releases on master, and asking people not to commit while the release is pending | 13:10.07 |
| <KenSharp> Yes, I'm inclined to agree, but I'm not sure what else there is | 13:10.41 |
| <chrisl> It's only a problem because release testing is now done on the cluster | 13:12.08 |
| <Robin_Watts> @chrisl As I say, I can "promote" release jogs temporarily. | 14:26.16 |
| <Robin_Watts> @chrisl As I say, I can "promote" release jobs temporarily. | 14:26.21 |
| <chrisl> @Robin_Watts It just feels a little hacky, but I suppose it'll do | 14:33.24 |
| <RayJohnston> @Robin_Watts -sNupControl=1x1 installs the N-up subclass device, so it has the same 'dummy' effect as -dFirstPage=1 | 15:47.12 |
| <Robin_Watts> @RayJohnston See #artifex 🙂 | 15:47.32 |
| <RayJohnston> (as @KenSharp wrote above) | 15:47.33 |
| <RayJohnston> going there next ... | 15:48.19 |
| <<<Back 1 day (to 2021/03/08) | Forward 1 day (to 2021/03/10)>>> | |