| | <<<Back 1 day (to 2012/04/15) | 2012/04/16 |
| Robin_Watts | For tor (reading the logs) (and for my crap memory), I've looked into why we are now linking all the font data etc into a mupdfclean build. | 11:03.12 |
| | Opening a PDF file now goes through the pdf_document interface, rather than calling all the entrypoints separately. That means it pulls everything in at once. | 11:04.11 |
| | I don't consider it worth changing that. | 11:04.24 |
| | Damn. Too slow :) | 13:58.19 |
| kens | :-) | 13:58.35 |
| | funny cluster resutls. | 13:59.00 |
| | 'no change' code caussing changes | 13:59.14 |
| Robin_Watts | :( | 14:06.57 |
| Shyren | I am using djet500 device but its not printing color. Any other settings I should be using? -sColorModel=CMY or -sColorModel=RGB doesn't help. | 14:21.27 |
| kens | ProcessColorModel might | 14:21.46 |
| | But I think that is an unsupported device | 14:22.23 |
| | Certainly I know little about it | 14:22.33 |
| chrisl | Shyren: you might try the djet500c device instead | 14:27.24 |
| Shyren | chrisl: I tried that but it prints black on the right fold of the color image where its supposed to be white and shouldn't print anything. | 14:44.15 |
| chrisl | Shyren: well, that sounds like a bug. It's a contributed device, so not one we support - you could try to track down the contributor. | 14:47.39 |
| | Shyren: are you building your own gs, or using a prebuilt/packaged one? | 14:58.31 |
| Shyren | Chrisl: I am building my own gs from source. I am wondering if there is any parameter that I should be passing. | 15:00.38 |
| chrisl | Shyren: no, there's no parameter - you need to use the 500C driver, but there *appears* to be a bug or an incompatibility with more modern DeskJets - what Deskjet are you actually printing to? | 15:01.47 |
| Shyren | Chrisl: I am printing ok Officejet H470, which is not even a DeskJet. Don't know what difference is there actually? The B&W print comes out fine. | 15:03.16 |
| chrisl | Shyren: okay, give me a second...... | 15:03.43 |
| | Shyren: can you apply this patch: http://pastebin.com/ngPUTqBf | 15:05.02 |
| | and tell me what the result is? (I'd suggest "cleaning" the build to make sure everything gets rebuilt properly). | 15:05.55 |
| Shyren | chrisl: Yeah let me clean and try! | 15:06.36 |
| Robin_Watts | Gah. I need a sanity test please: http://pastebin.com/ByngNV9z | 15:26.49 |
| | I've written "my_sinf", which should do the same as sinf, except in a quick and dirty way, using a lookup table. | 15:27.19 |
| | And it works in almost all files. | 15:27.32 |
| | but in 1, I get a white line down the middle of a shading. Can anyone see anything stupid I'm missing? | 15:27.51 |
| kens | Well it *looks* OK | 15:29.07 |
| | Should 512 be 511 ? | 15:29.38 |
| | To give the other half of the curve ? | 15:29.57 |
| Robin_Watts | Which occurence? | 15:30.00 |
| kens | Actually no I think its OK | 15:30.09 |
| | I'm confusing myself now.... | 15:31.18 |
| | Should a = 512 - a; be 511 - a ? | 15:31.32 |
| Robin_Watts | I don't think so. | 15:31.59 |
| | if a == 256, then 512 - 256 = 256, which is correct. | 15:32.12 |
| kens | is doing a number | 15:32.13 |
| | No I think that's OK | 15:32.17 |
| | But 512 is not a possible number ? | 15:32.36 |
| | Since a & 511 | 15:32.41 |
| Robin_Watts | Right. | 15:32.49 |
| | 511 is 'just before the wave loops'. | 15:33.11 |
| | so it maps to 1, which is "just after the wave starts", so that seems correct. | 15:33.22 |
| kens | Yes, that's whats' making my hed pound | 15:33.23 |
| | So it still looks OK to me | 15:34.52 |
| Robin_Watts | Removing the 0.5f + solves it, but I can't see why. | 15:38.19 |
| | but I don't really care. | 15:41.44 |
| kens | I'd have to sit down and munge some numebrs to understand better.... | 15:42.20 |
| Robin_Watts | I suspect it's not sinf/cosf at fault, but rather the code that calls it. But it works, so I'm happy. | 15:43.36 |
| kens | Fair enough | 15:43.46 |
| | Robin_Watts : I've got my branch screwed up again (I don't know why this keeps happening). | 15:44.50 |
| | THe master is one commit haead of me. | 15:45.12 |
| | Err, I think | 15:45.18 |
| | * f5a21db (cluster/ken) WIP on master: ffedf4d Fix ref counting of CIEBased 'p | 15:45.58 |
| | |\ | 15:45.58 |
| | | * 8b13e0b index on master: ffedf4d Fix ref counting of CIEBased 'params' durin | 15:45.58 |
| | |/ | 15:45.58 |
| | * ffedf4d (HEAD, origin/master, tmp_mem_branch, master) Fix ref counting of CIEB | 15:45.58 |
| | * 34f32ee Fix 692707. Clear pointers in text_enum when freeing the widths array. | 15:45.59 |
| | * fd34d15 bmpcmp: Flip psdcmyk images to be the right way up. | 15:45.59 |
| | Can you remind me how to get this straightened out please ? | 15:46.10 |
| | git something HEAD~1 | 15:46.30 |
| | Note I have uncommitted changes in the branch | 15:46.50 |
| Shyren | Chrisl: Now color comes up but then it gets stuck and have to cancel the printing. Also need to improve resolution, I will try -rWxH for that. | 15:47.21 |
| Robin_Watts | kens: sorry, was fetching tea. | 15:50.09 |
| kens | N | 15:50.13 |
| | NP | 15:50.16 |
| chrisl | Shyren: that's a shame, 'cause it works okay on my dj970C - where does it get stuck? | 15:50.27 |
| kens | Tried to fix it the same way as last time, just got worse..... | 15:50.29 |
| Robin_Watts | So you've got something committed to master, that should have been committed on tmp_mem_branch ? | 15:50.55 |
| kens | Robin_Watts : I believe so, yes. | 15:51.05 |
| | Its causing me to have seg faults that are masking my own work | 15:51.15 |
| Robin_Watts | actually, no. | 15:51.48 |
| kens | No ? | 15:51.54 |
| Robin_Watts | If you look at the git logg you pasted, origin/master, master and tmp_mem_branch are all the same. | 15:52.25 |
| kens | Then I'm confused.... | 15:52.39 |
| | Nothing new there | 15:53.08 |
| Robin_Watts | The triangle thing with cluster/ken at the top? That's to do with "git cluster" | 15:53.10 |
| kens | Oh.... | 15:53.17 |
| Shyren | Chrisl: On one page it gets stuck right after printing the image in color. Previously it was printing black there. There is no text for few lines after the image in that page. On another page it gets stuck after printing some text after the image. | 15:53.23 |
| kens | I'm getting a load of seg faults on QL files that I didn't get before. I don't *think* my code is causing it. I guess its possible. | 15:53.54 |
| Robin_Watts | In order to get cluster based pushing working, I have to stash everything, and then push the stash. | 15:54.02 |
| | but I can't stash unchanged code. | 15:54.11 |
| kens | I'll squirrel it away and try a clean copy. | 15:54.12 |
| Robin_Watts | so I have to put something into the tree so that a stash works. | 15:54.34 |
| chrisl | Shyren: so it's stopping after all the marks are made on the page? | 15:54.47 |
| Robin_Watts | and the upshot is you get the extra entry in the logg. | 15:55.13 |
| kens | OK I can live with that. I wonder what's causing my seg faults though | 15:55.27 |
| Robin_Watts | kens: git stash, then git cluster, to test the 'clean' version. | 15:55.36 |
| | Then git stash pop to get your changes back. | 15:55.42 |
| Shyren | Chrisl: not really. It stops after printing few lines after the image (color). There are more lines after that and it doesn't print those. | 15:55.43 |
| ray_laptop | kens: those segfaults are really strange. | 15:55.45 |
| kens | Exaclth what I'm about to try Robin_Watts | 15:55.47 |
| ray_laptop | the ones that showed up when I "fixed" the text_enum dangling pointer. | 15:56.11 |
| kens | ray_laptop : my problems seem to be related to that (I think). | 15:56.34 |
| ray_laptop | kens: I keep finding more (different) things to fix | 15:56.36 |
| kens | Its some of the QL files 11-*.ps to 13-*.ps | 15:56.53 |
| Robin_Watts | Damn. kens beat me to it again. | 15:58.11 |
| kens | Well you suggetsed it Robin :-) | 15:58.24 |
| Robin_Watts | yeah. I'm not complaining (really). | 15:58.45 |
| | ray_laptop, mvrhel: When do you get to the UK? | 15:59.06 |
| ray_laptop | my tortoise git seems honked up. It's hanging in "Please wait" looking for what's changed, but "git status" shows the single file right away | 15:59.14 |
| kens | ray sent his itinerary robin | 15:59.23 |
| ray_laptop | Robin_Watts: Monday about noon iirc | 15:59.35 |
| Robin_Watts | ok. | 15:59.52 |
| mvrhel | I arrive Sunday morning | 16:00.16 |
| | Robin_Watts | 16:00.20 |
| Robin_Watts | I'd mentioned the idea of clay pigeon shooting on the monday if anyone was up for it. | 16:00.21 |
| Shyren | Chrisl: It seems that data is moved up a bit. | 16:00.23 |
| Robin_Watts | There is a place not far from Heathrow that does it. | 16:00.33 |
| ray_laptop | tortoise git hanging -- I hope that doesn't mean my laptop is about to crash again | 16:00.37 |
| mvrhel | Robin_Watts: sounds like fun | 16:00.39 |
| Robin_Watts | but people may prefer to just do the tourist thing. | 16:00.45 |
| chrisl | Shyren: I don't know what else to suggest - "PCL 3 Enahnced" doesn't seem to be documented anywhere, so I've no idea what should be sent to the printer. | 16:00.51 |
| mvrhel | although I was going to go to a museum | 16:00.58 |
| | on Monday | 16:01.01 |
| Robin_Watts | mvrhel: Any one in particular? | 16:02.23 |
| mvrhel | well last time I went to the British Museum. | 16:02.50 |
| | I was thinking of the Science museum maybe this time. But I am open to suggestions | 16:03.08 |
| Robin_Watts | South Kensington has a good set (Science Museum, Natural History, Geoglogical Museum and V&A are all practically next to one another) | 16:03.15 |
| mvrhel | ok that is where I was thinking | 16:03.26 |
| Robin_Watts | and Harrods is there too which is good for a tourist visit. Possibly Hamleys too. | 16:03.55 |
| | No, Hamleys is Regent Street. Shame on me. | 16:04.42 |
| mvrhel | ok, maybe I should have you come and be my tour guide | 16:05.02 |
| marcosw | mvrhel: I like the Tate Modern: http://www.tate.org.uk/visit/tate-modern | 16:08.07 |
| Robin_Watts | I like the idea of the Tate Modern :) | 16:08.33 |
| | It puts all the modern art you'd never want to look at in one large building that's nicely impossible to bump into by accident :) | 16:09.04 |
| mvrhel | :) | 16:10.24 |
| ray_laptop | I'm seeing a warning I don't recall seeing previously: | 16:12.13 |
| | warning: LF will be replaced by CRLF in gs/base/gscscie.c. | 16:12.15 |
| | The file will have its original line endings in your working directory. | 16:12.17 |
| Robin_Watts | (It is a nice building though - whether you like the contents depends on your stance on Modern Art) | 16:12.42 |
| | ray_laptop: That's not something to worry about. | 16:12.54 |
| ray_laptop | gonna have to wait for ken's and Robin_Watts' cluster runs. :-( BBIAB. | 16:13.08 |
| kens | Sorry ray.... | 16:13.16 |
| Robin_Watts | ray_laptop: Mine will be very quick. | 16:13.23 |
| marcosw | The UK science museums aren't bad, but they are disappointing compared to the Deutsches Museum. | 16:14.04 |
| Shyren | Chrisl: Thanks for all help. Should I try any other device which could be near to "PCL 3 Enhanced" implementaiton? | 16:14.15 |
| chrisl | Shyren: there is a pcl3 device, but I don't know anything about it - might be worth trying if you can work out the options to give it | 16:15.57 |
| Shyren | chrisl: Thanks will try! | 16:16.32 |
| mvrhel | marcosw: I can imagine the German Science Museums are cool | 16:17.51 |
| kens | Deutsches Museum is excellent | 16:18.13 |
| mvrhel | off to the coffee shop | 16:20.50 |
| | bbiab | 16:20.52 |
| chrisl | Shyren: there's a bunch of variants of the pcl3 driver if you look about line 161 in contrib/pcl3/src/gdevpcl3.c | 16:21.21 |
| Shyren | chrisl: I think by default it doesn't compile in the build. | 16:26.36 |
| | chrisl: I mean pcl3 | 16:26.45 |
| chrisl | Shyren: what platform are you on? | 16:27.23 |
| ray_laptop | it's really concerning that there's so many segfaults showing up now after fixing a long standing segfault (and the zcharx.c has NOTHING to do with the current issues) | 16:30.23 |
| kens | i think that's the problem I'm fcing too | 16:30.40 |
| | facing | 16:30.43 |
| | I'm getting seg faults that should not be anything to do with the code I'm testing.... | 16:31.01 |
| ray_laptop | kens: the next change fixes (at least) 12-13.PS -- going on to 11-13.PS next | 16:31.22 |
| Robin_Watts | ray_laptop: But these are genuine faults that you're finding? | 16:31.42 |
| kens | ray_laptop : thanks ray | 16:31.43 |
| ray_laptop | all the ones I'm seeing are during the alloc_restore_all that cleans up at the end of the job. | 16:32.09 |
| Robin_Watts | Sounds like the net effect is that gs will be more stable at the end of this process. | 16:32.19 |
| kens | Ah. None fo them are iwth pdfwrite (I don't think) and its only pdfwrite code I'm changing. So I don't *think* my code is at fault. | 16:32.43 |
| ray_laptop | this function is sort of unique in that stable_mem is processed even though stable_mem is not ordinarily subject to save/restore | 16:33.00 |
| kens | I am however, continuously confused by the seg faults appearing. Since my own code *does* regularly introduce them.... | 16:33.10 |
| | Anyway, time for me to be off, goodnight everyone | 16:33.31 |
| Shyren | chrisl:Mac | 16:33.35 |
| Robin_Watts | Night kens. | 16:33.38 |
| kens | BTW Robin_Watts the seg faults do show up with a 'clean' set of source in my branch, so I don't htink its me :-) | 16:34.10 |
| | Thanks again, and goodnight | 16:34.16 |
| chrisl | Shyren: I'm pretty sure the devices in the contrib directory should be included in the Mac bulid | 16:34.19 |
| ray_laptop | kens: as I mentioned in the email, some of the segfaults may be caused by chunks being freed so that the dangling pointers are now in invalid memory | 16:34.23 |
| | for the logs: previously the dangling pointers may have (only) pointed to a free area in a chunk that's still around. | 16:35.38 |
| | which is still bad enough. Memento _should_ show those up since it puts every object in its own chunk. | 16:36.24 |
| Robin_Watts | Memento won't catch reads through those pointers, but it will catch writes (as it keeps the blocks around and specifically checks them) | 16:37.53 |
| | With valgrind + memento it should catch reads too. | 16:38.04 |
| ray_laptop | darn. 11-13 doesn't segfault on my debug build (from HEAD) on peeves or on windows | 16:42.11 |
| chrisl | Shyren: I'm trying these command line options: -sColorModel=CMYK -sDEVICE=hpdj1120c -o out.pcl | 16:43.58 |
| Shyren | chrisl: I get this on hpdj1120c <Notice>: pdf14_compressed_encode_color devn_params not from pdf14 device, device = 'hpdj1120c' | 16:46.28 |
| | chrisl: <Notice>: GPL Ghostscript 9.05: pdf14_compressed_encode_color devn_params not from pdf14 device, device = 'hpdj1120c' | 16:46.40 |
| chrisl | Shyren: it sounds like these devices have bitrotted :-( They aren't ours, so we really don't know much about them. | 16:47.33 |
| | Shyren: as a workaround, you could convert to Postscript first, then convert to PCL3....... | 16:48.50 |
| Shyren | chrisl: pcl3 works on one pdf but on others it gets stuck. Let me do the postscript but how is it going to help? | 16:51.16 |
| chrisl | Shyren: well, I'm assuming from the "Notice" messages you posted above, that the pcl3 device doesn't work correctly when there is transparency in the PDF, so converting to PS will "flatten" the transparency first. I'm just guessing, though | 16:53.09 |
| ray_laptop | oh, great (sarcastically). 11-13 segfaults with a release build, but not with a debug build :-( | 16:53.28 |
| | and it dies during "look09" GLOBINT _not_ in the final cleanup as other failures (so far) | 16:54.17 |
| Robin_Watts | ray_laptop: Try a profile build. | 16:55.44 |
| ray_laptop | Robin_Watts: doing that now | 16:55.52 |
| | also building a release version on Windows to see if it has problems | 16:58.35 |
| | darn. forgot to use -j5 on peeves for the profile build. Taking a LONG time. | 16:59.34 |
| | profile build on peeves doesn't segfault :-( | 17:00.44 |
| Robin_Watts | Ah, well, profile on unix means something different. | 17:02.48 |
| henrys | Robin_Watts:do you happen to recall a file that failed the bmpcmp for fill mode - your fill bmpcmp results are no longer around. | 17:02.51 |
| | ? | 17:02.53 |
| Shyren | chrisl: the notices above I got were from hpdj1120c but I will converting to PS first nd then to PCL3 | 17:03.02 |
| Robin_Watts | profile means -pg for unix, which actually changes the compiled code, it doesn't just keep the debug symbols. | 17:03.27 |
| | I think you might want to try make CFLAGS="-g" ? | 17:03.46 |
| | henrys: Urm, yes, just a mo. | 17:03.57 |
| | tests_private/customer_tests/ci2.test I think. | 17:04.22 |
| chrisl | I have to go - bye all! | 17:04.33 |
| Robin_Watts | night chrisl. | 17:04.42 |
| ray_laptop | hmm... the release build call stack shows up in 'moveshow' which is what my zcharx.c "fixed" (or at least changed) | 17:05.07 |
| henrys | hmm actually I detected a problem that should be seen on every fts yet it wasn't in the bmpcmp. The border is missing a closepath resulting in a missing join. | 17:06.11 |
| Robin_Watts | If it's using square caps, then it won't be visibly different? | 17:06.53 |
| henrys | well the border common to all the fts tests is wrong and I'm just surprise that didn't pop out at us when we looked at the bmpcmp results but I suppose there are limits on the number of files bmpcmp will look at. | 17:09.48 |
| Robin_Watts | bmpcmp stops after 1000. My attention stops before that :( | 17:11.25 |
| henrys | anyway no big deal I'll make a small example and we'll see what's going on. | 17:11.53 |
| ray_laptop | narrowing it down with eprintf statements -- at least the segfault hasn't disappeared. Sure is tedious, however | 17:13.11 |
| Robin_Watts | c12.test is pretty much the smallest example you could hope for. | 17:13.32 |
| | ci2.test, sorry. | 17:13.55 |
| henrys | I imagine they are different issues. | 17:15.54 |
| | but I will look at that one first. | 17:16.38 |
| Robin_Watts | If you can fix ci2.test it may well punt the ball back into my court. | 17:17.42 |
| ray_laptop | well that wasn't too bad. Under some error conditions, the 'penum' wasn't being set, so we'd dereference someplace invalid (depending on the stack) YUCK ! | 17:19.14 |
| | mvrhel_laptop: I am changing many of the rc_decrement_only calls to rc_decrement to clean up dangling pointers to freed items in gscscie.c -- do you recall why you uesd rc_decrement_only ??? | 17:38.23 |
| | mvrhel_laptop: the changes are in the *_final functions | 17:39.22 |
| mvrhel_laptop | ray_laptop: I don't recall | 17:40.28 |
| | I am knee deep in pattern stuff right now | 17:40.39 |
| | sorry | 17:40.42 |
| ray_laptop | on the uninitialized 'penum' I am sort of surprised that we didn't get a warning about that | 17:40.45 |
| | mvrhel_laptop: np. Just thought I'd ask. | 17:40.52 |
| mvrhel_laptop | yes | 17:40.53 |
| ray_laptop | mvrhel_laptop: related to the planar spot color change set ? | 17:41.36 |
| mvrhel_laptop | yes. | 17:42.04 |
| | looking at those decrements, I have no idea why I did not use rc_decrement | 17:43.13 |
| | thanks for fixing this | 17:43.26 |
| | ray_laptop ^^ | 17:43.33 |
| ray_laptop | mvrhel_laptop: sorry for the dsitraction. | 17:43.51 |
| mvrhel_laptop | I need a high level color version of strip_tile_rectangle | 17:45.52 |
| | otherwise I end up having to break this thing up into hl rect fills which is ugly in itself. this does not quite work without an ugly hack though for the clist due to the may that the pattern device color procs are set up with a can't write proc. | 17:48.30 |
| ray_laptop | mvrhel_laptop: I checked my pockets -- I don't have one | 17:48.37 |
| mvrhel_laptop | ok. so I need a bit of advice here. do I make a new device proc or change the params to strip_tile_rectangle so that I can pass along devn colors | 17:49.42 |
| | ray_laptop? | 17:49.47 |
| ray_laptop | I guess the clist HL color writing was never really finished | 17:49.50 |
| mvrhel_laptop | well the rect fill works fine | 17:50.02 |
| | the issue is if you have a pattern mask for example with a hl color | 17:50.17 |
| ray_laptop | mvrhel_laptop: you have to make a new proc -- changing parameters to old procedures can cause contributed devices to break. | 17:50.35 |
| mvrhel_laptop | ok. as I suspected | 17:50.47 |
| | all the strip tiling stuff assumes gx_color_index colors | 17:51.14 |
| | this will add a couple more days to this, but I am getting very close. | 17:51.38 |
| Robin_Watts | mvrhel_laptop: Wooooah! | 17:51.44 |
| ray_laptop | mvrhel_laptop: as long as you make a default function for older devices, then adding is preferred. | 17:51.55 |
| Robin_Watts | You're fiddling with strip_tile_rectangle, and you expect it to only take a couple of days? | 17:52.03 |
| mvrhel_laptop | yes. | 17:52.05 |
| | hehe well I am going to leverage the current code heavily | 17:52.23 |
| Robin_Watts | Into the valley of death rode the brave 600... | 17:52.41 |
| ray_laptop | mvrhel_laptop: I hope so | 17:52.42 |
| mvrhel_laptop | the changes in this work are probably as entangled in the code as the icc stuff was | 17:52.57 |
| | but they only effect the tiffsep and psdcmyk devices | 17:53.10 |
| | or any sep devices that are added by users | 17:53.33 |
| | or developers I should say | 17:53.44 |
| | anyway, time to get my hands dirty now... | 17:53.59 |
| ray_laptop | mvrhel_laptop: call if I'm not here or not responding ... | 17:54.34 |
| mvrhel_laptop | ok thanks | 17:54.46 |
| Robin_Watts | mvrhel_laptop: Good luck. That code is a rats nest of interdependencies. | 17:55.11 |
| mvrhel_laptop | yes. I know :( I thought I had made my way through it until this issue with the clist made my current approach too much of a hack | 17:55.47 |
| ray_laptop | OK. got the segfaults down to just a few (6). | 18:14.16 |
| henrys | Robin_Watts:I don't think it will come back to you, the problem is to get rid of all superflous moveto's in gl and I really don't have a sense of how much that is going to break until I start. Many of the problems would be fixed like ci2.test if gapto was treated identically moveto in stroke mode - i.e. in stroke mode gapto would create a new subpath. But it wouldn't save me from fixing gl/2 so I don't know that you should fool with | 18:15.45 |
| | it. | 18:15.46 |
| ray_laptop | running an errand. bbiaw. | 18:16.13 |
| Robin_Watts | henrys: My gut feeling is that the intent of this mode is that you can define a path one, and then stroke/fill it. | 18:17.01 |
| | and the area described by the path will be filled, but only the edges where the pen was down would result in a stroke. | 18:18.00 |
| henrys | yes I need to fix gl. | 18:18.58 |
| Robin_Watts | OK, I think I have document properties back in MuPDF. | 18:20.35 |
| mvrhel_laptop | ok this is not starting out well. added the proc defs in everywhere and crazy segv with the null device starting out of the gate... | 18:25.57 |
| | sigh | 18:26.02 |
| | oh I see why | 18:27.46 |
| | ok. got things building. now to do the actually work. off to eat lunch now though bbiaw | 19:02.47 |
| | Forward 1 day (to 2012/04/17)>>> | |
IRC Logs