| | <<<Back 1 day (to 2012/03/07) | 2012/03/08 |
| mvrhel | for the logs, as I push forward with my fix for the tiffsep device and am implementing read and write of my new color type into the clist just stumbled across this interesting bit of coding, the gx_device_color_saved_s type. what surprised me was to find an equivalent but different type than gx_device_color | 06:23.12 |
| | marcos: I am making good progress on this if you want to let the customer know. It is still going to take a few weeks I am sure but not much more than that | 06:24.18 |
| | marcosw^ | 06:24.37 |
| | after stumbling across this, I am done for the night... | 06:25.59 |
| kens | chrisl ping | 08:42.15 |
| chrisl | kens: pong | 08:42.28 |
| kens | If the memory being watched by a memory watchpoitn changes, should ddd/gdb break execution of the target ? | 08:42.54 |
| chrisl | It should, yes | 08:43.04 |
| kens | Hmmm... | 08:43.11 |
| | Didn't for me yesterday. | 08:43.17 |
| | And since it took 6 hours to get there, I'm not keen on repeating it :-( | 08:43.33 |
| chrisl | It could be a problem with soft-watchpoints - I never use them, for obvious reasons | 08:44.05 |
| kens | Like 6 hours to get them to trigger ;-) | 08:44.25 |
| | I may be forced to ask for some help with this one. | 08:44.36 |
| chrisl | yep...... | 08:44.39 |
| kens | I'm going to try a different approach this morning. If that fails I'll need someone to reproduce it with hardware that works. | 08:45.21 |
| chrisl | I'm still not able to reproduce it, but I'll have another try later on | 08:45.56 |
| kens | Id be grateful, otherwise I'll post to tech and ask other people. | 08:46.16 |
| chrisl | I'm assuming that even though my Windows laptop would go wrong, it probably won't in the debugger | 08:47.02 |
| kens | It wouldn't for me, the debug build failed, but under a debugger it worked. | 08:47.18 |
| | Memento builds work for me on both Windows and Linux | 08:47.37 |
| chrisl | There's no avoiding how much memento will change the memory layout | 08:48.07 |
| kens | Exactly, and even small changes seem to disrupt this one. | 08:48.28 |
| | Not too surprisingly | 08:48.35 |
| | OK hte problem is caused by an interp_reclaim | 09:23.21 |
| | So its garbage collection | 09:23.33 |
| chrisl | I'd be a little surprised if that's the cause - more likely, something is holding a reference to the string without telling the garbage collector about it | 09:24.22 |
| kens | The name table I guess | 09:24.33 |
| chrisl | The name table *must* be known to the garbage collector, otherwise we'd be having problems all over the place....... | 09:25.27 |
| kens | The code which sets the colour space converts the string Separation name into a name object, and then lodges it in the name table. Therer doesn't seem to be anything that prevents it being reloctaed, or tells the GC that the name is used by the name table | 09:25.35 |
| | Of course, I am *way* out of y comfort zone now. | 09:25.56 |
| | Ah, memory is Ray's bailiwick, I don't think I can burden him with this at the moment. | 09:26.57 |
| chrisl | Can you find out the VM mode when the color space is being set? | 09:27.15 |
| kens | I'll have to modify the PS file, which probably means it will stop failing, but I'll give it a go. | 09:27.54 |
| | I strongly suspect its local VM | 09:28.01 |
| | Oh dear, that idiot is back with his dumb questions | 09:29.48 |
| chrisl | Yep, I'm going to ignore him.... | 09:30.03 |
| kens | Me too :-) | 09:30.09 |
| chrisl | Well, the name table "object" is known to the garbage collector | 09:32.10 |
| kens | But that doesn't cover the strings contained in the table, does it ? | 09:32.50 |
| chrisl | Yes - see line 607 in iname.c | 09:33.40 |
| kens | I'll take your word for it... | 09:34.05 |
| | VM allocation mode is local for all occurences of setcolorspace | 09:40.32 |
| chrisl | And I expect changing it to global will move things around too much to know if it's helped or not :-( | 09:42.20 |
| kens | Undoubtedly. | 09:42.30 |
| | It would mean significantly changig the PostScript file too, you wouldn't believe how complex the proedure it uses for images is. | 09:43.07 |
| chrisl | I would probably be easier to just move the string into global in the C code, then - but still, we wouldn't have a worthwhile "result" | 09:44.53 |
| kens | That solution worries me. | 09:45.11 |
| | THere is obviously a GC problem, and we haven't fixed it, which just means it'll bite us again later | 09:45.33 |
| | But I may have reached as far as I can go, especially since I have to debug in such an unfamiliar environment. | 09:46.15 |
| chrisl | Oh, you are using 32 bit Linux, aren't you? | 09:46.26 |
| kens | Yes. | 09:46.32 |
| | Its a 32-bit host OS, I know that isn't supposed to matter, but.... | 09:46.48 |
| | Oh, oh.... | 09:47.14 |
| | Its just stopped failing for me.... | 09:47.21 |
| chrisl | Damn, I don't think I have a 32 bit hardware setup for Linux - I wonder how much I have to setup up to build and run a 32 bit exe on a 64 bit OS.... | 09:47.34 |
| kens | I wonder if that would even fail. | 09:48.24 |
| chrisl | Well, the runtime environment should be exactly the same as running on a 32 bit OS, so..... | 09:48.53 |
| kens | OK its still failing, I was looking at the wrong memory.... | 09:50.00 |
| chrisl | Well, that's something | 09:50.17 |
| kens | By sheer coincidence it was pointing at the same place. | 09:50.37 |
| chrisl | kens: can you remind me the name of the test job for this problem? | 09:54.12 |
| kens | Mine is called test.ps :-) | 09:54.23 |
| | JN_19299.ps | 09:54.34 |
| chrisl | Damn, the command line has dropped out of my history..... | 09:55.10 |
| kens | For me it fails with a simepl 'gs -sDEVICE=pdfwrite...' | 09:55.29 |
| | But the command is in bug #692884 | 09:55.47 |
| chrisl | Ooh, 32 bit exe gives me an empty sep name - now to try in the debugger | 09:57.44 |
| kens | That's encouraging. | 09:57.57 |
| | Do you want some breakpoitns to set ? | 09:58.06 |
| chrisl | I think I'm going to get a coffee first! | 09:58.46 |
| kens | Good idea, I could use some too, brb | 09:58.56 |
| chrisl | Back..... | 10:09.21 |
| kens | akready here :-) | 10:09.28 |
| chrisl | I forgot I had to empty the washing machine | 10:10.07 |
| kens | Nice day for it... | 10:10.16 |
| chrisl | At this time of year, my back garden is mostly in the shade! | 10:10.46 |
| kens | Oh, ours gets the sun. that's the side the solar water heater is. | 10:11.14 |
| chrisl | The front of my house gets the sun, which is where my office is - which is why my office is sometimes rather sauna-like! | 10:11.56 |
| kens | My office is at the back, so it gets the morning sun, but not the afternoon | 10:12.35 |
| chrisl | When you get the empty name, is the name length also 0? | 10:14.36 |
| kens | yes | 10:14.41 |
| | Oh that's unexpected... | 10:16.08 |
| | OK not unexpectedly the routine which changes the memory is 'names_trace_finish' | 10:16.40 |
| | called from gs_gc_reclaim | 10:17.02 |
| chrisl | Right, but is the name still there? | 10:17.40 |
| kens | Before it is called, yes, afterwards no | 10:17.53 |
| | Now I have to g rouund teh loop again | 10:18.08 |
| chrisl | kens: do you happen to know which subtable the relevant name is in? | 10:22.50 |
| kens | OK so it finds the relevant name in the table. nidx == 514 (for me) and the string data is correct. | 10:22.53 |
| | chrisl if you can tell me how to know the subtable, I'll tell you :-) | 10:23.14 |
| chrisl | kens: doesn't matter then, I can find it | 10:23.38 |
| kens | Currently I'm debugging like this: | 10:23.40 |
| | set a breakpoint in setsaeparationspace, ignore count =16 | 10:23.52 |
| | Follow into the name creation, find the memory address of the string, set a 'display' on that memory | 10:24.19 |
| | Set a breakpoint on gs_gc_reclaim | 10:24.37 |
| | continue to next breakpoint | 10:24.45 |
| | I'm currently walking the loop in names_trace_finish | 10:25.08 |
| | OK hte name has no 'mark', so it is removed, that's the problem. | 10:25.59 |
| chrisl | Oh, that is bad! | 10:26.23 |
| kens | The 'mark' phase precedes this. | 10:26.42 |
| | I'm assuming the name should be marked | 10:26.49 |
| | I wonder if the colour space code should do it, but this is beyond me, I'm flailing at the moment | 10:27.15 |
| chrisl | No, the gc should mark memory it can find. | 10:27.37 |
| kens | Well I'm stumped then. | 10:27.49 |
| | Looking at the structure, mark is 0 at this point, so it really isn't marked | 10:28.19 |
| | But the string bytes pointer is OK and so is the size. | 10:28.30 |
| kens | restarts the application, again..... | 10:29.11 |
| chrisl | I'm confused - if you look at the bottom of iname.c, it has a RELOC_PTRS function for name *sub*-tables, but the ENUM_PTRS is emtpy - doesn't seem right | 10:30.21 |
| kens | wait one. | 10:30.31 |
| | Yes, that's odd. | 10:31.24 |
| | Maybe it never eneds to enumerate them ? | 10:31.33 |
| chrisl | It's the ENUM_PTRS function that tells the gc memory should be marked as "used" | 10:31.54 |
| kens | Which suggests that name sub tables would never be marked, that can't be right | 10:32.24 |
| | We'd know :-) | 10:32.33 |
| | Don't forget tehre seems to be a special mark function for the name table | 10:32.48 |
| chrisl | Yes, where does that get called from? | 10:33.24 |
| kens | Give me a minute, need to debug back to that point | 10:33.40 |
| | Now I'm confused. | 10:34.23 |
| | Its all in gs_gc_reclaim, but I can't see where it marks the name table | 10:34.41 |
| | However its 'names_trace_finish' which removes the name | 10:35.12 |
| chrisl | No, I see where it *sweeps*, but not marks...... | 10:35.13 |
| | Oh, hang on - is it possible the color space POstscript object has been restored away? | 10:37.07 |
| kens | I don't believe so. | 10:37.19 |
| | When we get to the PDF image handler, the colorspace is still valid | 10:37.37 |
| | Only the name is blown aeay | 10:37.44 |
| | It is drawing a /Separation image, so the color space should still be OK. | 10:38.00 |
| | I could check by setting restore breakpoints I guess. | 10:38.18 |
| | But if the color space was restoreed away, the PostScript should not work properly anyway | 10:38.52 |
| chrisl | The color space, yes, but that's an "internal object", I don't believe GS keeps a link between the PS object and the internal color space. | 10:38.59 |
| kens | I think it does :-) | 10:39.13 |
| | Because that's what 'currentcolorspace' returns isn't it ? | 10:39.25 |
| | (maybe not) | 10:39.44 |
| chrisl | The thing is, a name table reference isn't a "markable " reference - the name needs to be in use somewhere, otherwise it will be removed from the table | 10:40.24 |
| kens | I was just coming to that conclusion | 10:40.41 |
| | All memory is check, and if the name/string is in use 'somewhere' then it gets marked, and not removed form the name table. | 10:41.12 |
| | I think. | 10:41.21 |
| | Which suggests the name/string is no longer in use anywhere, and I'm reasonably sure it should be. | 10:41.46 |
| | I'll set breakpoints on restore and friends and see. | 10:42.09 |
| | round we go again.... | 10:42.14 |
| chrisl | Yes, so the name needs to be reference from a dictionary or a stack (or from an internal structure), otherwise it won't get marked. | 10:42.15 |
| kens | yes. | 10:42.24 |
| | OK breakpoints set on zrestore and zgrestore | 10:43.44 |
| | And it gets into the recalim without hitting either | 10:44.08 |
| | So the PostScript is not restoreing the color space away | 10:44.28 |
| chrisl | Of course, it needn't be a restore, it could simply be that it's reference gets overwritten in a dictionary, or popped off the stack | 10:45.02 |
| kens | It certainly leaves the stack | 10:46.19 |
| | So maybe the problem is that it should be referenced from the internal structure. | 10:46.37 |
| chrisl | Oh god, the color space structure definition is a freakin' nightmare! | 10:47.17 |
| kens | Certainly is. | 10:47.24 |
| | I never undertood it properly, I just copied most of the code dealing with it from the older code. | 10:47.44 |
| Samae | Anyone from mupdf ? | 10:49.37 |
| kens | Almost certainly | 10:49.53 |
| Samae | I'd like to know how to relate window width and resolution | 10:50.08 |
| | in the source | 10:50.12 |
| kens | You will have to explain more, there is no obvious relationship thre. | 10:50.40 |
| Samae | right | 10:50.58 |
| | I want to modify the zoom so that my pdf page fits the width of the window | 10:52.04 |
| kens | I thought there was a way to do that already. Robin_Watts ? | 10:52.26 |
| Samae | for that I have to change app->resolution to some value | 10:52.41 |
| kens | Obviously its the PDF page width divided by the window size. | 10:53.20 |
| Robin_Watts | To be fair, I felt his latest question was much less idiotic. | 10:53.47 |
| kens | Robin_Watts : its an improvement, certainly | 10:54.02 |
| Robin_Watts | OOh, I'd missed all this cos I was scrollbacked. Sorry Samae, wasn't talking about you! | 10:54.21 |
| kens | But 'why does PS->PDF /PDF->PS conversion take longer /@ is a dim question | 10:54.23 |
| Samae | Robin_Watts: right :) | 10:54.32 |
| kens | knew that.... | 10:54.33 |
| Robin_Watts | Samae: Are you using the viewer, or are you writing your own code? | 10:55.49 |
| Samae | kens: I just have to find a way to access pdf page width then :) | 10:55.54 |
| kens | Samae : I'm sure Robin can help you | 10:56.08 |
| Samae | Robin_Watts: I'm messing with the source | 10:56.09 |
| | of mupdf (apps/pdfapp.c) | 10:56.19 |
| chrisl | kens: You probably need to look at adding to ENUM_PTRS_BEGIN_PROC(color_space_enum_ptrs) in base/gscspace.c | 10:56.27 |
| kens | chrisl I was looking at that. | 10:56.38 |
| | In some confusion | 10:56.44 |
| Robin_Watts | kens: I read his question as being related to the speed difference between 8.71 and 9.05 with -dUseFastColor. | 10:57.00 |
| | And 9.05 does indeed appear to be much slower. | 10:57.14 |
| kens | And teh answer is 'because it works now' | 10:57.16 |
| Robin_Watts | Well, that's an easy answer to give him back :) | 10:57.32 |
| kens | I also am doubtful about his resutls, 9 should generally be faster than 8 | 10:57.35 |
| | Of course, he isn't testing many files, or particularly different ones I think | 10:57.56 |
| chrisl | Well, color managing *every* color is going to be a bit slower than color managing almost no colors...... | 10:58.13 |
| kens | So he may just have hit a case where it is slower, because it works properly now and didn't before (even if he didn't see it) | 10:58.17 |
| Robin_Watts | chrisl: -dUseFastColor... | 10:58.38 |
| chrisl | Oh, I thought you meant without that | 10:59.01 |
| Robin_Watts | chrisl: his figures are all for with using -dUseFastColor. | 10:59.27 |
| | We should ask for his test files. | 10:59.36 |
| kens | Indeed. | 10:59.37 |
| Robin_Watts | Samae: OK, so with mupdf, you get the fz_page * for the page contents. | 11:00.18 |
| | Then you ask to 'bound' this, to get a rectangle. | 11:00.33 |
| chrisl | I didn't read it that carefully - "tell me how Ghostscript works" type questions don't merit much attention, IMHO | 11:00.44 |
| Robin_Watts | That gives you the bounding rectangle in points. | 11:01.12 |
| | points being 1/72 of an inch. | 11:01.19 |
| | When you come to render the page, you supply a transform to the rendering function that scales the page from points to pixels. | 11:01.55 |
| | Hence if the width of the bounding rectangle is w_points, and you want it to be w_pixels, then you use a transform with the top left entry of 72*w_pixels/w_points. | 11:03.07 |
| chrisl | kens: I think you're going to have to add a ref (ptr?) at least to the gs_separation_params_s | 11:06.01 |
| kens | chrisl I am looking into it, DeviceN will have to change too | 11:06.19 |
| Samae | Robin_Watts: ook | 11:06.53 |
| chrisl | kens: yes - I wonder why it uses the gs_separation_name thing instead of just ref ptrs....... | 11:07.50 |
| kens | Well, this is historical code in some places, and as I sadi, I didn't understand nay of this too well when I rewrote it into C | 11:08.27 |
| chrisl | I assumed these structures hadn't changed with that work, given that this is graphics lib stuff. | 11:09.08 |
| kens | I don't think htey did, no, but its possible that the old way of working maintained a reference to the string data, and I didn't realise | 11:09.31 |
| Samae | Robin_Watts: the window width in pixel is available, so it is just a matter of adjusting the resolution to make the rectangle width = to the window width, right ? | 11:09.34 |
| kens | Because it was in PostScript | 11:09.40 |
| chrisl | Yes, true. I suppose using the index keeps it language agnostic, too | 11:10.14 |
| kens | I'm going to have to go and think about this some, its been too long since I did anything with the GC. | 11:10.45 |
| chrisl | kens: actually, maybe the best way to do this is to add a second function pointer, and implement a "gs_get_colorname_ref" function - then the ENUM_PTRS can use that to retrieve the ref memory for the garbage collector | 11:14.29 |
| kens | Lost me there chrisl, I'm not that familiar with this stuff any more. | 11:14.54 |
| chrisl | So, at the moment there is function pointer in there which gets the C string for the color name, yes? | 11:15.34 |
| kens | Umm not that I was aware of, which is why its uses the name lookup | 11:16.21 |
| chrisl | gs_get_colorname_string | 11:16.35 |
| kens | This is in the color strcuture ? | 11:16.56 |
| chrisl | yes: pcs->params.separation.get_colorname_string = gs_get_colorname_string; line 3452 in zcolor.c | 11:17.25 |
| kens | Oh yes, I was thinking of the other way around. We always convert string parameters into names | 11:18.12 |
| chrisl | Right, so gs_get_colorname_string() looks up an index in the name table, gets a name ref, converts that to a string ref and extracts the length and "bytes" to return to the caller | 11:19.07 |
| kens | OK | 11:19.15 |
| kens | is still grepping for the source to that | 11:19.34 |
| chrisl | It's in psi/zht2.c | 11:19.56 |
| | Line 45 | 11:20.05 |
| kens | OK got it | 11:20.20 |
| | THis all looks like stuff I copied originally. | 11:20.42 |
| chrisl | So, what I'm thinking is you implement something similar which just retrieves a pointer to the name in the name table. Then the ENUM_PTRS, when appropriate call that, and return the ref ptr for marking. | 11:21.32 |
| kens | Makes sense I htink, I'll start looking into it. | 11:21.54 |
| chrisl | So, names_index_ptr looks like something you need to know about......... | 11:25.21 |
| kens | You're a long way ahead of me I think. | 11:25.45 |
| chrisl | Oh, actually, name_index_ptr() | 11:25.50 |
| | kens: I spoke with forked tongue there, you need names_index_string_inline() | 11:32.31 |
| kens | I'm trying to figure out how to handle DeviceN, which can return an unknown number of ink names | 11:33.15 |
| chrisl | But you know *in* the DeviceN part of the color space how many inks there are? | 11:34.05 |
| kens | I suppose so, I'll have to check | 11:34.19 |
| chrisl | gs_device_n_params->num_components | 11:34.46 |
| kens | But it looks like ENUM_PTRS gets called repeatedly with different values of index. | 11:34.54 |
| | I suppose if index > inks I just return 0 | 11:35.15 |
| | inks + number of other ptrs that is | 11:35.33 |
| chrisl | In theory, yes. In practice the color space ENUM_PTRS has a final ENUM_USING(*pcs->type->stype, vptr, size, index - 3) | 11:36.00 |
| kens | OK so fall through if index > inks etc then. | 11:36.25 |
| chrisl | Yes | 11:36.30 |
| kens | and subtract inks +3 instead of 3 I suppose | 11:36.45 |
| chrisl | Yes | 11:37.06 |
| kens | Icky horrible stuff | 11:37.14 |
| chrisl | There's plenty of worse code around! | 11:37.46 |
| kens | I just hate making it worse.... | 11:38.07 |
| | Of course, after I make this change, it almost certainly won't be possible to reproduce the problem anyway :-) | 11:38.50 |
| chrisl | Well, if you want a quick hack, with minimal impact, there is a names_mark_index() function | 11:39.32 |
| kens | I'll try and do it properly. I could manually mark teh name in the debugger, which would have teh same effect, and prove it works. I'm sure it will. | 11:40.16 |
| chrisl | kens: well, yell if you need sanity check or whatever | 11:42.49 |
| kens | I might, let me whack on it with a hammer for a bit. | 11:43.06 |
| chrisl | Oh, b*gger, cust 532 again..... | 11:53.54 |
| kens | wonders if its their own substitution code again :-) | 11:55.47 |
| chrisl | I will not be terribly happy if that is the case | 11:57.24 |
| kens | chrisl? | 12:04.01 |
| | chrisl ping | 12:13.56 |
| chrisl | kens: here (sorry, using laptop...) | 12:16.15 |
| kens | I have a problem | 12:16.22 |
| | The colour space has no 'mem' pointer and I need that to get the name table | 12:16.34 |
| | To retrieve the string | 12:16.39 |
| | I think my only alternative si to add 'mem' to the colour space structure | 12:16.53 |
| | Which kind of makes sense if its going to reference names/strings | 12:17.05 |
| | Unless you know differently ? | 12:17.12 |
| chrisl | I'm surprised the colour space doesn't have a mem ptr somewhere..... | 12:18.00 |
| kens | If it does, I can't find it. | 12:18.09 |
| chrisl | In rc | 12:18.57 |
| kens | Theres one in pcs->rc->memory | 12:18.59 |
| | :-) | 12:19.06 |
| | OK I'll use that. | 12:19.11 |
| chrisl | Snap! | 12:19.14 |
| kens | Bit deeper than I expected to see it | 12:19.25 |
| chrisl | Me too, but since various of the methods in "type" do stuff that'll need memory, I figured it must be there somewhere! | 12:20.08 |
| kens | Yeah I was puzzled.... | 12:20.27 |
| chrisl | Possibly when rc memory was added whoever did it thought it pointless have two mem pointers - it would be oddly sensible to make that kind of decision! | 12:21.42 |
| kens | Grr, can't include inamedef.h in gscspace.c | 12:21.46 |
| | inamedef.h is in psi, gscspace is in base.... | 12:22.29 |
| chrisl | Yeh, I think you're need to use some opaque pointer in tehre | 12:22.42 |
| kens | A pointer to somethign that just uses the macro I assume you mean. | 12:23.29 |
| chrisl | Oh, I thought you were adding a function pointer like for the name string? | 12:24.07 |
| kens | At the moment, no, was trying to do it all in the ENUM_PTRS function | 12:24.30 |
| | Going to have to though I think. | 12:24.41 |
| chrisl | No, I don't think that'll work, for the same reason the function pointer is needed to retrieve the string | 12:25.23 |
| kens | hates all this crap | 12:26.13 |
| | chrisl why can't I just sue the existing get_colorname_string ? It seems to reurn a pointer to the string data in the name table. | 12:32.30 |
| chrisl | Because you need a pointer to string ref, not just the bytes and length | 12:33.06 |
| kens | Umm, I wish I understood this stuuf. OK | 12:33.34 |
| chrisl | kens: actually, that may not be true. You might be able to use ENUM_STRING2 to return just the bytes and the length. | 12:39.42 |
| kens | Too late, I'm most of the way through the other appraoch | 12:40.03 |
| chrisl | Oh, sorry | 12:40.23 |
| kens | I may back it out, now gscspace.h doesn't know about ref | 12:41.01 |
| | I'm going to have lunch this is the part of working with the GS code I hate most | 12:41.44 |
| chrisl | Well, ENUM_STRNG2 looks easy to do: ENUM_STRING2(string_bytes, string_size) | 12:41.56 |
| kens | right, I'll back out and retry, thanks. | 13:03.33 |
| | <sigh> That causes a GP fault relocating the separation pointers | 13:15.09 |
| | Loks like ENUM_USING should already be enumerating the separation/DeviceN names, and I think it is not. | 13:17.37 |
| | Aha, I think I see, there is code in gscsepr.c which returns the 'map'. I think it also needs to enumerate the string. Or something like aht | 13:21.17 |
| | chrisl you still there ? | 13:22.19 |
| Robin_Watts | kens: where ? | 13:25.50 |
| kens | here | 13:25.58 |
| Robin_Watts | I have had to look at garbage collection a bit before, dunno if I can help? | 13:27.10 |
| kens | Possibly, I'll take any help I can get. | 13:27.21 |
| Robin_Watts | I can't see any ENUM_USINGs in gscsep.c | 13:27.33 |
| kens | You'll need to look at gscspaces.c and gscsepr.c | 13:27.34 |
| Robin_Watts | gscspace.c ? | 13:27.58 |
| kens | yes, that one... | 13:28.06 |
| | The ENUM_USING is in gscspace.c | 13:28.15 |
| Robin_Watts | I see it. | 13:28.25 |
| kens | ABout line 841 | 13:28.28 |
| | THat uses the code in gscsepr.c | 13:28.36 |
| | At about line 67 | 13:28.49 |
| Robin_Watts | So is there something in gs_color_space that isn't being enumerated/relocated ? | 13:28.50 |
| kens | Yes. | 13:28.54 |
| Robin_Watts | What? | 13:28.58 |
| kens | The ink name | 13:28.59 |
| | I was trying to enumerate it in gscspace.c, I now think it should be done in gscsepr.c | 13:29.19 |
| | And teh equivalent DeviceN code. | 13:29.28 |
| | But I'm lost in the usual macro hell of trying to figure out what the code in gscsepr.c is actually doing. | 13:29.54 |
| Robin_Watts | The ink name being part of gs_separation_params ? | 13:30.00 |
| kens | Its referenced from there, but stored in the name table. The problem is that unless gscsepr.c says its using it, the garbage collector clears it fro mteh name table. | 13:30.33 |
| Robin_Watts | Right. | 13:30.41 |
| kens | So I need 'somewhere' to say its in use. | 13:30.53 |
| | Somewhere being in the colour space code, obviously | 13:31.06 |
| | What I don't understand is wht the f... rthe ENUM_* stuff does. | 13:31.24 |
| Robin_Watts | So, the enumeration code in gscspace.c says "0,1,2 are mine, and are relocated like this." | 13:31.24 |
| kens | Yes. | 13:31.32 |
| | THen it calls code specific to each kind of space | 13:31.41 |
| | 'ENUM_USING' | 13:31.49 |
| | Or so I believe | 13:31.58 |
| Robin_Watts | "to enumerate 3 upwards, use ..." | 13:32.00 |
| | yes. | 13:32.03 |
| | So I agree that you need to be looking at the pcs->type->stype entry for separations. | 13:32.22 |
| kens | Which is in gscsepr.c: | 13:32.35 |
| | static | 13:32.35 |
| | ENUM_PTRS_BEGIN(cs_Separation_enum_ptrs) return 0; | 13:32.35 |
| | ENUM_PTR(0, gs_color_space, params.separation.map); | 13:32.35 |
| | ENUM_PTRS_END | 13:32.35 |
| | static RELOC_PTRS_BEGIN(cs_Separation_reloc_ptrs) | 13:32.35 |
| | { | 13:32.35 |
| | RELOC_PTR(gs_color_space, params.separation.map); | 13:32.36 |
| | } | 13:32.36 |
| | RELOC_PTRS_END | 13:32.37 |
| Robin_Watts | Right. | 13:32.41 |
| | So you need an ENUM_something for sep_name | 13:32.54 |
| kens | ENUM_STRING2 | 13:33.04 |
| | But where do I put it ? | 13:33.09 |
| | Also, I need some local variables | 13:33.21 |
| Robin_Watts | line 69 | 13:33.22 |
| | just before the ENUM_PTRS_END | 13:33.35 |
| kens | Can I use local variables there ? | 13:33.51 |
| Robin_Watts | What are you hoping to add ? | 13:34.08 |
| kens | I need a char * and an int | 13:34.20 |
| | To retrieve teh name from the table | 13:34.29 |
| Robin_Watts | ENUM_PTRS_BEGIN just sets up a function and a switch I believe. | 13:34.51 |
| | Let me check that. | 13:34.53 |
| | so you can do: | 13:35.09 |
| | case 1: | 13:35.12 |
| | { char *tmp; int i; return ...; } | 13:35.34 |
| kens | OK so default is the first case | 13:35.36 |
| Robin_Watts | return 0 is the first case. | 13:35.45 |
| kens | Right, as long as its in braces, it should be OK | 13:35.48 |
| Robin_Watts | see the end of the ENUM_PTRS_BEGIN line? that's the default. | 13:36.06 |
| kens | Lets see if ti will comp[ile | 13:36.18 |
| Robin_Watts | There must be code elsewhere to cope with enumerating names. | 13:36.52 |
| kens | Nope. | 13:37.04 |
| | I'll need to add the same code for relocating pointers of course. | 13:37.39 |
| | Well, it compiles.... | 13:38.12 |
| | And didn't crash, that's a plus | 13:38.51 |
| Robin_Watts | kens: Are you aware of anywhere else in the code that has a name represented by a long in the same way ? | 13:39.54 |
| | Can we look at it's gc code to compare ? | 13:40.03 |
| kens | Yes, the DeviceN code | 13:40.06 |
| | Oh, you mean totally different code, no. | 13:40.16 |
| | Pointing at names is a bit odd, I can't think of any PostScript code offhand that does it, outside of colour spaces. | 13:40.57 |
| | Mostly its stored in dictionaires and arrays and stuff | 13:41.24 |
| Robin_Watts | gs_device_n_params_s has a gs_separation_name *names | 13:41.24 |
| | where we have a gs_separation_name sep_name | 13:41.35 |
| kens | Yeah, but it will have the same problem | 13:41.36 |
| | I don't believe it tracks the naems properly either | 13:41.58 |
| Robin_Watts | I was hoping you knew somewhere that did this that wasn't broken :) | 13:42.01 |
| kens | Hencce, my later 'no' above ;-) | 13:42.12 |
| Robin_Watts | Ah :) | 13:42.19 |
| | Random thought; do we NEED to keep the name pointer? | 13:42.45 |
| kens | Yes. | 13:42.50 |
| | pdfwrite needs it and so does currentcolorspace | 13:43.03 |
| Robin_Watts | Can't we just keep the name itself (i.e. a block of chars)? | 13:43.22 |
| kens | Its an entry in the name table, and that's what's there. | 13:43.40 |
| | We convert the string parameter to setcolorspace to a name and store it in the name table. | 13:43.53 |
| Robin_Watts | And we need to do that because... postscript needs to get it back as something in the name table ? | 13:44.31 |
| | The garbage collector works by mark and sweep. | 13:45.04 |
| kens | Postscritp needs to retrieve a name or string in order to fill in the array used by curretncolorspace. devices need to know ink names for separation production etc. We need to know which named spearation this is marking and so on | 13:45.21 |
| Robin_Watts | It runs through all the pointers it can find marking the ones it knows about. | 13:45.34 |
| kens | Yes, see my discussion with chrisl this morning | 13:45.45 |
| Robin_Watts | Presumably one part of the marking phase must be marking the names it knows about. | 13:45.52 |
| kens | Exactly. There are no outstanding references to the name, so it gets freed. | 13:46.08 |
| Robin_Watts | There is presumably a specific function to be called to mark a name. | 13:46.09 |
| | and that is what we should be calling in the enumeration part. | 13:46.31 |
| kens | If 'global' is true hten the code first unmarks all the names | 13:46.33 |
| Robin_Watts | I fear we can't just mark it as as normal pointer. | 13:46.49 |
| kens | Then walks memory looking for references to the names, and marking any it finds. | 13:46.51 |
| Robin_Watts | Where is that code ? | 13:47.03 |
| kens | gs_gc_reclaim I thnk | 13:47.18 |
| | basically, the colour space internal struct needs to declare that it uses the name I believe. | 13:47.49 |
| Robin_Watts | names_mark_index looks like the puppy. | 13:49.49 |
| kens | Yes. | 13:49.58 |
| | But I think that we can't call it ourselves (I could be wrong) | 13:50.14 |
| Robin_Watts | That's what you were planning to call in the enumerate phase ? | 13:50.14 |
| kens | No. | 13:50.18 |
| Robin_Watts | SO how were you planning to get it called ? | 13:50.25 |
| kens | I was just going to return the pointer to the string in the name table | 13:50.31 |
| Robin_Watts | Can't do that. | 13:50.38 |
| | I'm sure that will give problems. | 13:50.45 |
| kens | Why ? | 13:50.45 |
| | Still, why ? | 13:51.12 |
| Robin_Watts | because pointers are assumed to be pointers to allocated blocks, I believe. | 13:51.12 |
| kens | Hmm.... | 13:51.25 |
| kens | hates this whole GC crap even more than before | 13:51.37 |
| Robin_Watts | Why can't we call names_mark_index ? | 13:51.56 |
| kens | Why do you think that will work ? | 13:52.05 |
| | I'm not saying it won;t mind | 13:52.17 |
| Robin_Watts | That sounds like the most plausible thing to do. | 13:52.31 |
| | s/do/me/ | 13:52.36 |
| kens | It all sounds like bollocks frankly | 13:52.43 |
| | We shoudl throw this memory system away | 13:52.53 |
| Robin_Watts | kens: The alternative is MUCH MUCH worse. | 13:53.03 |
| kens | Jaws used reference coutning, worked fine and was totally comprehensible | 13:53.20 |
| | Unlike this rubbish | 13:53.30 |
| Robin_Watts | worked fine *most of the time*. | 13:53.34 |
| kens | Worked fine for as long as Ghostscript's memory manager | 13:53.49 |
| Robin_Watts | The overreliance on macros here is bad IMHO, but that's peters style. | 13:54.21 |
| kens | Its not just the macros, its the special casing of names and all the other bollocks | 13:54.35 |
| | How is anyone supposed to know what to do ? | 13:54.43 |
| Robin_Watts | And the complexities of memory forced on us by PS is bad. | 13:54.47 |
| | but the actual mark/sweep operation is pretty standard. | 13:55.00 |
| kens | PS memory is not a constraint | 13:55.04 |
| | You can implement PS without a garbage collector and that throws away all this | 13:55.24 |
| Robin_Watts | Names, and Refs etc, aren't forced onto us by PS ? | 13:55.26 |
| kens | They are just objects, like any other | 13:55.36 |
| | Can be reference counted, like any other object | 13:55.43 |
| Robin_Watts | Right. | 13:55.58 |
| kens | Therefore no need for all this garbage | 13:56.09 |
| | And don't get me started on teh macros | 13:56.18 |
| Robin_Watts | When I wrote the actionscript engine for picsel, it had reference counted objects, plus garbage collection on top. | 13:56.28 |
| | but everything fitted into one model there; no special case names and refs etc. | 13:56.50 |
| kens | THis special casing of hte name table is juat crap | 13:56.57 |
| | Can anyone give me definitive answer as to what I am supposed to do to the names ? | 13:57.11 |
| Robin_Watts | Well, I believe that in the enumeration phase you should mark them. | 13:57.24 |
| kens | enumerate the pointer to the string ? mark teh name table ? Wave a magic wwand ? | 13:57.30 |
| | Is that a *definitive* ansqwer Robin ? | 13:57.42 |
| | 100% certain ? | 13:57.47 |
| Robin_Watts | and in the relocation phase you do nothing (but make sure you have a case there, so the indexes match up) | 13:58.04 |
| kens | AGGGHHHH | 13:58.15 |
| Robin_Watts | I'm 100% certain that it's my best guess right now. | 13:58.19 |
| kens | More magic. | 13:58.23 |
| Robin_Watts | It's not magic! | 13:58.28 |
| kens | I have to have a case kjust so the indxes match up | 13:58.44 |
| Robin_Watts | The enumeration phase says: My nth pointer is .... | 13:58.46 |
| kens | goes off to back of cave to sulk | 13:59.01 |
| Robin_Watts | And the relocation phase says: "Relocate the nth pointer..." | 13:59.24 |
| | oh, wait, maybe it doesn't. | 13:59.28 |
| kens | ROFL | 13:59.34 |
| Robin_Watts | maybe the relocation just says "relocate all the pointers". Let me check some code. | 13:59.39 |
| | yes, so ignore what I said about having matching pointers, sorry. | 13:59.55 |
| kens | LOL | 14:00.01 |
| | Next time I shall re-assign it to Ray | 14:00.35 |
| | And of course, the likely result is that I won't even be able to tell if this 'fixes' the problem, because the change in memory layout will make it go away anyway..... | 14:01.25 |
| | Well the mark code gets called, and the garbage collector still throws the name away. | 14:24.17 |
| | Anyone else with any ideas ? | 14:24.25 |
| chrisl | Oh, sorry kens, man from the double glazing company turned up..... | 14:35.48 |
| kens | I'm just about ready to gice up and reassign this to Ray. FFighting the source and teh debugger at the smae time is not making me happy. | 14:36.27 |
| chrisl | So, are you seeing the pantone name getting marked? | 14:37.01 |
| kens | Yet more carppy macros with compile time contenst making ti hard to figure out what the f... is going on | 14:37.07 |
| | chrisl if you cna tell me how I would know, I cna tell you ig its getting marked. | 14:37.21 |
| | the structure uses a number of bits for things, which makes it terribly hard ot know. | 14:37.38 |
| | Especially since its unclear how many bits are used for each flag, what with tehm being assigned from a macro at compile time | 14:38.01 |
| chrisl | name_string_t has a "mark" entry | 14:38.30 |
| kens | Yes, and its a bit flag | 14:38.38 |
| | So are tll the preceding entries | 14:38.55 |
| chrisl | names_mark_index() just sets it to "1" | 14:39.00 |
| kens | Which bit ? | 14:39.08 |
| chrisl | pnstr->mark = 1; | 14:39.16 |
| kens | Yes, which bit of the byte in memory ? | 14:39.29 |
| chrisl | I fear this is a different "mark" :-( | 14:40.12 |
| kens | And because the code I'm calling is in a macro, I can't easily break on the call to mark_names_index, and can't seem to follow it in if I do | 14:40.18 |
| kens | applies head to wall some more | 14:40.30 |
| chrisl | kens: as a test, how about calling names_mark_index() explicitly? | 14:42.14 |
| kens | Where ? | 14:42.26 |
| chrisl | You have a function pointer in the colour space still? | 14:42.49 |
| kens | No. Took it all away | 14:43.01 |
| chrisl | Okay, well temporarily you could just call names_mark_index() from the colour space ENUM_PTRS | 14:43.44 |
| kens | I'm doing it from the separation ENUM_PTRS | 14:44.02 |
| | See my conversation with Robin above. | 14:44.10 |
| | And now the debugger won't open the soruce file I want..... | 14:44.47 |
| chrisl | kens: where is the separation ENUM_PTRS? | 14:47.01 |
| kens | In gscsepr.c | 14:47.11 |
| | line 67 or so, ddd won't open it for me | 14:47.27 |
| | Ah, now its giving me 'no debug sysmbols' I really don't like this debug setup | 14:48.31 |
| | So, complete rebuild time again to see if I can get debug symbols back | 14:50.15 |
| | FWIW adding names_mark_index to the ENUM_PTRS in gscsepr.c seemed to have no useful effect at all | 14:50.49 |
| chrisl | I don't understand the declaration of cs_Separation_enum_ptrs....... | 14:51.07 |
| kens | I can't claim I understand any of it | 14:51.27 |
| chrisl | It seems to be a function declaration with no "{}" around the body..... | 14:51.51 |
| kens | I think ENUM_PTRS_BBEGIN does tha,t but what do I know, crappy macros.... | 14:52.31 |
| chrisl | Oh, yeh, I see. I think that's why adding the names_mark_index() call didn't work..... | 14:55.44 |
| kens | ? | 14:55.56 |
| chrisl | I don't think ENUM_PTRS_BEGIN() allows for anything outside the "implicit" switch statement. | 14:56.55 |
| kens | Its in the switch, or is that some other kind of ridiculous limitation ? | 14:57.31 |
| | Oh wait, you mean index is always 0 ? | 14:57.50 |
| chrisl | Can you paste the code somewhere? | 14:58.10 |
| kens | Stuiff it I'll put an explicit mark in the colour space enumerator | 14:58.14 |
| | These macros are doing my head in | 14:58.33 |
| | static | 14:58.53 |
| | ENUM_PTRS_BEGIN(cs_Separation_enum_ptrs) return 0; | 14:58.53 |
| | ENUM_PTR(0, gs_color_space, params.separation.map); | 14:58.53 |
| | { | 14:58.53 |
| | EV_CONST gs_color_space *pcs = vptr; | 14:58.53 |
| | names_mark_index(pcs->rc.memory, pcs->params.separation.sep_name); | 14:58.53 |
| | } | 14:58.54 |
| | ENUM_PTRS_END | 14:58.54 |
| | Right, that's never going to work | 15:00.45 |
| | buggered case | 15:00.50 |
| | case 1:{} might be OK | 15:01.13 |
| chrisl | Yes, just what I was typing up | 15:01.26 |
| kens | I wonder how many hours get wasted by all this macros rubbish | 15:01.50 |
| chrisl | As it stands, you'll hit the "default" case before ever reaching your additional code | 15:01.57 |
| kens | Yes. | 15:02.02 |
| | Well it builds on VS, but not gcc, must have made a typo | 15:03.39 |
| chrisl | To be fair, we had a *lot* of hassle with the referencing counting in Jaws because of some of the crazy font optimisations in there....... | 15:03.58 |
| kens | Not (IMO) to this level | 15:04.12 |
| | At least it was possible to read the code and understand it | 15:04.25 |
| chrisl | True - all I meant was, for me, the big difference is in how legible the code is, rather than the actual problems inherent in each approach | 15:05.17 |
| kens | Well gcc won't compile that code at all, wonderful | 15:05.22 |
| chrisl | What's the error? | 15:05.41 |
| kens | Soemthing about 'no effect' | 15:05.51 |
| | OK it was a typo | 15:06.08 |
| Robin_Watts | back. | 15:06.49 |
| kens | chrisl that causes a seg fault | 15:08.55 |
| | in names_mark_index | 15:09.08 |
| chrisl | so it does..... | 15:09.10 |
| Robin_Watts | names_mark_index doesn't exactly do much... | 15:09.59 |
| chrisl | Oh, I bet that's a "standard" name..... | 15:10.18 |
| kens | pnstr is not vlaid after names_index_string_inline | 15:10.20 |
| chrisl | Is that for index 2430? | 15:10.44 |
| kens | yes | 15:10.50 |
| | First time we call the code to mark the separation name | 15:11.04 |
| | I expect that is /Black | 15:11.10 |
| | I think there's one of those in the job | 15:11.17 |
| | OK so how do I know its a 'standard' name and doesn't need marked ? | 15:12.45 |
| | (yet more special cases) | 15:12.51 |
| chrisl | That's crazy, though, I can't believe that's the case...... | 15:13.26 |
| kens | I'm open to other suggestions | 15:13.47 |
| Robin_Watts | Urm... | 15:14.24 |
| | If you look in gc_unmark_names | 15:14.30 |
| kens | which module ? | 15:14.43 |
| Robin_Watts | igc.c | 15:14.51 |
| | Line 612 | 15:15.01 |
| | That runs a loop of i from 0 to op_array_table_{local,global}->count | 15:15.37 |
| kens | Yes | 15:15.42 |
| Robin_Watts | and the nidx it marks is op_array_table_{global,local}->nx_table[i] | 15:16.07 |
| kens | So it marks all the operators | 15:16.10 |
| | operator names I should say | 15:16.31 |
| Robin_Watts | is your name long an nidx? or an i? | 15:16.38 |
| kens | As far as I know, an nidx | 15:16.55 |
| chrisl | kens: names_mark_index() takes a name table parameter, are you passing a memory pointer? | 15:17.04 |
| kens | Yes | 15:17.17 |
| chrisl | That might cause a problem..... | 15:17.57 |
| kens | OK so where do I get a name table from ? | 15:18.06 |
| | Oh bugger imemory is a macro, not a variable | 15:19.11 |
| Robin_Watts | mem->gs_lib_ctx->gs_name_table; ? | 15:19.12 |
| chrisl | Yep. I thought there was macro to do that for you - seems not.... | 15:20.48 |
| kens | imemory, but it takes a variable called mem (though it doesn't say that | 15:21.11 |
| | It just has tp be present | 15:21.18 |
| | imemory(mem) would be more obvious of course.... | 15:21.32 |
| Robin_Watts | Hidden variables in macros is a route to madness :( | 15:21.56 |
| kens | Yes, it also hides the fact that it *is* a macro, I thougth it was a variable | 15:22.30 |
| | I knew at the time of course. | 15:22.43 |
| | severl years ago when I was working on the code | 15:22.56 |
| Robin_Watts | Do you have a mem pointer during enumeration ? | 15:23.04 |
| kens | Its in the colour space | 15:23.15 |
| | Hidden of course | 15:23.23 |
| chrisl | kens: that *seems* to work | 15:23.42 |
| kens | Yo're ahead of me, I've just started the debugger. | 15:23.59 |
| | Now I need to set up all my breakpoints and so on, since ddd won't remember them for me | 15:24.13 |
| chrisl | I just ran it, and saw all the calls to gs_get_colorname_string() get a valid string back - might just have moved things around, though. | 15:24.51 |
| kens | Indeed, I plan to follow through the execution path and look at it. | 15:25.16 |
| | Oh good, a seg fault | 15:25.34 |
| | well its not hte mark that's the problem this time | 15:26.55 |
| Robin_Watts | installs the installer for the Xcode installer. | 15:26.58 |
| | ain't app stores grand. | 15:27.08 |
| chrisl | Here's what I've got: | 15:27.10 |
| kens | Its marking the entry OK | 15:27.18 |
| chrisl | static | 15:27.19 |
| | ENUM_PTRS_BEGIN(cs_Separation_enum_ptrs) return 0; | 15:27.21 |
| | ENUM_PTR(0, gs_color_space, params.separation.map); | 15:27.23 |
| | case 1: | 15:27.25 |
| | { | 15:27.27 |
| | EV_CONST gs_color_space *pcs = vptr; | 15:27.29 |
| | names_mark_index(pcs->rc.memory->gs_lib_ctx->gs_name_table, pcs->params.separation.sep_name); | 15:27.30 |
| | return(0); | 15:27.32 |
| | }; | 15:27.33 |
| kens | Yes, pretty much the same. | 15:27.44 |
| | seg fault is not happening there | 15:27.53 |
| chrisl | No. | 15:28.03 |
| Robin_Watts | return 0 means "nothing more to enumerate", right? | 15:28.23 |
| kens | Don't get any debug info when it does seg fault | 15:28.26 |
| chrisl | Robin_Watts: yes | 15:28.36 |
| kens | Shouldn't be a problem | 15:28.50 |
| | There is nothing more to enumerate | 15:28.57 |
| chrisl | kens: could it be the lack of a prototype for names_mark_index()? | 15:28.59 |
| kens | I suppose that could be it. I'll add the .h file. | 15:29.12 |
| Robin_Watts | ordinarily that would happen on case 2, but shouldn't matter in this case - until someone else comes along in 2 years time to add something new, and it doesn't get called. | 15:29.22 |
| kens | Robin_Watts : I'll happily fix that, when everything else works, I'm kind of experimenting right now | 15:29.47 |
| Robin_Watts | kens: sure. | 15:30.07 |
| chrisl | Robin_Watts: the problem is we *have* to return something, but this code is doing the "mark" itself. | 15:30.13 |
| kens | I can easily return the address of the string | 15:30.41 |
| Robin_Watts | chrisl: Right. I might be tempted to move this into the default case when all is said and done. | 15:30.42 |
| | kens: No... | 15:31.11 |
| kens | Lets get it to work first.... | 15:31.14 |
| Robin_Watts | I'll shut up for now, but don't do that :) | 15:31.25 |
| chrisl | Robin_Watts: yes, _or_ make into a ENUM_PTRS_BEGIN_PROC() so the switch is explicit and clear...... | 15:31.38 |
| | (not yes to you shutting up, necessarily!) | 15:31.54 |
| kens | And of course, I can't include inames.h in gscsepr.h because (tada) inames.h is in psi, and gscsepr is in base | 15:32.58 |
| | gscsepr.c | 15:33.06 |
| chrisl | Well, this is only a hacky proof of concept, so do a local prototype | 15:33.33 |
| kens | Isn't this fun :-) | 15:33.38 |
| | cd base | 15:33.45 |
| | sorry wrong window | 15:33.51 |
| chrisl | Would you prefer cust 532? | 15:34.11 |
| kens | TO be honest, I'm beginning to think so | 15:34.24 |
| | After 4 days spent with this | 15:34.33 |
| chrisl | Even if I tell you the first of these latest problems *is* with their MM substitution code? | 15:35.02 |
| kens | At least it hasn't taken you long to find it | 15:35.20 |
| | That was my first 3 days | 15:35.29 |
| chrisl | No, but I'm sure getting fed up of investigating problems with their code :-( | 15:36.12 |
| kens | I'm also thikning this local prototype won't work unless I cast the parameters to void types. I think the type definiitions are in psi as well | 15:36.49 |
| chrisl | It's odd that I don't get a seg fault...... | 15:37.37 |
| kens | Now gcc is saying I have too many arguments :-( | 15:38.18 |
| | OK that shut it up | 15:39.03 |
| | cd debugbin | 15:39.26 |
| Robin_Watts | No such directory | 15:39.42 |
| kens | Works here :-) | 15:40.06 |
| | Still segment faults | 15:40.13 |
| chrisl | Do you know where? | 15:40.30 |
| kens | 0x00 in ?? () | 15:40.40 |
| | Missingseparate debuginfos, use: debuginfo-install cups.i386..... | 15:41.08 |
| chrisl | Ah, go to status menu, and backtrace, it might have more info | 15:41.16 |
| kens | gc_trace appears to be the last place | 15:41.32 |
| | Where everything looks OK | 15:42.03 |
| chrisl | What line in gc_trace? | 15:42.24 |
| kens | if ((*ptp->mark) (&nep, pstate)) | 15:43.02 |
| | Doens't give me a line number | 15:43.20 |
| | oh, try 876 | 15:43.30 |
| chrisl | Yeh, got it | 15:43.38 |
| kens | Hmm, I think I'm returning garbage, let me fix that | 15:44.30 |
| | brain is giving up on me I think | 15:45.17 |
| | That got it. | 15:46.15 |
| | Lets check the output | 15:46.18 |
| | Output is correct. | 15:50.08 |
| Robin_Watts | So, seems solved? | 15:50.19 |
| kens | Now I want to check the flow to be certain | 15:50.30 |
| | I'm going to debug through it and see the mark changing to be sure | 15:50.42 |
| | If so then I need to sort out the code, and then add similar code for DeviceN spaces | 15:50.58 |
| | OK well the good news is that the string is marked even before I get to setting the separation space :_) | 15:53.43 |
| | Lets see if ti gets unamrked in gs_gc_reclaim | 15:53.53 |
| | OK good, it unmaks the name in gc)unmark_names | 15:55.37 |
| | And nmarks it again in the sweep. | 15:56.30 |
| | Excellent | 15:56.32 |
| | Its working as I wanted now. | 15:56.51 |
| | So all I need to do now is rewrite the code. | 15:56.59 |
| Robin_Watts | the enum stuff? | 15:57.15 |
| kens | Which I can do in VS | 15:57.16 |
| | Robin_Watts : the return to start with (will move to default I think as you suggested) | 15:57.36 |
| henrys | Robin_Watts:this was all being tracked under 692674 - I guess he thought starting a new report would get us to expedite the enhancement. | 15:57.43 |
| kens | Try and sort out the function prototype | 15:57.44 |
| | and do DeviceN as well as /Separation | 15:57.57 |
| | But first, coffe. | 15:58.02 |
| Robin_Watts | kens: fun. sounds good. | 15:58.04 |
| chrisl | kens: you'll need to implement this as a function pointer back in to the interpreter - the stuff about marking names and such is PS specific. | 15:59.13 |
| henrys | Robin_Watts:and the situation is summarized by Ray in comment 27 which is ken's second priority right now. | 16:00.04 |
| | they're in the running for our most maddening customer. | 16:00.53 |
| Robin_Watts | henrys: Oh, right, I see what you mean. | 16:00.58 |
| | henrys: Yes. I completely agree. But I thought I'd answer his email after snubbing him on the bug the other day. | 16:01.30 |
| kens | chrisl yes, that was what I was thinking, its the only sensible way to get the stuff sorted out. Hence the need for more coffee. | 16:03.46 |
| | henrys I was going to talk some more about the memory handling at next Tuesdays' meeting. | 16:04.03 |
| | As far as I can see, pdfwrite is explicitly freeing all the memory it uses. | 16:04.18 |
| | So I need some ideas on how to find out if it isn't. | 16:04.30 |
| | Also hints on how to move all hte memory into non-gc memory | 16:04.46 |
| | But right at the moment I'm overloaded with teh garbage collector problem I've spent the last 4 dayson | 16:05.02 |
| henrys | yes I see that. | 16:05.19 |
| kens | Thanks to chrisl and Robin_Watts it looks like there's a solution now though ;-) | 16:05.42 |
| henrys | I guess memento is best for memory leaks. Didn't we create a bug for leaks running plrm with %d? | 16:06.22 |
| kens | Yes, but I'm unconvinced that's a leak as such | 16:06.42 |
| | Its a crash I think | 16:06.47 |
| Robin_Watts | Memento will certainly tell you if blocks leak. | 16:07.07 |
| henrys | maybe pdfwrite is not leaking but the memory used appears to be growing constantly. | 16:07.13 |
| Robin_Watts | It may be defeated slightly if the gc is freeing blocks for you. | 16:07.20 |
| kens | But there is an old (PCL I think) bug which says that three are a lot of memory allocations not freed, and it slows the job down because it is printing them out or something | 16:07.20 |
| | Robin_Watts : currently all the memory in pdfwrite is GC'ed I think | 16:07.46 |
| | make that 'allocations' | 16:07.51 |
| Robin_Watts | hence we might want to memento pcl -> pdf ? | 16:07.58 |
| | To take the gc out of the way. | 16:08.08 |
| kens | Robin_Watts : yes that was what I was thinking | 16:08.11 |
| | Which is why I'd looked up the earlier bug, which I now can't remember the ' of | 16:08.29 |
| | number | 16:08.32 |
| Robin_Watts | grows old waiting for xcode to update AGAIN. | 16:08.49 |
| kens | I think the server crash thing is a different issue altogether | 16:08.51 |
| henrys | 692674 doesn't need pcl to work though that's the important issue. | 16:09.43 |
| kens | IMO that's a different thing altogether | 16:10.32 |
| | THey can't currently use pdfwrite in a server mode, but they never could, so they are really no worse off. | 16:10.59 |
| | a server would be an enhancement for htem (and others) but its a different problem altogether | 16:11.20 |
| | It ought to work with Ray's code, but as you ntoe that : | 16:11.47 |
| | a) crashes | 16:11.47 |
| | b) increases memory | 16:11.47 |
| | Which are probably 2 different problems | 16:12.08 |
| | I wouldn't be surprised to find that the bug I'm woriing on now is implicated in the crash | 16:12.21 |
| henrys | kens:hmm was it a pdfwrite bug - no big deal if we can't find it I imagine I can easily create another. | 16:16.47 |
| kens | henrys I'm sure it was, and I will be able to find it again, its assigned to me | 16:17.07 |
| chrisl | kens: I had a look at the "mark" code, and I think this approach is the only possible one - there is no provision for ENUM_PTRS to return a name string type........ so explicit marking is the only alternative. | 16:19.01 |
| kens | chrisl thanks for looking. | 16:23.23 |
| | It does look like this is the 'correct' way to proceed | 16:23.34 |
| chrisl | Where 'correct' == 'only' | 16:23.57 |
| Robin_Watts | unless we extend the gc so we can return name pointers somehow. | 16:24.24 |
| kens | No I think this is the intended appraoch | 16:24.37 |
| | I don't like it, but it looks deliberate | 16:24.52 |
| chrisl | Robin_Watts: that would mean fairly heavy reworking of name objects, and probably make them (non-trivially) bigger | 16:25.15 |
| Robin_Watts | chrisl: really? I was hoping it would only require a change to the gc structures passed around at enumeration time. | 16:25.50 |
| | At the moment you get a pep, which you are expected to fill in. | 16:26.30 |
| | (pep->ptr = blah, pep->size = blah, ptr_string_type) for example | 16:27.09 |
| | We could do: | 16:27.12 |
| | (pep->ptr = (void *)mem, pep->size = name, ptr_name_type) | 16:27.44 |
| | That way no horrid function pointer hackiness is required. | 16:27.58 |
| | kens: IF you want to send me your patch, I'll have a look at doing that. | 16:28.34 |
| | I've had a terrible bloody day and achieved sod all, so that might actually let me get something useful out of the day :) | 16:29.05 |
| kens | Robin_Watts : my patch isn't ready to be done, I need to do the function pointer indirection thing first. Or if you want the patch I'm using now, chris wrote it in IRC a while back, mine is functionally the smae | 16:29.19 |
| | Robin_Watts : that describes my previous 3 days | 16:29.38 |
| | Fighting with ddd | 16:29.50 |
| Robin_Watts | kens: To avoid confusion can you pastebin it again, and I'll have a look. | 16:29.57 |
| kens | OK | 16:30.02 |
| | Need to start up Linux again first | 16:30.26 |
| chrisl | I'll do it, if you like | 16:30.45 |
| kens | That would be good. | 16:30.53 |
| | Save me a minute or two | 16:30.58 |
| chrisl | Robin_Watts: do you want the whole file? | 16:31.50 |
| Robin_Watts | Just the changed bits... | 16:31.59 |
| chrisl | http://pastebin.com/QivKnpLL | 16:33.04 |
| Robin_Watts | Thanks. | 16:33.10 |
| | This might all come grinding to a halt, but hopefully it'll give something that ken can use more neatly. | 16:33.30 |
| kens | :-) | 16:33.39 |
| | I'm going to press ahead with the function pointer in the colour space anyway | 16:33.58 |
| | That will replicate this method and so should be OK | 16:34.26 |
| | I won't get it done today, I will be off to Melanie's riding lesson shortly | 16:34.52 |
| chrisl | Robin_Watts: actually, it looks like it might be quite easy to add "indirect" name string marking - I rather thought we needed at least a "type" field for it, but it looks like not | 16:47.33 |
| henrys | kens I did a quick looking at pcl->pdfwrite leaks and you should have no problem finding holes to patch. Just run a file like tools/owl.pcl | 16:57.55 |
| kens | Right I'll consult with Robin on using Memento | 16:58.14 |
| henrys | I have a hacky script that turns memento ouput into gdb backtraces | 16:59.06 |
| kens | Wouldn't help me :-) | 16:59.17 |
| henrys | right | 16:59.30 |
| kens | never wants to use ddd/gdb again | 16:59.51 |
| chrisl | never wants to use VS again - but..... | 17:00.08 |
| henrys | kens:the output is quite intimidating it appears nothing is being freed. | 17:14.03 |
| kens | That shuld not be. | 17:14.15 |
| | There are explicit frees for the resource chains | 17:14.25 |
| henrys | yes exagerating but owl to ppmraw leaves about 60 mallocs outstanding (setup etc.) pdfwrite is well over a 1000 - so I think you might have some work to do. | 17:21.14 |
| Robin_Watts | Leak fixing is one of those things where you go "but how come we never noticed this before!" a lot. | 17:22.07 |
| | It's also one of those things where you fix 1 thing, and huge numbers of your leaks disappear. | 17:22.26 |
| kens | OK fair enough, that sounds priomising anyway | 17:22.43 |
| henrys | Robin_Watts:good point about fixing 1 thing. | 17:23.10 |
| kens | I have to be off, goodnight all | 17:23.13 |
| henrys | Robin_Watts:right you are - the script shows pdf_set_drawing_color implicated in over half the outstanding mallocs | 17:25.54 |
| | Robin_Watts:did you check if they have the same number of gx_image_cached_char() calls as we do... is the cache hit the same (Eric's mail) | 17:31.52 |
| | cache hit rate. | 17:32.04 |
| Robin_Watts | I did not. | 17:32.14 |
| | I've just looked quickly at the profile, and clist_change_bits seems to be being called lots more in the new one, for much less overall time. | 17:32.56 |
| | I have therefore decided to ignore it for the time being and push on with the gc stuff. | 17:33.22 |
| chrisl | clist_change_bits being called more often probably suggests we're not pushing as many glyph bitmaps into the tile cache (without tile compression on) | 17:34.14 |
| Robin_Watts | chrisl: The difference between this file and the last one *should* just be the band height in use. | 17:34.51 |
| | (Although I think he may have sneakily changed from 6 pages to 10 pages of test file. I mean, ffs, how hard is it to grasp the concept of only varying one thing at a time when testing) | 17:35.25 |
| chrisl | Hmm..... well, as I said, I keep being asked to investigate *their* code, so....... | 17:35.57 |
| mvrhel | alexcher: any luck tracking down the output intent issue? | 17:38.29 |
| Robin_Watts | Who added the doc dir to the visual studio solution? | 17:41.44 |
| | hmm. Apparently that happened ages ago. | 17:42.58 |
| | so why am I only seeing XHTML validation warnings now... | 17:43.16 |
| | kens: For the logs - I'm clusterpushing a patch now. | 18:18.42 |
| | paulgardiner dropped the Transformer Prime round earlier. Forget your ipads. That thing is awesome. | 18:19.39 |
| mvrhel | aha. gdev_prn_set_planar errors if num_comp > 4.... | 19:46.16 |
| | Robin_Watts: you don't mind if I remove that greater than check do you | 19:46.35 |
| Robin_Watts | Urm... just thinking. | 19:46.52 |
| | why is that there... | 19:46.55 |
| | where ? | 19:46.57 |
| mvrhel | and update the code to handle more | 19:47.03 |
| | in gdevppla.c | 19:47.08 |
| | line 90 | 19:47.16 |
| Robin_Watts | Ah, right. | 19:47.54 |
| | So I was wondering why that check was there, and now I see. Sure. go for it. | 19:48.08 |
| mvrhel | ok cool. | 19:48.15 |
| | actually off to run some errands now that I have gotten this far. bbiaw. | 19:48.28 |
| Robin_Watts | henrys: For the record, I see 53547 calls to gx_image_cached_char, on a file which has 10 pages of (roughly) 5000 chars on a page. So that sounds plausible. | 20:39.49 |
| | I see 46330 calls to clist_change_bits though. | 20:40.21 |
| | but it's only accounting for 0.8 seconds now. | 20:40.44 |
| ray_laptop | Robin_Watts: was that you that sent the SMS ? | 20:47.31 |
| Robin_Watts | It was, sorry. | 20:47.39 |
| | I wanted to check something quickly if I may. | 20:47.56 |
| ray_laptop | np. my laptop was rebooting (it crashes several times a week) | 20:48.01 |
| Robin_Watts | In the last profile from Eric, he has a file with 10 pages, and has 130 calls to clist_playback_band | 20:49.14 |
| | so 13 bands a page. | 20:49.20 |
| | He has 520 calls to clist_get_bits_rectangle. | 20:49.36 |
| ray_laptop | Robin_Watts: OK. so it sounds like 1024 lines per band | 20:49.37 |
| | that also makes sense | 20:49.48 |
| Robin_Watts | so he's extracting 256 lines a time from the rastered buffer, which only actually renders every 4th time ? | 20:50.15 |
| ray_laptop | if the data requested is already in the clist buffer it just returns it | 20:50.29 |
| Robin_Watts | OK, that seems plausible to me too. Just wanted to check with you. Thanks. | 20:50.41 |
| ray_laptop | correct -- renders every 4th time | 20:50.42 |
| Robin_Watts | I am confused by the number of calls to clist_change_bits though. | 20:50.57 |
| ray_laptop | many devices just get 1 line at a time | 20:51.01 |
| Robin_Watts | I see 53547 calls to gx_image_cached_char, on a file which has 10 pages of (roughly) 5000 chars on a page. So that sounds plausible. | 20:51.17 |
| | but then I see 46330 calls to clist_change_bits. | 20:51.38 |
| ray_laptop | sounds like the tile_cache is not working too well | 20:51.57 |
| Robin_Watts | I'd expect to see 10*13*64 or so at most. | 20:52.19 |
| | i.e 8000 | 20:52.27 |
| ray_laptop | Robin_Watts: what does standalone gs do? | 20:53.38 |
| Robin_Watts | no idea. | 20:54.03 |
| | I've only just spotted this. | 20:54.11 |
| ray_laptop | Robin_Watts: how many 'make_font' calls do you see ? | 20:54.12 |
| Robin_Watts | make_font is not shown in the profile | 20:54.35 |
| ray_laptop | their mods to pdf_font.ps seem to interfere with font caching | 20:54.43 |
| | and I think the 6thgen is almost the same | 20:55.05 |
| Robin_Watts | I see 22 calls to zbuildfont2 | 20:55.20 |
| ray_laptop | how many calls to make_font in psi/zfont.c | 20:55.52 |
| | Robin_Watts: and is that on the simulator or on current gs ? | 20:56.16 |
| Robin_Watts | ray_laptop: I can't tell from their profile. | 20:56.19 |
| | That's from their profile - so on their target. | 20:56.34 |
| ray_laptop | Robin_Watts: let me look at their profile | 20:56.42 |
| | Robin_Watts: I only see 834 calls to gx_add_cached_char | 20:58.45 |
| Robin_Watts | Yes. | 21:00.14 |
| | So 834 characters used throughout 10 pages? | 21:00.33 |
| | (I am not that familiar here, but that sounds plausible) | 21:01.00 |
| ray_laptop | Robin_Watts: clist_change_bits looks like it is called and may or may not end up deciding that the tile is already in the cache | 21:01.09 |
| Robin_Watts | Oh! | 21:01.24 |
| | Damn. I was thinking of cmd_put_bits. | 21:01.48 |
| | Which is 3598. Much more reasonable. | 21:02.02 |
| ray_laptop | the clist_add_tile is used when the tile is not in the cache | 21:02.11 |
| Robin_Watts | Down from an (estimated) 9800 with a band height of 256. | 21:02.59 |
| ray_laptop | Robin_Watts: but their paltry improvements correspond with what I saw on the simulator | 21:03.16 |
| Robin_Watts | Right. | 21:03.24 |
| | I think they have some background process going on that periodically stalls time for 2 seconds. | 21:03.40 |
| ray_laptop | Robin_Watts: where do you get that from ? | 21:04.01 |
| Robin_Watts | Look at (say) obj_le | 21:04.17 |
| | The 3rd column is (I think) the maximum time spent in this function. | 21:04.55 |
| | 1st column = Total time in this function (and it's children) | 21:05.22 |
| | second column is the average time. | 21:05.31 |
| | Clearly there is some MAJOR standard deviation there :) | 21:06.08 |
| | There are lots of functions with 1.9999 maximum times. | 21:07.12 |
| | You see what I mean? | 21:07.39 |
| ray_laptop_ | Robin_Watts: I see the third column as 0.000052 (occurs twice in the profile) | 21:08.10 |
| | (sorry connection to IRC dropped) | 21:08.28 |
| Robin_Watts | Sorry, I was looking at the old profile. Let me try and find an example in the new profile. | 21:08.58 |
| | bbox_transform_either | 21:09.12 |
| ray_laptop | Robin_Watts: OK. yep -- that is a question | 21:09.55 |
| Robin_Watts | Maybe it's (another) problem with their profiler. | 21:10.40 |
| ray_laptop | I'll look at how many times that kind of thing happens (the "max" is a lot more than the avarage) | 21:10.46 |
| Robin_Watts | or maybe they genuinely have something on the device thats suddenly locking it up. | 21:10.57 |
| ray_laptop | Robin_Watts: I think some of the bbox_ issue has to do with text rendering (bbox_finish_fill) | 21:15.04 |
| | bbox_finish calls (sometimes) type1_contimue_dispatch | 21:15.43 |
| Robin_Watts | I might agree if this mysterious 2 seconds didn't keep jumping around. | 21:15.53 |
| ray_laptop | Robin_Watts: good point | 21:16.19 |
| viric | Hello | 22:20.26 |
| ghostbot | privet, viric | 22:20.26 |
| viric | ÐÑÐ¸Ð²ÐµÑ | 22:20.29 |
| | It may be a FAQ... | 22:20.51 |
| | but what is different between gnu ghostscript and gpl ghostscript? | 22:21.05 |
| | Neither gpl ghostscript pages talk about gnu ghostscript, or the other way round | 22:21.16 |
| | and the versions are close but not equal | 22:22.30 |
| Robin_Watts | viric: GPL Ghostscript is the GPL release of Ghostscript from Artifex. | 22:26.42 |
| | All the development on gs has been done by Artifex (or people who have sold their contributions to artifex). | 22:27.07 |
| | We choose to release it for free under the GPL to the community. | 22:27.18 |
| | We also choose to allow people to buy commercial licenses for it (printer manufacturers etc) so they can ship products without being bound by the GPL. | 22:27.55 |
| | This money is used to fund further development (and pay our mortgages etc). | 22:28.11 |
| | Some people think this is EVIL. | 22:28.26 |
| | So they take our GPL release, strip out all references to Artifex and the commercial version, and repackage it as GNU Ghostscript. | 22:28.58 |
| | They finally seemed to get bored of that a few versions ago though. | 22:30.00 |
| viric | no no | 22:33.09 |
| | they are back | 22:33.11 |
| | 9.04.1 is there | 22:33.14 |
| | Some time ago they stopped at some 8.x | 22:33.21 |
| | Who is the copyright owner? | 22:34.02 |
| | Artifex? | 22:34.06 |
| | or it's not clear? | 22:34.19 |
| henrys | Artifex - but we release it under a private license and GPL as Robin_Watts said. | 23:15.04 |
| | s/private/commercial | 23:16.02 |
| | Forward 1 day (to 2012/03/09)>>> | |
IRC Logs