| | <<<Back 1 day (to 2014/03/02) | 2014/03/03 |
| Robin_Watts | Has anyone else seen anything like: http://ghostscript.com/~regression/robin/compare12.html | 11:48.30 |
| | The first one there. | 11:48.35 |
| | It looks like it's mixing 2 pages. | 11:48.45 |
| | but I can't understand how. | 11:48.58 |
| | and I can't reproduce it locally, or on peeves. | 11:49.08 |
| kens | Prety weird, looks like showpage didn't work | 11:53.35 |
| Robin_Watts | mupdf :) | 11:53.44 |
| kens | Well can't help there :-) | 11:53.53 |
| Robin_Watts | I can reproduce it locally. | 12:22.20 |
| | I see what's going wrong. | 12:30.06 |
| | getenv is not thread safe, right? | 13:54.53 |
| | If 2 threads call getenv at the same time, they can overwrite one anothers buffers. | 13:55.18 |
| | We use gp_getenv in the core of gs, so that's a potential problem, right? | 13:56.15 |
| tor8 | It's not guaranteed to be reentrant | 13:56.27 |
| | but most likely it just returns a pointer to the envp char** array (the third, mostly unused, argument to main) | 13:56.50 |
| chrisl | "As typically implemented, getenv() returns a pointer to a string within the environment list. The caller must take care not to modify this string, since that would change the environment of the process." | 13:57.24 |
| henrys | "The getenv() function is inherently not thread-safe because it returns a value pointing to static data." | 13:58.16 |
| Robin_Watts | chrisl: But anyone writing to the environment in another thread can invalidate that pointer. | 13:58.18 |
| | So for anyone calling gsapi, it's a crapshoot. | 13:58.45 |
| chrisl | Robin_Watts: generally, yes. But it's fairly rare to change the environment within the exe | 13:59.12 |
| Robin_Watts | Surely there must be a thread safe standard version... | 13:59.52 |
| chrisl | Not a standard one, no | 14:00.02 |
| | Robin_Watts: actually, I've been thinking about threading stuff: we currently have no way to do one time initialisation tasks in threadsafe gs.... | 14:00.27 |
| Robin_Watts | chrisl: static int inited = 0; | 14:01.04 |
| chrisl | Robin_Watts: doesn't work, that's a race condition | 14:01.18 |
| Robin_Watts | if (inited) { do_init(); inited =1; } | 14:01.18 |
| henrys | Robin_Watts: how would that happen? - the environment belongs to the process not the entire system | 14:01.32 |
| Robin_Watts | As long as do_init() can safely be called reentrantly, it's fine. | 14:01.46 |
| | i.e. to init some tables etc it's fine. | 14:02.00 |
| | To make a 'guaranteed once only' call out to something external, it's not. | 14:02.21 |
| chrisl | That's what I mean - guaranteed once only, like pthread_once() | 14:02.47 |
| Robin_Watts | henrys: Suppose I have an application that uses gsapi to run one (or more than one) instances of gs. | 14:03.05 |
| | I might also be calling other similar applications on other threads. | 14:03.22 |
| | If any of them change the environment, gs can fall in a heap. | 14:03.36 |
| | i.e. any call to putenv during a call to gsapi has the potential to break gs. | 14:04.03 |
| henrys | Robin_Watts: no the environment is copied from the parent when you started the beginning gs exe and nobody "sees" that, right? | 14:04.32 |
| chrisl | henrys: he's talking about threads, not processes | 14:04.49 |
| Robin_Watts | henrys: hence me saying gslib and gsapi. | 14:05.06 |
| chrisl | henrys: if we're calling getenv() in one thread, and someone calling putenv() in another thread, there is a chance of problems | 14:05.33 |
| henrys | but there has to be a parent process that owns and starts all these threads and presumably you wouldn't have conflicting calls in that process. | 14:06.27 |
| chrisl | henrys: conflicting calls happen a lot in threading, hence using mutexes | 14:06.59 |
| | Robin_Watts: the reason I mentioned the one time init stuff is that we could add a lock around getenv(), but we've no way to initialise that lock, currently | 14:07.17 |
| Robin_Watts | Picsel had a 1 time lock inited in their copy of fortify.c I think. | 14:08.08 |
| henrys | chrisl: that's not what I mean, I wouldn't expect a thread to call setenv, I'd expect that to happen if at all before the threads were started by the parent process. | 14:08.53 |
| Robin_Watts | henrys: If I'm writing an app (a single process) that calls gs using gsapi, then nowhere in the docs is it written that I can't change the environment. | 14:08.54 |
| chrisl | henrys: I agree the risk is tiny, and I don't think it's something we need be overly worried about | 14:09.40 |
| Robin_Watts | henrys: Some processes write to the environment to say how far along they are. cvs2git did for example. | 14:09.46 |
| | It might be worth a line in the documentation. | 14:10.03 |
| henrys | Robin_Watts: well they're evil and should drown in their puke. | 14:10.10 |
| chrisl | Robin_Watts: sticking a note in the docs seems a reasonable "solution" | 14:11.03 |
| henrys | that reminds me I've been meaning to ask michael about all this strtok() business. | 14:15.46 |
| | chrisl: did I send you the $ amounts for Cyrillic and Greek? sticker shock for me, I wonder how much more your new glyphs will add to the totals. | 14:21.40 |
| Robin_Watts | tor8: That commit has finally passed my tests. | 14:21.59 |
| chrisl | henrys: no, I haven't seen any numbers | 14:22.04 |
| henrys | chrisl: sent | 14:23.14 |
| | chrisl: I guess it isn't that crazy, cyrillic is large. | 14:25.47 |
| Robin_Watts | And it's going to be getting more important soon, what with Russia annexing the Ukraine. | 14:26.22 |
| chrisl | henrys: I was just typing that - if you divide by the number of glyphs, it probably a pretty tiny amount per glyph | 14:26.35 |
| | henrys: And I'm sceptical whether we'd ever see a return on that expenditure | 14:27.44 |
| henrys | chrisl: actually if the customer we are talking to switched to our postscript it would pay for itself very quickly but that is indeed a long shot. | 14:29.27 |
| chrisl | henrys: well, obviously, I'm not party to that, and I'm not saying I'm convinced we wouldn't see a return, I'm just not convinced we would see a return, either. | 14:31.36 |
| henrys | Robin_Watts, chrisl hope they can keep that gas coming, well summer is coming ;-) | 14:32.33 |
| Robin_Watts | A friend on facebook suggested that europe should just freeze all the assets of the russian oligarchs that live here until it's resolved. | 14:34.33 |
| henrys | chrisl: my lenevo is finally being shipped - 2 delays. | 14:34.51 |
| | lenovo | 14:34.57 |
| chrisl | henrys: did you go for the highest res screen? | 14:35.13 |
| Robin_Watts | They are all such gangsters that putin would be assassinated within about 45 minutes, and the troops would be pulled out immediately. | 14:35.30 |
| henrys | Robin_Watts: yea I was surprised that they are one of the most corrupt countries in the world. They have a list with rankings. | 14:38.08 |
| tor8 | aaargh! the libc time functions are really crap. | 14:41.59 |
| henrys | chrisl: no I took the default screen, my 50 year old eyes would never appreciate it. | 14:42.28 |
| tor8 | and windows is even better... calling localtime() or gmtime() on a time value that is negative (i.e. before 1970) fails | 14:42.36 |
| chrisl | henrys: oh, that's odd. My lenovo was about 3 weeks coming, because I opted for the highest res screen I could select. | 14:43.54 |
| henrys | I did add a small startup ssd and larger ram. | 14:44.38 |
| chrisl | henrys: that's usually okay, they usually change those locally, the screen is specced at the factory. Hence mine couldn't be supplied from stock. | 14:45.41 |
| henrys | when I saw that customer ask for smaller spool files for gsprint and I just sank a few inches. I guess images composed of uncompressed xps vectors might not suffice. | 14:46.51 |
| kens | I don't really see it as a problem, who cares if the spool file is a few hundred megabytes ? | 14:47.32 |
| | Surely disk space can't be a problem..... | 14:47.43 |
| | NB the uncompressed nature of the spool file isn't *our* fualt | 14:47.57 |
| henrys | kens:that was my thinking with xpswrite stuff, it isn't zipped. | 14:48.40 |
| kens | henrys, again. do we really care ? | 14:48.54 |
| henrys | kens: well it's in a zip archive uncompressed. | 14:49.14 |
| kens | Its a few nundred MB at most, and presumably we'll delete the intermediate XPS file after priinting | 14:49.16 |
| | henrys, then its zipped, surely ? | 14:49.28 |
| | THe spool file is up to WIndows, not us | 14:49.38 |
| chrisl | zipped is not necessarily compressed | 14:49.47 |
| kens | OK true, but it usually will be | 14:49.59 |
| | Why don't we compress it, and how hard cna that be anyway ? | 14:50.19 |
| chrisl | I thought that customer *wanted* the raster solution, anyway? | 14:51.27 |
| henrys | kens:I can add it pretty quickly but my initial thinking was the space was worth saving the decompress time. | 14:51.29 |
| kens | henrys I agree | 14:51.40 |
| | But remember, whether we compress the image or not has nothing to do with the Windows printing system spool file | 14:51.54 |
| | We print a bitmap to the canvas, then Windows bundles that up for the device, spools it to disk (if asked to) and sends the result to the printer | 14:52.38 |
| | If Windows chooses not to compress the spool file we cna hardly be held responsible | 14:53.04 |
| chrisl | But that's not how the proposed XPS solution would work | 14:53.25 |
| kens | chrisl its pretty much the same | 14:53.33 |
| | Given that the XPS file we produce from the PS/PDF/PCL will be an image | 14:53.49 |
| chrisl | xpswrite is (a little) smarter than that, isn't it? | 14:54.19 |
| kens | I don't know, up to henrys :-) | 14:54.32 |
| henrys | it's a vector device. There are no images presently. | 14:54.40 |
| kens | henrys then its not our problem | 14:54.52 |
| henrys | kens:well it does need improvement. It is a "stupid" vector device right now. | 14:55.23 |
| kens | Its up to MS and the printer driver vendor (mostly the printer vendor) to work out how to convert XPS into whatever the pritner wants | 14:55.25 |
| | gsprint *does* render the whole input into a bitmap though | 14:55.50 |
| chrisl | henrys: mostly what needs added is images, so images don't get degenerated | 14:56.01 |
| henrys | chrisl: yes I actually have that laying about. | 14:56.30 |
| chrisl | henrys: with that, it probably would be okay, and anything more would just be icing on the cake | 14:57.06 |
| | kens: I thought we had, at some point, suggested to this customer using a high level PDL output, and they didn't like the idea - I could be wrong, though | 14:57.44 |
| kens | chrisl No idea, you could bw correct. In fact I think for PostScript input and a PS printer they do just send the PS direct (IIRC) | 14:58.20 |
| chrisl | Anyway, I think for high res, full colour printing, you need to accept the possibility of a large spool file - that can happen, even directly from the driver | 14:59.41 |
| kens | Yes, certainly, and really, its not that big | 15:00.02 |
| chrisl | In fact: http://support.microsoft.com/kb/919543 | 15:00.33 |
| kens | Well, there you are then. Marcos should maybe point them to that. | 15:01.00 |
| marcosw | just been reading the discussion, i'll email the customer. thanks. | 15:03.53 |
| chrisl | Ah, okay, I won't bother mailing that link to you, then! | 15:04.30 |
| henrys | marcosw: but I thought they had to spool, not doing so would disable features they are adding. | 15:06.23 |
| | but I might be mistaken | 15:06.31 |
| | kens? | 15:06.33 |
| kens | I don't see why they need to spool | 15:06.42 |
| | But if they want to, then they will get a big file | 15:06.56 |
| chrisl | henrys: I thought it was more that the large spool files are known to happen, regardless of our involvement, so there's not whole lot we can do about it | 15:08.20 |
| henrys | chrisl: you are pointing them to a link that says print direct to the printer and that will disable ... I don't think disabling that stuff is an option for the customer but I may be mistaken. | 15:09.28 |
| chrisl | henrys: it's a page that says you can "fix" the problem by printing direct, but you lose certain functions. If you need those functions, tough. | 15:11.05 |
| Robin_Watts | Aha. mvrhel_laptop! | 15:11.11 |
| kens | welcome back Michael | 15:11.25 |
| Robin_Watts | Welcome back. I have a couple of WinRT questions when you have a mo, please. | 15:11.45 |
| mvrhel_laptop | good morning | 15:11.46 |
| henrys | hi mvrhel_laptop | 15:11.52 |
| mvrhel_laptop | Robin_Watts: ok. I have to help get kids out the door and eat first | 15:12.16 |
| Robin_Watts | mvrhel_laptop: No worries. I've got to run out on an errand in a bit, so we'll have to try to catch a moment when we're both around later. | 15:13.10 |
| mvrhel_laptop | Robin_Watts: ok sounds good. | 15:13.39 |
| Robin_Watts | oh. How much tea? :) | 15:13.51 |
| | 1 bag a day, 90 days? | 15:14.17 |
| | tor8: ping | 15:21.10 |
| | tor8: For the logs. | 15:39.35 |
| | I'd like to get my commit (or as much as possible) committed before I fly. What remains to be done to it so you are happy with it? | 15:40.02 |
| Robin_Watts | pops out on an errand.back soon. | 15:40.21 |
| mvrhel_laptop | Robin_Watts: I am back | 16:59.51 |
| | Robin_Watts: 1 bag a day for 90 days would be great, thanks | 17:00.15 |
| Robin_Watts | mvrhel_laptop: Back too. | 17:03.50 |
| mvrhel_laptop | Robin_Watts: ok so you said you had a winRT question? | 17:04.11 |
| Robin_Watts | so, I've been looking into gp_open_scratch_file | 17:04.13 |
| | There is a bug to do with unicode chars in the TEMP dir path. | 17:04.29 |
| | and i think I have a fix for windows. | 17:04.40 |
| | but there is some WINRT stuff in there. | 17:04.46 |
| | GetTempPathWRT | 17:04.53 |
| | Do you know anything about that? | 17:05.03 |
| mvrhel_laptop | paulgardiner must hav done this I think | 17:06.05 |
| Robin_Watts | looking at git blame, I think you are right. | 17:06.15 |
| henrys | yes paulgardiner did that for raed | 17:06.25 |
| Robin_Watts | I can't find any reference to GetTempPathWRT | 17:06.27 |
| | Is that file not used for WinRT maybe? | 17:06.41 |
| paulgardiner | Ah. What did I do? :-( | 17:07.28 |
| mvrhel_laptop | I don't believe there is any such standard windows API called GetTempPathWRT | 17:07.37 |
| Robin_Watts | mvrhel_laptop: Dould you do a quick test please? | 17:07.57 |
| paulgardiner | Yeah, that's a gs function | 17:08.09 |
| | that you can blame me for | 17:08.17 |
| Robin_Watts | Stick your favorite expletive in there next to GetTempPathWRT and check whether it still builds? | 17:08.22 |
| | paulgardiner: Where does it live? | 17:08.27 |
| mvrhel_laptop | Robin_Watts: sure hold on | 17:08.31 |
| kens | winrtsupp.c ? | 17:09.02 |
| paulgardiner | winrtsup.cpp | 17:09.09 |
| Robin_Watts | Ah! | 17:09.17 |
| | a .cpp file. | 17:09.20 |
| | That's why my grep didn't find it. | 17:09.26 |
| kens | Yes,sorry | 17:09.29 |
| paulgardiner | Yes. I thought that would make your blood run cold | 17:09.38 |
| kens | Well I have no idea what that stuff does with Unicode paths :-) | 17:10.03 |
| Robin_Watts | paulgardiner: So your code expects the strings in what format? | 17:10.16 |
| | windows encoded ascii? utf8 ? or unicode ? | 17:10.31 |
| paulgardiner | Robin_Watts: I'm just looking | 17:10.40 |
| Robin_Watts | mvrhel_laptop: OK, sorry to have disturbed you on this one! | 17:10.56 |
| mvrhel_laptop | Robin_Watts: no worries. I am looking this over anyway out of interest | 17:11.22 |
| Robin_Watts | mvrhel_laptop: I have a reworked version here that makes a better job of handling unicode chars. I think. | 17:11.52 |
| mvrhel_laptop | cool | 17:12.00 |
| paulgardiner | I'd guess it's the conversion from std::wstring to std:string at the end that is problematic | 17:12.21 |
| kens | paulgardiner : we don't know if its problematic | 17:12.44 |
| | The other temp path code doesn't work correct;y with Unicode filenames, Robin has reworked it. | 17:13.09 |
| | I guess he needs to know what your code returns | 17:13.19 |
| | Goodnight all | 17:27.05 |
| tor8 | Robin_Watts: I've nothing further to complain about, go ahead and push. I thought you wanted to split the commit into bits in the end, I guess you changed your mind about that? | 17:33.43 |
| marcosw | Robin_Watts: just a friendly reminder to bring the watch I had shipped to your house with you to the meeting. oddly enough I don't have anything for you, or anyone else. | 17:33.44 |
| Robin_Watts | marcosw: Well reminded. I will go put that in my case now. | 17:34.10 |
| | tor8: I may well split it. | 17:35.31 |
| | Thanks. | 17:35.53 |
| sebras | where is you meeting this time around..? | 17:45.37 |
| Robin_Watts | Denton, Texas | 17:46.40 |
| | So technically, it's "Where y'all meeting..." | 17:47.17 |
| sebras | Robin_Watts: oh, sorry. :) | 17:47.26 |
| mvrhel_laptop | bbiab | 18:07.14 |
| Robin_Watts | ray_laptop: peeved still unhappy about talking to the wide world? | 18:10.41 |
| ray_laptop | Robin_Watts: I haven't had a chance to go in and debug it. Maybe later today. | 18:12.02 |
| | I need to be in the office and I have to work from here today | 18:12.34 |
| Robin_Watts | oh, of course. | 18:13.21 |
| mvrhel_laptop | henrys: you are I are still driving together Thursday, yes? | 18:20.27 |
| | you have the car if I recall? | 18:20.36 |
| henrys | mvrhel_laptop: I do yes | 18:20.42 |
| mvrhel_laptop | ok. great | 18:20.54 |
| henrys | mvrhel_laptop: we should probably meet at the car rental place. let me find the name | 18:21.11 |
| | mvrhel_laptop: EZ Rent a Car | 18:22.15 |
| mvrhel_laptop | henrys: ok sounds good. I found the email with your flight information too | 18:22.32 |
| | Do you still have mine? | 18:22.44 |
| henrys | yes alaska 664 | 18:23.36 |
| mvrhel_laptop | ok great | 18:24.05 |
| henrys | have to find my bubba teeth | 18:24.17 |
| mvrhel_laptop | I arrive about 10 minutes after you. | 18:24.27 |
| | :) | 18:24.29 |
| | I wish I had some bubba teeth | 18:24.36 |
| Robin_Watts | mvrhel_laptop: Make that joke at Dallas airport, and your wish will be granted :) | 18:26.49 |
| mvrhel_laptop | yes | 18:28.02 |
| Robin_Watts | Damn. | 18:43.16 |
| | tor8: You here? | 18:43.19 |
| | tor8: For the logs. Reordering around this commit is hard: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a653d006c5a19059ee201c3240a8d848e43ace92 | 18:50.06 |
| | ISTR you weren't opposed to the idea, but didn't like the use of hints to do it. | 18:50.26 |
| | Anyway you can think of we can refactor it and get it in too ? | 18:50.42 |
| paulgardiner | Robin_Watts: pretty sure that the winrtsup code wasn't converting from/to utf8 correctly. I've pushed what I believe to be a corrected version to paulg/master. Not tested other than that it builds, though. | 18:51.36 |
| Robin_Watts | paulgardiner: Ship it! | 18:52.04 |
| | I've got to pop out now, but we can find a merge of our two commits that we're happy with and commit that tomorrow. | 18:52.29 |
| paulgardiner | okay great | 18:52.41 |
| Robin_Watts | Thanks. | 18:52.48 |
| paulgardiner | Hopefully I'll be able to remember how to test it. | 18:53.25 |
| ray_laptop | marcosw: O rented a car as we discussed and will pick you up at the airport (if I am on schedule) if you think that will work | 19:15.59 |
| | mvrhel_laptop: I have the 4-bit changes in C working for the gxht_thresh.c code. Even without SSD it completes in 70% of the non-optimized code | 19:17.37 |
| mvrhel_laptop | ray_laptop: nice | 19:17.56 |
| | the potential customer hopefully will appreciate this | 19:18.13 |
| ray_laptop | mvrhel_laptop: do you (or does anyone else) know if Surendra's company is considering a CPU with SSD ? | 19:18.16 |
| mvrhel_laptop | ray_laptop: I dont' know. It would be good to ask him | 19:18.32 |
| ray_laptop | i know you met with them last time (not the most recent trip) | 19:18.48 |
| mvrhel_laptop | I wish we had been able to visit there. | 19:18.56 |
| | I did not even realize they were doing this evaluation until just recently | 19:19.20 |
| ray_laptop | Do you think it is OK to send them a preliminary version (that i have now) that still needs to be flehsed out for 2-bit , aubtractive and planar (color) | 19:21.24 |
| | mvrhel_laptop: but since they mentioned doing performance evaluation, I don't want to delay too long | 19:21.53 |
| mvrhel_laptop | ray_laptop: I would def. ship to them now with the caveat that you mention above | 19:22.44 |
| | they appreciate steady progress | 19:22.51 |
| | henrys: sent you a couple things to add to the agenda since it is so short | 19:25.41 |
| | ;) | 19:25.44 |
| henrys | mvrhel_laptop: thanks ;-) marcos added regression testing mupdf for android etc. and said you guys talked about that. Were you thinking of tools that emulate the arm instruction set on a host? | 19:28.26 |
| mvrhel_laptop | henrys: I don't think I talked with marcos about this. | 19:29.04 |
| henrys | oh yeah mopria I did join a long time ago but they never responded to anything I sent them, I thought it was dead. | 19:30.03 |
| | guess not | 19:30.12 |
| mvrhel_laptop | henrys: oh. really? well CSR just joined last month and it seems to be gathering a bit of steam | 19:33.16 |
| henrys | mvrhel_laptop: yeah I'll look into it and add it to the agenda. | 19:34.48 |
| mvrhel_laptop | ok. I think Miles may have already signed us up | 19:35.04 |
| henrys | okay I'll see what he did. We discussed it and it was quite expensive at the time. | 19:35.45 |
| mvrhel_laptop | lunch... | 20:40.20 |
| ray_laptop | mvrhel_laptop: please have a look at a patch to the bit device for bitrgb -dGrayValues=16. I found it setting the max_color to 0x1f which made the device fail the gx_device_must_halftone | 20:40.26 |
| | no rush, since I just happened to trip over it | 20:40.43 |
| | hmm... looks like we don't have any planar device that needs halftoning that has more than 1 bit per component. | 20:51.18 |
| | so I guess I'll just leave that until later. I do need to make sure that the 'offset_bits' and landscape stuff works. | 20:52.20 |
| | Forward 1 day (to 2014/03/04)>>> | |
IRC Logs