| <<<Back 1 day (to 2013/01/17) | 2013/01/18 |
mvrhel_laptop | hmm. Miami flights from here all pretty much blow | 06:27.16 |
marcosw | mace: I was just looking at flights too. | 06:38.15 |
| ^mace^mvrhel_laptop | 06:38.29 |
mvrhel_laptop | you probably have a few more options from where | 06:38.31 |
| there | 06:38.33 |
| I saw one of my options was to fly to SFO | 06:38.53 |
| first | 06:38.55 |
| marcosw: the times from here are all pretty sucky and the prices are high | 06:39.22 |
marcosw | it's still a long travel day and $500+ | 06:39.31 |
mvrhel_laptop | yes | 06:39.35 |
marcosw | oddly enough if I stay an extra day the fare drops by nearly $200. I've never heard of a Monday night stay requirement. | 06:40.05 |
mvrhel_laptop | wow | 06:40.12 |
marcosw | or maybe the Monday afternoon flights are pretty full already. | 06:40.23 |
mvrhel_laptop | that could be | 06:40.28 |
| most of the flights back seem to leave early in the morning | 06:40.40 |
marcosw | $661 if I fly back on Monday, $475 if I fly back on Tuesday | 06:41.35 |
mvrhel_laptop | wow I can't get below 500 | 06:41.56 |
| even with a tuesday return | 06:42.04 |
| I take that back. AA is below 500 | 06:43.59 |
marcosw | I'm not a big fan of AA. BTW, have you seen their new logo? | 06:45.35 |
mvrhel_laptop | I am not either. I think I am going to use Alaska. It shares the AA flights | 06:46.01 |
| and the cost is the same and I am more likely to use the miles on Alaska | 06:46.16 |
| oh wow. they repainted the planes | 06:47.04 |
marcosw | apparently they couldn't keep the old plane colors since that color scheme kept part of the plane was unpainted aluminum (i.e silver colored) and the 787 which they are getting soon is composite, so not silver. THis presumes they manage to figure out how to keep 787 the batteries from starting fires :-( | 06:49.29 |
mvrhel_laptop | yes. I would not want to be a Boeing EE right now | 06:49.52 |
| big news around here since Boeing has such a big presence here | 06:50.11 |
| oh a non stop back at $538 | 06:59.00 |
marcosw | non-stop miami->seattle? That has to be the longest continental US flight. | 07:01.31 |
mvrhel_laptop | yes :) | 07:01.37 |
| and it leaves at 5pm | 07:01.44 |
marcosw | 2724 miles. SFO-BOS is close though, 2707. | 07:03.46 |
| I booked the Tuesday return, but not sure if that's a good idea. Oh well, I have 24 hours to decide. | 07:06.21 |
mvrhel_laptop | well I hate the AA web site. no wonder they went bankrupt | 07:14.42 |
| after putting in the credit card information it gave me this | 07:15.14 |
| Note: This is not your receipt. You will be receiving your itinerary confirmation along with your receipt soon. You may print your Itinerary & Receipt directly from AA.com once the status is updated from "Purchased" to "Ticketed". | 07:15.16 |
| if the status is purchased you would think I would get a receipt | 07:15.42 |
| as purchased implies I paid for it | 07:15.57 |
| plus I got a bonus pop up of "We are experiencing technical difficulties with your seat assignment at this time. Please try again later. " | 07:16.27 |
| so, I am not sure if I bought a ticket or not | 07:16.51 |
| ok that is done. good night all | 07:25.34 |
kens | chrisl ping | 08:22.59 |
chrisl | kens: pong | 08:24.29 |
kens | Have you looked at flightsa yet ? | 08:24.39 |
| Virgin flight back departs at 22:35 | 08:24.53 |
chrisl | No, I'm busy being annoyed at VA right now..... | 08:25.05 |
kens | Oh .... What is the problem ? | 08:25.15 |
chrisl | Looking at Premium Economy seats: money only 1079ukp, money + miles 1004ukp - wtf is the point of the air miles? | 08:26.31 |
kens | Not a great deal really | 08:26.45 |
kens | thinks economy this time | 08:27.02 |
chrisl | I may go PE on the return | 08:27.26 |
kens | £611 | 08:27.30 |
| return is under 9 hours flight time | 08:27.43 |
chrisl | No too bad, the | 08:27.53 |
| then.... | 08:27.57 |
kens | Yes | 08:28.03 |
| We get a big wind boost coming home it seems, outward is nearly 10 hours | 08:28.14 |
| Hmm T&Cs have changed on the web site. Oh well.... | 08:31.06 |
chrisl | I'm surprised at how much extra PE is this time | 08:33.31 |
kens | Well verified by viosa collapsed on me, now I have to start again | 08:33.36 |
| I guess I'll use Internet Exploder | 08:33.51 |
| OMG the stie looks totally different.... | 08:37.32 |
| Bizarrely the outward flight is 160 more than the return leg... | 08:38.06 |
| WHich wasn't what the site showed under Firefox | 08:38.18 |
chrisl | But the total is the same? | 08:38.30 |
kens | Yes | 08:38.50 |
chrisl | I've got the same difference between the out and return - maybe more people want to go *to* Miami than return from there! | 08:39.46 |
kens | OK lets see if VbyV works on IE | 08:41.45 |
| Nope transaction failed. | 08:41.53 |
| So I'm going to have to phone Visa (again) | 08:42.05 |
| Card blocked by Visa, no explanation but I can use it now.... | 08:46.23 |
| and teh virgin web site won't let me go forward now. Guess I get to start again :-( | 08:46.54 |
| Oh God this time IE crashed.... | 08:51.12 |
| Not having a good morning here | 08:51.32 |
| ?me goes back to Firefox | 08:51.45 |
chrisl | Okay, I'm booked. Strangely, the booking summary gave both flights at exactly the same price..... total cost/2 | 08:54.52 |
kens | I'm not getting anywhere I'm going to phone them. THIs time the verified by visa screen just vanished | 08:55.18 |
| I wonder if its a Java bug | 08:55.43 |
| IU know, lets try Chrome | 08:56.23 |
| Can't have too many browesers | 08:56.37 |
| Huh had a look at 'bid now' to upgrade your seat, and the lowest possible bid is the same as the PE cost. So what'st the point ? | 09:04.01 |
chrisl | I'm going to check the upgrade price nearer the time - just in case | 09:06.28 |
| Oh, crap, it's snowing quite heavily here, now :-( | 09:06.56 |
kens | here too | 09:07.05 |
| chrisl what seat did you book ? | 09:10.35 |
chrisl | 63G out, and 59G return | 09:11.25 |
kens | OK I'll take 52G | 09:11.53 |
| 62G | 09:11.57 |
| let'sd see what the return looks like | 09:12.21 |
| 60G then | 09:13.04 |
| and now, some work.... | 09:13.36 |
chrisl | or possibly coffee..... | 09:14.44 |
kens | Actually, now you mention it..... | 09:14.54 |
Robin_Watts | I think Helen is going to come with me to Miami, and then we'll head down to Key West for a few days after the meeting. | 10:55.08 |
| For the price of her flight + a few nights in a hotel, it's a nice break. | 10:56.08 |
kens | sounds goods | 11:07.53 |
| good* | 11:08.03 |
| Melanie still at college so we can't do that | 11:08.16 |
Robin_Watts | chrisl: You here? | 13:00.17 |
chrisl | Robin_Watts: I am now | 13:07.15 |
Robin_Watts | I'm pondering this unicode stuff again. | 13:08.48 |
kens | Aaaaggghh (runs away screaming) | 13:09.13 |
chrisl | Ugh :-( | 13:09.14 |
Robin_Watts | The basic plan is that ghostscript should hold everything (filenames/paths etc) as utf8 internally. | 13:09.52 |
| For unix this is no change, for windows, this means stuff gets rewritten as it goes in. | 13:10.08 |
| For systems with weird encodings (like say EBCDIC) we'd convert on the way in too. | 13:10.38 |
| I think I've got everything working, and sags is happy with it all, except for the handling of environment variables on windows. | 13:11.05 |
| gp_getenv calls getenv, and I'm currently assuming that that will be utf8 encoded. | 13:11.54 |
| This is fine for 7 bit stuff, but when we start having top bit set stuff in the environment var, it's going to all go wrong. | 13:12.25 |
chrisl | I take it we're ignoring the executive mode? | 13:12.43 |
Robin_Watts | So, the plan which I have just formulated, and I'd like your opinion on, is to... | 13:12.51 |
| the what? | 13:12.54 |
kens | interactive typing at prtompt | 13:13.03 |
chrisl | Postscript executive | 13:13.07 |
Robin_Watts | I think that's all sorted. | 13:13.55 |
| For gswin32, input and output are converted to/from utf8 and displayed appropriately. | 13:14.26 |
chrisl | Oh, okay | 13:14.40 |
Robin_Watts | So if we output a utf8 string, it appears as unicode chars in the windows. | 13:14.43 |
| Can't remember about gswin32c.exe, but it's filed mentally in the 'done' column. | 13:14.58 |
| I think the only problem we have now is with gp_getenv. | 13:15.19 |
| My plan is to change gp_getenv to use wgetenv instead of getenv. | 13:15.45 |
chrisl | Not much choice, I'd have thought | 13:16.11 |
Robin_Watts | This means (I believe) that windows will automatically convert any 8 bit environment variables from the current codepage to unicode (and any unicode ones will stay there). | 13:16.29 |
| Then I convert them down to utf8, and we get what we want. | 13:16.39 |
| presumably I need to check that gp_getenv_registry is doing the right thing too. | 13:17.17 |
| Can anyone see any immediate reasons why this is a bad idea? | 13:17.34 |
chrisl | Looks like you've already done gp_getenv_registry() | 13:19.23 |
Robin_Watts | No, currently just the name that I look up is converted | 13:20.31 |
| oh. wait... yes, you may be right. | 13:21.02 |
| so it's just wgetenv then. | 13:21.19 |
| OK. I'll dive back into that after lunch. | 13:21.28 |
chrisl | Sounds good to m | 13:21.38 |
| e | 13:21.40 |
Robin_Watts | I am NOT enabling this before the release, but hopefully we can enable it immediately after it. | 13:21.47 |
chrisl | I could do as we originally planned and do a "beta" build of the release but with the new code active. | 13:23.04 |
Robin_Watts | I wouldn't even want to commit this (on the trunk) until after the release. | 13:25.26 |
chrisl | Okay, fair enough. I still think it would be good to "preview" it before it goes in a full release | 13:26.36 |
Robin_Watts | chrisl: We could do a 'unicode' branch and put it there and do a build from that. | 13:26.55 |
chrisl | Sure, we can discuss it nearer the time - not rush | 13:27.31 |
Robin_Watts | Wow. Bug 693212 is FUNKY. | 14:37.13 |
kens | weird | 14:51.09 |
Robin_Watts | It's dashed strokes specifically. | 14:54.35 |
| hehe, it's one of the very earliest things I did :) | 15:23.35 |
henrys | Postscripters:I'll ask ray when he comes in later, any reason all the languages shouldn't use O_BINARY for stdin? http://bugs.ghostscript.com/show_bug.cgi?id=693543 | 16:02.43 |
| if not I'll move my change to the library instead of isolating it to PCL. | 16:03.51 |
chrisl | henrys: I think we should be using binary for stdin for everything | 16:04.47 |
Robin_Watts | henrys: If you use binary stdin can you still Ctrl-Z? or could you ever? | 16:05.04 |
henrys | chrisl:did you get with karen yet? curious to see how that goes. | 16:05.32 |
chrisl | henrys: I mailed yesterday, she replied that she's passed it onto the account manager for approval - the tone was that it's just a formality | 16:06.32 |
| Robin_Watts: Ctrl-Z on Windows? | 16:07.21 |
Robin_Watts | yeah, it's like Ctrl-D on unix. | 16:07.36 |
henrys | Robin_Watts: I think it means ctrl-z would not have special meaning to the OS we can of course parse for it. | 16:07.51 |
Robin_Watts | "copy con: file" then type, and it goes into file, until you hit Ctrl-Z. | 16:07.56 |
kens | CTRL-Z = EOF | 16:08.14 |
| If you set to binarty mode that won't woprk | 16:08.27 |
chrisl | Of course, Windows would be different..... | 16:08.34 |
Robin_Watts | Right, if I do gswin32c.exe and then type some postscript, and hit Ctrl-Z and then hit return, that's EOF. | 16:09.15 |
henrys | right with binary mode the read will not return EOF if a ctrl-z is encountered n the stream. | 16:09.26 |
Robin_Watts | henrys: I'm guessing that's a problem for postscript then. | 16:09.45 |
chrisl | Presumably the interpreter must handle EOFs otherwise stdin wouldn't respond to ctrl-d on Unix? | 16:09.52 |
Robin_Watts | The interpreter doesn't see a Ctrl-D though. It just sees stdin come to the end, right ? | 16:10.39 |
chrisl | stdin on Unix is "binary" | 16:11.06 |
Robin_Watts | right, but the Ctrl-D interpretation is done by the shell that's taking your keystrokes and putting them into stdin. | 16:11.35 |
| isn't it ? | 16:11.41 |
| Maybe it'll be the same on windows. | 16:12.01 |
| I guess we should try setting stdin to binary on windows and see if Ctrl-Z still works as we expect | 16:12.21 |
chrisl | Easy way to find out is to use henrys' pcl exe | 16:12.39 |
Robin_Watts | except I can't type pcl. | 16:12.52 |
chrisl | You don't need to, just send it ctrl-z | 16:13.25 |
| An empty file is a valid PCL file | 16:13.55 |
kens | Or just type some text, right ? | 16:14.23 |
henrys | yes just text is better than nothing I think. | 16:14.39 |
| actually I can test it thanks for the feedback. I'd like to hear from ray - I don't understand how we have all these postscript tests read from stdin in the cluster tests. There are no binary tokens not armored? | 16:16.25 |
| I guess nobody does windows cluster tests also. | 16:17.03 |
Robin_Watts | right, on unix stdin is binary, hence no problems. | 16:17.29 |
| Ctrl-Z (or Ctrl-D) have no meaning once they are into the stdin stream. | 16:17.53 |
| sorry, no *special* meaning. | 16:18.02 |
chrisl | Using stdin on Windows is pretty rare, I reckon - stdin/stdout pipelines are much more a Unix thing..... | 16:18.10 |
Robin_Watts | It's when we have a terminal converting keystrokes into the stdin stream, that the ctrl-D turns into an EOD. | 16:18.36 |
henrys | right but the terminal signals EOF not the C library when it sees ctrl-D right? | 16:19.19 |
Robin_Watts | OK, I added a _setmode(_fileno(stdin), O_BINARY); to a ghostscript windows build and ctrl-z still works as expected. | 16:19.33 |
| yes, the terminal closes stdin for writing. | 16:19.58 |
| so when the reader gets to that point, it gets EOF back from the C lib. | 16:20.23 |
| So, I take it back, I think setting stdin to binary is fine for everything. | 16:20.51 |
henrys | well since it is sitting there in your tree you can go ahead and pop it in and I'll ditch my pcl change. I feel pretty confident it is okay. | 16:21.56 |
Robin_Watts | henrys: I hacked it in horribly. | 16:22.10 |
chrisl | henrys: just got a reply from Karen - I can download the latest version, and I have a login to their developer portal. I'm going to leave it until Monday, though. | 16:22.12 |
henrys | Robin_Watts: oh right I'll do it. you didn't use the gp call either. | 16:22.59 |
Robin_Watts | gp call wasn't present on my build. | 16:23.13 |
| (i.e. I tried it and got a symbol not found) | 16:23.22 |
henrys | oh it worked okay with windows pcl - that's odd. | 16:23.59 |
| I'll look into it. | 16:24.08 |
Robin_Watts | I was probably calling a function that's in the DLL from outside the DLL or something. | 16:26.55 |
henrys | yet another change where it would be nice to have some windows cluster testing going on. | 16:28.19 |
| marcosw heads for the hills | 16:28.40 |
| Robin_Watts:Helen coming to Florida? Saw she said something on FB | 16:29.30 |
Robin_Watts | henrys: Yes, Helen is coming, and we're heading down to Key West afterwards for a few days. | 16:29.59 |
| (I'm paying for Helen's flight etc, obviously) | 16:30.26 |
| will Sabrina be joining you? | 16:30.40 |
henrys | I really enjoyed returning to Key West last meeting in Florida - I lived there for a few years and got tired of it but it was nice to return. | 16:31.32 |
Robin_Watts | I've been told it's lovely. Looking forward to it. | 16:34.22 |
| hmm. Looks like the potential fix for bug 693212 will change 1/4 of our cluster files. Marcosw will hate me. | 16:48.09 |
henrys | his ears were ringing | 16:54.40 |
Robin_Watts | hmm. so thin lines don't obey fill adjust. | 17:26.44 |
| mvrhel_laptop: So, did you have any luck with that pattern file? | 18:03.29 |
mvrhel_laptop | Robin_Watts: I talked with ray_laptop about it on the phone yesterday afternoon. What is weird is that on the interpreter side the pattern is getting put into the pattern cache twice | 18:04.55 |
| that is the drawing fill occurs two times for some reason | 18:05.28 |
| Looking at your file, I don't see why that should be happening | 18:05.43 |
Robin_Watts | If the interpreter is putting the same pattern into the cache twice, how come the reader fails to find it? | 18:05.45 |
mvrhel_laptop | well, the reader works ok the first time | 18:06.04 |
Robin_Watts | I mean, surely one of the two things in the cache should match the one the reader is looking for? | 18:06.06 |
mvrhel_laptop | let me back up | 18:06.11 |
| the cache is flushed the second time the drawing occurs since there is not enough room for another copy of the pattern | 18:06.35 |
Robin_Watts | (Woop! Woop! Woop! This Michael is reversing...) | 18:06.43 |
mvrhel_laptop | so that is puzzling to me. why would, during the writing phase (interpreter) the drawing for the pattern occur twice | 18:07.26 |
Robin_Watts | ok, so it gets put in twice, but by the time the reader gets there one of them has been evicted. | 18:07.35 |
mvrhel_laptop | then during the clist reading, the correct pattern is in the cache | 18:07.43 |
| but we have a soft mask push | 18:07.52 |
| a pattern fill, which works fine | 18:07.57 |
| then the soft mask pop | 18:08.02 |
| and another attempt at a pattern fill, which is wrong | 18:08.12 |
| as the pattern fill should only be occurring during the softmask | 18:08.26 |
Robin_Watts | Sounds like it might be the postscript calling the C wrongly? | 18:09.04 |
| i.e. a bug in the interpreter? | 18:09.17 |
mvrhel_laptop | I was hoping to have ray_laptop explain to me why the two fills are occurring initially before time is spent debugging clist stuff | 18:09.18 |
ray_laptop | mvrhel_laptop: I'm here | 18:09.29 |
mvrhel_laptop | Robin_Watts: that seems like a possibility to me. I dont understand looking at the source file why it occurs twice, but it is possible I have made a mistake | 18:09.54 |
ray_laptop | I do see the pattern written twice. Once with id=f3 and the second time with id=101 | 18:10.14 |
mvrhel_laptop | oh good. it is possible there are two problems occurring here | 18:10.54 |
ray_laptop | let me trace that again to watch the sequence. I wish the cutdown file didn't have so much indirection. I have to keep remembering which object is which. | 18:11.59 |
Robin_Watts | ray_laptop: Have you got my cutdown file? | 18:12.25 |
| I can't reduce the indirection any further, IIRC. | 18:12.40 |
ray_laptop | mvrhel_laptop: first, I'll try and understand why the SMask is being done twice (the transparency group going in twice) | 18:12.52 |
| Robin_Watts: yes | 18:12.55 |
| Robin_Watts: the Resources on the page can be direct dictionaries, e.g. /ExtGstate << /Image2 11 0 R >> | 18:14.12 |
Robin_Watts | That's true. | 18:14.33 |
| Would you like me to shrink the file with that in mind? | 18:14.44 |
ray_laptop | Robin_Watts: no, that's OK. I can do it. A couple more times through and I'll have the object numbers all straight anyway | 18:15.18 |
mvrhel_laptop | ray_laptop: yes. you are correct. the whole softmask gets pushed twice for some reason | 18:16.34 |
| once to all the bands | 18:16.55 |
| and then once for bands 1 to 11 | 18:17.09 |
kens | Night all | 18:17.16 |
mvrhel_laptop | bye kens | 18:17.21 |
| oops too slow | 18:17.24 |
| I have to head out for bit. bbiaw. | 18:19.13 |
ray_laptop | mvrhel_laptop: OK so the Contents does "/Image2 gs" which is an ExtGstate (obj 11) that has an SMask (obj 10). The SMask has it's Group in obj 9 which is a Form that includes the stream that paints a rectangle with the pattern. | 18:26.12 |
| mvrhel: So this I see in the -Zv and PDFDEBUG output pretty clearly. | 18:27.09 |
henrys | ray_laptop:you may want to opine about the stdin discussion above. | 18:33.00 |
ray_laptop | henrys: let me look at the logs ... | 18:34.29 |
| henrys: I don't think the PS interpreter ever opens stdin -- it is expected to be open when we start. But binary is fine (unless the shell captures something), but when piping from a file, stdin is biinary | 18:44.26 |
henrys | ray_laptop:you mean gs sets it to binary somewhere? It isn't binary by default on windows, that's what my bug is about. | 18:50.08 |
ray_laptop | henrys: this: { (%stdin) (r) file 4 string readstring = { = } forall flush } exec A^ZB^Dquit (where the ^Z is 0x1a ans the ^D is 0x04) prints: | 18:51.25 |
| true | 18:51.27 |
| 65 | 18:51.28 |
| 26 | 18:51.30 |
| 66 | 18:51.31 |
| 4 | 18:51.33 |
| on Windows when that file is piped into stdin | 18:51.34 |
| henrys: let me try with a file that has the upper bit set... | 18:52.13 |
henrys | so somewhere gs must be setting stdin to binary. Or my bug fix is misunderstanding the underlying issue. | 18:53.44 |
ray_laptop | that works fine as well. I changed the 1a to 9a and got out 154 | 18:53.49 |
| henrys: which bug (sorry I haven't been following this) | 18:54.13 |
| henrys: gs doesn't do ANYTHING with stdin (except perform 'fread' on it) | 18:54.45 |
henrys | 693543 | 18:54.45 |
ray_laptop | whatever starts the process opens stdin, apparently as binary | 18:55.07 |
henrys | dwmainc.c sets it no? | 18:58.06 |
| what happens if you don't use the display device? | 18:58.29 |
ray_laptop | henrys: I tested with the console mode 'gswin32c.exe' | 18:59.06 |
| henrys: have a look. dwmainc.c only performs '_read' on stdin | 19:00.16 |
chrisl | ray_laptop: dwmainc.c does _setmode(fileno(stderr), _O_BINARY); | 19:00.49 |
ray_laptop | chrisl: but NOTHING with stdin | 19:01.15 |
chrisl | ray_laptop: it also does _setmode(fileno(stdin), _O_BINARY); | 19:02.12 |
ray_laptop | oops. no, i do see it. Sorry | 19:02.19 |
| (why didn't my first search find that ??? :-/ ) | 19:02.48 |
henrys | well I'm glad I asked. now I need to understand _isatty() | 19:03.01 |
ray_laptop | so it is conditional on _isatty | 19:03.07 |
| _isatty is just the Windoze name for isatty | 19:03.54 |
chrisl | "Determines whether a file descriptor is associated with a character device." | 19:04.08 |
| I need to finish - 'nite all | 19:05.13 |
henrys | right - what I mean is my current thinking was it should be okay for binary and a tty. Anyway since you already have something that someone obviously thought about carefully :-) I'll just make my change local to PCL. | 19:05.30 |
ray_laptop | henrys: so I recommend you go ahead and make it conditional on isatty like dwmainc does | 19:05.55 |
| otherwise starting up pcl from stdin may end up not being responsive to ^C | 19:07.08 |
henrys | I guess I could but there is no console for the other languages. | 19:07.11 |
ray_laptop | henrys: what do you mean, there is no console ? | 19:07.45 |
henrys | nobody types in PCL and XPS to stdin from the terminal | 19:08.30 |
| or PDF for that matter. | 19:08.55 |
ray_laptop | no, but if they did it by mistake, it would be nice to be able ^C out (someone mistakenly hits <enter> after "pcl6 ... - " | 19:09.56 |
henrys | now I need a gp routine for tty | 19:11.09 |
ray_laptop | henrys: I don't understand your comment in the bug: you will need to find another way to run the interpreter for it to be useful. Once fixed it will not pause at each page. | 19:12.03 |
| henrys: or just make a conditional compile that does #define isatty _isatty when on windows | 19:13.33 |
henrys | well if you run from stdin pause is disable so the display page just scroll by, should be the same in gs | 19:13.40 |
| no? | 19:13.42 |
| ray_laptop:guess I could do that. | 19:14.02 |
ray_laptop | henrys: there is a disable of pause based on stdin_is_interactive | 19:15.04 |
henrys | right so I was just saying in the bug that the change will fix the crash but once it's fixed he won't be able to see the pages because PAUSE isn't in effect. | 19:16.13 |
ray_laptop | henrys: depends on how slow his computer is ;-) | 19:16.44 |
| back to the VOX crash debugging... | 19:17.20 |
henrys | If we used the gp_ routines in dwmainc.c I would have seen it and this would have been a lot easier. I know it is device dependent file but it's nice not to fish around for platform specific system calls. | 19:20.47 |
ray_laptop | Robin_Watts: (mvrhel for the logs). OK. So the reason we load the pattern twice is that we do it once for the '/Image2 gs' because that ExtGstate has the SMask, but then pdf_draw.ps pushes another transparency group because the ExtGState has an SMask and we load the pattern again for the group. | 19:32.27 |
| so clearly we _should_ be finding the same pattern already in the cache, but we don't. Just a performance hit, not a bug (yet) | 19:33.06 |
| Robin_Watts: (mvrhel) OK. everything works as expected if I only have 1 band. So the problem happens when there is more than one band. | 19:50.35 |
| When it is in multiple band mode, it immediately gets the 'end_run' following the pattern data. In the single band case, this is followed by 'fill' that paints the pattern, so the SMask is left unpainted. Then we end the transparency mask. | 20:01.56 |
| OK. so the second copy of the pattern is being loaded from the clist, without the intervening second set of 'begin transparency group' and 'begin transparency mask' that should be there. This | 20:21.33 |
| back to watching the 'writer' side. | 20:21.55 |
| The writer only writes the second set of transparency actions because it calculates which bands will need it -- in this case band 1 to band 11, so band 0 doesn't get the compositor commands | 20:41.12 |
| next looking at why the pattern _is_ getting written to all bands (probably because it is big and we don't want to only write it in some bands) | 20:42.13 |
| YEP. That's the culprit. Strange we haven't run across this before | 20:44.59 |
| so when the reader stumbles across the second pattern, the transparency had done an 'end_mask' so the device color space was back to depth 24, but the pattern expects to be loaded as part of a mask, so it has depth 1. | 20:47.03 |
| so the question is, do we need that check ?? | 20:55.14 |
marcosw | alexcher: is this a good time to add the new cluster node? | 20:55.32 |
ray_laptop | marcosw: while you are here... | 20:56.04 |
marcosw | ray_laptop: yes? | 20:56.13 |
ray_laptop | marcosw: did you see the discussion that the -dMaxBitmap for the regression mode .1 was bogus | 20:56.39 |
| marcosw: it had been set to 40,000,000 not 400,000,000 | 20:56.58 |
| commas for clarity | 20:57.09 |
| so many of our .0 mode files were using clist mode | 20:57.36 |
| (sorry above, the problem is for the .0 page mode) | 20:57.50 |
marcosw | clearly we need to be able to specify values scientific notation. i.e.: 4e8 | 20:59.00 |
| I've changed the cluster scripts to use 400,000,000, but the value has never been that big. In 2009 it was 30,000,000. | 21:09.01 |
alexcher | marcosw: yes, everything is ready. | 21:21.06 |
ray_laptop | alexcher: we (mvrhel and I) just realized that the issue we were tracking was exactly what you had found on bug 693422. | 21:59.57 |
| marcosw: the value used to be 300,000,000 for non-clist (page) mode | 22:09.44 |
| iirc | 22:10.19 |
| mvrhel_laptop: the patch (alex's) did get rid of the sumatra SEGV's -- the only remaining one I got was the plank one | 22:13.20 |
| Robin_Watts: weren't you working on a fix for the plank SEGV ?? | 22:13.41 |
marcosw | ray_laptop: what are you basing the claim that the valued used to be 300,000,000? | 22:21.52 |
| alexcher: sorry, I was away from my computer. | 22:22.11 |
| brb | 22:29.25 |
ray_laptop | marcosw: just memory from long ago | 22:29.37 |
| 30,000,000 also would not have been big enough to do some jobs in page mode | 22:30.02 |
marcosw | ray_laptop: I checked the git history for the cluster and as far back as 2009 it was 30,000,000. The nightly cluster regression that used to run peeves and now runs on my imac says this: | 22:32.01 |
| def process(self): | 22:32.03 |
| bandsize = 30000000 | 22:32.03 |
| if (self.band): bandsize = 10000 | 22:32.03 |
| which is also 30,000,000 | 22:32.18 |
| I'm not saying that 30,000,000 isn't wrong, just that it what it has always been. | 22:32.57 |
ray_laptop | marcosw: I guess I remember wrong. Even so, 40,000,000 isn't large enough to do page mode on many files with transparency | 22:33.14 |
marcosw | it's now 400,000,000, so presumably that's more better. | 22:33.41 |
| I guess I should change it on the nightly/weekly/performance regression machines as well... | 22:34.40 |
ray_laptop | marcosw: thanks for updating it to 400m even for letter size pages, it takes 150m | 22:36.12 |
| for 300 dpi ppmraw, that is | 22:36.32 |
marcosw | presumably it was originally set for 300 dpi, non-transparency, which I believe is 25m for a letter size page | 22:38.08 |
| Forward 1 day (to 2013/01/19)>>> | |