| | <<<Back 1 day (to 2012/09/19) | 2012/09/20 |
| Noldorin | hello | 02:44.35 |
| ghostbot | bonjour, noldorin | 02:44.35 |
| Noldorin | getting this error when trying to use the pdfwrite device: | 02:44.45 |
| | **** Unable to open the initial device, quitting. | 02:44.46 |
| | any ideas, folks? | 02:44.50 |
| henrys | Noldorin:what command line are you using? | 02:50.00 |
| Noldorin | henrys: gs -sDEVICE=pdfwrite | 03:01.45 |
| | err | 03:01.54 |
| | henrys: gs -sDEVICE=pdfwrite foo.pdf | 03:01.58 |
| henrys | does 'gs -sDEVICE=pdfwrite -o my.pdf foo.pdf' work (don't type the single quotes) | 03:03.05 |
| Noldorin | henrys: so it does! | 03:03.54 |
| | odd, heh. or at least, unhelpful error message | 03:04.04 |
| henrys | arguably yes. | 03:05.14 |
| Noldorin | henrys: my next question would be: how do i run some ghostscript commands before reading in the pdf. specifically, i want to make some changes to page labels | 03:06.37 |
| | henrys: eh. let me know another time perhaps. i'm off now. | 03:10.08 |
| | thanks for the tip :) | 03:10.13 |
| | 'night | 03:10.16 |
| henrys | Noldorin read the documentation about the -c option on the command line. | 03:15.43 |
| Noldorin | henrys: there is no -c option | 03:16.21 |
| | at least on the mac version i'm running | 03:16.28 |
| henrys | http://www.ghostscript.com/doc/9.06/Use.htm section 10.1 -c and use the stackoverflow ghostscript group for more questions, they will help you if you spend some time to properly formulate a good specific question. | 03:21.28 |
| Noldorin | thanks | 03:24.45 |
| | *heads off for real now* | 03:24.49 |
| ray_work | mace_: (for the logs). Robin_Watts mentioned that you have our (artifex.com) website. I'll chat with you tomorrow here, or via email about getting this moving. | 03:44.43 |
| | mace_: I have the logins for the artifex.com hosting | 03:45.14 |
| | off to sleep for now... | 03:45.45 |
| mvrhel_laptop | ok deviceN output profile is making it through now without crashing. need to fix a few color issues then I think I will be there | 05:51.12 |
| | done for the night now though | 05:51.21 |
| Robin_Watts | kens: What version of VMWare Player are you using ? | 10:04.08 |
| | m@cb00k | 10:04.28 |
| kens | I have a full version of VMWare | 10:04.30 |
| Robin_Watts | bah. | 10:04.41 |
| | What version? | 10:04.59 |
| kens | VMWare workstation 6.5.5 | 10:05.04 |
| Robin_Watts | hmm. old. | 10:06.03 |
| kens | I suppose there's no reason why I can't use VMWare player as well | 10:06.11 |
| | Its free isn't it ? | 10:06.21 |
| Robin_Watts | It is. | 10:06.24 |
| kens | Shouldn't be a problem then | 10:06.32 |
| Robin_Watts | But I suspect that they use the same DLLs etc for networking etc. | 10:06.38 |
| | so installing both at once (in different versions) is bound to be a problem. | 10:06.51 |
| kens | Well, if they share locations yes. | 10:07.01 |
| | Lunch time.... | 11:26.56 |
| marcosw | Just install VMWare player in a virtual machine running inside VMWare workstation. | 14:00.48 |
| paulgardiner | Robin_Watts: a few more commits on paulg/master if you have a moment. | 14:22.31 |
| kens | Robin_Watts : ping | 14:49.32 |
| Robin_Watts | pong | 14:49.40 |
| kens | Got a problem with Git merging | 14:49.47 |
| | I think its because I've changed gdevpdf.c after you altered teh dprintf stuff. | 14:50.05 |
| | But I don't know how to fix it. | 14:50.19 |
| Robin_Watts | OK. So what command did you do ? | 14:50.26 |
| kens | git up | 14:50.30 |
| | which is a macro for git rebase | 14:50.39 |
| | I have already locally committed my changes | 14:50.46 |
| Robin_Watts | git pull --rebase, I assume? | 14:50.47 |
| kens | That's the thiing yes | 14:50.54 |
| | Its given me a conflict and failed to merge | 14:51.11 |
| Robin_Watts | Ok. So it would have backed out your changes, pulled mine in, and then tried to recommit yours one at a time. | 14:51.17 |
| | It will have given you a list of files that it's failed to merge. | 14:51.26 |
| kens | I only have one commit and only chnaged one file (but a number of changes) | 14:51.41 |
| Robin_Watts | So you have to edit each one in turn, to remove the collision markers <<<< ===== >>>> etc. | 14:51.55 |
| kens | Ah, OK | 14:52.02 |
| Robin_Watts | When you've done that, you git add the edited file. | 14:52.09 |
| kens | OK, let me try that. | 14:52.25 |
| Robin_Watts | When you've git added all the files that collided, you do: git rebase --continue | 14:52.33 |
| kens | Right, let mew edit this file first | 14:53.02 |
| | OK was only the dprintf statements which I had surrounded with a #ifdef, because they were coming out in the cluster logs. | 14:54.03 |
| | Seemed to confuse the merge... | 14:54.12 |
| | OK so far seems OK | 14:55.14 |
| | Changes pushed let#'s se what happens :-) | 14:55.57 |
| | Looks OK, thanks Robin_Watts | 14:57.45 |
| Robin_Watts | chrisl: ping | 15:18.02 |
| chrisl | Robin_Watts: pong | 15:18.10 |
| Robin_Watts | I've made gs_malloc_init call gscms_create. | 15:18.39 |
| | and this is now dying when building mkromfs. | 15:18.52 |
| | Is there a standard trick to avoid this? Do we have a symbol that's defined in the mkromfs build that I can #ifndef with ? | 15:19.33 |
| | or do I just define stub gms_create/gcms_destroy calls in mkromfs ? | 15:19.53 |
| chrisl | Not sure, I can't remember how much gs stuff gets pulled into mkromfs | 15:20.06 |
| | Robin_Watts: it looks to me like you might just have to stub it - I don't see any flags to differentiate. Although, why does initialising the memory manager also have to initialise the CMM? | 15:23.01 |
| Robin_Watts | It's not the MM, as such, it's the libctx. | 15:23.28 |
| | but it's around about gs_malloc_init time that it happens. | 15:24.05 |
| | I think gs_malloc_init may init the libctx. | 15:24.15 |
| | It's cos the lib ctx hangs off the lowest level gs_memory_t. | 15:24.38 |
| | and is copied into all newer ones when they are created. | 15:24.50 |
| | I can stub it. it's no biggy. | 15:25.07 |
| chrisl | Okay | 15:25.36 |
| Robin_Watts | Thanks. | 15:27.58 |
| Robin_Watts | pops to post office. | 15:31.15 |
| sebras | paulgardiner: do you have a test build with 9e609e1 for me to test or did you manage to reproduce the issue locally? | 15:33.14 |
| paulgardiner | It was 9e609e1 that I put up for test the day before yesterday, so it fixes the memory problem, but now runs into the too-long stalling of the UI thread | 15:35.46 |
| | I know why we are stalling the UI thread, but I've yet to think of a nice work around. | 15:36.48 |
| ray_laptop | Robin_Watts: why is gs_malloc_init being called from mkromfs ? (it has its own minimal allocator that doesn't use gs_malloc, doesn't it ?) | 15:37.40 |
| sebras | paulgardiner: aha. | 15:38.38 |
| | paulgardiner: ok. I didn't realize I had already tested that patch. | 15:38.57 |
| paulgardiner | yeah, the two tests you did yesterday told me all I needed to know, thanks. | 15:39.42 |
| Robin_Watts | ray_laptop: I have no idea. All I know is that gs_lib_ctx_init is being called. | 16:13.49 |
| | or at least the linker thinks it is. | 16:14.02 |
| chrisl | mkromfs has it's own minimal "low level" allocator, that is called via the Ghostscript memory framework - presumably so things like gp_enumerate_files...() calls don't have to be reimplemented for mkromfs. | 16:21.26 |
| ray_laptop | Robin_Watts: chrisl: I'm looking at it to see why gs_malloc_init is needed | 16:22.18 |
| Robin_Watts | If anything in gslibctx.c is required (errwrite/errflush/outwrite etc) then gs_lib_ctx_init will be included in the build, and hence gscms_create/destroy will be required. | 16:24.09 |
| | I'm assuming that code in mkromfs will do {d,e,em,dm,etc}printf | 16:24.39 |
| | so that's why. | 16:24.43 |
| chrisl | ray_laptop: it may be that the minimal_memory assignment just needs an appropriate flag set to "pretend" it's already initialised | 16:25.01 |
| | Robin_Watts: mkromfs just uses printf's, I think | 16:25.12 |
| Robin_Watts | but stuff in gp_enumerate_files probably does if_debug etc? | 16:25.46 |
| ray_laptop | Robin_Watts: I delete gsmalloc.obj and it doesn't relink mkromfs.exe | 16:25.58 |
| Robin_Watts | which boils down to emprintf | 16:26.04 |
| chrisl | Robin_Watts: could be, yes | 16:26.11 |
| Robin_Watts | ray_laptop: Right, so it's not the malloc, it's the libctx. | 16:26.15 |
| ray_laptop | Robin_Watts: where is the lib_ctx being initialized (I don't see mkromfs doing that) | 16:28.25 |
| Robin_Watts | ray_laptop: The lib ctx is initialised in gs_lib_ctx_init, which lives in gslibctx.c - that calls gscms_create. | 16:29.23 |
| ray_laptop | Robin_Watts: looks like gp_macio.c and gp_unifs.c are the ones that use if_debug* | 16:29.27 |
| Robin_Watts | That may not itself be being called. | 16:29.28 |
| ray_laptop | Robin_Watts: right, but mkromfs never calls gs_lib_ctx_init | 16:29.52 |
| Robin_Watts | It's the nature of object based linking, that if any function that is defined in gslibctx.c is required, then all of them will be linked in. | 16:30.17 |
| | hence if any code calls errwrite or outwrite, then gs_lib_ctx_init will be included and hence gscms_create will be required. | 16:30.45 |
| ray_laptop | Robin_Watts: so if the gp_ file enum stuff is changed to use the nomem printing, we would not need the lib_ctx ? | 16:31.58 |
| Robin_Watts | Not true. | 16:32.10 |
| | The nomem printing still calls the same functions- it just gets a mem pointer from a static. | 16:32.33 |
| ray_laptop | Robin_Watts: OK. | 16:33.14 |
| Robin_Watts | All those printing functions assume that the libctx has been initialised though. | 16:33.23 |
| ray_laptop | Robin_Watts: The gs_lib_ctx is NULL in mkromfs's minimal allocator | 16:34.21 |
| chrisl | I still don't quite see why the CMM needs initialised at the same time as the memory manager......... | 16:34.50 |
| ray_laptop | Robin_Watts: looks like any errwrite or outwrite would de-reference NULL and fault if mkromfs (via gp_enumerate_files_*) ever tried to debug print | 16:37.09 |
| chrisl | ray_laptop: is that a big deal, as it's only ever called in the fairly controlled build environment? | 16:38.24 |
| ray_laptop | chrisl: agreed. | 16:38.36 |
| Robin_Watts | chrisl: The CMM gets initialised (and destroyed) at the same time as the libctx does. | 16:38.37 |
| chrisl | Robin_Watts: yeh, can't we do it on demand, though, the first time we use it? | 16:39.13 |
| ray_laptop | Robin_Watts: are you actually seeing gs_lib_ctx_init being called (or gs_malloc_init) by mkromfs ? (or is it just the linker issue) | 16:39.28 |
| Robin_Watts | The idea is that if the CMM needs any persistent state, it can malloc a structure with it in and store the pointer in the libctx. | 16:39.37 |
| | chrisl: Well, that's not trivial. | 16:39.47 |
| | ray_laptop: Just the linker issue. | 16:39.54 |
| ray_laptop | Robin_Watts: OK. | 16:40.06 |
| chrisl | Robin_Watts: fair enough.... | 16:40.26 |
| Robin_Watts | The problem with doing it 'the first time it's used' is that it might get called from different threads. | 16:40.33 |
| | and from different routes. | 16:40.43 |
| | It's *far* simpler to just init it up front and fin it at the end. | 16:40.55 |
| chrisl | But the different threads will all carry the context around, where the CMM data gets allocated | 16:41.23 |
| Robin_Watts | And there are many different ways that gs can start up. (pcl is different to ls, is different to gs, is different to gsapi etc). | 16:41.30 |
| | All the threads belonging to a single gsapi instance share the same context. | 16:42.09 |
| chrisl | Ugh, that needs fixing :-( | 16:42.09 |
| Robin_Watts | chrisl: Look at the docs for lib_init0 and lib_init1 etc. | 16:42.37 |
| | Putting it in the libctx was by far the easiest route. | 16:42.49 |
| ray_laptop | chrisl: why ? each instance uses threads for a variety of things, the display and clist MT rendering for example | 16:42.51 |
| Robin_Watts | s/Putting it in/Initing it with/ | 16:43.17 |
| ray_laptop | chrisl: but that set of threads has a DIFFERENT lib_ctx to the other instances | 16:43.29 |
| Robin_Watts | ray_laptop: K | 16:44.01 |
| | ray_laptop: I believe that chrisl's comment about "that needs fixing" was about the "many different ways gs can start up", not about the "all the threads belonging to a single gsapi share the same context" | 16:44.38 |
| chrisl | ray_laptop: Robin_Watts was saying different interpreters initialise the graphics lib in different ways, and even different ways of calling Ghostscript initialising it in different ways - that's just plain confusing! | 16:45.09 |
| Robin_Watts | And while I agree, it would be lovely to have a consistent startup sequence, I suspect it's problematic due to those darned Hysterical Raisins again. | 16:45.38 |
| chrisl | I certainly wasn't suggesting it should be fixed as part of the thread safety work! | 16:46.07 |
| | Anyway, got to go - 'nite all! | 16:47.36 |
| Robin_Watts | One fix for this would be to make CCFLAGSAUX have -DAUX | 16:47.42 |
| | night chrisl. | 16:47.46 |
| | and then #ifndef AUX around stuff. | 16:47.56 |
| | but that requires discussion with chrisl, so I'll leave it with the stubs for now. | 16:48.20 |
| ray_laptop | Robin_Watts: might be worth considering. | 16:48.26 |
| | Robin_Watts: but I agree that chrisl should be consulted (and may end up doing it) | 16:49.13 |
| | Robin_Watts: but thanks for clearing up my confusion about mkromfs | 16:49.41 |
| | Robin_Watts: if mkromfs had it's own errwrite and outwrite exported, that would resolve the link issue, correct ? | 16:51.56 |
| kens | OK time to go, goodnight all. | 16:52.16 |
| ray_laptop | bye, kens | 16:52.22 |
| Robin_Watts | and if we removed gslibctx.obj from the list of obj's to link, yes. | 16:52.47 |
| ray_laptop | Robin_Watts: it's not there in the Windows make. That's why when I touched gslibctx.obj it didn't re-link mkromfs.exe for me. The unix-aux has a LOT more files included | 16:55.55 |
| Robin_Watts | That would be an ecumenical matter. | 16:56.30 |
| ray_laptop | agreed. | 16:56.50 |
| | and left up to chrisl | 16:56.58 |
| Robin_Watts | Great xkcd today | 17:34.21 |
| henrys | I couldn't figure it out because I read it in google reader and the drag part was just a blank box. Now I see. | 17:44.50 |
| mace_ | ray_work: hi | 18:03.13 |
| Robin_Watts | mace: he's probably better reached as ray_laptop, but I think his irc client beeps on every mention of "ray". | 18:14.26 |
| | Is artifex.dsis.co.uk the latest version of the website? | 18:14.59 |
| | And are you waiting for anything from us? | 18:15.08 |
| | (Sorry, I meant to say if ray_laptop isn't here, then he's probably moving from place to place. Let me sms him for you) | 18:15.55 |
| | Ah, crap, ANOTHER lcms threading problem. | 18:19.47 |
| mvrhel | ugh. I hate it that the name strings in a separation color space are some how extracted by a call back to the interpreter. In creating equivalent CMYK values for the spots that exist in the DeviceN output profile I was planning to create a bogus Separation space and push it through the existing code to compute the equivalent CMYK values. Unfortunately, the tie in with the interpreter... | 18:27.41 |
| | ...makes it pretty much impossible | 18:27.43 |
| Robin_Watts | kens may have insight on that. | 18:28.23 |
| | How often would you need to do that? Is that a once per spot per page thing? | 18:29.12 |
| mvrhel | Once for each non cmyk colorant in the output profiel | 18:29.46 |
| | I think I just came up with an approach by using an ICC color space instead of a separation color space | 18:30.08 |
| Robin_Watts | So, could we do something funky in zshowpage ? | 18:30.25 |
| mace | Robin_Watts: yeah thats the latest version.. i'm waiting on hearing back from ray i think | 18:30.28 |
| Robin_Watts | mace: Right, what do you need from ray? | 18:30.44 |
| mace | there were some concerns about whether the server would have php/mysql on it i think | 18:31.05 |
| | this was a good while back, ray seemed very busy with customer stuff so i didn't pester | 18:31.21 |
| mvrhel | Robin_Watts: I don't know. The device and the profile all have to be set up as well as the spot name lists. not sure where showpage occurs. plus I have to have access to the imager state and the device | 18:31.25 |
| | I am going to push on for a bit with this other approach | 18:31.45 |
| Robin_Watts | mvrhel: 'showpage' is (AIUI) the very last thing that happens. It's the "and put that on paper and eject it" command. | 18:32.04 |
| | I believe if we did it in showpage we'd have both the device and the imager state. | 18:32.27 |
| | The question is, is that too late - presumably you need to have done the conversion to cmyk before the rendering stuff that used that spot color. | 18:33.59 |
| | And ANOTHER lcms threading issue. jeez. | 18:35.35 |
| henrys | damn dog bit the meter man ... I told him to wait until I put the dogs away before he burst through the gate | 18:35.57 |
| Robin_Watts | henrys: oops. But if you warned him and he ignored you, you should be OK. | 18:36.28 |
| | was it bad? | 18:36.32 |
| mvrhel | Robin_Watts: yes. It would need to be done before rendering | 18:36.48 |
| henrys | no not too bad but now my dog is quarantined for 10 days in my house. | 18:36.57 |
| mvrhel | I think I have an approach now | 18:36.58 |
| Robin_Watts | henrys: 10 days? is that a legal thing ? | 18:37.24 |
| henrys | it's a rabies thing - animal control comes back in 10 days and makes sure the dog is healthy. | 18:37.55 |
| Robin_Watts | henrys: Ah! | 18:38.04 |
| | No rabies in the UK, so you kinda forget the issue. | 18:38.35 |
| | Do you get anti-rabies shots for dogs in the US? | 18:39.09 |
| | I believe there is a vaccine now. | 18:39.27 |
| henrys | yes they are required. | 18:39.58 |
| Robin_Watts | Certainly it used to be impossible to take dogs to the continent and back without 6 months quarantine here, and now you can do it if you have rabies shots and a "dog passport". | 18:40.12 |
| | So animal control are coming back to check that the dog didn't catch anything from the meter man? | 18:48.37 |
| henrys | no they assume the dog has rabies and is likely to bite others so they quarantine it, if the dog does have rabies in 10 days it's health condition will be obvious. | 18:55.17 |
| marcosw | henrys: can you remind me of the end-of-support policy for ghostscript? I think it was 1 year after two releases (so effectively two years, presuming we release every 6 months). | 18:57.03 |
| henrys | yeah 2 years. But I didn't recognize that customers name, I guess you verified. | 18:58.49 |
| marcosw | no, he's asking about the GPL ghostscript, I was going to tell him that it's not supported at all but if he wants to pay what our support terms are. | 18:59.37 |
| henrys | okay tell him not use support@ too. | 19:00.12 |
| Robin_Watts | marcosw: Did you spot his job title in his .sig? | 19:00.19 |
| henrys | these yahoos | 19:00.20 |
| Robin_Watts | "Application Packager". That smells non-GPL to me. | 19:00.34 |
| henrys | yes I think this stinks enough to report to scott and miles. | 19:01.22 |
| | I'm going to lunch be back in an hour or so. | 19:01.39 |
| | sms me if you need anything | 19:02.02 |
| marcosw | apparently ken already forwarded the email to scott, I just received a cc of scott's email to Anju (apparently ken didn't cc support). | 19:09.05 |
| Robin_Watts | marcosw: The pam testing we do in the cluster... which device is that? | 19:49.49 |
| | pam? pamcmyk32? pamcmyk4? | 19:50.00 |
| marcosw | Robin_Watts: -sDEVICE=pam | 19:50.32 |
| Robin_Watts | I wonder why we don't have the device in the windows build by default then. | 19:50.50 |
| mvrhel | bbiaw | 20:31.55 |
| ray_work | henrys: marcosw: actually, our support (for customers) is 1 year after the release that replaces a release, so with every 6 mo, that is 18 mo. | 23:42.29 |
| | so a release in Feb has the one year clock start ticking when we release in Aug. | 23:43.24 |
| | Forward 1 day (to 2012/09/21)>>> | |
IRC Logs