| | <<<Back 1 day (to 2012/10/02) | 2012/10/03 |
| mvrhel_laptop | good night all | 05:51.06 |
| chrisl | kens: I'll run some more tests on the G4 Mac this afternoon - I only tested the default output last night, as I was having networking problems with my laptop..... | 08:37.42 |
| kens | chrisl thanks, I *hope* that fixes the problems..... | 08:38.04 |
| | The trouble is that this code really isn't well tested, there may well be more of this sort of problem lurking in there | 08:38.31 |
| | Hmm, I htink I'll let Marcos answer the support question from Nestle | 08:43.02 |
| chrisl | All to be expected, I think. I'm off to squash..... | 08:47.12 |
| mvrhel | the support question from nestle is funy | 13:37.56 |
| | funny | 13:37.58 |
| kens | :-) | 13:38.08 |
| | I'd want to be careful answering it. | 13:38.21 |
| | Its not 'freeware' | 13:38.29 |
| | And I wouldn't want them quoting an email form me saying it was OK. | 13:38.45 |
| slestak_work | kens: i am cloning ghostpdl.git and will test yesterdays patch | 13:38.59 |
| kens | Personally I'd refer them to the GPL and tell them that's the legal status | 13:39.10 |
| | slestak_work : will be interesting to hear. | 13:39.27 |
| | chrisl says its OK on a Mac now (PPC) | 13:39.36 |
| slestak_work | awesome | 13:39.43 |
| | my user will be very happy | 13:39.57 |
| kens | Hope so, its nice to see the txtwrite device being used. | 13:40.20 |
| slestak_work | i am using it in a printer filter for lp | 13:40.58 |
| kens | Interesting, I didn't really expect it to be used for printing ;-) | 13:41.19 |
| slestak_work | user prints in pcl (as he has done for years) and I convert it to tiffs and drop them on an ftp server for a remote business partner. need the textwriter to get some info for a meaningful name for the tiff. | 13:41.47 |
| kens | Ah, so you don't print the output of txtwrite, that makes more sense | 13:42.06 |
| slestak_work | basically printing to an ftp site | 13:42.09 |
| | no i am delivering the output of g3tiff device, but i wanted to name it for the order number contained within | 13:42.54 |
| kens | Yes, makes sense now | 13:44.22 |
| slestak_work | i should have grabbed a tarball instead of cloning the repo. i think I am dl'ing a LOT | 13:44.48 |
| kens | I think cloning the Git repository copies the database, so its bigger than just the source. | 13:46.35 |
| slestak_work | i have cancelled that and have a tar.gz coming now | 13:46.55 |
| kens | However, if you need new source frequently, then future git rebase woudl be very quick | 13:46.56 |
| | Yes, was going to say a tarball was probably what you wanted | 13:47.13 |
| slestak_work | glad i could be part of the process to make it better for other ppc users | 13:47.38 |
| | thats how foss works | 13:47.48 |
| kens | Yes. Actually the bug in txtwrite was generic, it was copying from the wrong structure member. | 13:48.25 |
| | I don't really figure how that was working on other platforms. Dumb luck I expect.... | 13:48.43 |
| slestak_work | lol | 13:48.48 |
| | sometimes you dont ask why | 13:48.56 |
| ray_laptop | Robin_Watts: I had test.artifex.com in the DNS for a while, but when I cut/pasted the IP address, I missed the trailing 8 so it was going to some clothing site. | 14:00.11 |
| | It seems that DNS updates are slow, and slow to clear out. 'test' should be gone by now and I set up 'new' but it doesn't show up yet | 14:01.06 |
| | Robin_Watts: the current nameserver is ns1.cnchost.com so you can check there | 14:01.39 |
| | they say 15 minutes for an update and I guess they mean it | 14:02.01 |
| | strange that it is taking this long. I logged back in and 'new' is in the DNS zone file (with the correct address) but it _still_ doesn't resolve, even when I specify ns1.cnchost.com as the server | 14:15.37 |
| | ahh -- now it does | 14:16.12 |
| | now we just have to wait for it to propagate. | 14:16.45 |
| | kens: can you try: nslookup new.artifex.com ns1.cnchost.com | 14:17.14 |
| kens | OK one second | 14:18.18 |
| | server: ns1.cnchost.com | 14:19.04 |
| | address: 207.155.248.30 | 14:19.14 |
| | new.srtifex.com | 14:19.20 |
| | 188.121.46.128 | 14:19.27 |
| ray_laptop | kens: I hope that the new.srtifex.com was a typo and not what I did by mistake | 14:28.19 |
| kens | No, it was my typo | 14:32.46 |
| henrys | kens:I'll find your warning at some point today when I update and send it on. | 14:45.08 |
| kens | Thanks henrys I did change a cnadidate | 14:45.19 |
| chrisl | kens: okay, with that change, all the TextFormat options give "sane" output with the user's test file, on the G4 Mac | 14:48.18 |
| ray_laptop | Robin_Watts: the new.artifex.com seems to have propagated to my cable system's dns server. | 14:49.35 |
| henrys | brb have to do a quick errand | 14:50.12 |
| ray_laptop | Can everyone see it now (the web page just says 'pageok' at this point) | 14:50.16 |
| | Robin_Watts: are you going to replace that with Miah's website ? | 14:50.45 |
| chrisl | ray_laptop: the 'pageok' page comes up for me, yes | 14:51.15 |
| kens | chrisl thanks for testing that | 14:53.24 |
| chrisl | np | 14:53.39 |
| Robin_Watts | ray_laptop: new.artifex.com ? | 15:40.23 |
| | OK, well, I've not setup new.artifex.com on the server. | 15:41.13 |
| | I set up test.artifex.com | 15:41.19 |
| kens | Heading otu for pizaa, bye all | 16:01.15 |
| Robin_Watts | night kens | 16:02.12 |
| | Does http://new.artifex.com work for anyone else ? | 16:10.34 |
| chrisl | Robin_Watts: yep | 16:12.01 |
| Robin_Watts | fab. | 16:12.14 |
| henrys | works for me, got the big eye and all. | 16:13.23 |
| chrisl | Hmm, I need to mention to Miles about removing the stuff about "our own font scalers......" | 16:13.29 |
| Robin_Watts | If you have comments like that, can you please send an email to 'everybody' with specific suggested changes? Otherwise this will never get finished. | 16:15.28 |
| chrisl | I don't think the new website going live should be "gated" on something like that | 16:16.04 |
| | I suppose it could be argued that we do still font interpreters for various technologies, so it's not entirely inaccurate | 16:18.25 |
| henrys | (together = PCL6) is not clear what it is modifying. | 16:18.27 |
| | I read it as PDF+XPS+PCL etc = PC6 | 16:19.00 |
| | PCL6 | 16:19.15 |
| chrisl | We don't really need that since PXL includes PCL5 now | 16:19.56 |
| henrys | can somebody just delete (together = PCL6) or do we need an everybody email. | 16:20.15 |
| Robin_Watts | henrys: I think wording changes need to at least be run past Miles. | 16:20.34 |
| henrys | you can blame me. | 16:20.36 |
| Robin_Watts | Hence an everybody email means we can go ahead and change it, and claim to have checked with/informed him. | 16:20.55 |
| henrys | okay | 16:21.01 |
| | done | 16:23.08 |
| | chrisl:we have a 20 line intellifont scaler, for example. | 16:25.26 |
| chrisl | henrys: yes, but our Type 1 and TTF code is now unsupported, and Freetype is not licensed separately from a vendor..... | 16:26.28 |
| henrys | I understand it was sort of a joke - how marketing inflates claims ... | 16:27.31 |
| ray_laptop | henrys: I agree that is confusing. It was in my comments (in progress). Also we don't mention XPS some places, particularly with mupdf | 16:28.13 |
| henrys | I think the font stuff should be changed/removed. | 16:28.30 |
| chrisl | I'm drafting something now | 16:28.48 |
| henrys | send a message to everybody like Robin_Watts said. | 16:28.52 |
| | okay | 16:28.55 |
| ray_laptop | rather than here, however, I agree that email should be used | 16:28.58 |
| henrys | I'm doing a warning cleanup in pcl - gawd the include file spagetti ball is just a disaster in all the code. | 16:30.50 |
| chrisl | henrys: hence tor8's preference for one big header file! ;-) | 16:38.08 |
| henrys | either spagetti or big header is just a reflection of the underlying chaos. | 16:39.32 |
| | I think big header is worse, at least the includes should give you some clue of what uses what. | 16:42.35 |
| chrisl | Unfortunately, I find the header spaghetti is often the result of the strict compartmentalisation of components - however carefully you design the components, inter-dependencies change over time, and rarely does anyone have the time to rejig the compartments to suit the new requirements.... | 16:42.54 |
| henrys | bbiab | 16:55.00 |
| Robin_Watts | Oh great. I can make this go wrong on peeves, but not on my local ubuntu. | 17:37.30 |
| | So I try to build with PACIFY_VALGRIND on peeves so I can safely use helgrind... and the valgrind there is too old :( | 17:37.57 |
| | ray_laptop: Is Michael about today? | 18:27.25 |
| Robin_Watts | would like a quick word with both mvrhel and ray about bug 693361 | 18:28.28 |
| ray_laptop | Robin_Watts: I called mvrhel and got his voicemail | 18:45.36 |
| | Robin_Watts: where are you at with this ? | 18:46.01 |
| | Robin_Watts: ready to tear your hair out ? | 18:46.30 |
| | Robin_Watts: what version valgrind does peeves need ? | 18:49.48 |
| | .- .- .- crickets | 18:50.14 |
| | Robin_Watts: Have to drop off lunches at the school. bbiab. | 18:56.53 |
| mvrhel | I am here | 19:07.35 |
| | I was down the hall eating lunch | 19:07.44 |
| | I am pulling my hair out as well | 19:07.55 |
| | getting stuff working for customer 330 | 19:08.06 |
| | Robin_Watts: ^^ | 19:08.18 |
| | Robin_Watts: I am probably not going to be of much help with this now | 19:08.48 |
| | I have a deadline to get this stuff done for customer 330 | 19:08.59 |
| | bbiab. off to finish lunch and the pick up kids | 19:09.44 |
| Robin_Watts | mvrhel: OK, sorry, had to step away to have dinner. | 19:13.18 |
| | I'll burble here for the logs, and maybe you can answer when you get back. | 19:13.31 |
| | The problem with bug 693361 is, I think, down to different memory *'s being used. | 19:14.46 |
| | Before this commit, all the lcms stuff went into malloc/free. | 19:15.14 |
| | After it, it goes into memory allocators controlled by gs_memory_t *'s. | 19:15.32 |
| | With multithreaded rendering we get a new gs_memory_t * for each thread, being a chunk allocator that wraps the underlying allocator. | 19:16.03 |
| | I was told (or at least, my understanding ended up being) that every threads icc use was independent. | 19:17.08 |
| | So profiles/links would be created in a thread, used, and then destroyed. None of them were used in more than 1 thread. | 19:17.42 |
| | It's looking very much like this is not the case. | 19:17.58 |
| oy | Robin_Watts: using a lcms transform in more than one thread is easy, provided the correct API is used | 19:18.55 |
| Robin_Watts | I can see profiles being destroyed in 'teardown_threads' (i.e. in the main thread) that internally have gs_memory_t *'s that correspond to rendering threads. | 19:19.04 |
| oy | trasnform creatio in parallel does not work so good :-/ | 19:19.20 |
| Robin_Watts | oy: Yes, my problem is not with lcms' capabilities, but rather with our use of it. | 19:19.42 |
| | oy: I have some threading fixes for lcms in my github repo. | 19:20.30 |
| oy | oh, nice | 19:21.01 |
| | lcms cmsDoTransform() is used together with OpenMP just fine | 19:21.40 |
| Robin_Watts | Yes. | 19:21.56 |
| | but as you say, reading profiles etc doesn't work reliably in multithreading cases. | 19:22.13 |
| | I believe it does with my fixes. | 19:22.25 |
| oy | would be great :-) | 19:23.06 |
| Robin_Watts | https://github.com/robinwatts/Little-CMS/commits/artifex | 19:23.20 |
| | commits 4,5,6 on that page. | 19:23.45 |
| ray_laptop | Robin_Watts: are you there ? | 19:26.36 |
| Robin_Watts | I am | 19:26.43 |
| | Sorry, I'd been called away to dinner before. | 19:27.13 |
| ray_laptop | np | 19:27.19 |
| Robin_Watts | I burbled above. Probably easiest if you check the logs. | 19:27.30 |
| ray_laptop | so, is the issue that the gs_memory_t * being used when the transforms are 'destroyed' is not the same as when created ? | 19:28.06 |
| Robin_Watts | It's either that, or it's that the gs_memory_t being used to destroy them has already itself been destroyed. | 19:28.52 |
| ray_laptop | i.e., does every structure being malloced / freed have it's own gs_memory_t *mem element that can be used when freeing (set when allocated) | 19:29.27 |
| Robin_Watts | ray_laptop: It's not that simple. | 19:30.04 |
| | lcms doesn't provide for every allocated block to have an additional pointer to a gs_memory_t. | 19:30.34 |
| | I suppose I could extend the blocks by a pointers worth, and prepend the gs_memory_t there... | 19:30.58 |
| ray_laptop | Robin_Watts: OK. but if we were using an allocator that has been freed, that'll be consistent and will happen on debug builds | 19:31.03 |
| Robin_Watts | The debug build does give some cryptic messages. | 19:31.26 |
| | "this allocator is not idle" or something. | 19:31.43 |
| ray_laptop | does every malloc/free in lcms get a context structure ? | 19:31.46 |
| Robin_Watts | Every malloc/free gets a context pointer, yes. | 19:32.04 |
| | and the context pointer *is* the gs_memory_t. | 19:32.13 |
| | but the context pointer has to be set on every call into lcms. | 19:32.43 |
| ray_laptop | Robin_Watts: OK, but where does that come from ? i | 19:32.45 |
| Robin_Watts | In unthreaded mode, you call cmsMakeProfileBlahBlahBlah(foo,bar,baz) | 19:33.14 |
| | In threaded mode, you call cmsMakeProfileBlahBlahBlahTHR(context, foo,bar,baz) | 19:33.36 |
| ray_laptop | So the problem is the call to do cms functions from the rendering thread ? | 19:33.41 |
| | Robin_Watts: give me a function example, please (what file ?) | 19:35.07 |
| Robin_Watts | The problem is (I think) that if we make a cms link in a rendering thread and then destroy it in the main thread, we get different contexts. | 19:35.12 |
| | gsicc_lcms2.c | 19:35.16 |
| ray_laptop | OK. momentico | 19:35.26 |
| Robin_Watts | gscms_get_profile_handle_mem calls cmsOpenProfileFromMemTHR((cmsContext)mem,...) for example | 19:35.49 |
| | Then when we make a link in gscms_get_link_proof_devlink we get another memory * (dunno if this is the same or not) and we call: cmsCreateMultiprofileTransformTHR((cmsContext)memory,...) | 19:37.05 |
| ray_laptop | Robin_Watts: I see: cmsOpenProfileFromMem(buffer,input_size) -- there is no context/mem_ptr | 19:37.50 |
| Robin_Watts | Are you looking at the right file? | 19:38.06 |
| | gsicc_lcms2.c, not gsicc_lcms.c | 19:38.15 |
| ray_laptop | Robin_Watts: sorry. switching... | 19:38.47 |
| radistao | Hi, guys. I have question about ghostscrip/postscript usage: i have watermark.ps file, which watermarks every page with simple text. now i need to center this text. i locate text using "/Arial-Bold 120 selectfont .5 setgray 100 100 moveto 45 rotate (Sample) show". Now i need to pass values instead of "100 100" from command line. | 19:39.06 |
| | How this can be done? | 19:39.25 |
| ray_laptop | radistao: after the move to the desired center point, and the rotation, you need to move backwards by 1/2 of the string size... | 19:41.29 |
| Robin_Watts | radistao: You need to learn some postscript. Dup the string, measure the string, measure the width of the page, do some maths to get where to move to... | 19:41.48 |
| ray_laptop | radistao: e.g. /Arial-Bold 120 selectfont .5 setgray 100 100 moveto 45 rotate (Sample) dup stringwidth pop 2 div 0 moveto show | 19:42.53 |
| | radistao: assuming that 100 100 gets replaced with where you want to the center of the string to be | 19:43.49 |
| Robin_Watts | Hi mvrhel. Sorry, had stepped away for dinner. | 19:44.04 |
| mvrhel | no problem. | 19:44.27 |
| Robin_Watts | I burbled earlier in the logs about what I think the problem is. | 19:44.46 |
| | I can recap, or you can read that if you want (that is probably as clear as I'll manage to make it) | 19:45.08 |
| ray_laptop | radistao: to use values from the command line, pick an unused variable name, e.g. WMctrX and WMctrY then use -dWMctrX=___ -dWMctrY=___ on the command line and just replace the 100 100 in the PS snippet with WMctrX WMctrY | 19:45.58 |
| mvrhel | Robin_Watts: I read it. I am not going to be of much help on this in the short term unfortunately. I have a customer issue that I need to tend to that has Miles involved and it is pretty much P1 for me | 19:46.10 |
| ray_laptop | Robin_Watts: so, back to the memory issue... | 19:46.17 |
| Robin_Watts | mvrhel: Sure. I understand. | 19:46.24 |
| | Good luck. | 19:46.27 |
| ray_laptop | mvrhel: oh, oh -- they're bugging Miles ??? | 19:46.42 |
| | mvrhel: I'll see if I can figure out what Robin_Watts is seeing... | 19:47.00 |
| mvrhel | he got involved since they were not answering my emails | 19:47.09 |
| | then it all cascaded from there | 19:47.15 |
| Robin_Watts | Can you at least confirm whether my understanding is flawed or not; are profiles/links etc shared at all between threads? | 19:47.21 |
| mvrhel | anyway back to the saltmine | 19:47.30 |
| Robin_Watts | (or just say if you don't know) | 19:47.41 |
| ray_laptop | Robin_Watts: I _think_ the links get cached in a common cache shared amongst the threads. They are rc'ed by the threads so the cache manager knows when one can be freed | 19:48.37 |
| Robin_Watts | Right. | 19:48.50 |
| | That goes exactly against what mvrhel told me (or what I believe he told me at least) | 19:49.15 |
| ray_laptop | but when a profile is freed, it has a 'mem' pointer as to which allocator allocated it | 19:49.27 |
| mvrhel | due to lcms not being thread safe we had to disable the common cache | 19:49.56 |
| ray_laptop | Robin_Watts: it's been a while (> 1yr) since I did the MT extensions to the link profile stuff, so let me check | 19:50.16 |
| mvrhel | thread safe in the sense that we cant use the same link amongst threads | 19:50.21 |
| | so each imager state has its own link cache | 19:50.50 |
| | i.e. each band creates a new one | 19:51.02 |
| ray_laptop | mvrhel: Oh, I missed that (you probably found that while getting it to actually work) | 19:51.09 |
| mvrhel | yes. this was sometime ago | 19:51.20 |
| | when we fixed the many MT bugs | 19:51.26 |
| Robin_Watts | Right, so I shouldn't see the main thread trying to destroy links created in threads then? | 19:51.29 |
| ray_laptop | mvrhel: and each thread has it's own chunk allocator | 19:51.36 |
| mvrhel | when the image state is destroyed for the band the cache should be destroyed too | 19:51.59 |
| ray_laptop | Robin_Watts: all of the profiles in a cache are (should be) freed when the link cache is destroyed | 19:52.32 |
| Robin_Watts | So where is the image state destroyed for a band? teardown_threads? | 19:52.54 |
| mvrhel | I think in the big raster function | 19:53.05 |
| | that is where it is created | 19:53.10 |
| ray_laptop | Robin_Watts: and the main thread should not have any pointers to anything link profiles that were created by the threads | 19:53.12 |
| mvrhel | at the start | 19:53.13 |
| | gxclrast | 19:53.18 |
| Robin_Watts | ok, thanks mvrhel. Let's not distract you any more. | 19:53.58 |
| radistao | ray_laptop: /Arial-Bold 120 selectfont .5 setgray 100 100 moveto 45 rotate (Sample) dup stringwidth pop 2 div 0 moveto show -- This works great! | 19:54.02 |
| mvrhel | oh the cache is share amongst bands | 19:54.20 |
| | but each thread has its own | 19:54.25 |
| | it comes from the device link cache | 19:54.32 |
| | see line 601 in gxclrast | 19:54.41 |
| | now I remember | 19:54.44 |
| ray_laptop | mvrhel: OK. that makes more sense. since a thread presumably may be used to render more than a single band as the page is rendered | 19:55.05 |
| mvrhel | so each thread instance has is own icc_cache_cl | 19:55.09 |
| | which is the icc cache maintained across the bands for the thread | 19:55.40 |
| | search on that | 19:55.48 |
| Robin_Watts | That's fine; every thread gets it's own gs_memory_t *, so if that's used for multiple bands, then it's fine to use the links created with that in those same bands. | 19:55.53 |
| mvrhel | need to get back to the salt.... | 19:55.56 |
| ray_laptop | comment circa line 196 in gxclthrd.c | 19:56.00 |
| Robin_Watts | mvrhel: Thanks. | 19:56.02 |
| ray_laptop | Robin_Watts: and it looks like it shares the 'master' link cache depending on #if CMM_THREAD_SAFE | 19:56.55 |
| | Robin_Watts: what's that defined as with lcms2 ??? | 19:57.08 |
| Robin_Watts | Always 0 currently. | 19:57.28 |
| | ray_laptop: http://pastebin.com/PvfBqdFW | 19:58.39 |
| | That's what I've caught in gdb. | 19:58.55 |
| | gs_lcms2_free is being called with a memory pointer of 12b3a80, right? | 19:59.30 |
| radistao | ray_laptop: /Arial-Bold 120 selectfont .5 setgray 100 100 moveto 45 rotate (Sample) dup stringwidth pop 2 div 0 moveto show -- this calculates inly string width, but does not account page width | 20:00.09 |
| Robin_Watts | which is the memory pointer given by wrapping the underlying allocator into a chunk allocator for thread 2. | 20:00.25 |
| radistao | ray_laptop: i need some thing like x = (pageWidth - stringWidth) / 2; y = (pageHeight - stringHeight) / 2 | 20:01.06 |
| Robin_Watts | Oh, hmm, that does make sense actually, doesn't it. | 20:01.36 |
| | That's the line that's destroying that threads device. | 20:02.06 |
| ray_laptop | Robin_Watts: right, so it rc_decrements (and thus frees) the profiles that were used. | 20:04.36 |
| Robin_Watts | Right, so I've caught a bad example in gdb. | 20:04.51 |
| | I'm knackered. I'm going to call it a night now and then try to come at this fresh in the morning. | 20:05.11 |
| | Aha. I'm going to extend every block by a pointers worth, and put the mem * in that place. | 20:07.40 |
| | That way when I come to free, I can check that I'm getting the same mem * back again. | 20:07.57 |
| ray_laptop | Robin_Watts: it's freeing the device_profile -- I thought that was shared, so it may be a ref_count problem. | 20:08.27 |
| Robin_Watts | ray_laptop: This may not be a problem at all. | 20:08.59 |
| | This particular instance where I've caught it was by some (flawed) debugging code of mine. | 20:09.15 |
| | So I may have just caught it in the middle of a perfectly reasonable operation. | 20:09.48 |
| | Let me bash on it some more tomorrow before I bother you any more with it. | 20:10.12 |
| ray_laptop | Robin_Watts: you are able to reproduce it on peeves ??? | 20:11.55 |
| Robin_Watts | peeves is the only place I can reproduce it. | 20:12.11 |
| ray_laptop | Robin_Watts: well, at least that's easy for me to do debugging on (since I can use ddd and not be over a network) | 20:13.08 |
| | Robin_Watts: I'll build it and poke around a bit. Does it fail with a debug build ??? | 20:13.39 |
| Robin_Watts | That's be way too easy. | 20:13.54 |
| | make pcl XCFLAGS="-g" is the best way I've found to make a version that fails, with some limited debuggability. | 20:14.23 |
| ray_laptop | Robin_Watts: OK. Thanks. I'll post anything I find on the bug report so you don't have to search for it in the logs | 20:14.55 |
| radistao | ray_laptop: so is it possible to calculate text position like x = (pageWidth - stringWidth) / 2; y = (pageHeight - stringHeight) / 2 ? | 20:17.19 |
| ray_laptop | radistao: assuming that you are at an 'initgraphics' state where the clip path is the printable area of the page, then the page center can be calculated: | 20:19.12 |
| | radistao: using: clippath pathbbox 2 index sub 2 div /PctrY exch def 2 index sub 2 div /PctrX exch def pop pop | 20:22.08 |
| | radistao: this sets PctrX and PctrY to the center of the imageable area on the page (as defined by the clippath) | 20:22.47 |
| | heading to the office (and peeves). bbiab | 20:23.55 |
| ray_work | radistao: oops. that should be: clippath pathbbox 2 index add 2 div /PctrY exch def 2 index add 2 div /PctrX exch def pop pop | 20:38.17 |
| | radistao: but I am confused about what you actually want, since orignally you said "Now i need to pass values instead of "100 100" from command line." | 20:40.04 |
| radistao | actually i need to make this text "/Arial-Bold 120 selectfont .5 setgray 100 100 moveto 45 rotate (Sample) show" not in [100; 100], but locate text on page center | 20:41.17 |
| | in regular languages this is calculated like this : | 20:41.40 |
| | x = (pageWidth - stringWidth) / 2; y = (pageHeight - stringHeight) / 2 | 20:41.49 |
| | but PS is very unusual language | 20:42.12 |
| rayjj | Robin_Watts: where is 'thesis.pcl' it's not attached to the bug. | 20:42.13 |
| Robin_Watts | tests/pcl/thesis10.pcl | 20:42.31 |
| rayjj | radistao: you want a strange language, have a look at M (formerly MUMPS before ANSI named it) | 20:43.02 |
| | or B1800 microcode -- that's even stranger | 20:43.49 |
| | Robin_Watts: thanks | 20:44.16 |
| radistao | no, i do not want strange language - i want to center text. But to make it in PS after 2 days studying - very difficult | 20:44.18 |
| Robin_Watts | radistao: Pretty much the first thing you'll find in any text about postscript is the fact that it uses reverse polish notation. | 20:45.16 |
| | I don't believe you can have been studying for 2 days and not been told that :) | 20:45.34 |
| radistao | i undertsant this stack notation | 20:45.54 |
| rayjj | radistao: pstack is your friend | 20:46.36 |
| radistao | but, unfortunately, this is not enough to make a programm | 20:46.57 |
| | rayjj: i'm on win | 20:47.29 |
| rayjj | Robin_Watts: I'm seeing several "chunk_free_obj failed, object 0x315c6d8 not in chunk at 0x314d8f0, size = 65584" messages before the SEGV | 20:51.55 |
| Robin_Watts | sometimes, yes. | 20:52.13 |
| | It's all horribly indeterministic because of the threading. | 20:52.36 |
| | but that fits with my belief that we are trying to free stuff with a different gs_memory_t than we had when we alloced it. | 20:53.06 |
| rayjj | Robin_Watts: I ran it three times. One time I got 3 messages, another, just one message, the third time it hangs | 20:54.40 |
| | Robin_Watts: so I see what you mean. | 20:54.51 |
| | radistao: if you clearly state what you want, I'll be able to help (while waiting for the computer to do things), but so far, I don't know what you want from the command line, and why. | 21:02.56 |
| | radistao: if you just want to center a watermark string, that's easy | 21:03.17 |
| radistao | exactly i want this | 21:05.33 |
| | not from command line only - maybe from ps script | 21:06.12 |
| | rayjj: i just want to center a watermark string | 21:12.43 |
| | pls, help me (while waiting for the computer to do things) | 21:13.03 |
| jen__ | hello radistao | 21:37.36 |
| radistao | jen__: hi, jen__ | 21:38.13 |
| sebras | tor8: ouch! my eyes! the gtk+ viewer does not do doublebuffering of the image I noted when resizing the windows. | 21:44.18 |
| | tor8: but the viewer itself appears to scroll happily. | 22:01.55 |
| | tor8: ah! now I see. since you remove_page() whenever the width's don't match and re-insert them when asked to render them this is what is causing the flickering. | 22:06.51 |
| | of course the reason that this doesn't happen in the normal viewer is that there is no fit to width. sorry for the noise. :) | 22:07.40 |
| | valgrind seems to indicate that a gtk_widget_destroy(window); or similar might be desired after the gtk_main_loop()... | 22:08.26 |
| | but since it's gtk+-based I have learned at work that I'd better run it with their suppression-file. :-P | 22:08.55 |
| mvrhel_laptop | bbiaw | 22:55.50 |
| rayjj | Robin_Watts: for the logs. on peeves, using a debug build, I breakpointed on all of the dmprintf1(mem, "*** chunk_obj_alloc: this memory allocator is not idle, used for: %s\n" statements | 23:51.52 |
| Robin_Watts | ok... | 23:52.13 |
| | and they were hit in the chunk_free_obj calls from teardown ? | 23:52.36 |
| | or free_chunk, or whatever? | 23:53.08 |
| rayjj | Robin_Watts: and it detected a case where thread 1 (main thread) memory was 121f320, but that was the SAME memory as is being used in gscms_get_link when it _should_ be 0x12c6450 | 23:54.49 |
| Robin_Watts | Right. | 23:55.21 |
| rayjj | Robin_Watts: when in thread 348 (rendering a band) | 23:55.24 |
| Robin_Watts | so I'm not going mad, there is something wrong here. | 23:57.11 |
| rayjj | the gsicc_get_link_profile call has the correct 'memory', but it's calling gscms_get_link at line 808 with cache_mem->non_gc_memory which is wrong! | 23:57.12 |
| Robin_Watts | Ah. | 23:58.23 |
| | cache_mem comes from pis->icc_link_cache->memory. | 23:58.42 |
| rayjj | Robin_Watts: but I thought each thread was supposed to have its own link_cache | 23:59.28 |
| Robin_Watts | In the discussion with mvrhel earlier, we decided that each thread had... yeah. | 23:59.38 |
| | Forward 1 day (to 2012/10/04)>>> | |
IRC Logs