| | <<<Back 1 day (to 2011/07/21) | 2011/07/22 |
| mvrhel2 | tkamppeter: I am glad to see that 691755 is finally completed | 04:44.18 |
| Robin_Watts | tkamppeter: Turns out that stars.pdf has a load of 300x300ish images in. | 10:58.02 |
| | which are specifically set to be interpolated within the file. | 10:58.20 |
| | with softmasks. | 10:58.24 |
| | And then it draws over the top of them so you can't see them. | 10:58.34 |
| kens | Thought that might ve the case when I read the logs. | 10:58.34 |
| | Its unusual to find image siwht /Interpolate true. | 10:58.51 |
| | Of course with Cairo, who knows..... | 10:59.01 |
| Robin_Watts | I just replaced them all by 1x1 transparent images, and the files render the same. | 10:59.10 |
| kens | Finally, I think I've stopped my text extraction class from eating bits of text. | 11:20.24 |
| | Now all I need to do is figure out why it seems to be spaced a bit weirdly. | 11:20.44 |
| | chrisl when did you want to tag the release, or are you going to wait until some of the blockers are fixed ? | 11:25.13 |
| chrisl | kens: Not tag, branch - I think I'll leave it another day or two, given the blockers we have | 11:26.21 |
| kens | That suits me, I'd like to try and get my spacing problem fixed toady, tehn I could chekc in what I have. | 11:26.54 |
| | Err, today, not toady | 11:27.10 |
| chrisl | Well, Henry may have a different opinion, but I'll probably do it on Monday, regardless - I can always pull fixes into the branch. | 11:28.27 |
| kens | Sure, I don't really think its worth spending a lot of effort pulling the text device fixes in, its not going to be perfectly functional in this release. But I'd like the basics to be there so people can at least look at it. | 11:29.29 |
| tkamppeter | Robin_Watts, then the program which generated stars.pdf (or the libraries it uses) is really buggy. But gettin execution time down to a minute from several hours is also a good sign also for users who have only correct PDF files. | 11:47.36 |
| Robin_Watts | tkamppeter: Yeah. I wanted to understand where the time was going though in case it was a bug in gs. | 11:48.07 |
| | and it's really not :) | 11:48.11 |
| tkamppeter | Robin_Watts, in Oneiric I will use 9.04 with -dNOINTERPOLATE for all printing and so jobs should go fast, very fast with correct files and in reasonable time with buggy files.\ | 11:49.55 |
| | Robin_Watts, now the next step is fixing all the segfault bugs, to make the printing workflow more stable. | 11:50.40 |
| Robin_Watts | Are there seg faults in gs? | 11:50.53 |
| tkamppeter | Robin_Watts, yes, I think I have already reported some bugs. And today or Monday I will report another one. | 11:51.32 |
| Robin_Watts | Can you remember bug numbers offhand? | 11:52.00 |
| tkamppeter | Robin_Watts, no. | 11:52.38 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=691586 looks like one. | 11:53.15 |
| tkamppeter | Yes, that it is a good example. | 11:56.30 |
| | Robin_Watts, http://bugs.ghostscript.com/show_bug.cgi?id=692368 Is the bug I discovered yesterday. | 12:14.43 |
| chrisl | kens: have you Acrobat X? | 12:39.22 |
| kens | No, sorry | 12:40.04 |
| chrisl | But you've got earlier ones? | 12:40.20 |
| kens | 7 & 9 pro to hand, earlier versions of reader | 12:41.03 |
| chrisl | kens: If you have the test file, could you try svn-private/ghostpcl/trunk/tests_private/comparefiles/Testform.v1.0.2.pdf with Acro 7 please? | 12:41.15 |
| | If you don't have the test file, don't worry about it | 12:41.39 |
| kens | I htink I have it just a minute | 12:41.47 |
| | "There was an error processing the page. Invalid ColorSpace" | 12:43.39 |
| | Same in 9 | 12:44.05 |
| chrisl | Great, thanks, same as I get with 9.x Pro, and Shelly gets with whatever Reader version he's using! | 12:44.16 |
| kens | Also Reader X | 12:44.38 |
| | Reader 5.0 is happy with it | 12:45.09 |
| chrisl | Hmm, that's weird - still, how much do we want to worry about files which don't work on sensibly recent Acrobat releases | 12:46.09 |
| kens | I guess it depends why it fails, and what the file is testing ;-) | 12:46.49 |
| chrisl | True. GS doesn't complain about it, so I guess there is a problem with the output, but really, who cares - or maybe the problem is that we *don't* error...... | 12:48.08 |
| Robin_Watts | alexcher: kens: chrisl: As our PS experts... | 14:54.34 |
| | I have an idea that should save us 200K off the size of a compiled ghostscript. | 14:54.52 |
| kens | sounds goo | 14:55.25 |
| | d | 14:55.27 |
| Robin_Watts | When we put .ps files into mkromfs, mkromfs could strip out extraneous whitespace, comments etc. | 14:55.32 |
| kens | I htought it did | 14:55.48 |
| Robin_Watts | I've done a simple prototype of that here, and it saves 192K. | 14:55.57 |
| | It doesn't. | 14:56.05 |
| | It compresses the files with zlib, but clearly compacting them before compression should give better results. | 14:56.24 |
| | (The 192K is the figure *after* compression). | 14:56.47 |
| | But gs is giving me an error on startup now, so I've clearly broken something. | 14:57.15 |
| | http://ghostscript.com/~robin/blah.ps is my compacted version of gs_statd.ps | 14:58.06 |
| | There is more to be saved by removing whitespace before and after { [ etc. | 14:59.14 |
| kens | sorry diverted | 14:59.29 |
| Robin_Watts | but before I invest too much more time in it, I'd like to a) get it working as is, and b) get feedback from people about whether it's worth pursuing. | 14:59.52 |
| | You'd hope that it should give speedups too - less crap to read at startup. | 15:00.14 |
| chrisl | Robin_Watts: we discussed this at a staff meeting a while back - I'm sure Ray said he did that already | 15:00.29 |
| Robin_Watts | chrisl: Well, if ray did it already, then why I am managing to save 192k? :) | 15:00.50 |
| | (other than me maybe breaking stuff :) ) | 15:01.04 |
| | There claims to be special case handling in there for gs_init.ps actually. | 15:02.03 |
| | Let me look at that. | 15:02.05 |
| | yeah, ray has some code in there, but it only gets applied to one file, AIUI. | 15:04.44 |
| chrisl | Seems strange - plenty of comments and white space in files other than gs_init.ps | 15:05.27 |
| Robin_Watts | indeed. | 15:05.46 |
| | I am a bit confused as to what is wrong with the file I produce. | 15:06.01 |
| | The error I get is: | 15:06.09 |
| | While reading gs_statd.ps: | 15:06.22 |
| | Error: /ioerror in -file- | 15:06.24 |
| | Operand stack: | 15:06.26 |
| | Execution stack: | 15:06.27 |
| | %interp_exit --nostringval-- --nostringval-- --nostringval-- false | 15:06.29 |
| | 1 %stopped_push | 15:06.30 |
| | Dictionary stack: | 15:06.32 |
| | --dict:681/1123-- --dict:5/200-- --dict:681/1123-- | 15:06.33 |
| kens | I'm sure opdfread.ps got the same treatent, before I removed it. | 15:07.37 |
| | Robin_Watts : I'd have to see the file before and after really | 15:07.55 |
| Robin_Watts | Resource/Init/gs_statd.ps | 15:08.21 |
| | and the after file is the link above. | 15:08.27 |
| chrisl | Robin_Watts: what job are you running to get the error? | 15:09.37 |
| Robin_Watts | gs/debugbin/gswin32c.exe | 15:09.48 |
| | i.e. just starting up. | 15:09.54 |
| chrisl | Okay, well the file you posted the link to works fine for me running directly off disk | 15:10.28 |
| kens | It *looks* OK, I'll replace teh one I have here on disk and try startup | 15:10.33 |
| | Oh, OK what Chris said then | 15:10.42 |
| Robin_Watts | oh, hmm. then I'm confused. | 15:10.55 |
| kens | Maybe the problem is that i can't *open* gs_statd.ps | 15:11.14 |
| chrisl | And it's fine when I build it into a romfs, too | 15:11.17 |
| kens | Modify the original file to put some '(testing 1) == flush' statements to see if it executes the file at all | 15:12.14 |
| | and then strip and comrepss etc. | 15:12.30 |
| Robin_Watts | Can I save that file to disc, and then make gs start up and use the file from disc instead of the %rom% version? | 15:13.20 |
| kens | Yes. Set -sGenericResourecDir, or add -I with the Resource path to the command line | 15:13.53 |
| Robin_Watts | Thanks. | 15:14.02 |
| | so it does indeed work when reading from disc. | 15:27.15 |
| | I've modified my code so that ONLY that one file is compacted in the romfs, and it works from disc, but not from %rom% | 15:27.45 |
| | so I must be screwing up the compression or something. | 15:27.53 |
| | Is there a way in gs to tell it to dump the contents of a file ? | 15:28.18 |
| | i.e. can I get postscript to cat %rom%/Init/gs_statd.ps ? | 15:28.41 |
| kens | Not util after its started up | 15:28.45 |
| Robin_Watts | I can start it with the disc one :) | 15:28.54 |
| kens | You can open teh file, tehn use readstring and writestring and write it to a disc file. | 15:29.23 |
| Robin_Watts | or to stdout ? | 15:29.36 |
| kens | Possibly, why not just write it to a file ? | 15:29.51 |
| Robin_Watts | whatever is easier. | 15:30.07 |
| kens | Well I'd write it to a file. | 15:30.19 |
| | { | 15:31.02 |
| | InFile Data readstring { | 15:31.02 |
| | OutFile exch writestring | 15:31.03 |
| | } { | 15:31.03 |
| | OutFile exch writestring | 15:31.04 |
| | exit | 15:31.04 |
| | } ifelse | 15:31.05 |
| | } loop | 15:31.05 |
| | InFile closefile | 15:31.06 |
| | OutFile closefile | 15:31.06 |
| | Bugger | 15:31.08 |
| | "/InFile (/temp/freetype.font.bin) (r) file /FlateDecode filter def | 15:31.15 |
| | { | 15:31.15 |
| | InFile Data readstring { | 15:31.15 |
| | OutFile exch writestring | 15:31.15 |
| | } { | 15:31.16 |
| | OutFile exch writestring | 15:31.16 |
| | exit | 15:31.17 |
| | } ifelse | 15:31.17 |
| | } loop | 15:31.18 |
| | InFile closefile | 15:31.18 |
| | OutFile closefile" | 15:31.19 |
| Robin_Watts | I don't want the /FlateDecode do I ? | 15:32.06 |
| kens | "/InFile (/temp/freetype.font.bin) (r) file /FlateDecode filter def" | 15:32.09 |
| | "/OutFile (/temp/freetype.font.txt) (w) file def" | 15:32.09 |
| | "/Data 32768 string def" | 15:32.09 |
| | { | 15:32.09 |
| | InFile Data readstring { | 15:32.09 |
| | OutFile exch writestring | 15:32.10 |
| | } { | 15:32.10 |
| | OutFile exch writestring | 15:32.11 |
| | exit | 15:32.11 |
| | } ifelse | 15:32.12 |
| | } loop | 15:32.12 |
| | InFile closefile | 15:32.13 |
| | OutFile closefile | 15:32.13 |
| | The FlateDecode is for Flate compressed files :-) Its just an example I had here | 15:32.29 |
| Robin_Watts | (%rom%/Init/gs_statd.ps) ? | 15:35.33 |
| kens | I guess but you're on your own with that one | 15:35.49 |
| chrisl | I don't think you want the "/" after the trailing "%": so (%rom%Init/gs_statd.ps) | 15:36.31 |
| Robin_Watts | %romesource/Init/gs_statd.ps seems to be the one. Thanks. | 15:39.03 |
| | bah, stuid chatzilla. | 15:39.13 |
| | Percent rom Percent Resource/Init/gs_statd.ps | 15:39.32 |
| kens | :-) | 15:39.41 |
| Robin_Watts | Now I get an ioerror in readstring. | 15:42.36 |
| | I wonder if that's because the zlib data is corrupt or something ? | 15:42.50 |
| kens | Sounds like its improperly compressed then | 15:42.55 |
| ray_laptop | Robin_Watts: I saw comments about stripping comments and whitespace from the init files. Sorry you are re-inventing a wheel. That code existed, and I moved it into mkromfs, but held off releasing it because we were to close to a release. | 15:47.45 |
| Robin_Watts | ray_laptop: yeah. | 15:48.05 |
| ray_laptop | then promptly other projects surfaced, so it never got checked in. | 15:48.15 |
| Robin_Watts | Ah, so it's recent code ? | 15:48.16 |
| | oh, I see. | 15:48.24 |
| ray_laptop | Robin_Watts: but if you want to _really_ cut down the gs size, then going to a better CMap would make a large difference | 15:49.00 |
| henrys | I thought it done too, can we have a bug? | 15:49.13 |
| Robin_Watts | ray_laptop: I think I found my mistake. | 15:49.23 |
| ray_laptop | henrys: IIRC there is a bug for the CMap compression | 15:49.48 |
| | but maybe it was just a staff meeting discussion | 15:50.02 |
| Robin_Watts | The CMAP compression was what I actually had in mind when I started to look at this, but I got sidetracked into this :) | 15:50.14 |
| henrys | ray_laptop:I think we could have one bug for both. | 15:50.37 |
| ray_laptop | let me look to see if I can find the bugs (or email thread) | 15:51.08 |
| henrys | ray_laptop, Robin_Watts:I copied you guys in on a bug sags worked on about lib_ctx - I think we should talk about the lifetime of this objects, I'm a bit confused. | 15:51.56 |
| ray_laptop | I mention CMap compression in my comment #3 of bug 692335 | 15:52.29 |
| henrys | probably best if you read the bug before talking about it. | 15:52.42 |
| Robin_Watts | henrys: Gimme 5 mins, and I'll read it. | 15:53.13 |
| henrys | ray_laptop:okay can we just add in a comment there to strip out whitespace in the files. | 15:53.35 |
| | ? | 15:53.38 |
| | if Robin_Watts figure of 200K is correct that's worth doing right? | 15:54.00 |
| Robin_Watts | That's better. I'm down to actual errors in the compaction process now I think. | 16:02.21 |
| ray_laptop | Robin_Watts: the method I have actually builds all of the init files into a single file, so it reduces execution time by a bit as well since we only do one %rom% lookup | 16:03.47 |
| Robin_Watts | ray_laptop: Yes. I see that. | 16:04.01 |
| | but we don't want that for all the .ps files do we ? | 16:04.30 |
| ray_laptop | Robin_Watts: the process I have uses the previous 'geninit.c' method so it only loads the files we need. | 16:06.05 |
| | for a given configuration of gs | 16:06.22 |
| Robin_Watts | ray_laptop: Right. I don't claim to understand all the intricacies there. | 16:06.44 |
| | I just hooked the 'read in, compress files, write nodes' code in there to spot files ending in .ps and rather than calling 'fread' it calls 'fread_with_compaction', | 16:07.48 |
| | henrys: You were talking about bug 692367 right ? | 16:09.19 |
| henrys | yes I was | 16:10.01 |
| ray_laptop | calling init_with_args more than once clearly wasn't intended to be supported, but I guess we don't disallow it | 16:14.36 |
| Robin_Watts | So the lib_ctx is allocated by us calling gs_lib_ctx_init on a gs_memory_t that doesn't already have a lib_ctx in it. | 16:14.36 |
| | and that happens in gs_malloc_init | 16:14.57 |
| ray_laptop | the expected sequence is _new_instance ... init_with_args .... delete_instance (gsapi omitted) | 16:15.41 |
| Robin_Watts | The lib_ctx has to live on (and keep itself valid) for as long as we have a gs_memory_t | 16:16.58 |
| | So it seems to me that either we need to be destroying the mem (and the lib_ctx) | 16:19.19 |
| | or we need to be destroying the lib_ctx and setting the pointer to it in the mem to NULL. | 16:19.39 |
| | or we need to ensure that the lib_ctx's pointers are correct. | 16:19.50 |
| | The latter seems the easiest route. | 16:19.56 |
| | and sags patch seems to achieve that. | 16:20.09 |
| henrys | I think we should use stable memory for those pointers and not need sags patch. | 16:20.47 |
| Robin_Watts | though it is horrible that we have to 'know' that the restore will have removed those pointers and fix them up later. | 16:21.34 |
| | so yes, you may be right. | 16:21.44 |
| ray_laptop | Robin_Watts: stable memory is still subject to GC, but that shouldn't hurt | 16:22.02 |
| Robin_Watts | I have no feeling for the lifecycle of those pointers at all. | 16:22.23 |
| henrys | and multiple init_with_args I find quite non-intuitive there must be a better way of reseting the resolution which is what I think russel wants to do. | 16:22.39 |
| Robin_Watts | henrys: Do you find that offensive? | 16:23.04 |
| ray_laptop | you don't have to init_with_args to reset resolution | 16:23.07 |
| Robin_Watts | It seems reasonable to me that I should be able to init the dll, then call it several times, for several jobs, then exit. | 16:23.30 |
| ray_laptop | but I suppose we don't say that init_with_args ... gsapi_exit ... gsapi_init_with_args is illegal | 16:23.54 |
| henrys | init means once to me. | 16:23.56 |
| ray_laptop | if he had done the gsapi_delete_instance then gsapi_new_instance it would have been fine | 16:24.47 |
| | he (Russell) could just use 'put_params' to set the resolution, if that's all he wanted | 16:26.09 |
| Robin_Watts | I'm new to this, so bear with me. | 16:26.55 |
| ray_laptop | but I think that when he 'opens' a new file he wants a fresh interpreter state so that there won't be anything "dangling" from the previous | 16:27.01 |
| Robin_Watts | We call gsapi_new_instance to make a new instance. | 16:27.23 |
| ray_laptop | (GSView predates us having a working -dJOBSERVER) | 16:27.27 |
| Robin_Watts | We then call gsapi_init_with_args. | 16:28.21 |
| | If that's only intended to ever be called once, then why isn't that part of the gsapi_new_instance call? | 16:28.42 |
| ray_laptop | but what GSView is doing is rather moot at this point -- if we didn't forbid it, it should work (IMHO) | 16:28.49 |
| Robin_Watts | Anyway, if we move those pointers into stable memory, then the alloc_restore_all won't free them ? | 16:29.56 |
| | the lib_ctx will be left with pointers pointing to valid objects. | 16:30.14 |
| | Will they correctly get reused when gs is next entered? | 16:30.28 |
| henrys | Robin_Watts:I thought you could make other funtions like gsapi_init_with_file which would presumably use something like a .file but I don't know for sure why it isn't one function as you say. | 16:30.31 |
| Robin_Watts | (i.e. they won't just get overwritten and leak?) | 16:30.53 |
| | or are you suggesting that in the same place as sags is currently blanking the pointers, we should free the objects (and blank the pointers) anyway? | 16:31.33 |
| kens | Time for me to go. Night all. | 16:31.38 |
| Robin_Watts | night kens. have a good weekend. | 16:31.44 |
| henrys | my view is we should explicitly free the pointers when the instance is destroyed if we agree 1 libctx per instance. | 16:32.41 |
| ray_laptop | actually init_with_args is optional. You can call gsapi_run_string_begin and never call init_with_args | 16:32.44 |
| | and the reason init_with_args is separate is that we want people to be able to set up the stdio and display callbacks AFTER the instance is created, but before init | 16:33.34 |
| henrys | oh okay that makes sense | 16:34.04 |
| Robin_Watts | 1 lib_ctx per instance, yes. 1 lib_ctx per call to init_with_args, no. (I'm sure that's what you meant, I'm restating for my own clarity) | 16:34.05 |
| ray_laptop | henrys: putting those pointers in stable memory, then freeing them when we delete the instance makes sense to me | 16:34.29 |
| Robin_Watts | ray_laptop: Ah, ok. | 16:34.34 |
| henrys | now are we allowing multiple gsapi_exits per instance? | 16:35.47 |
| ray_laptop | henrys: we didn't say you couldn't, and I thought that is what gsview was doing | 16:36.38 |
| Robin_Watts | If exit is intended to 'bookend' init, then that's a very poor choice of words. | 16:37.26 |
| ray_laptop | sort of moot now since we have a published API | 16:37.52 |
| chrisl | Robin_Watts, ray_laptop: shouldn't it be non_gc_memory rather than stable_memory for this? | 16:38.00 |
| Robin_Watts | init matches with a fin. create matches with a destroy. begin matches with end. enter matches with exit. etc. | 16:38.02 |
| ray_laptop | but I like it better than the non-word PCL uses 'dnit' | 16:38.15 |
| henrys | chrisl:why would the pointer be subject to gc? We are concerned about save/restore? | 16:39.11 |
| Robin_Watts | ray_laptop: We can always create a gs_api_finalise, that does the same as exit, and deprecate exit. | 16:39.25 |
| ray_laptop | chrisl: putting them in non_gc_memory is fine (and I rather like it) | 16:39.33 |
| chrisl | henrys: I thought you were talking about taking them *out* of the garbage collector's remit? | 16:39.55 |
| Robin_Watts | chrisl: That sounds better to me too. If we're expecting them to never be garbage collected, then why put them in garbage collectable memory. | 16:40.05 |
| henrys | so stable non gc memory | 16:40.25 |
| chrisl | If we intend to explicitly free these pointers at shutdown, then I think that makes sense. | 16:41.06 |
| ray_laptop | I'd have to see if the GC has any knowledge of them. I don't think it does since they aren't traceable from the 'root'. The pseudo-global gs_lib_ctx is invisible to the GC | 16:41.08 |
| henrys | ray_laptop:actually I think you and mvrhel2 already did that for iccdir. | 16:41.10 |
| ray_laptop | henrys: yes, and the more stuff we move to non_gc_memory, the better (IMHO) since it will make the GC run faster when it does run | 16:41.54 |
| chrisl | ray_laptop: If they are allocated from GC memory, but not accessible from "root" that's *bad*! | 16:42.31 |
| ray_laptop | the two 'gotchas' with moving stuff in general to non_gc_memory is that each allocation is a separate one so we don't want lots of small allocations and we have to make sure we don't leak. | 16:43.29 |
| henrys | who want to be the point person (victim) for this one? | 16:43.40 |
| Robin_Watts | has disconnected. | 16:43.57 |
| ray_laptop | chrisl: yes, if they are in a 'chunk' owned by the GC, and they aren't traced, that is bad (assumed lost and are collected) | 16:44.22 |
| henrys | we've agreed to allocate non gc stable memory, so this isn't an issue right? | 16:45.08 |
| chrisl | ray_laptop: so the only thing that's saved us, probably, is that they are in the outermost global VM save level, which probably doesn't get swept until we're shutting down. | 16:45.24 |
| ray_laptop | chrisl: I don't see where/how the io_device_table (for one) is made known to the GC, but the init process does a GC call before the outermost save and it works. Try: gs -dNOOUTERSAVE -c 2 vmreclaim quit | 16:49.08 |
| henrys | sags is correct that the outermost restore affect global vm right? That is the issue not gc? | 16:50.25 |
| | right? | 16:50.30 |
| ray_laptop | the outermost restore _does_ restore global AND local VM | 16:51.00 |
| | henrys: that is intentional in the PS spec and design to allow for a jobserver to isolate VM state between jobs | 16:51.46 |
| | but if the tables are in non_gc_memory we have to make sure that they are not EVER traced by the GC | 16:52.44 |
| chrisl | This is looking like a potentially quite de-stabilizing change so close to a release :-( | 16:56.06 |
| ray_laptop | chrisl: I agree. | 16:56.41 |
| henrys | no this goes in next time. | 16:56.54 |
| | next release | 16:57.07 |
| ray_laptop | anybody have any idea why this didn't show up before ? i.e., does 8.71 fail ? | 16:57.09 |
| chrisl | Could we pull in sags's changes for 9.04? | 16:57.22 |
| henrys | chrisl:I wouldn't even do that all we have now is a gsview bug | 16:58.36 |
| | arguably if russel didn't exit and just used set params this would not have come up. | 16:59.16 |
| ray_laptop | I think that the gs_main_finit change of SaGS' patch is safe enough | 16:59.32 |
| | henrys: I think the issue with GSView when a file is dragged to to GSView would do the same -- for that he wants a 'new' interpreter state | 17:00.23 |
| chrisl | henrys: My worry is a lot of users, customers and potential customer are using/will use GSView as a simple way to play with Ghostscript, it's not a good show to crash, I think. | 17:00.35 |
| henrys | cringes but won't argue | 17:00.36 |
| ray_laptop | but (IMHO) a delete_instance .. new_instance would be preferred | 17:00.46 |
| ray_laptop | agrees with chrisl | 17:01.06 |
| chrisl | ray_laptop: do you think we could get Russel to make that change and do a GSView release to approximately coincide with 9.04? That would also solve the problem...... | 17:01.54 |
| ray_laptop | but if the pointers are moved to stable_memory, then we haven't touched the GC aspect and the pointers won't get freed by the alloc_restore_all | 17:02.23 |
| chrisl | ray_laptop: so we could do that 9.04 and do the moving out of GC memory altogether after? | 17:03.09 |
| ray_laptop | henrys: the problem is that GSView is designed to use newer versions of GS, but there isn't a way to make older GS NOT use a newer one | 17:03.15 |
| henrys | votes to assign the general problem to be fixed in 9.05 to chrisl as it is a system setup problem and requires postscript kung fu. | 17:03.30 |
| | well at least understanding of ps memory | 17:03.57 |
| chrisl | thinks he's being punished for something........ | 17:04.11 |
| ray_laptop | chrisl: yes, stable_memory means that it will persist (and we will have to explicitly free the elements somewhere) | 17:04.35 |
| chrisl | henrys: okay, I just didn't want to have to try to solve it properly before 9.04. | 17:04.50 |
| ray_laptop | chrisl: but SaGS' patch will allow the objects to be freed (as now) and just make sure we know we have to reallocate them, so maybe it is the 'least change' -- no new leaks | 17:05.33 |
| chrisl | ray_laptop: just to clarify: stable_memory (I thought) was still subject to garbage collection, but not compaction and not PS restore? | 17:06.30 |
| ray_laptop | although I like to set pointers to NULL instead of 0 | 17:06.34 |
| | chrisl: stable_memory is still subject to GC, thus is subject to relocation and collection | 17:07.09 |
| | it is just not subject to save/restore | 17:07.24 |
| chrisl | ray_laptop: okay, thanks! | 17:07.51 |
| | So we're agreed I'll do something suitably low risk for 9.04, and the "proper" fix after the release? | 17:08.25 |
| ray_laptop | but if the gs_lib_ctx pointers aren't known to the GC (i.e., don't have a structure descriptor) then relocation would kill us anyway | 17:08.32 |
| mvrhel2 | ok. the blocking bug 692364 has been resolved | 17:08.43 |
| | now to commit the gray to K fix | 17:08.58 |
| tkamppeter | Robin_Watts, have you seen my last messages, about the segfault bug which I have reported today? | 17:09.03 |
| mvrhel2 | after a bit of testing | 17:09.05 |
| Robin_Watts | tkamppeter: I saw that you opened a bug. I haven't had a chance to look yet. | 17:09.28 |
| chrisl | ray_laptop: I didn't think the outermost save level memory would get swept until we were shutting down? | 17:09.35 |
| ray_laptop | ahh, we use gs_alloc_bytes_immovable to keep relocation from being a problem (in gs_lib_ctx_init) | 17:09.47 |
| chrisl | ray_laptop: that makes sense. | 17:10.54 |
| ray_laptop | but I don't see a structure descriptor for gs_lib_ctx so that implies it is never traced (it is allocated as 'bytes', not an object of specific type) | 17:11.59 |
| | ahh.... it becomes somewhat clearer to me... the gs_iodev_init calls gs_register_struct_root to make the io_device_table itself 'known' to the GC | 17:16.29 |
| chrisl | ray_laptop: if we added a finalize method to the offending objects, that could NULL out the pointers in the context when the memory is freed. | 17:17.02 |
| ray_laptop | so it is best to NOT move it (for now) to non_gc_memory [along with the other elements]. and go with SaGS' patch | 17:17.20 |
| | chrisl: how about you do it and as long as a cluster run is OK, we go with it. It will fix GSView and is unlikely to affect anyone else. | 17:19.55 |
| chrisl | ray_laptop: okay, it'll have to wait until Monday (or maybe the weekend) I need to finish in a few minutes. | 17:20.38 |
| ray_laptop | chrisl: you can put a 'FIXME:' comment in that describes doing the finalize | 17:20.40 |
| | chrisl: do you want me to do it (still early in my day) ? | 17:21.00 |
| chrisl | ray_laptop: no, I'm happy to do it - you've got plenty else on your plate! | 17:21.29 |
| ray_laptop | OK. I just wanted to make sure one of us does :-) | 17:21.48 |
| Robin_Watts | woooah. | 17:22.28 |
| | now I'm confused. | 17:22.32 |
| ray_laptop | chrisl: and when you do it, if you prefer to go ahead and do the 'finalize' that's fine too | 17:22.33 |
| chrisl | I'll leave a note for myself on my desk - that usually works ;-) | 17:22.33 |
| Robin_Watts | gs_fonts.ps contains a line: %%END FONTPATH | 17:23.05 |
| | bah. | 17:23.08 |
| | %END FONTPATH | 17:23.11 |
| | If I remove it, it goes wrong. | 17:23.20 |
| | is there some magic going on here ? | 17:23.30 |
| chrisl | ray_laptop: I'll have to have a look: for gs_name_table adding the finalize looks quite easy, but I haven't checked the other two. | 17:23.50 |
| Robin_Watts | Oh, yes. Magic. | 17:24.15 |
| chrisl | Robin_Watts: there are places where we "pre-process" files, it might be a case like that - horrid! | 17:24.33 |
| Robin_Watts | chrisl: It's exactly that :( | 17:24.44 |
| chrisl | Robin_Watts: nasty, I really don't like when it does that :-( | 17:25.28 |
| | I gotta go - enjoy your weekends! | 17:26.50 |
| henrys | bye chrisl | 17:27.01 |
| ray_laptop | Robin_Watts: there are places that use certain %% comments to process files. Some 'skip' until %%End... | 17:31.04 |
| | Robin_Watts: it is probably best to focus on the CMap issue since it is larger and the other problem has been solved already | 17:31.38 |
| | Robin_Watts: if you want, I can send you the modified 'mkromfs' for you to wrap up. | 17:41.11 |
| Robin_Watts | ray_laptop: Yes. It'd be OK if we always followed the same idiom, cos I could spot for that. | 17:41.47 |
| | It annoys me being SO close. | 17:42.06 |
| | actually, from a quick grep, it might be just %END I need to look for. | 17:44.08 |
| ray_laptop | Robin_Watts: yeah, I know. But as I mentioned, having the files we need all pickled into a single Resource/Init/gs_init.ps helps | 17:44.12 |
| Robin_Watts | ray_laptop: Right. There is code for that in mkromfs already. | 17:44.34 |
| | Is that code not called or something ? | 17:44.54 |
| ray_laptop | Robin_Watts: Oh, I must have already committed that | 17:45.31 |
| Robin_Watts | yes, that's what confused me. | 17:45.56 |
| ray_laptop | Robin_Watts: all we need it to modify it to use the -g switch, and delete the other stuff | 17:46.04 |
| Robin_Watts | Right. | 17:46.09 |
| ray_laptop | did say it was a while ago | 17:46.18 |
| Robin_Watts | So that will result in %romesource/Init/gs_init.ps being the only file in Resource/Init ? | 17:47.47 |
| ray_laptop | about march 2010 | 17:47.52 |
| | well, you need to modify the PS_ROMFS_ARGS | 17:48.30 |
| | Robin_Watts: in particular you have to get rid of Init$(D)* in RESOURCE_LIST and add in the -g args to PS_ROMFS__ARGS | 17:50.15 |
| Robin_Watts | ok. | 17:50.36 |
| ray_laptop | you can execute mkromfs from the command line with manual args and see what goes in | 17:51.27 |
| Robin_Watts | will this affect the Resource/Colorspace/ files etc? | 17:51.56 |
| ray_laptop | Robin_Watts: nope. | 17:52.07 |
| Robin_Watts | OK, so we can benefit from compacting them. | 17:52.20 |
| ray_laptop | Robin_Watts: yeah, except those are smaller | 17:53.15 |
| Robin_Watts | and the header comments are a larger proportion :) | 17:53.37 |
| ray_laptop | Robin_Watts: I think we can manually reduce whitespace in the Decoding set without affecting maintainability | 17:54.58 |
| Robin_Watts | ray_laptop: I think with your code and my code working together we have this covered :) | 17:55.24 |
| ray_laptop | Robin_Watts: except for the big item -- CMap files | 17:55.42 |
| Robin_Watts | indeed. | 17:55.48 |
| ray_laptop | I assume you looked at how much a simple comment + whitespace cleanup can do to the CMap suite ? | 17:56.50 |
| Robin_Watts | not yet. | 17:57.07 |
| ray_laptop | Robin_Watts: and we have to make sure and follow the rules w.r.t. CMap files and the "notice" requirement | 17:58.08 |
| Robin_Watts | ray_laptop: Not when pickled into %rom%, surely. | 17:58.28 |
| | We supply them with the comments intact for disc based operation. | 17:58.54 |
| ray_laptop | Robin_Watts: I am not a legal beagle | 17:59.00 |
| Robin_Watts | When we pickle them into rom, we strip that all out. | 17:59.16 |
| ray_laptop | The relevant part is probably: | 17:59.39 |
| | %Copyright: Redistributions in binary form must reproduce the above | 17:59.41 |
| | %Copyright: copyright notice, this list of conditions and the following | 17:59.43 |
| | %Copyright: disclaimer in the documentation and/or other materials | 17:59.45 |
| | %Copyright: provided with the distribution. | 17:59.46 |
| | We just have to make sure the self-extracting install conforms | 18:00.33 |
| Robin_Watts | yeah. | 18:00.40 |
| ray_laptop | Our 'LICENSE' file says: the files in the CMap subdirectory. The CMap files are copyright Adobe Systems Incorporated and covered by a separate license which permits only verbatim distribution. | 18:01.41 |
| | which isn't exactly true. So we may need to make sure and distribute their statement. Also they changed to say 'with or without modification' (no longer verbatim) | 18:03.25 |
| | that is something we should clean up for 9.04 release | 18:03.48 |
| | but at least it allows for 'binary' which is where the big win can be. | 18:04.32 |
| | right now the CMap files have LOTS of lines that are '<XXXX> <XXXX> NNN' which can reduce to 6 bytes (from 18) | 18:10.54 |
| henrys | mvrhel2:are you around? | 18:13.27 |
| mvrhel2 | yes. | 18:13.35 |
| | cleaning up my gray to K stuff. I would like to get it committed today | 18:13.53 |
| henrys | I was asking before about the cie joint caches do we use that at all anymore? | 18:13.59 |
| mvrhel2 | we use a small part of it (that going from PS to CIEXYZ) for generating equivalent ICC profiles from PS CIE based objects | 18:15.02 |
| | however, in general, the whole squashed thing with the CRD should not be created | 18:15.16 |
| | I think we have a bug open about this | 18:15.26 |
| henrys | it's a 50K memory hit every job | 18:15.51 |
| mvrhel2 | oh | 18:15.55 |
| | if you want to see about stopping it that is fine. I can spend some time on it this weekend and early next week to | 18:16.22 |
| henrys | not a lot but if I saw 50K on the sidewalk I'd probably pick it up ;-) | 18:16.46 |
| mvrhel2 | :) | 18:16.52 |
| henrys | okay I'll study it a bit. | 18:17.27 |
| Robin_Watts | ray_laptop: It looks like your routines are running into exactly the same problems mine did. | 18:27.49 |
| | (unless I'm being foolish somehow) | 18:28.00 |
| mvrhel2 | bbiab | 18:29.08 |
| ray_laptop | Robin_Watts: that could be. I never finished it. Is it eating the %%End | 18:30.07 |
| Robin_Watts | That's what I'm thinking. | 18:30.22 |
| | Except the code doesn't use %%End. | 18:30.30 |
| | It uses %END something | 18:30.36 |
| | grep for .skipeof for example. | 18:31.03 |
| ray_laptop | Robin_Watts: right. I remember skipeof | 18:31.28 |
| Robin_Watts | Is skipeof the only miscreant, or are there others ? | 18:31.49 |
| ray_laptop | Robin_Watts: look at the top of gs_init.ps | 18:36.04 |
| Robin_Watts | The %Replace stuff ? | 18:36.35 |
| ray_laptop | The %% Replace is what is handled by the geninit code (now in mkromfs) | 18:36.48 |
| Robin_Watts | right. | 18:37.24 |
| | I've dumped out the gs_init.ps that's created in ROM (by starting gs with -Igs/Resource/Init | 18:37.52 |
| | ) | 18:37.54 |
| ray_laptop | it could be that the old 'geninit' never handled %%END right -- I will go look | 18:37.57 |
| Robin_Watts | and that contains ps code to look for %END but no %END markers to find. | 18:38.16 |
| | but I can see where 'doit' in mkromfs.c tries to leave such lines alone. I will play for a bit. | 18:38.41 |
| ray_laptop | hmm... the 'doit' in mkromfs.c has: if (!strncmp(str, "%END", 4))/* keep these for .skipeof */ (just like the original geninit.c) | 18:40.14 |
| | looks like a typo, or something changed along the way from %END to %%END | 18:41.27 |
| Robin_Watts | %END is what it is supposed to be looking for. | 18:42.50 |
| ray_laptop | ahh.. that's it then. The 8.54 gs_init.ps had %END _not_ %%END | 18:43.00 |
| Robin_Watts | Sorry? | 18:43.28 |
| | Currently all the ps files have %END in them. | 18:43.37 |
| | so we should be strcmping for %END, right ? | 18:43.52 |
| ray_laptop | Robin_Watts: sorry. that's right. so is the %END line making it into the smashed file ? | 18:44.23 |
| | (it looks like it should be) | 18:44.31 |
| Robin_Watts | it looks like it ought to be to me too. | 18:47.01 |
| | And Visual Studio dies. Joy. | 18:49.20 |
| | but it's not making it into the final file. | 18:52.13 |
| | In fact only 2 %ENDs are making it. | 18:52.35 |
| | actually... mkromfs says this is a 508777 byte smashed file. | 18:54.15 |
| | and the postscript output stuff that I got from kens is only dumping 34430 bytes. | 18:54.37 |
| ray_laptop | Robin_Watts: yeah, I see len=511164 32 blocks, compressed size=154778 | 18:55.44 |
| | the compressed size is about what I expect | 18:55.58 |
| Robin_Watts | yes, likewise. | 18:56.15 |
| ray_laptop | the compressed size of the existing Resource/Init/ files is about 317K | 18:56.34 |
| | actually the current compressed total is 371114 | 18:58.15 |
| ray_laptop | didn't recall correctly | 18:58.28 |
| | Robin_Watts: could be that mkromfs is counting wrong | 18:59.08 |
| Robin_Watts | Right. In the smashed file, I still get (gs_std_e.ps)dup runlibfile | 19:00.29 |
| ray_laptop | In the original, the total Resource/Init uncompressed files are 1,175,730 (compressed: 371,114) | 19:03.49 |
| | so 608777 is quite reasonable | 19:04.05 |
| | so 508777 is quite reasonable | 19:04.13 |
| Robin_Watts | Before your changes I was getting a total romsize of 7843404 | 19:04.34 |
| | With my changes, that dropped to 7643064. | 19:04.48 |
| | With your stuff in it should be about the same, and it is. | 19:05.11 |
| ray_laptop | Robin_Watts: the 'runlibfile' would be a problem, however | 19:06.56 |
| Robin_Watts | indeed. | 19:07.07 |
| ray_laptop | hmm... it has the %% Replace header | 19:08.06 |
| Robin_Watts | indeed. And I can see it stepping in. I really don't understand it. | 19:11.55 |
| ray_laptop | Robin_Watts: I added a debug statement... | 19:12.45 |
| Robin_Watts | OK. I added a printf in the wl function to dump the merged file, and it looks right to me. | 19:19.03 |
| | But gs won't start up. | 19:20.27 |
| | unless I start it as: | 19:20.32 |
| | gs/debug/bin/gswin32c.exe -I gs/Resource/Init | 19:20.45 |
| | so it uses the resources on disc. | 19:20.53 |
| | Then I drop in the bit of magic that kens gave me: | 19:21.02 |
| ray_laptop | well, a 'runlibfile' would need to have the -IResource/Init | 19:21.05 |
| Robin_Watts | "/InFile (%romesource/Init/gs_init.ps) (r) file def | 19:21.52 |
| | "/OutFile (out.txt) (w) file def | 19:21.54 |
| | "/Data 32768 string def | 19:21.55 |
| | "{ InFile Data readstring | 19:21.58 |
| | "{ OutFile exch writestring } | 19:21.59 |
| | "{ OutFile exch writestring exit } ifelse | 19:22.01 |
| | "} loop | 19:22.02 |
| | "InFile closefile | 19:22.04 |
| | "OutFile closefile | 19:22.05 |
| | And that still has the call to runlibfile in it. | 19:23.10 |
| | oh, I see the problem maybe. | 19:31.26 |
| | OK. I now have a build that has the real squashed file in it. | 19:39.38 |
| | Still doesn't start up. | 19:39.43 |
| | Silently exits unless I point -I at the disc based ones. | 19:40.01 |
| ray_laptop | Robin_Watts: does it still have the runlibfile ? | 19:42.12 |
| Robin_Watts | no. | 19:42.16 |
| | I had managed to get it building both versions of gs_init into the same rom. | 19:42.37 |
| ray_laptop | Robin_Watts: and you can try -dDEBUG to see the stages during init | 19:42.42 |
| Robin_Watts | The version that my code was crushing was coming in later, and hence overwriting your version. | 19:43.06 |
| | START 0 1474612 194494 1299496 19476 true 544 3 <0> | 19:43.29 |
| | GPL Ghostscript GIT PRERELEASE 9.04 (2011-03-30) | 19:43.51 |
| | Copyright (C) 2010 Artifex Software, Inc. All rights reserved. | 19:43.53 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 19:43.54 |
| | Total memory malloced = 3148874 bytes | 19:43.56 |
| | Peak memory malloced = 1557642 bytes | 19:43.57 |
| | 989 mallocs, 989 frees, 0 reallocs | 19:43.59 |
| | Average allocation size 3183 bytes | 19:44.00 |
| | And that's all she wrote. | 19:44.02 |
| | I have an idea... | 19:44.17 |
| ray_laptop | Robin_Watts: what about -ZI ??? | 19:45.25 |
| | note that only works with debug build | 19:46.42 |
| Robin_Watts | run{dup type/filetype ne{(r).systemvmfile}if | 19:53.02 |
| | It gets as far as that, but gets no further. got to go for dinner now. | 19:53.19 |
| | Will look more later/tomorrow. | 19:53.23 |
| ray_laptop | Robin_Watts: OK. I'm looking at mkromfs from the command line, just doing the -g options. I'm using the --b option so that it is uncompressed and am throwing together a 'dump' for it. | 19:54.20 |
| | OK, I've converted the mkromfs -g output to the resultant file and -ZI gives me some info | 20:05.32 |
| henrys | hey marcosw_ are you around? | 20:25.25 |
| marcosw_ | I am. | 20:25.33 |
| henrys | where can I look at the code for the overnight script instead of bugging you each time asking what is supported? | 20:25.59 |
| | in particular I was wondering about the pxlcolor, pxlmono devices? | 20:26.27 |
| marcosw_ | at the moment you can't. the overnight regression tests run on cluster machines that are in my house. | 20:27.57 |
| henrys | can we add pxlcolor if it isn't there already? | 20:28.39 |
| ray_laptop | marcosw_: can't you upload the overnight script somewhere ? | 20:28.42 |
| | just the script, not the files | 20:28.54 |
| | I meant not the files, just the script (sorry) | 20:29.12 |
| | does the script have to be confidential, or can it go into toolbin/something ? | 20:30.03 |
| marcosw_ | wait, I'm confused. is this the nightly code that sends out emails once a day or the nightly/weekly code that runs but only I see the results? | 20:30.19 |
| henrys | I didn't know there was a difference ;-) | 20:31.22 |
| | but now I see what goes on - the weekly I am interested in. | 20:32.29 |
| marcosw_ | the nightly regression that runs on my iMac and sends out the emails is pretty much the same regression code that we've been running for years and years. It's written in python. | 20:32.36 |
| | the weekly regression has the various options (such as 32 bit, debug build, luratech, etc). | 20:32.55 |
| henrys | yes right I see that now - I thought we did that and the weekly nightly but we don't. | 20:33.03 |
| marcosw_ | I have to run in about 2 minutes, but will upload the scripts to casper and send you the location. | 20:33.50 |
| henrys | thanks | 20:33.58 |
| | sigh we keep breaking x11, 692369 ... I wonder if we've messed up alpha generally | 20:36.05 |
| | with this bug | 20:36.23 |
| Robin_Watts | ray_laptop: Right. In the crushed file I have here, I've found some corrupted data. | 20:38.59 |
| ray_laptop | Robin_Watts: really ? I haven't found that yet | 20:39.34 |
| Robin_Watts | search for .printerror | 20:39.46 |
| ray_laptop | but it's hard to tell. | 20:39.48 |
| | Robin_Watts: yes, what about it. The definition /.printerror or a usage ? | 20:40.40 |
| Robin_Watts | I see: | 20:40.47 |
| | stop}bind def/.printerror{$error begin newerror{/commands | 20:41.03 |
| ray_laptop | (I see it in line 240 of the smashed file) | 20:41.07 |
| Robin_Watts | Then stop}bind def/.printerror{$error begin newerror{/command load errorname SHORTERRORS{(%%[ Er | 20:41.16 |
| | (miss the s off the top one of those). | 20:41.31 |
| ray_laptop | Robin_Watts: I have: stop}bind def/.printerror{$error begin newerror{/command load errorname SHORTERRORS{(%%[ Error: )print =only flush | 20:42.05 |
| Robin_Watts | So some data is repeated, some is missing. | 20:42.10 |
| | When your copy into a block is split over 2 blocks are you copying the same data twice? forgetting to increment ? | 20:42.43 |
| | Do you not need linebuf += move_len ? | 20:43.38 |
| | in flush_line_buf | 20:43.45 |
| | ah, well, that's a global, but you see what I mean. | 20:44.17 |
| ray_laptop | Robin_Watts: but in that area I see some corruption. The two lines I see are: | 20:45.10 |
| | $error/.inerror//false$err | 20:45.12 |
| | stop}bind def/.printerror{$error begin newerror{/command load errorname SHORTERRORS{(%%[ Error: )print =only flush | 20:45.13 |
| | -- the first line $error/.inerror//false$err looks wrong. | 20:45.15 |
| Robin_Watts | Aha! Now gs starts up. | 20:45.43 |
| | In flush_line_buf, add: | 20:46.07 |
| | int line_offset = 0; | 20:46.12 |
| | change the memcpy(curr_block_p, linebuf...) to be memcpy(curr_block_p, linebuf + line_offset...) | 20:46.43 |
| | add add line_offset += move_len; | 20:46.53 |
| | I now get: | 20:47.12 |
| | Warning: the map file FAPIfontmap was not found. | 20:47.26 |
| | Warning: the map file FAPIcidfmap was not found. | 20:47.28 |
| | oh, because I forgot to add them to the rom :) | 20:47.51 |
| mvrhel2 | argh! VS crash. Internal error.... | 20:47.54 |
| Robin_Watts | ray_laptop: I'm done for the night (leave on a positive note), but I'll polish this all off and get it committed on monday, | 20:48.34 |
| | or tomorrow, if I'm bored. | 20:48.42 |
| ray_laptop | Robin_Watts: OK. Well that should be in the MISC_INIT_FILES right ? | 20:48.48 |
| Robin_Watts | ray_laptop: Yes. It used to include the whole Init directory. | 20:49.09 |
| | and now I'll have to add those 2 files specifically. | 20:49.21 |
| ray_laptop | Robin_Watts: that's what ths MISC_INIT_FILES is for | 20:49.54 |
| Robin_Watts | yes, I appreciate that. | 20:50.19 |
| ray_laptop | Robin_Watts: are you going to commit the fix for mkromfs.c ? | 20:50.22 |
| Robin_Watts | will do. | 20:50.28 |
| | Unless you want to. | 20:50.35 |
| ray_laptop | Robin_Watts: no, that's fine. | 20:50.41 |
| Robin_Watts | I was pondering adding a new flag to mkromfs. | 20:50.51 |
| | -C | 20:50.53 |
| ray_laptop | what about the psromfs.mak change ? | 20:50.58 |
| | Robin_Watts: what would -C do ? | 20:51.08 |
| Robin_Watts | -C means 'compact the next file'. | 20:51.09 |
| ray_laptop | Robin_Watts: -c and -b allow control of compression | 20:51.31 |
| Robin_Watts | so when listing a postscript file, you'd say -C filename, rather than just the filename. | 20:51.34 |
| | No, this is compaction, not compression. | 20:51.41 |
| ray_laptop | oh, sorry | 20:52.00 |
| Robin_Watts | basically it'd save me having to 'guess' which files are postscript and which aren't. | 20:52.03 |
| ray_laptop | Robin_Watts: or -ps | 20:52.32 |
| Robin_Watts | so instead of saying CMAP1 CMAP2 CMAP3, we'd say: -C CMAP1 -C CMAP2 etc. | 20:52.35 |
| | or -ps. | 20:52.37 |
| | currently it's all 1 char options. | 20:52.45 |
| | actually, it might be better to do -C and -B to mirror -c and -b. | 20:53.33 |
| ray_laptop | true. but what about an on/off for compaction -C -B | 20:53.37 |
| | hey, I typed to slow | 20:53.46 |
| Robin_Watts | A good sign that we are thinking the same way :) | 20:54.03 |
| | I'll do that too. | 20:54.11 |
| ray_laptop | Robin_Watts: that would be fine with me | 20:54.23 |
| Robin_Watts | fab. I must go be sociable now, or I'll be shot... | 20:54.26 |
| ray_laptop | Robin_Watts: np. Have a good weekend | 20:54.40 |
| Robin_Watts | you too. | 20:54.49 |
| ray_laptop | thanks. I hope so | 20:54.57 |
| mvrhel2 | bye Robin_Watts | 20:55.46 |
| | ok. finally cluster pushing this gray to k fix | 21:26.41 |
| | bbiab | 21:26.44 |
| | I still don't understand why we create a pdfwrite device when we are going out for example to a tiff24nc device | 21:28.11 |
| | we create it and clean it all up at the end | 21:28.39 |
| henrys | mvrhel2:I'll bring that up at the meeting last time I brought it up I didn't like the answer so I don't remember it... | 22:14.54 |
| mvrhel2 | henrys: ok great | 23:06.34 |
| | ok. at the bmcmp stage for the gray to K fix | 23:07.54 |
| | going to do a spot check. it looks like the diffs are only in the cmyk output devices as expected | 23:08.20 |
| | bbiab. sun is finally out here... | 23:11.03 |
| | need to clean up the bear scat on the playground. Apparently the bear has a "regular" schedule that includes our yard | 23:11.50 |
| Robin_Watts | mvrhel2: You can buy Lion poo to put on your garden. Scares cats away. | 23:13.55 |
| | I wonder what scares bears... | 23:14.03 |
| mvrhel2 | good question | 23:14.07 |
| | I hope noisy kids | 23:14.15 |
| | it is late there. time for bed | 23:15.21 |
| | bbiab | 23:15.48 |
| Robin_Watts | 7184280bytes, down from 7943404. | 23:44.26 |
| | 7843404. 640K saving though. | 23:50.23 |
| mvrhel2 | longest bmpcmp ever... | 23:50.51 |
| | only 7792 files. doesnt it limit the number? | 23:51.26 |
| Robin_Watts | to just 1000, yes. | 23:51.44 |
| mvrhel2 | ok | 23:51.47 |
| Robin_Watts | Your bmpcmp aborted though. | 23:52.00 |
| mvrhel2 | I guess 1000 takes a bit of time | 23:52.02 |
| | huh? | 23:52.05 |
| | why | 23:52.07 |
| Robin_Watts | It said "aborted" on the dashboard a moment ago. | 23:52.23 |
| mvrhel2 | hmm. it says running to me | 23:52.37 |
| Robin_Watts | maybe it's just glitching... | 23:52.37 |
| mvrhel2 | of course it has said running for a while | 23:52.53 |
| Robin_Watts | now all the machines say idle, and it says "finished" at the top. | 23:52.54 |
| mvrhel2 | and everything is idle | 23:53.00 |
| Robin_Watts | The last bit of processing is done on casper. | 23:53.11 |
| mvrhel2 | ok | 23:53.15 |
| Robin_Watts | (the actual production of the bmpcmp images from the whole images, and the html pages etc) | 23:53.32 |
| | so this is normal | 23:53.38 |
| | Forward 1 day (to 2011/07/23)>>> | |
IRC Logs