| | <<<Back 1 day (to 2013/11/11) | 2013/11/12 |
| Robin_Watts | ray_laptop: Unless you're developing for Win 8.1, why do you need to upgrade? | 00:27.31 |
| | ray_laptop: I found a typo. | 00:59.41 |
| | Now I think the cache is working, but it's dying in my garbage collection code when it tries to reloc. | 01:00.03 |
| | ray_laptop: Latest version on robin/master. Maybe you can spot what I am doing wrong in the gc. | 01:10.59 |
| ray_laptop | Robin_Watts: OK, I'll download now, and check in the morning. Robin_Watts I assume you saw my discussion with mvrhel_laptop about the same ICC profile in and out being the cause of the "resampling" | 07:43.32 |
| | good morning to the .eu group | 07:44.12 |
| kens | Mornign ray | 07:44.19 |
| | working late again ? | 07:44.25 |
| ray_laptop | kens: and chrisl: | 07:44.28 |
| | kens: yep. | 07:44.36 |
| mvrhel_laptop | morning all | 07:44.37 |
| chrisl | good morning, ray | 07:44.39 |
| | and mvrhel_laptop.... | 07:44.49 |
| ray_laptop | mvrhel_laptop: you're working late, too! | 07:44.49 |
| kens | Oh Michael here too, and yesterday was a holiday in the us | 07:44.55 |
| mvrhel_laptop | beating on this stupid windows 8.1 stuff | 07:45.01 |
| | I dont think it was a real vacation day was it? | 07:45.12 |
| kens | No idea, henrys said it was veterans day | 07:45.25 |
| mvrhel_laptop | yes it was | 07:45.49 |
| | but it is not on the official holiday list | 07:46.14 |
| ray_laptop | Robin_Watts: (for the logs) I was going to download the 2013 Pro stuff to try and get a profiler that didn't die. AFAICT it will cost me just as much to get 2013 as 2012 given that the latest I have is 2008 | 07:46.22 |
| kens | Ah, well we're not current on US public holidays over ehre :-) | 07:46.43 |
| mvrhel_laptop | right | 07:46.49 |
| chrisl | I'm not even current on UK public holidays! | 07:47.01 |
| mvrhel_laptop | ok bed time for me. i finally got this thing working again | 07:47.01 |
| | talk to you all in about 8 hours.... | 07:47.12 |
| chrisl | Sleep well | 07:47.24 |
| kens | goodnight mvrhel_laptop | 07:47.28 |
| ray_laptop | The (free) CodeTune seems to work, but it doesn't let me launch gswin32c -- I have to start GS, then start a profile session, attach to the gswin32c process and then start GS processing once "sampling" starts | 07:48.06 |
| | I'd much rather have a working profiler that allowed for "instrumentation" rather than "sampling" so I can get results more like gprof | 07:48.55 |
| | as I mentioned, VS 2008 profiler gives me BSOD *immediately* whether sampling or instrumented mode. | 07:50.17 |
| | and Very Sleepy seems to collect samples (like CodeTune), but then dies while assembling the results | 07:51.04 |
| | so far, I have to recommend CodeTune. It's free and sort of works, and is worth every penny :-) | 07:51.50 |
| kens | Very Sleepy works OK for my limited needs | 07:52.09 |
| | I've not liked any recent version of the MS profiler, they're hard to use at best | 07:52.38 |
| ray_laptop | the major issue is that it has a minimum 1ms sampling period, which is rather sow on my laptop | 07:52.52 |
| | (my comment above relates to CodeTune) | 07:53.27 |
| | kens: I think Robin_Watts has also had success with Very Sleepy. | 07:55.06 |
| | At least with VS, if I (Miles) bought the current 2013 and it didn't work, I'd have the pleasure of demanding my money back from Redmond :-) | 07:56.16 |
| chrisl | Is VS2013 out yet? Last time I looked it was still a beta | 07:57.02 |
| kens | Good grief: | 07:57.04 |
| | http://www.bbc.co.uk/news/uk-england-manchester-24906040 | 07:57.04 |
| | And nobody noticed when raising it ? | 07:57.18 |
| chrisl | Actually, I quite like that! | 07:57.52 |
| ray_laptop | chrisl: it is slated for release on Nov 13, 2013, but you can buy it and download it now. I don't really know what you get if you buy it now | 07:57.57 |
| | kens: so, that isn't your flag ? | 07:58.52 |
| kens | Well, *nearly*.... | 07:59.04 |
| chrisl | ray_laptop: ah, okay - they usually give the "release date" as the day the physical media will be available... | 07:59.08 |
| ray_laptop | it looks sort of funny with some extra stripes | 07:59.12 |
| kens | The stripes normally go from centre to edge, not 'round' the edge.... | 07:59.32 |
| ray_laptop | is that some other country's flag, then ? | 07:59.45 |
| kens | Its supposed to be the UK flag | 07:59.56 |
| | But someone got it badly wrong | 08:00.05 |
| ray_laptop | maybe that's just the "Manchester Variant" ;-) | 08:00.21 |
| kens | and apparently nobody at the local government even noticed. | 08:00.25 |
| ray_laptop | kens: BTW, what is the Scottish flag going to be when they break away ;-) | 08:01.59 |
| kens | I assume the Saltire | 08:02.08 |
| ray_laptop | some tartan or the other ? | 08:02.12 |
| kens | Not he flag they've had for centuries, teh Saltire, or cross of St Andrew | 08:02.32 |
| | Its one of the flags incorporated into the Union flag | 08:02.54 |
| ray_laptop | kens: that seems rather boring by today's standards. They need to spruce it up a bit ;-) | 08:03.42 |
| kens | Well, its an old flag, but why change ? | 08:03.58 |
| | "In 2003 the Scottish Parliament specified the official colour of the flag using the international colour coding system and it was decided that the white St Andrew's Cross should appear on an azure background known as Pantone 300." | 08:04.53 |
| ray_laptop | how about some gradients and SMask drop shadow shading, and maybe a hologram embedded ;-) | 08:04.59 |
| kens | THey can do that with the currency :-) | 08:05.14 |
| chrisl | They'll hire a PR company who'll charge a large amount of money to tell them "use the flag you already have"...... | 08:05.33 |
| kens | Nah, the PR company will charge them lots of money for Ray's idea, then there'll be a huge public outcry and tehy'll have to change it back, for yet more expense | 08:06.07 |
| | Isn't that how government 'works' ? | 08:06.27 |
| chrisl | Only if someone from the PR company is reading this channel! Otherwise it would suggest the PR people actually thought of something different - unlikely! | 08:07.08 |
| kens | could believe this is how PR companies get their ideas | 08:07.29 |
| ray_laptop | kens: yeah, and those of us that got "pre-release" copies of the flag that got recalled will be able to make a lot of money because they'll be rare ;-) | 08:07.36 |
| chrisl | ray_laptop: especially if it's in the original, unopened packaging! | 08:09.16 |
| kens | Hmm, well marcos reckons that bug #694772 is a regression caused by Alex chaning the PDF interpreter for DOCINFO pdfmarks, but when I run it here with STOPONERROR it tells me its an invalid font | 08:09.29 |
| | And indeed, it *is* an invliad font, it has a FontMatrix of [0.04 0 0 0.-4 0 0] | 08:10.25 |
| ray_laptop | g'nite, all | 08:10.38 |
| kens | goodnight ray | 08:10.47 |
| chrisl | I wonder how other readers "open it correctly", then? | 08:13.03 |
| kens | Well, I've still to track it down further, but we know that Acrobat has a habit of ignoring numbers it doesn't like | 08:13.36 |
| | Very probably the Acrobat display isn't correct either but its hard to see small errors in a 48x36 page | 08:14.19 |
| | I notice that the file has been modified, I bet whatever modified it broke it | 08:14.55 |
| chrisl | I wonder if it ignores the errant number(s) or ignores the entire matrix | 08:15.07 |
| kens | chrisl previous experience would be that it substitutes 0 for broken numbers | 08:15.25 |
| | So we'd get a degenerate font matrix, and text might go missing | 08:15.38 |
| | But like I said, on a 48x36 inch page, its really hard to tell | 08:15.54 |
| | I'm going to examine the fontents now | 08:16.06 |
| chrisl | How on earth can that be considered the "correct" behaviour - what a pile of crap :-( | 08:16.28 |
| kens | Well, this is Acrobat.... | 08:16.41 |
| chrisl | Exactly - a pile of crap..... | 08:16.59 |
| kens | I still don't understand why marcos thinks that a change to the Info dictionary processing caused a regression on this | 08:17.33 |
| chrisl | Well, I can easily checkout the commit before and try it, if you like | 08:18.15 |
| kens | Ah, its a type 3 font. Want to bet someone added some annotations ? | 08:18.23 |
| | chrisl if you cna check that I'd be interested | 08:18.39 |
| | The bug is 694772 | 08:18.46 |
| | and Marcos listed the commit in the comments | 08:18.53 |
| | Hmmm actually I see -4 in the original file. I wonder if Alex did manage to mess this up somehow | 08:21.19 |
| | Looks like he did, there is no -.4 in the file | 08:21.34 |
| chrisl | With the commit before the DOCINFO one I get "**** Unknown operator: '0.-4', processed as number, value: 0.0" and "**** Unknown operator: '0.-526', processed as number, value: 0.0" | 08:22.02 |
| kens | What does hte output look like ? | 08:22.24 |
| | blank ? | 08:22.27 |
| chrisl | No, there's quite a lot on the page | 08:22.57 |
| kens | Interesting | 08:23.09 |
| chrisl | Like brickwork illustrations | 08:23.18 |
| kens | THe output is blank for me and I don't get those warnings | 08:23.24 |
| | I wonder if mupdfclean 'fixed' the broken FontMatrix, I'll have to go back to the original file | 08:23.43 |
| | Ah yes it did fix the file | 08:24.13 |
| | OK so somehow Alex screwed up the code that considers broken numbers to be '0' | 08:24.49 |
| chrisl | Yep, that seems to be so - the DOCINFO commit doesn't give the "Unknown operator...." warnings | 08:25.56 |
| kens | Thanks chrisl I'll try and figure out what he did | 08:26.18 |
| | Nevertheless, teh PDF file *is* wrong, and I can't believe the Acrobat ouput is correct | 08:26.39 |
| | THat is, as intended by the edit | 08:26.50 |
| | And if I fix the two type 3 font matrices, then current code will read the file too | 08:27.38 |
| chrisl | Hmm, looking at that commit, there doesn't seem to be much to it...... | 08:27.54 |
| kens | That's why I'm surprised | 08:28.03 |
| | I did read it already and couldn't immediately see how it broke this | 08:28.15 |
| | But I'll find out | 08:28.23 |
| | And a whole *bunch* of annotations are missing with the assumption that theFontMatrix entries should be 0. When I check them in Acrobat I can see that *exactly* the same text is missing. So the output in Acrobat is, as expected, wrong. Ot at least not as the annotater intended. | 08:32.35 |
| chrisl | How on earth can that be better than giving some kind of error? I really don't get it..... | 08:33.47 |
| kens | I agree and I'm putting comments to that effect in the bug. I shall also enourage Marcos to send the files back to the customer and point out to them that the text ia *missing* and that the Acrobat view is incorrect. | 08:34.36 |
| | I'd rather have an error than stuff silently being ignored personally | 08:35.01 |
| | But I do have to figure out what Alex broke and fix it. Just so we can be 'compatible' with Acrobat | 08:35.29 |
| nl_ | hi | 09:04.30 |
| ghostbot | niihau | 09:04.30 |
| nl_ | Is there somebody here that knows a lott about ghostscript? | 09:05.03 |
| kens | If you have a question, just ask it | 09:05.40 |
| nl_ | I build the gs32.dll from code with the XCFLAGS="-DGS_THREADSAFE=1" flag | 09:06.08 |
| | Everything went fine.. pdfwrite seems to be working correct | 09:06.26 |
| | I only have a problem with the PNG device. | 09:06.35 |
| | When I convert a pdf to png and the parameter -dTextAlphaBits=4 is set I get blank pages | 09:07.01 |
| | When I set -dTextAlphaBits=1 everything works ok | 09:07.28 |
| kens | I suggest you report a bug, attach the input file and state the command line used. You should probably also check with teh stock pre-built binaries | 09:07.53 |
| nl_ | I used the latest code | 09:08.13 |
| kens | Fine, but you should still check with teh binary we build | 09:08.26 |
| nl_ | That one works fine | 09:08.39 |
| | But the THREADSAFE flag isn't turned on in those builds | 09:08.51 |
| kens | I know, but I would suggest you try bulding the binary yourself *without* the threadsafe option and trying that | 09:09.16 |
| nl_ | The reason why I want to use the threadsafe flag is because I want to do parallel processing | 09:09.18 |
| kens | This elimiates more possible prblems | 09:09.25 |
| nl_ | If I build it without everything is ok | 09:09.34 |
| kens | Right, then I suggest you open a bug report and include all that information | 09:09.48 |
| chrisl | And a sample file that shows the problem | 09:10.23 |
| kens | Yep, I did say that previously, also a full d line | 09:10.40 |
| nl_ | I'll do that | 09:10.41 |
| | It only happens when the anti aliasing is turned on... | 09:11.37 |
| | I had the same with the pnggray device but there I didn't need the anti aliasing and could fix the problem with the "-dBufferSpace=2147483647" '2GB Buffer command | 09:12.22 |
| kens | Which is useful information, but just put it in the bug report. Whoever looks into it will welcoms a minimal casew to reproduce and the additional information will reduce the investigation needed. | 09:12.26 |
| nl_ | bye and have a nice day | 09:14.01 |
| chrisl | Hmmm, yes, GS_THREADSAFE is *badly* broken :-( | 09:39.38 |
| kens | Well we never test it | 09:39.50 |
| | I guess we should..... | 09:40.08 |
| chrisl | I thought it had been tested | 09:40.20 |
| kens | Umm, no idea ? | 09:40.43 |
| chrisl | Well, maybe not - we just ignore calls to the default path filling method....... | 09:41.13 |
| kens | That doesn't sound like a good idea | 09:41.43 |
| chrisl | Nope, but adding it back in, throws a bunch of undefined symbol errors on debug code :-( | 09:42.32 |
| kens | Oh that's not great | 09:42.56 |
| chrisl | And our friend hasn't actually opened a but (yet)..... | 09:43.47 |
| kens | The 'fix' from Alex tht causes the problem seems to have multiple problems starting with a dup which leaves something on the stack. It appears this wasn't to do the original enhancement, but to fix a file in our test suite with a broken Infor dict. Of course Alex didn't say which file so I've had to revert the fix and run a cluster test to find out..... | 09:44.15 |
| | chrisl well, up to him, you can ignore it until he does ;-) | 09:44.30 |
| chrisl | indeed | 09:44.56 |
| | OTOH, if I build the modified code with the right CFLAGS it works - doh! | 09:51.35 |
| kens | ROFL well if he ever opens a bug report you can tell him what's wrong | 09:51.57 |
| chrisl | I could have told him earlier - "it's broke"..... | 09:52.45 |
| Robin_Watts | chrisl: So, is GS_THREADSAFE broken? | 10:25.00 |
| chrisl | Robin_Watts: Oh yes - if you look in gxfill.c line ~654 - you'll see the call to gx_general_fill_path() is conditionally compiled out. Fills don't get filled.... easy fix, though | 10:33.10 |
| Robin_Watts | What the hell was i thinking? | 10:34.15 |
| | Presumably I was intending to only remove the vd_ stuff ? | 10:34.27 |
| chrisl | Yeh, I think the function call just got caught up in the mix | 10:34.45 |
| | I've got fixed code here - as I said, it's trivial | 10:35.15 |
| Robin_Watts | chrisl: Are you going to commit that? | 10:35.33 |
| chrisl | Once I type the commit message | 10:35.46 |
| Robin_Watts | Fab, thanks. | 10:35.53 |
| chrisl | I'm assuming you won't need to review such am obvious change...... | 10:36.13 |
| Robin_Watts | no, that's fine. | 10:36.28 |
| chrisl | I guess I should clusterpush with GS_THREADSAFE (after the commit run is complete), just for kicks | 10:37.52 |
| kens | I guess it might be useful | 10:38.22 |
| | I'm still trying to fathom what Alex was up to with this PostScript change | 10:38.53 |
| chrisl | When was the change made? | 10:39.18 |
| kens | 2012 | 10:39.22 |
| | 16th August | 10:39.35 |
| | The enhacement works fine,its the code to 'fix' the broken Info dict aht's borked | 10:40.03 |
| Robin_Watts | http://news.slashdot.org/story/13/11/12/039249/digital-textbook-startup-kno-was-sold-for-15-million | 11:02.27 |
| chrisl | Eeek! | 11:03.22 |
| Robin_Watts | chrisl: I've got a gc problem I don't understand here. | 13:29.50 |
| kens | thinks this is perfectly normal | 13:30.24 |
| Robin_Watts | The first time my code tries to relocate a non NULL gsicc_cache pointer, the code falls in a heap. | 13:30.41 |
| chrisl | I did take a quick look at your code earlier, and nothing stood out as daft | 13:33.14 |
| Robin_Watts | chrisl: The actual relocation appears to be done using igc_reloc_struct_ptr | 13:37.41 |
| | which makes reference to 'chunk_head_t' etc. | 13:37.54 |
| | but the memory that this object is in is NOT a chunked allocator - it's the underlying thread safe allocator (which is the standard allocator based on malloc I think). | 13:38.31 |
| chrisl | Well, it can't be gc'ed memory | 13:38.53 |
| | Hmm, you've got ENUM_OBJ() but RELOC_VAR() | 13:40.04 |
| Robin_Watts | RELOC_VAR == RELOC_OBJ_VAR | 13:40.20 |
| | The existing code already handles gsicc_cache pointers. In the same routines look at the lines dealing with icc_cache_cl | 13:41.10 |
| | I just copied those. | 13:41.18 |
| chrisl | Oh, is it an array of pointers? Or an an array gsicc_cache objects? | 13:41.33 |
| Robin_Watts | I have an array of pointers. | 13:42.02 |
| chrisl | So, cache is allocated separately | 13:42.16 |
| Robin_Watts | yes | 13:42.23 |
| chrisl | each cache | 13:42.24 |
| Robin_Watts | yes | 13:42.33 |
| | so I probably need to cope with enumerating/relocating the block of pointers too. | 13:42.49 |
| | but I don't believe that's the problem at the moment. | 13:43.03 |
| chrisl | Ah, it may be that the array of pointers has been gc'ed by then | 13:44.16 |
| Robin_Watts | chrisl: I have some debugging in there, and the pointers look fine to me. | 13:46.08 |
| chrisl | Try running with -Z@ | 13:46.29 |
| Robin_Watts | From the command line, it still crashes in the same place. | 13:47.12 |
| | my VS just died :( | 13:47.18 |
| chrisl | I would expect it to crash in the same place, but it *may* have overwritten the pointers by then, if the array has been gc'ed | 13:48.05 |
| Robin_Watts | pointers have not been overwritten. | 13:50.07 |
| chrisl | Robin_Watts: are you sure the memory in question gc'ed memory? | 13:50.23 |
| Robin_Watts | -Z@ fills memory on freeing? | 13:50.30 |
| | chrisl: Oh, possibly not. | 13:50.47 |
| chrisl | Yes, it fills with different bit patterns on whether it was freed, or gc'ed. But I can't remember when during the compaction the gc'ed memory gets written into | 13:51.09 |
| Robin_Watts | Is memory allocated using the basic gs heap allocator gc'd ? | 13:51.19 |
| chrisl | No | 13:51.34 |
| Robin_Watts | Then that might explain it :) | 13:51.42 |
| chrisl | You should be able to look in the allocator in the debugger | 13:52.07 |
| Robin_Watts | I need to use a thread safe allocator for a memory space that won't go away until after the clist device does. | 13:52.29 |
| | so I used cdev->memory->thread_safe_memory | 13:52.40 |
| | which I think is the raw gs_heap stuff. | 13:52.56 |
| | Let me trap the allocation. | 13:53.02 |
| | gs_heap_alloc_struct | 13:53.29 |
| | THat does still put the structure descriptor in ptr[-1] | 13:54.39 |
| chrisl | So, if you look into the allocator's procs. the register_root method will tell you if it's gc'ed | 13:54.57 |
| | A gc'ed allocator will have i_register_root() | 13:55.40 |
| Robin_Watts | gs_heap_register_root ? | 13:55.44 |
| chrisl | Yeh, isn't that an empty function? | 13:56.00 |
| | Yep, so that's non-gc'ed memory | 13:56.25 |
| Robin_Watts | so it is. | 13:56.33 |
| | OK, thanks! | 13:56.36 |
| chrisl | I have squash training now - back for the meeting. I can debug it properly then, if you're still struggling | 13:57.58 |
| Robin_Watts | Morning henrys | 14:06.00 |
| henrys | howdy | 14:06.19 |
| Robin_Watts | Can I get a sanity check from someone please? gxclist.c line 68 | 14:06.21 |
| | In the CLIST_IS_WRITER case, we have a switch with explicit cases for 0,1,2,3,4,5 | 14:06.56 |
| kens | yes | 14:07.16 |
| Robin_Watts | and a default case where we pass on the enumeration with index - 5. | 14:07.17 |
| | surely that should be index-6 ? | 14:07.23 |
| kens | Don't know, depends what ENUM_USING is exepcting, 0-based or 1-based | 14:07.57 |
| Robin_Watts | cos for index == 6 (the first one that isn't handled explicitly) we want to pass that on as being index == 0 ? | 14:08.01 |
| | ENUM stuff always works 0 based, I believe. | 14:08.10 |
| kens | C eums are 0 based by defatul, but need tno be AIUI | 14:08.25 |
| Robin_Watts | kens: no, this is garbage collection enumeration. | 14:08.43 |
| kens | GC I don't really understand :-( | 14:08.54 |
| Robin_Watts | gc ENUM routines enumerate the list of pointers that a given structure holds. From 0 upwards. | 14:09.24 |
| kens | THat is, I understand garbage collection, I don't understadn our garbage collector | 14:09.50 |
| Robin_Watts | Ok, code works now. and OptimiseByResampling is taking 8% rather than 50%. | 14:17.15 |
| | lunchtime. | 14:17.20 |
| kens | sounds like progress | 14:17.28 |
| henrys | kens:according to your comment you wanted this to go back to Robin ⦠http://bugs.ghostscript.com/show_bug.cgi?id=693916 | 14:51.41 |
| Robin_Watts | It's the clist that needs altering I believe. | 14:56.00 |
| kens | henrys we taslked about that at the last staff meeting, its mine again | 14:56.37 |
| henrys | kens:oh sorry I don't remember ⦠it seems trivial to fix up the array size if necessary get rid of the postscript code. | 14:58.26 |
| kens | there are several parts, PS, pdfwrite/ps2write and the clist | 14:58.48 |
| Robin_Watts | Nothing that involves changes to the clist is trivial. | 14:59.23 |
| kens | ray claims clist will work | 15:00.02 |
| henrys | okay just going through the agenda before the meeting and noticed that one. | 15:00.03 |
| | kens:clist doesn't need to change if you exceed the max pattern it uses a fill. | 15:01.33 |
| kens | henrys yes that's what ray said | 15:02.46 |
| Robin_Watts | God, that sounds awful for performance. | 15:03.06 |
| tor5 | huzzah for broken internets. | 15:03.08 |
| kens | Robin_Watts : Its incredibly rare to find such a thing | 15:03.22 |
| henrys | Robin_Watts: patterns like that are never seen | 15:03.30 |
| kens | You more or less have to handcraftone | 15:03.34 |
| henrys | sorry what kens said | 15:03.37 |
| | we can look at the coverage data to see if we test that path. | 15:04.25 |
| kens | henrys we do not | 15:04.35 |
| | the setdash anyway | 15:04.42 |
| | clist I don't know, but I'll find out when I do the work | 15:04.53 |
| henrys | kens:we do - pcl does | 15:05.49 |
| kens | yeah I mentioned that in teh bug thread | 15:06.01 |
| henrys | kens:only in some very dreaded set files | 15:06.55 |
| kens | technically there is no limit in PostScript these days..... | 15:07.17 |
| | THe hard part is going to be fixing pdfwrite | 15:07.28 |
| henrys | but that is fairly good evident the fallback in clist will work for ps and pdf. | 15:07.41 |
| kens | Yes I would think so | 15:07.50 |
| kens | fetches coffee for meeting, brb | 15:08.47 |
| henrys | marcosw: I really appreciate the coverage stuff - nice to look at a path in the code and have a list of test files. | 15:09.53 |
| Robin_Watts | apparently gdevrops.c is never used. | 15:12.12 |
| | likewise gdevm2.c, gdevmr1.c, gdevmr2.c, etc | 15:14.13 |
| kens | surely gdevrops.c is used by PCL for rasterops ? | 15:16.38 |
| Robin_Watts | It's not used according to the gs coverage data - but it is under the PCL stuff. I guess that makes sense. | 15:18.46 |
| kens | Yes indeed, GS won't use it, but PCL does. | 15:19.08 |
| | gdevm2.c is 2bpp output, which I gues our coverage doesn't test | 15:19.24 |
| Robin_Watts | kens: yeah, there are probably reasons for all of them. | 15:19.50 |
| kens | gdevmr1,c is monobit rasterops apparently so same as gdevrasterops.c etc | 15:20.13 |
| | I'm guessing gdevmr*.c is rasterops | 15:20.28 |
| marcosw | henrys: nice to hear that the coverage analysis is being used. | 15:24.47 |
| henrys | marcosw: Sorry I missed you comment about the windows problem and only noticed it today. | 15:25.55 |
| | marcosw: but it looks like you've moved on. | 15:26.37 |
| | coffee before meeting | 15:28.31 |
| marcosw | henrys: no, I haven't assigned that bug to anyone. it's | 15:30.19 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=694771 | 15:31.09 |
| henrys | marcosw: not a clue here | 15:32.14 |
| Robin_Watts | Coo. Memento isn't threadsafe. That never occurred to me before. | 15:32.30 |
| henrys | So I think a good next step in the 801 plan is to get their device in the nightly test suite. | 15:34.14 |
| Robin_Watts | henrys: How do we do that without checking their device into a public repo? | 15:34.38 |
| henrys | Robin_Watts: the same way we test the ufst I suppose | 15:34.57 |
| | marcosw? | 15:35.27 |
| Robin_Watts | It's a different problem though. | 15:35.33 |
| henrys | Robin_Watts: in that we frequently change it? | 15:36.00 |
| chrisl | henrys: surely it's not our responsibility to test customer's devices? | 15:36.05 |
| Robin_Watts | ufst is a configure option that will cause a third party lib to be linked in/called. | 15:36.07 |
| | i.e. there is public code permanently in the gs tree that can be enabled/disabled. | 15:36.34 |
| | that is not the case with cust801. | 15:36.42 |
| ray_laptop | I can only stay for about 30 min today -- my wife can't take my youngest to school | 15:36.43 |
| henrys | chrisl: we are testing that we don't break a customers device | 15:36.46 |
| marcosw | henrys: yes | 15:37.19 |
| chrisl | henrys: well, we should test customer 532's device, too. And any other customers that have custom devices...... | 15:37.30 |
| Robin_Watts | henrys: IMHO the only way we should undertake this is if they are prepared to work from a git repo that they will share with us. | 15:37.50 |
| ray_laptop | chrisl: cust 532's device can't really be tested -- it's an ASIC (they have a s/w simulator but that is *NOT* suitable for automated testing, IMHO) | 15:38.26 |
| Robin_Watts | That way we can ensure we are testing the latest version of their device, and if changes are required, we can fix them. | 15:38.33 |
| henrys | Robin_Watts: I don't know that we have to have every single change. | 15:38.54 |
| Robin_Watts | BUT I suspect we don't really need to test their device. | 15:39.02 |
| marcosw | we can put customer devices into tests_private, the nightly regression code can copy the file(s) from that repository into devices (or wherever they need to go) before compiling. | 15:39.10 |
| henrys | the important thing is to test we don't break 5 color with their profile etc. | 15:39.34 |
| ray_laptop | Robin_Watts: I agree, as long as they move to proper use of the device interface | 15:39.41 |
| chrisl | ray_laptop: my point is that 801 isn't the only customer to have their own code, and we don't regression test any others - that's the customer's responsibility | 15:39.41 |
| Robin_Watts | all we need to do is to test a 'similar' device. a planar device that uses process_page. | 15:39.59 |
| ray_laptop | chrisl: right, thanks for clarifying. I agree | 15:40.16 |
| henrys | chrisl: yes it was a new idea of mine only for customers that are significant. Sorry I though I had said something about that. | 15:40.28 |
| | chrisl: and feasible as ray_laptop points out. | 15:40.46 |
| chrisl | henrys: I'm putting the counter-argument...... | 15:40.52 |
| ray_laptop | Robin_Watts: I do feel the need to check a device that use plane skipping in band mode | 15:41.08 |
| chrisl | henrys: if we start down that road, we can be taking on a huge burden, in the long run | 15:41.38 |
| henrys | Robin_Watts: so why not have marcosw put gdev801.c in a private place and just test it. | 15:41.55 |
| Robin_Watts | henrys: It's not just that file. | 15:42.08 |
| mvrhel_laptop | I do have it on my list to come up with color testing, one of which would be the use of N-color output profiles henrys | 15:42.09 |
| ray_laptop | chrisl: but only for our top two or three customers. That's why we test UFST, after all, is for the significant customers | 15:42.20 |
| Robin_Watts | It's a change to the makefiles to include it etc. | 15:42.23 |
| | marcosw could have a patch that he applies each time, but it's effort when it inevitably breaks. | 15:42.42 |
| kens | is distinctly uneasy about doing customer-specific testing | 15:42.43 |
| mvrhel_laptop | yes me too | 15:42.48 |
| henrys | chrisl: just significant customers with unusual devices - a very small crowd | 15:42.58 |
| ray_laptop | mvrhel_laptop: a psdcmykog shouldn't be too difficult | 15:43.08 |
| mvrhel_laptop | exactly | 15:43.14 |
| chrisl | henrys: but that group can change over time | 15:43.22 |
| kens | When/if a customer is no longer in our top 2 or 3 will we stop esting their device ? How many devices from each customer ? | 15:43.23 |
| mvrhel_laptop | ray_laptop: I already have a profile and input file that tests the use of this quite nicely | 15:43.50 |
| Robin_Watts | Personally, I'd like to make a public example device that shows planar, process_page operation, with band skipping and just put that into our regular commit tests. | 15:43.56 |
| ray_laptop | kens: well, if all of our customers stopped using UFST, we'd sure drop that !!! | 15:44.08 |
| chrisl | Robin_Watts: I agree, that seems sensible | 15:44.14 |
| kens | I'd rather do Robin's approach | 15:44.15 |
| mvrhel_laptop | Robin_Watts: I think a demo device would be great | 15:44.20 |
| henrys | kens: I think we look at each device. In my view we have high probability of breaking 801's device so ... | 15:44.20 |
| chrisl | It's probably worth doing a 5+ color test set, too | 15:44.36 |
| kens | I'd rather have a device we cna make public as an example, and test ourselves | 15:44.42 |
| ray_laptop | Robin_Watts: I agree. And I agree with *NOT* testing actual customer device code | 15:44.48 |
| Robin_Watts | henrys: Their *current* device is completely fragile. The one we've done should be much more robust. | 15:45.03 |
| ray_laptop | chrisl: we do (with psdcmyk) test > 4 planes when the files call for Separations | 15:45.39 |
| mvrhel_laptop | not with an icc profile though | 15:46.05 |
| kens | ray_laptop : I'm not convinced UFST is a similar example, we have a font API which we should keep up to date to allow other Font handlers, and also UFST is not a singel customer | 15:46.05 |
| henrys | okay so somebody is going to make a 5 color profile? | 15:46.16 |
| ray_laptop | chrisl: mvrhel_laptop proposed adding a device that would have the ICC profile that generates > 4 colorants | 15:46.20 |
| chrisl | ray_laptop: sorry, I meant with a suitable profile | 15:46.20 |
| mvrhel_laptop | henrys: I have one | 15:46.23 |
| ray_laptop | guessed that mvrhel_laptop would | 15:46.39 |
| henrys | if it has the same features, fine by me. | 15:46.40 |
| Robin_Watts | ray_laptop: We'd probably want to have our example device have 5 (or more) colorants. | 15:46.42 |
| henrys | Robin_Watts: and it should have ht in the device, right? | 15:47.18 |
| ray_laptop | Robin_Watts: yes. I'd recommend using the one that mvrhel_laptop is proposing, and adding band skipping by writing 0's for empty colorants (ignoring what's actually rendered in the plane) | 15:47.48 |
| Robin_Watts | I think it's far better for us to have a public device that we can show to customers to say "this is an example you can work from" rather than to say "we test this stuff in the background, but it's secret, so we can't show you." | 15:47.50 |
| henrys | paulgardiner: so I guess we'll stop looking at open source solutions and see what Robin_Watts comes up with? | 15:48.17 |
| Robin_Watts | henrys: The device currently renders contone internally and SSE's down to 4bits. | 15:48.17 |
| paulgardiner | henrys: Seems sensible to me. | 15:48.50 |
| ray_laptop | Robin_Watts: or better yet, to make sure that thee color_usage is tracking, checking the contents of "empty" planes and dying if a plane is actually marked (to spot color_usage wrong) | 15:48.58 |
| Robin_Watts | We can't use their bluenoise tables in public of course. | 15:49.11 |
| mvrhel_laptop | we can generate our own with ray's code | 15:49.26 |
| ray_laptop | Robin_Watts: I can easily generate BNM tables | 15:49.32 |
| henrys | Robin_Watts: I don't think we need sse, but we should get a 4 bit result right? | 15:49.33 |
| paulgardiner | henrys: I'd sort of assumed that, so I've been back working on the iOS app. | 15:50.07 |
| Robin_Watts | henrys: Having SSE is nice as an example. | 15:50.13 |
| | cos it demonstrates alignment etc. | 15:50.23 |
| mvrhel_laptop | yes | 15:50.28 |
| henrys | Robin_Watts: I'm concerned that will get on their radar that our device is much like theirs | 15:50.52 |
| mvrhel_laptop | is the SSE code "ours" or is it part of their device? | 15:50.53 |
| ray_laptop | henrys: I don't think we need to test the 4-bit, but the SSE is useful as Robin_Watts says | 15:50.54 |
| | mvrhel_laptop: we (Robin) wrote it | 15:51.10 |
| Robin_Watts | Personally I'd like to rip out the bluenoise tables entirely. | 15:51.11 |
| | The only bit of SSE that is theirs is the application of the bluenoise. | 15:51.34 |
| mvrhel_laptop | ok | 15:51.38 |
| Robin_Watts | so if I rip that out everything is then ours. | 15:51.43 |
| | and it doesn't matter if we're on their radar. | 15:51.51 |
| mvrhel_laptop | sounds reasonable | 15:52.10 |
| Robin_Watts | actually, we should possibly rip out the code that changes the scale of CMY to be a different res to K. | 15:52.46 |
| henrys | Robin_Watts: we need to back this up a bit - they very reasonably may not want a 5 color planar device released as open source. | 15:52.52 |
| ray_laptop | Robin_Watts: right -- just "strict" 8-bit to 4-bit. But what about the 600->300 do we seriously want a device with different res for some planes | 15:52.53 |
| mvrhel_laptop | I would say no | 15:53.14 |
| Robin_Watts | ray_laptop: I would say not. | 15:53.17 |
| mvrhel_laptop | :) | 15:53.23 |
| | henrys: I will do 6 color | 15:53.46 |
| | that is what my profile is | 15:53.49 |
| Robin_Watts | henrys: OK, so let's do a 7 color planar device. | 15:53.50 |
| ray_laptop | Robin_Watts: although if we want to just have the SSE to the averaging downsampling for ALL planes, that would be OK | 15:53.52 |
| Robin_Watts | CMYcmyK ? | 15:53.55 |
| henrys | they are not a rival for which we are trying to make a legal case - they are a potential customer that we don't want to annoy. | 15:54.28 |
| ray_laptop | Robin_Watts: light y is not common | 15:54.31 |
| Robin_Watts | ray_laptop: OK. | 15:54.38 |
| | henrys: I don't see how this can be bad for them. | 15:54.48 |
| mvrhel_laptop | I forget what it is. It is some extra spot colors | 15:54.49 |
| ray_laptop | light K *is* seen more often | 15:54.59 |
| | mvrhel_laptop: I think I have a CMYK+Orange+Green ICC profile (from Raph) | 15:55.54 |
| mvrhel_laptop | generally the light c, light m and light k are not produced from the icc profile, but from 1-D look ups | 15:55.56 |
| ray_laptop | *if* I can find it | 15:56.00 |
| henrys | Robin_Watts: I don't either but they have been very specific that everything be confidential so I'm a bit nervous about release a similar open source device. | 15:56.05 |
| mvrhel_laptop | ray_laptop: ok that would be nice | 15:56.10 |
| ray_laptop | mvrhel_laptop: I'll look for it later today | 15:56.25 |
| mvrhel_laptop | thanks | 15:56.28 |
| Robin_Watts | henrys: We can always go back to them and suggest this as a course of action. | 15:56.29 |
| kens | Hexachrome (CMYKOG) was common enough in the past | 15:56.29 |
| henrys | Robin_Watts: that i'd be good with. | 15:57.03 |
| ray_laptop | kens: if you know where to get an ICC profile for that, just forward it to mvrhel_laptop (and let us all know) | 15:57.12 |
| henrys | Robin_Watts, ray_laptop : you saw they had build problems? | 15:57.22 |
| kens | I don't have one any more, sorry | 15:57.23 |
| mvrhel_laptop | I may have one actually | 15:57.30 |
| ray_laptop | henrys: no, I haven't processed emails yet. | 15:57.44 |
| henrys | ray_laptop: you mentioned in the /tmp file bug that it might have been fixed with bgprint? | 15:58.14 |
| Robin_Watts | We can say "we would like to produce a simple open source example device, that uses cmykog in 4 bits. It would be similarly structured internally to the device we have produced for you. We'll put this into our test suite, thus you can have confidence that as we develop ghostscript, your device will not be broken. This helps keep the details of your device secret." | 15:58.28 |
| kens | It looked like they wanted to 'merge' in their own device, I didn't hitnk they needed to, I assumed Robin/Ray had sent them everything. | 15:58.40 |
| henrys | now we have tor5 and tor7 | 15:58.49 |
| kens | THat's not unusual | 15:58.58 |
| mvrhel_laptop | I bet they will take a month + to get back to you on that one Robin_Watts | 15:59.03 |
| tor7 | internet just recovered for tor7 | 15:59.09 |
| Robin_Watts | henrys: Yes, I saw their build problem. I was going to talk to ray_laptop about it when he's free. | 15:59.26 |
| ray_laptop | kens: we (mostly Robin_Watts) had hacked on their device pretty thoroughly. | 15:59.26 |
| kens | ray_laptop : that's what I thought, I assumed what you had sent them was 'ready to go' and wouldn't need any merging | 15:59.51 |
| | I may have misunderstood their mail though | 16:00.01 |
| Robin_Watts | I read their emails as "We've started working with gs 9.10. Can you give us just the changed files from 9.10?" | 16:00.07 |
| henrys | ray_laptop, kens, Robin_Watts: we must stop merging politely. | 16:00.10 |
| | tell them to upload the code and we'll fix it. | 16:00.29 |
| | anything else for the meeting? Can everyone have a look at the agenda and see what updates are needed? | 16:01.25 |
| Robin_Watts | And my response would be "We cannot easily do that. We have done significant changes since the release of 9.10 specifically to support your use case. You should take a current snapshot and apply these diffs." | 16:01.32 |
| ray_laptop | Robin_Watts: I'll be back at the office by no later than 8:45 | 16:01.37 |
| Robin_Watts | ray_laptop: No worries. | 16:01.44 |
| ray_laptop | We *could* give them all of the changed files since 9.10. I have their code on a branch under git | 16:02.41 |
| | Robin_Watts: he mentions linux -- I didn't even think to try building on linux | 16:03.06 |
| Robin_Watts | ray_laptop: We could, but really we should point out that that is NOT a good way to work. | 16:03.09 |
| tor7 | henrys: mupdf can do cmyk output, the svg parser is now functional (but incomplete) and can do vectors and the state stack tracking and a lot of the fundamentals are in, and I've got the system font loading callback API in place and a demo of it using fontconfig | 16:03.25 |
| henrys | chrisl: I need to ping urw again. | 16:03.31 |
| Robin_Watts | I've not built on linux either. | 16:03.38 |
| | tor7: Did you see zenikos comments earlier? | 16:03.50 |
| tor7 | Robin_Watts: I did not. | 16:03.55 |
| | my internet's been wonky | 16:04.09 |
| ray_laptop | Robin_Watts: I can try that (and debug that) when I get to the office. | 16:04.12 |
| henrys | tor7:wow can we let Raed give it a spin (svg) | 16:04.20 |
| | ? | 16:04.23 |
| chrisl | henrys: I was going to remind you in a week or two - they did say November before the personal responsible would be available | 16:04.29 |
| ray_laptop | Does gcc use the same SSE intrinsic syntax ? | 16:04.44 |
| tor7 | henrys: it only does vectors at the moment, but it can at least read most of the stuff that comes out of Robin's svgdevice | 16:04.49 |
| Robin_Watts | ray_laptop: I believe it's standard. | 16:04.55 |
| henrys | tor7:okay let's hold off ;-) | 16:05.09 |
| tor7 | henrys: but I'm pleased that at least it now works well enough that it can be incrementally improved :) | 16:05.30 |
| marcosw | In case anyone missed my email to tech@ I'd like to mention the custom test stuff I added to the nightly/weekly regression tests. See tests_private/comparefiles/custom_tests.lst for details. | 16:05.38 |
| henrys | tor7: yes that is good. | 16:05.44 |
| tor7 | Robin_Watts: where did zeniko comment? | 16:05.47 |
| marcosw | it would be good if people added tests before the next staff meeting, so we can discuss missing features. | 16:06.07 |
| henrys | marcosw: it was on my list to check that out, thanks marcosw | 16:06.08 |
| ray_laptop | chrisl: does our linux configure take care of HAVE_SSE* #defines somewhere ? | 16:06.10 |
| mvrhel_laptop | Robin_Watts: I will make sure that I am up and running with their device when we visit next week, in case they still can't build by then... | 16:06.14 |
| chrisl | ray_laptop: it does, yes | 16:06.21 |
| Robin_Watts | tor7: I'm trying to find it. | 16:06.34 |
| tor7 | Robin_Watts: found it in yesterday's log | 16:06.44 |
| ray_laptop | mvrhel_laptop: do you want me to upload the tarball to casper for you ? | 16:06.47 |
| henrys | marcosw: are you going to field guillaume stuff? | 16:06.55 |
| | I know it was addressed to me. | 16:07.03 |
| ray_laptop | mvrhel_laptop: or do a git patch for the xxxx branch I have? | 16:07.23 |
| marcosw | henrys: I've already replied to his most recent email and was reading his second when I remembered the meeting wasn't over. | 16:07.23 |
| | so yes, I'll deal with him. | 16:07.32 |
| henrys | marcosw: oh thanks great | 16:07.37 |
| tor7 | zeniko (FTL): I do *not* trust loading system fonts for the builtin fonts. at least not without setting the "is a substitute" flag. | 16:07.59 |
| mvrhel_laptop | ray_laptop: I think I would prefer to work in the git framework | 16:08.04 |
| ray_laptop | recommends using a git branch so we can track changes from origin/master easily | 16:08.06 |
| mvrhel_laptop | yes | 16:08.11 |
| tor7 | but the arguments to the function can definitely be extended with more information than just the font name | 16:08.27 |
| ray_laptop | mvrhel_laptop: OK, when I get back, I'll put a git format-patch together for you (and Robin_Watts in case he wants it) | 16:08.54 |
| mvrhel_laptop | ok thanks | 16:09.01 |
| ray_laptop | I have to go now. bbiaw (35 min or less) | 16:09.19 |
| | sorry | 16:09.20 |
| henrys | no problem | 16:09.28 |
| | move to adjourn anyway. | 16:09.46 |
| tor7 | and I'd be willing to add a second function for CJK fonts in particular | 16:09.48 |
| henrys | Robin_Watts: after thinking about it if we just do a hexacrhome planar open source device I doubt it would be a problem. | 16:11.44 |
| Robin_Watts | henrys: Cool. | 16:12.08 |
| henrys | or something of that ilk | 16:12.10 |
| marcosw | also, I setup windows 7 nightly regression testing. It's a Rube Goldberg combination of virtualbox, shared folders, batch files, cygwin, and perl code so probably will break if someone breathes on it, but for now it's working. I'll probably have it start sending out emails next week, so one more regression email that everyone can ignore :-) (except me, I read them very occasionally). | 16:12.14 |
| chrisl | marcosw: that is hardly fair - how can I delete them if I ignore them..... ;-) | 16:13.02 |
| marcosw | currently it does only gswin32c.exe testing. I do build the gswin64c.exe code but wasn't sure if anyone of our customer use it. | 16:13.20 |
| sh4rm4 | hrm is there a way to make ghostscript link against libgs.so instead of compiling everything into the binary ? | 16:14.04 |
| henrys | marcosw: great lots of folks using that crazy OS ;-) | 16:14.30 |
| chrisl | sh4rm4: "make so" | 16:14.35 |
| Robin_Watts | So I have J12_PS_ACR9.ps down to 14.3s from 21s at 600dpi. | 16:14.47 |
| sh4rm4 | chrisl, will that create the "gs" binary as well ? | 16:14.50 |
| chrisl | sh4rm4: it creates gsc and gsx binaries, linked to the .so | 16:15.09 |
| marcosw | I've run a comparison of output from gswin32c.exe vs gs on linux and there some significant differences that I'm tracking down and will enter bugs for. | 16:15.10 |
| Robin_Watts | And down to 11.2 from 18.38 at 300dpi. | 16:15.43 |
| sh4rm4 | chrisl, are those 2 sufficient to fully replace "gs" ? | 16:15.45 |
| chrisl | sh4rm4: yes | 16:15.58 |
| sh4rm4 | which one does what ? | 16:16.04 |
| Robin_Watts | mvrhel_laptop: Is there a 'cmsGetIdentityLink' or something ? | 16:16.10 |
| marcosw | henrys: just wait until we start having customer using Windows RT :-) | 16:16.15 |
| sh4rm4 | or which one do i use instead of "gs" ? | 16:16.18 |
| mvrhel_laptop | Robin_Watts: no | 16:16.22 |
| henrys | marcosw: which looks right? | 16:16.38 |
| Robin_Watts | mvrhel_laptop: I have the 'list of caches' stuff working. | 16:16.57 |
| chrisl | sh4rm4: either. The only difference is in the the way the screen output works | 16:16.58 |
| henrys | marcosw: also windows is 32 bit did you check against gcc 32 tests? | 16:17.03 |
| Robin_Watts | I worry that it might be leaking though. | 16:17.06 |
| sh4rm4 | chrisl, so which one would you symlink to "gs" then ? | 16:17.21 |
| marcosw | in most cases the windows build doens't produce output for all the pages. | 16:17.25 |
| mvrhel_laptop | Robin_Watts: essentially, if the source and destination profiles are the same, we currently mark the link as such and then later if we encounter said profile we ignore it and don't do the transform | 16:17.31 |
| chrisl | sh4rm4: I wouldn't, I would use the monolithic executable | 16:17.43 |
| mvrhel_laptop | s/said profile/said link/ | 16:17.48 |
| Robin_Watts | mvrhel_laptop: REALLY? | 16:17.49 |
| mvrhel_laptop | really | 16:17.56 |
| Robin_Watts | mvrhel_laptop: Then I am confused. | 16:17.58 |
| sh4rm4 | chrisl, and in my case ? which one is better suited ? | 16:18.06 |
| marcosw | henrys: yes, but there aren't significant differences between the linux 32 and 64 bit builds. I think only in some of the quality logic tests that check for maxint and such. | 16:18.07 |
| Robin_Watts | I've been looking at J12_PS_ACR9.ps | 16:18.16 |
| chrisl | sh4rm4: I don't know what your case is - try them both, and see which suits | 16:18.31 |
| Robin_Watts | which is the one where getting the link was taking ages. | 16:18.34 |
| sh4rm4 | chrisl, i take it i dont have to run "make install", only "make soinstall", right ? | 16:18.42 |
| Robin_Watts | ray_laptop had said that that was a case where the start and finish profiles were the same | 16:18.56 |
| mvrhel_laptop | ok that could be | 16:19.04 |
| chrisl | sh4rm4: that *should* work, yes | 16:19.05 |
| henrys | marcosw: christ my phone has 64 bits I wonder how long 32 will be around. | 16:19.09 |
| mvrhel_laptop | we currently will create the link | 16:19.20 |
| | I was going to add code to avoid that | 16:19.32 |
| Robin_Watts | Ah, we create the link, but never use it ? | 16:19.33 |
| mvrhel_laptop | right | 16:19.36 |
| Robin_Watts | This makes me wonder if I should bother committing my code. | 16:20.02 |
| | If we fix the identity case to not make the link, we'd sidestep this particular example. | 16:20.37 |
| mvrhel_laptop | oh a much cleaner solution | 16:20.53 |
| | let me drop what I am doing with 8.1 and see if I can quickly do this | 16:21.06 |
| marcosw | henrys: I was wondering if we should start shipping a gswin64c.exe in addition to gswin32c.exe. I know chrisl doesn't have enough to do for every release :-) | 16:21.10 |
| chrisl | Robin_Watts: are you seeing any performance improvement with the persistent cache? | 16:21.11 |
| Robin_Watts | but then I guess there are other (non-identity) examples which might also be slow, so might benefit from us keeping a cache. | 16:21.17 |
| | chrisl: Yes. | 16:21.20 |
| | 21->14s at 600dpi, 18->11 at 300dpi | 16:21.33 |
| mvrhel_laptop | Robin_Watts: yes, the cache should still elp | 16:21.34 |
| chrisl | marcosw: we do ship gswin64c.exe | 16:21.40 |
| mvrhel_laptop | that is signfiicant | 16:21.41 |
| Robin_Watts | OK, so it's probably worth me committing this code anyway. | 16:22.09 |
| chrisl | And presumably there will be times when we can't elide the transform (because it's identity)? | 16:22.27 |
| sh4rm4 | chrisl, thanks, it seems to work | 16:22.44 |
| Robin_Watts | chrisl: Presumably. I just don't have an example of that :) | 16:22.50 |
| sh4rm4 | however i hope that cups-filters likes gsx instead of gs | 16:23.00 |
| chrisl | sh4rm4: it uses the same command line args, so it *should* be fine(!!) | 16:23.29 |
| sh4rm4 | cool | 16:23.40 |
| chrisl | Robin_Watts: still, seems like a general solution is better than a special case one..... | 16:23.51 |
| Robin_Watts | chrisl: yeah. | 16:23.58 |
| | OK, so the only minor worry I now have is leaks. | 16:24.08 |
| chrisl | Well, as long as it's all cleaned up with the clist, then it should be fine | 16:24.29 |
| | clist doesn't rely on the garbage collector | 16:24.54 |
| Robin_Watts | If you run the current code as a debug build with NPR > 1, then we get 'leaks' of icc_cache's reported when the chunk allocator for each thread is closed down. | 16:25.22 |
| | They aren't really leaks though, because when the chunk allocator is closed down, all the storage goes away. | 16:25.45 |
| | In my code those have moved from being in the chunk allocator to being in the basic heap allocator. | 16:26.08 |
| | which means that any such leaks will be real. | 16:26.18 |
| chrisl | marcosw: what I haven't done is build both gswin32(c).exe and gswin64(c).exe into one installer - that presents "problems" for the build...... | 16:26.29 |
| henrys | marcosw: he asked me to buy some other product which I did, at the end of the day we want to see the hp output. | 16:26.40 |
| chrisl | Robin_Watts: Hmmm, that's not ideal :-( | 16:26.47 |
| henrys | marcosw: I'm worried he fishes through a bunch of apps until he finds output he likes ;-) | 16:27.11 |
| chrisl | henrys: that's what customers do! | 16:27.30 |
| Robin_Watts | We'll be leaking fewer objects as they are not created one per thread per page any more. | 16:27.34 |
| | but the leaks will be real now. Let me try to do some debugging to see if they really are leaking. | 16:27.58 |
| chrisl | Robin_Watts: I'd have thought having the cache lifetime tied to the clist lifetime would solve any such problems :-( | 16:28.40 |
| Robin_Watts | chrisl: I'm using reference counting. | 16:28.57 |
| | so if something isn't decrementing properly in the existing code, it won't go away on the clist_close. | 16:29.23 |
| chrisl | Oh, okay. | 16:29.44 |
| Robin_Watts | Possibly I should just free it and be done with it on clist_close. | 16:30.05 |
| marcosw | chrisl: right, sorry. I expected the 32 bit builds and the 64 bit builds to be in the same installer (didn't notice the gs910w64.exe installer). | 16:30.52 |
| | chrisl: do we know what the ratio of downloads is for the two installers? | 16:31.10 |
| chrisl | marcosw: not off hand no. The last time I looked the 32bit one far outstripped the 64bit, but that was quite a time ago | 16:31.54 |
| marcosw | maybe i'll run weekly tests on gswin64 vs nightly for gswin32... | 16:32.33 |
| chrisl | On sourceforge, the two are about equal, for 9.10 | 16:33.02 |
| marcosw | henrys: I agree that comparing ghostpcl to hp output is better than comparing to a third party hpgl rasterizer, but there isn't anyway of automating that. We can automate comparing to viewcompanion and then plot the files which are different to determine if we or they are correct. | 16:36.19 |
| | I'm happy not to do it, just surprised that ViewCompanion only cost $54. | 16:36.44 |
| henrys | marcosw: go for it, I agree it is cheap, I had difficulty automating the other product as there was non real batch mode. If they only do a windows display it doesn't help much. | 16:38.07 |
| marcosw | There is also a ViewCompanion Premium which also reads "EPS (Encapsulated Posctscript)". I wonder whose rip they are using. | 16:38.49 |
| Robin_Watts | I think there are tools that can automatically grab windows displays to bitmaps. | 16:39.01 |
| marcosw | they can generate TIFF and JPEG files, so it's only a question of if they have a batch mode or if I have to hack something up (unfortunately the latter is one of my skills). | 16:40.10 |
| | they have a 30 day trial, so we can even save the $54 (assuming they don't watermark the output). | 16:41.18 |
| chrisl | Is it worth buying Premium just to check whether they are using GS? | 16:41.30 |
| henrys | chrisl: probably | 16:41.43 |
| marcosw | chrisl: yeah, I'm going to download the trial and check. | 16:41.47 |
| henrys | Robin_Watts: I've tried that on other platforms and always seemed to trip over something. but yes I guess it is possible. | 16:42.30 |
| | Robin_Watts: you really want to generated lots of rasters fast and rifle through them for an effective strategy. | 16:43.28 |
| ray_laptop | OK, back (for a bit). My son was complaining of a stomach ache, so I'm hoping it fades and I don't get a call from the school. | 16:44.38 |
| Robin_Watts | henrys: Sure. But there are tools out there that you can call from a script that will grab the full extent of a scrollable window into a bitmap. | 16:45.13 |
| | so you can script the collection of rasters from a windows display. | 16:45.32 |
| | ray_laptop: OK, so I have the cache list thing working. 21->14s, 18->11s for J12 at 600 and 300dpi respectively. | 16:46.05 |
| ray_laptop | I know there is a similar thing for X11 buffers, but I haven't played with it for 15+ years | 16:46.21 |
| Robin_Watts | I'm just sorting out some leaks now. | 16:46.28 |
| ray_laptop | Robin_Watts: is that with -dBGPrint=true and -dNumRenderingThreads set to whatever is fastest ? | 16:46.58 |
| | Robin_Watts: but that sounds like quite an improvement. | 16:47.10 |
| henrys | Robin_Watts: and how do you write a script to tell the program to generate the next file without a batch mode? | 16:47.22 |
| Robin_Watts | No, that's without background printing (I don't have your changes), and with -dNumRenderingThreads=4 (cos that's how I did timings before) | 16:47.27 |
| ray_laptop | Getting rid of the resampling all together would be even better | 16:47.39 |
| Robin_Watts | henrys: There are tools to drive windows from scripts too. but I admit it's much nicer if it's command line drivable in the first place :) | 16:48.17 |
| | ray_laptop: We discussed this in your absence :) | 16:48.27 |
| ray_laptop | Robin_Watts: you may want to try 2 and 3 threads. On my laptop 4 and above got slower than 2 or 3, which were almost the same | 16:48.34 |
| mvrhel_laptop | Robin_Watts: ok cluster testing a simple fix to avoid the creation of the link from the CMM | 16:48.35 |
| Robin_Watts | Yes, avoiding the resampling in the first place would be nicer in this case - mvrhel_laptop is looking at that now. | 16:48.54 |
| | but there are likely to be non-identity cases where this is still a win and we can't sidestep the generation. | 16:49.18 |
| | mvrhel_laptop: Fab. | 16:49.25 |
| | I have 2 questions, the first for ray/chrisl (and anyone else interested) | 16:49.51 |
| | In gxclist.c line 70ish. | 16:50.20 |
| | That's an enumeration function. In the writer case we explicitly check for index = 0,1,2,3,4,5 | 16:50.40 |
| ray_laptop | Robin_Watts: if I format-patch xxxx (where xxxx is a branch) will that then let you and mvrhel_laptop get the branch on to your git repo ? | 16:50.44 |
| marcosw | I have to run. If consensus is reached on customer 801 regression testing and I need to do something please send email (I try to read the irc logs but sometimes miss stuff). | 16:50.57 |
| Robin_Watts | then in the default case pass it on with index-5. | 16:51.09 |
| ray_laptop | marcosw: OK. np | 16:51.32 |
| Robin_Watts | ray_laptop: Change onto the branch, then use "git format-patch master". That will output all the patches between master and where you are. | 16:51.50 |
| ray_laptop | Robin_Watts: OK. Thanks | 16:52.19 |
| Robin_Watts | or rather, all the patches from where your current branch deviates from the history of master, I think. | 16:52.22 |
| | Returning to my question. Surely it should be index-6 ? | 16:52.38 |
| chrisl | Robin_Watts: I would have thought so, unless there's a reason we skip the first pointer in the imager state | 16:55.40 |
| ray_laptop | chrisl: that's unlikely (and dangerous) since it assumes what the first pointer in the imager_state is. | 16:56.21 |
| | Robin_Watts: checking that, however, because stranger things have been done | 16:56.45 |
| chrisl | ray_laptop: Indeed - I wasn't suggesting that would a good reason, but might be a reason..... | 16:56.58 |
| | It's also possible that an additional pointer has been added above, and the number not changed | 16:57.33 |
| Robin_Watts | chrisl: The number was incremented for the last one added. | 16:57.58 |
| | but I didn't dig further back in history :) | 16:58.09 |
| ray_laptop | Robin_Watts: it looks like 'saved' is pointer 0 in gs_state_do_ptrs(m)\ | 16:59.48 |
| | m(0,saved) m(1,path) m(2,clip_path) m(3,clip_stack)\ | 16:59.50 |
| Robin_Watts | ray_laptop: OK, so it's a typo. I'll fix that. | 17:00.13 |
| | next question... | 17:00.24 |
| | (thanks, btw) | 17:00.29 |
| | ray_laptop: In gxclthrd.c | 17:00.43 |
| ray_laptop | I can't see any good reason to skip 'saved', but it probably works because there is some place else that points to it | 17:00.49 |
| Robin_Watts | aroundabout line 413, we rc_decrement the icc_cache_cl | 17:01.06 |
| | but only in the bg print case. | 17:01.12 |
| | why do we not rc_decrement it in the non bg print case ? | 17:01.26 |
| chrisl | ray_laptop: is the clist write imager_state the graphics state, or is it really the "cut down" imager state? | 17:02.52 |
| ray_laptop | Robin_Watts: when bgprint == false, this is not a thread for the BGPrint rendering, but rather a clist rendering thread that allocated its own icc_cache. That gets freed when we call gdev_prn_free_memory | 17:04.26 |
| Robin_Watts | ray_laptop: The icc_cache_cl was allocated in setup_device_and_mem_for_thread | 17:05.12 |
| | (in the non bg print case) | 17:05.21 |
| | at around line 175. | 17:05.40 |
| | It is never freed as far as I can tell. | 17:05.47 |
| ray_laptop | Robin_Watts: that may be something I fixed in the xxxx branch, let me switch back to it | 17:05.47 |
| Robin_Watts | It gets away with it because the chunk allocator gets thrown away, so the cache goes with it. | 17:06.15 |
| | BUT I just moved that icc cache out of the chunk allocator, so now it's a real leak. | 17:06.35 |
| ray_laptop | Robin_Watts: I think you are right. So we probably want to rc_decrement it, not actually free it. That was *not* fixed on my xxxx branch | 17:09.33 |
| | rc_decrement *will* free it ordinarily, but if you change to use one from an array, setup thread would (presumably) just rc_increment the one it uses, and the free/rc_decrement would be done by the manager of the array, right ? | 17:11.11 |
| Robin_Watts | ray_laptop: My local fix is to move the rc_decrement out of the if. | 17:13.19 |
| | I make the new ones into the array, and then rc_increment when copying them out. | 17:13.43 |
| ray_laptop | Robin_Watts: yes, that makes sense | 17:13.44 |
| Robin_Watts | and when I destroy the array I rc_decrement there. | 17:13.58 |
| ray_laptop | darn. how did my toolbin disappear ? | 17:14.03 |
| mvrhel_laptop | hmm seg faults and diffs with my push, which would indicate that there are places where we may be applying an "identity" link. Robin_Watts I am going to have to look at this a bit futher | 17:14.59 |
| | need to do my expense report this week to. | 17:15.10 |
| Robin_Watts | mvrhel_laptop: No worries. | 17:15.22 |
| ray_laptop | oh, I know. When packaging up the .zip for xxxx I did: rm -fr *bin to clean up my builds. That got toolbin :-/ | 17:15.42 |
| Robin_Watts | mvrhel_laptop: and indeed, no real hurry here. With my fix it's much less of an issue than it was. | 17:16.05 |
| ray_laptop | glad I can just check it out again | 17:16.05 |
| Robin_Watts | ray_laptop: So, how are you packaging for 801? | 17:16.29 |
| | Are you just sending them a zip of 9.10 + all changes? | 17:16.37 |
| ray_laptop | Robin_Watts: I'm just zipping up my gs | 17:17.12 |
| | since that way I know they have everything they need to build (in theory) | 17:18.15 |
| Robin_Watts | ray_laptop: Ok. We should really encourage them to track us in git. | 17:18.47 |
| ray_laptop | Robin_Watts: I agree. Any idea if they are able to use git ? | 17:19.18 |
| Robin_Watts | ray_laptop: No idea at all. | 17:19.35 |
| ray_laptop | as we know, it can be a bit of a learning curve. | 17:20.04 |
| Robin_Watts | I think one of us should explain to Masaru-san that there will be large differences from 9.10 as we have made lots of changes for their use case. | 17:20.22 |
| | If he wants differences from 9.10 we will do it, but they will be large. | 17:20.40 |
| ray_laptop | Robin_Watts: agreed. | 17:20.42 |
| | Maybe the best way to convince them is to explain how to set up a local git repo and tell them how to apply series of patches to get caught up as well as sending them all of the changed files (which will be much bigger) | 17:22.54 |
| kens | OK off now, goodnight all | 17:24.51 |
| Robin_Watts | ray_laptop: I think most developers will have some experience with git these days (or at least, within the team, there will be at least one person that does) | 17:24.56 |
| | The key thing is that by moving to a git based reflow they can continuously merge or rebase to keep their stuff up to date with ours. | 17:25.46 |
| ray_laptop | Robin_Watts: it is definitely worth a shot. It will make it a *lot* easier. | 17:33.35 |
| | Robin_Watts: the cluster doesn't have a way for us to add command line arguments for a test run, does it ? | 17:35.03 |
| Robin_Watts | ray_laptop: Not for a user push, no. | 17:35.41 |
| | marcosw has set up some custom test stuff, but that's for overnights etc, AIUI. | 17:36.12 |
| | ray_laptop: 3 commits on robin/master if you want to look them over before I push them. | 17:37.38 |
| ray_laptop | darn. I want to run -dBGPrint=true -dNumRenderingThreads=4. Guess I'll just hack gs_init.ps | 17:37.44 |
| | Robin_Watts: OK. | 17:37.57 |
| | have to go get coffee. bbiab. | 17:38.58 |
| Robin_Watts | ray_laptop: You're thinking of: clusterpush.pl gs --extra-args="-dBGPrint=true -dNumRenderingThreads=4" ? | 17:39.02 |
| | marcosw: ping | 17:43.14 |
| marcosw | Robin_Watts: hey | 18:25.30 |
| Robin_Watts | marcosw: Hi. I've been fiddling in the cluster again. | 18:26.00 |
| marcosw | oh no | 18:26.07 |
| Robin_Watts | I committed all the changes that were there before I started. | 18:26.11 |
| ray_laptop | Robin_Watts: are you trying to add support for --extra-args ?? | 18:26.21 |
| Robin_Watts | so we can easily back out my breakages :) | 18:26.21 |
| | ray_laptop: I am. | 18:26.27 |
| | marcosw: The plan is that I should be able to do: clusterpush.pl gs extras=-dNumRenderingThreads=3 and it will add that extra arg to every job. | 18:27.11 |
| ray_laptop | if so, I can back out FORCE_SAVED_PAGES_TEST :-) | 18:27.36 |
| marcosw | Robin_Watts: seems reasonable | 18:28.25 |
| Robin_Watts | Do we have docs anywhere for the switches you can use for the cluster? | 18:29.29 |
| | lowres/highres/filter=/ etc? | 18:29.46 |
| marcosw | docs? What are these docs you speak of? | 18:29.50 |
| Robin_Watts | OK, that's what I thought :) | 18:30.02 |
| marcosw | or "These aren't the docs you aren't looking for." | 18:30.16 |
| Robin_Watts | I would hate to impinge upon your job security :) | 18:30.28 |
| marcosw | or "Docs? We don't need no stinking docs!" | 18:30.34 |
| ray_laptop | or "we don't need no stinking docs: | 18:30.36 |
| marcosw | great minds think alike :-) | 18:30.52 |
| ray_laptop | typed a bit to slowly :-) | 18:30.59 |
| marcosw | Robin_Watts: actually there are docs, but probably out of date, in ghostpdl/gs/toolbin/localcluster/clusterpush.txt | 18:31.42 |
| ray_laptop | Robin_Watts: so, do you want me to try it ? | 18:34.33 |
| marcosw | it looks like Robin_Watts is trying it already... | 18:34.51 |
| Robin_Watts | ray_laptop: I am testing now. | 18:34.56 |
| | ray_laptop: I'll have the results in a mo. Just long enough for you to look at robin/master :) | 18:35.26 |
| ray_laptop | what? testing a change before letting users have the full bleeding edge experience ? That's not the Artifex way ;-) | 18:35.34 |
| marcosw | you probably should have used an extras= option that is going to produce a change in output. hopefully -dNumRenderingThreads=3 will be no different than leaving out the option. | 18:35.49 |
| Robin_Watts | marcosw: That was the point. I'll look at the logs. | 18:36.06 |
| ray_laptop | definitely not what they teach in colleges ! | 18:36.22 |
| marcosw | looking at the cluster/jobs files the option is on the command line. so that's good. What are you doing for pdfwrite/ps2write jobs? Feeding extras to the first or second operation (or both)? | 18:37.01 |
| Robin_Watts | marcosw: yes. | 18:37.13 |
| marcosw | looks like both. | 18:37.46 |
| Robin_Watts | sh: 1: cannot open -dNumRenderingThreads=3: No such file | 18:38.00 |
| | oops. | 18:38.03 |
| marcosw | you need it before the '- <' for ps/eps files. | 18:38.28 |
| ray_laptop | we pipe from stdin because the ps3cet files need it that way | 18:39.14 |
| marcosw | i.e. line 621 isntead of 624. | 18:39.32 |
| | and 883 instead of 886 | 18:39.48 |
| Robin_Watts | done. | 18:39.57 |
| marcosw | looks better now. | 18:40.00 |
| Robin_Watts | OK, ray. Do you use: "git cluster" or "clusterpush.pl" ? | 18:40.17 |
| marcosw | we need a google docs for source code, so one person can edit while another observes (or edits at the same time, what fun that would be :-) ) | 18:40.35 |
| ray_laptop | Robin_Watts: I use gitpush.sh | 18:41.38 |
| Robin_Watts | OK, so you should be good to go. | 18:41.50 |
| | gitpush.sh gs extras=-dNumRenderingThreads=3 extras=-dBgPrint=1 | 18:42.14 |
| | or whatever. | 18:42.16 |
| ray_laptop | so that looks like it puts the args in "clustercmd" when it pushes it | 18:43.00 |
| Robin_Watts | It does. | 18:43.07 |
| | gitpush.sh is a "cunning piece of engineering", or "a horrid hack" depending on how you look at it. | 18:43.48 |
| marcosw | it's both! | 18:46.07 |
| Robin_Watts | ray_laptop: Are you going to fire off a test? | 18:49.22 |
| ray_laptop | Robin_Watts: in process (remote: syncing) | 18:49.41 |
| Robin_Watts | I was about to commit some stuff, but I will hold off until after you set a test going if you want. | 18:49.43 |
| ray_laptop | hmm... not starting yet ? | 18:50.49 |
| Robin_Watts | ray_laptop: You did -extras="-dBGPrint=true -dNumRenderingThreads=2" ? | 18:52.37 |
| | I think spaces present it a problem. | 18:52.49 |
| | Try: extras="-dBGPrint=true" extras="-dNumRenderingThreads=2" | 18:53.14 |
| | sorrry, without the quotes. | 18:53.25 |
| | Try: extras=-dBGPrint=true extras=-dNumRenderingThreads=2 | 18:53.34 |
| | has your prompt come back to you? | 18:53.59 |
| | That seems to work for me. | 18:55.47 |
| ray_laptop | Robin_Watts: sorry, cust 532 called. | 19:04.08 |
| | back now | 19:04.10 |
| | trying with separate extras= options... | 19:05.13 |
| pipitas | Hi. I'm trying to build something called 'zathura'. It's a lean, commandline driven document/PDF viewer, which can use poppler or mupdf as PDF backend. | 19:05.28 |
| mvrhel_laptop | so one + for VS 2013 is that it is integrated with git | 19:05.51 |
| Robin_Watts | pipitas: It's been mentioned on here before. | 19:05.56 |
| mvrhel_laptop | not sure if 2012 had that feature | 19:06.00 |
| ray_laptop | mvrhel_laptop: sounds dangerous ;-) | 19:06.14 |
| Robin_Watts | mvrhel_laptop: There are git plugins for VS200x too. | 19:06.16 |
| mvrhel_laptop | ray_laptop: yes. no way I am going to do any operations other than look at history and do diffs | 19:06.39 |
| Robin_Watts | VS2005 and VS2008 both show a Git menu for me. | 19:06.48 |
| mvrhel_laptop | ok. I never played around with them before | 19:07.03 |
| pipitas | the zathura plugin for mupdf wants that -fPIC is used for building. I was able to build mupdf with that, but now zathura looks for something called libfitz.a from a mupdf build. However there is nothing like this in the mupdf build dir. | 19:07.11 |
| mvrhel_laptop | this one seems to at least work right out of the box for looking over history and looking at diffs | 19:07.26 |
| Robin_Watts | me either. I think these ones just call to gitk. | 19:07.45 |
| pipitas | Robin_Watts: Do you have any ideas about libfitz.a and why it may be missing from the mupdf build? (I'm using the current Git version for mupdf sources) | 19:08.07 |
| Robin_Watts | pipitas: On what platform? | 19:09.38 |
| | pipitas: We've probably reworked the makefiles since zathura was last updated. | 19:10.06 |
| | We now build a libmupdf.a | 19:10.35 |
| | I suspect that libmupdf.a may be broadly equivalent to what libfitz.a used to be. | 19:11.20 |
| pipitas | Robin_Watts: Ubuntu 13.10 | 19:14.14 |
| Robin_Watts | linux, right. | 19:15.43 |
| pipitas-www | Linux, yes. | 19:16.09 |
| | I just see the following note on the zathura website: "If you are using the git version of mupdf, make sure you checkout the mupdf-git branch in our plugin repository." Maybe this is the thing.... I'll try to locate it and use it. Sorry for the premature noise... | 19:17.08 |
| Robin_Watts | ok. best of luck! | 19:17.30 |
| ray_laptop | Robin_Watts: on the collection of icc_cache elements, I prefer calling things array rather than list (list to me means singly or doubly linked list). Other than that, it looks fine | 19:17.56 |
| | Robin_Watts: but I am not hung up about the naming. It's obvious from the code that it accessed as an array | 19:18.45 |
| Robin_Watts | ray_laptop: cool. | 19:19.06 |
| | so, are you going to mail 801 about their build problems, or should I ? | 19:19.33 |
| ray_laptop | Robin_Watts: so, the extra rc_increment following the gsicc_cache_new is so that it won't go away when the thread is torn down, right? | 19:20.08 |
| Robin_Watts | exactly. | 19:20.25 |
| | both the array and the icc_cache_cl entry have their own references. | 19:20.40 |
| | ray_laptop: So, are you going to mail 801 about their build problems? | 19:38.57 |
| | If I'm going to do it, I need to do so soon, cos I'm gonna stop for the night in a bit. | 19:39.16 |
| pipitas | Is there any commandline tool or parameter option (or a small PostScript program) for gs or for mutool that can attach a file to a PDF using /EmbeddedFile ? | 19:40.31 |
| | Also, is there a commandline parameter that tells Ghostscript to NOT remove an embedded file when doing PDF->PDF conversion? | 19:41.19 |
| Robin_Watts | pipitas: No, and no. | 19:42.19 |
| | PDF->PDF using gs completely breaks the file down and then builds a whole new file up. | 19:42.46 |
| | There is no concept of "not removing an embedded file" because the output file bears no resemblance to the input file (except for hopefully rendering the same) | 19:43.20 |
| Robin_Watts | will leave mailing 801 to ray then. | 19:45.30 |
| pipitas | Robin_Watts: I know that, basically. Let me re-phrase it: instead of "not removing an embedded file", could it be made so that when "gs completely breaks the input PDF down" it preserves the embedded file and "puts it back in when building the whole new file"? | 19:56.06 |
| ray_laptop | Robin_Watts: OK. I am trying the build on linux... | 19:56.28 |
| Robin_Watts | pipitas: still no way to do that | 19:56.53 |
| | ray_laptop: So shall I commit my cache changes? | 19:57.04 |
| ray_laptop | Robin_Watts: please got ahead. | 19:57.15 |
| | s/got/go/ | 19:57.21 |
| Robin_Watts | done. | 19:57.35 |
| | thanks. | 19:57.50 |
| pipitas | Robin_Watts: It would be cool if it could be added as a new feature sometime in the future. JDF job tickets are also passed along as embedded files, for example. | 19:59.19 |
| Robin_Watts | pipitas: It is something that could probably be added to mupdf fairly simply. | 20:10.36 |
| pipitas | Robin_Watts: Who decides about priorities for feature requests to be implemented in mupdf? Can he/she be bribed? :-) | 20:12.20 |
| henrys | oh joy my bug today is a 7 1/2 foot plot let the thrashing commence | 22:27.56 |
| | marcosw_:how did you view this. Imagemagick blows up. | 22:29.15 |
| | ? | 22:29.18 |
| marcosw_ | I didn't viewed it yet. still waiting for my plotter to finish :-) Have you tried photoshop? | 22:30.18 |
| henrys | I'll just fix the code I don't really need to look at it ;-) | 22:31.34 |
| | marcosw_: the ppm was 2.1 G | 22:36.21 |
| | marcosw_: probably not a good file for the cluster test | 22:37.58 |
| | marcosw_: the gimp works | 23:11.54 |
| marcosw_ | how long did it take to open? | 23:12.20 |
| henrys | 5 minutes or so | 23:12.33 |
| | on a dated mac pro | 23:12.46 |
| marcosw_ | hey, your mac pro is a generation newer than mine :-) | 23:13.34 |
| henrys | you have the retina no? | 23:13.53 |
| | I'm 2011 | 23:13.58 |
| marcosw_ | my MacBook Pro is a retina, from last year, but my Mac Pro is the 2007 model. | 23:14.21 |
| henrys | oh sorry I'm on my macbook pro woops | 23:14.38 |
| marcosw_ | they are about the same speed in terms of compiling ghostscript (both have 8 cores, 16 gigs of memory, etc). My Mac Pro is 2.2 GHz and my MacBook Pro is 2.6 Ghz. The MacBook Pro is faster with single tasks since it's cpu has turbo mode, otoh the MacPro has a very high end graphics card so photoshop is much faster. | 23:16.05 |
| henrys | you don't get any bang out of the xeons? | 23:16.52 |
| marcosw_ | Intel's web site says: "Intel® Turbo Boost Technology :No" | 23:18.31 |
| | and no hyper threading | 23:18.45 |
| henrys | Anyway I'm done with the bug and will have a fix so you need not fool with it unless you want to. | 23:19.06 |
| marcosw_ | henrys: this is for the oil plot? there is another file as well. | 23:20.09 |
| henrys | oh christ | 23:20.19 |
| | I wonder how big that one will be. | 23:21.06 |
| marcosw_ | it's not as big but not small. it's called 101.plt. I haven't opened a bug yet since I wanted to plot it first. | 23:23.10 |
| henrys | marcosw_: take your time ;-) | 23:24.13 |
| marcosw_ | my plotter is probably still wasting paper & ink plotting the oil files; I started it and left the house to run some errands. | 23:24.43 |
| | Forward 1 day (to 2013/11/13)>>> | |
IRC Logs