| | <<<Back 1 day (to 2012/09/17) | 2012/09/18 |
| kens | Hmm, well if I did that test corectly, my linearised PDF code worked perfectly with the cluster and only took an additional 30 minutes of CPU time. Soemhow I suspect I messed up the test.... | 08:32.32 |
| | qAnd indeed, my change to force linearisation on had got backed out by git for some reason. Oh well, here we go again. | 08:47.45 |
| | OK so why, when I run a clusterpush, is my file being erverted ? | 08:48.28 |
| | Huh ? Now my build is broken.... :-( | 08:49.43 |
| kens | goes to clean and rebuild | 08:50.05 |
| | OK can someone else update and try a build of GS please ? | 08:50.37 |
| chrisl | What's the problem? | 08:50.52 |
| kens | I'm getting an 'unexpected end of file' in gscms.h since updating | 08:50.53 |
| chrisl | Ah, I think that's a VC thing...... | 08:51.21 |
| kens | Hmm, because there's no EOF | 08:51.44 |
| chrisl | Yeh, gcc doesn't bother about that | 08:52.03 |
| kens | Yes, adding a linefeed to the last line it works | 08:52.06 |
| | I guess I'll commit a fix | 08:52.27 |
| chrisl | Interesting that it seems to be Michael's last commit that removed the trailing newline | 08:53.42 |
| kens | Indeed, since he normally builds on Windows | 08:53.53 |
| | git gui even gives a warning about it | 08:54.04 |
| chrisl | Are you going to commit the newline change? | 08:54.13 |
| kens | Yes, I'm doign it now | 08:54.22 |
| chrisl | Cool, cheers | 08:54.30 |
| kens | done | 08:55.09 |
| chrisl | So, back to the previous issue - what went wrong with your clusterpush? | 08:55.58 |
| kens | Well nothing went wrong exactly | 08:56.08 |
| | I had patched an include file to force linearisation on | 08:56.19 |
| | But when I do a clusterpush it keeps reverting it | 08:56.32 |
| chrisl | Which header file? | 08:56.38 |
| kens | gdevpdfb.h | 08:56.46 |
| chrisl | Okay, that shouldn't happen..... | 08:57.03 |
| kens | I know :-) | 08:57.10 |
| | I'm going to try again | 08:57.15 |
| | Because I *know* my tree is up to date now | 08:57.27 |
| chrisl | Are you using gitpush? | 08:58.00 |
| kens | No, gitpush.sh | 08:58.09 |
| | Because I'm on Windows | 08:58.14 |
| | Also using relaxtimeout, and as I discovered you have to supply a username with that one | 08:58.35 |
| | Looks like its OK this time | 08:58.44 |
| | I'm going to go log in to casper and check | 08:59.00 |
| | Yes, the file is correctly modified on casper now in my regression/users tree | 09:00.43 |
| | No idea what was going on before. | 09:00.51 |
| chrisl | Maybe something went screwy creating the commit for the push | 09:02.02 |
| kens | I think it must have, but I have no idea why. Still, as long as its working now.... | 09:03.35 |
| Robin_Watts | When you clusterpush using git, as part of that process it "stashes", then pushes the stash to casper, then stash pops. | 09:32.48 |
| | So for a moment during the git push process, your changes are backed out on the local machine. | 09:33.18 |
| | but they should all be back in place by the time it finishes. | 09:33.34 |
| kens | Robin_Watts : it wasn't temporary. I see this a lto because VS asks to reload the files. Normally they aren't changed in this case it reverted my changes (this is after the cluster had finished) | 09:34.06 |
| | I don't know why, but its OK now so I won;t worry | 09:34.15 |
| Robin_Watts | Did you abort it? | 09:50.24 |
| kens | I aborted one of them, but not the first | 09:50.37 |
| Robin_Watts | Or is that the 'too many timeouts' thing? | 09:50.45 |
| kens | No too many timeouts is the wone that 'works' | 09:50.57 |
| Robin_Watts | No, I mean the current job is dying. | 09:51.02 |
| kens | Yes, that's more or less expected | 09:51.14 |
| | Its actually etsting the linearisation code | 09:51.27 |
| | I'm fairly happy its aborting, I expected problems. | 09:52.22 |
| Robin_Watts | chrisl: Is there a dependency problem with gs/contrib/pcl3/gdeveprn.c ? | 11:51.10 |
| | If you do a build that fails to link due to a missing symbol from that file, and you edit that file to remove the need for that symbol, and rebuild, it immediately tries to link and fails again. | 11:51.57 |
| | Delete the .obj and rebuild and it remakes properly. | 11:52.08 |
| chrisl | Robin_Watts: I don't keep much track of dependencies in contrib, so it's quite possible | 12:58.00 |
| paulgardiner | Robin_Watts, tor: there are a few commits on paulg/master if you have a moment. | 13:37.55 |
| sebras | paulgardiner: thanks! :) | 13:40.01 |
| | paulgardiner: btw, I have managed to crash mupdf/android 1.1 fairly consistently. | 13:40.28 |
| | no bug reported yet though. | 13:40.36 |
| paulgardiner | Other than by dragging back and forward on the page slider? | 13:40.59 |
| tor8 | paulgardiner: mupdf/android 1.1 crashed on my sister's xperia with android 4.0.4, I suspect the lack of a Download folder | 13:41.01 |
| | opening a file directly worked, but not the "library" view | 13:41.14 |
| sebras | tor8: I thought that the Download folder was required by Android... | 13:41.36 |
| paulgardiner | tor8: Ah right. Might be an idea if I checked for the existance of the folder... I have some recollection of doing so, but probably not. | 13:41.57 |
| | sebras: BTW, those bugs I just cleared were fixed ages ago, just somehow I forgot to mark them fixed in bugzilla. | 13:43.29 |
| | sebras: ... but I may have just fixed the page-slider dragging one. I'll upload a test build. Would be handy if you could give it a try. | 13:44.28 |
| | tor8: what's your thoughts on bug 693275? I'm tempted to leave it as it is, but if you'd prefer wrapping... | 13:48.00 |
| tor8 | paulgardiner: the iOS app doesn't wrap, IIRC :) | 13:49.55 |
| paulgardiner | Excellent! :-) | 13:50.07 |
| tor8 | OTOH, the iOS search is kind of clumsy :( | 13:50.48 |
| Robin_Watts | paulgardiner: em*a*nating | 13:51.42 |
| paulgardiner | Oops | 13:52.05 |
| Robin_Watts | opens the floodgates for people to point out typos in his commits :) | 13:52.27 |
| | specifided | 13:53.04 |
| paulgardiner | but mostly you CAN spell. :-) | 13:53.06 |
| tor8 | grins wickedly. | 13:53.09 |
| paulgardiner | Robin_Watts: fixed those and pushed | 14:01.53 |
| Robin_Watts | OK. They all look fine. A question about the last one though... | 14:02.51 |
| | check_box_message always looks to be NULL currently. | 14:03.03 |
| | Is that because there are some message types you don't support yet? | 14:03.14 |
| | (I saw that you were only supposed to fill in button_checked if that was non NULL, right, but your code always fills in button_checked, right?) | 14:03.54 |
| | s/were only supposed to/only had to/ | 14:04.09 |
| paulgardiner | Yes, not handling the full generality, but let me just check the logic again. | 14:04.43 |
| sebras | paulgardiner: the absolutely easiest way to me to take you test build for a spin is if you mail it to me. | 14:09.37 |
| | paulgardiner: if so there's a chance I'll test it a bit tonight. | 14:09.55 |
| paulgardiner | Robin_Watts: I'm just ignoring the check_box completely at the moment, I believe | 14:10.43 |
| | sebras: Or email a web link? | 14:11.07 |
| sebras | paulgardiner: that works as well. | 14:11.22 |
| Robin_Watts | paulgardiner: Well it looks good to me then. | 14:12.54 |
| paulgardiner | Robin_Watts: great. thanks | 14:13.10 |
| Robin_Watts | will push it. | 14:13.21 |
| | tor8: My work on mupdfwrite is all on my casper repo. There are 4 commits there, the last one being the bulk of the work. I forget whether you've looked at the preceeding 3 or not... | 14:24.45 |
| | paulgardiner: pushed, btw. | 14:25.52 |
| paulgardiner | Robin_Watts: ta | 14:26.16 |
| Robin_Watts | I need a third monitor. | 14:27.39 |
| tor8 | Robin_Watts: new_cap = fz_maxi(256, buf->cap * 2); is the usual idiom | 14:27.46 |
| | not that I particularly care in this case | 14:28.00 |
| | the other two I've seen before, and they look okay | 14:28.20 |
| Robin_Watts | I dislike using max/min in this case, because my tiny mind gets confused, but I can change it if you prefer. | 14:29.01 |
| tor8 | aside from my question about the necessity of having both fz_image_params and pdf_image_params for just the one field | 14:29.03 |
| | Robin_Watts: no, it's fine as is | 14:29.11 |
| | I make the min/max mistake often enough too :( | 14:29.22 |
| Robin_Watts | To unify the two, I'd have to move the colorspace in, and it doesn't really fit. | 14:29.51 |
| tor8 | that's what I don't really see, but I guess you're storing the colorspace for pdfwrite only? | 14:31.58 |
| Robin_Watts | Urm, I can't remember which way around it is. hold on | 14:32.35 |
| | Or maybe I need someone to write unity mode for unity :) | 14:33.05 |
| | OK. pdf_write doesn't need the colorspace param. | 14:33.51 |
| tor8 | because from that commit, I don't see anybody use the colorspace param anywhere | 14:34.03 |
| Robin_Watts | It's the 'decode on demand' stuff that uses it. | 14:34.12 |
| Robin_Watts | changes colorspace to colorspace2 and rebuilds :) | 14:34.51 |
| tor8 | Robin_Watts: I just upgraded my one 24" monitor to a new 27" | 14:35.38 |
| | one more column in acme! | 14:35.44 |
| Robin_Watts | I have 2 24" ones. I'd have to stack one above the other to get more. Or move the tower under the desk. | 14:36.36 |
| | paulgardiner: Hmm. A windows build is failing missing fz_set_doc_event_callback and fz_access_alert_event. | 14:37.10 |
| paulgardiner | Aagh! I may have updated mupdf-v8 but not mupdf. I'll sort it out. | 14:39.01 |
| Robin_Watts | tor8: OK. I think you're right :) | 14:44.47 |
| | I'll remove the colorspace reference, and then the two can be identical. | 14:45.29 |
| henrys | kens:maturaba should probably go to scott and miles. we have a few multiple contracts per company cases. | 14:47.30 |
| | oh sorry they are already marked as a customer, my bad | 14:48.56 |
| kens | No problem | 14:50.16 |
| | My problem is I have no Mac and so cannot test the bug | 14:50.28 |
| | It exhibited before my fix on WIndows, now it doesn't. THey say it is fixed on Windows but not Mac, which seems weird. Perhaps it is a different problem.... | 14:51.06 |
| Robin_Watts | kens: Hackintosh? | 14:51.41 |
| kens | I don't have one of those either :-) | 14:51.55 |
| paulgardiner | Robin_Watts: Can't see anything I've missed. Which Windows build was showing the problem? | 14:52.32 |
| Robin_Watts | paulgardiner: Build solution. (Debug) | 14:53.06 |
| henrys | kens:well marcosw will show up soon, I'm just about to start a meeting here and I'll look after if he isn't around yet. | 14:53.12 |
| kens | Thanks henrys | 14:53.47 |
| paulgardiner | Robin_Watts: that just worked for me (after Clean Solution). | 14:54.47 |
| tor8 | henrys: Robin_Watts: I'm afraid I'm not going to be able to be around for the late meeting today. Anyway, I have no opinion on passing the memory context to all debug printing functions (and no memory of what you said I objected to, but it was a long time ago) | 14:54.54 |
| ray_laptop | morning, all | 14:55.12 |
| tor8 | but I think I'm with henry when he said that the memory argument should come before the debug character signifier | 14:55.15 |
| Robin_Watts | tor8: OK, I'm quite prepared to change that over. | 14:55.41 |
| henrys | tor8:oh you were serious, you had a smiley... Stefan told me Raph said you didn't want it, so in that chain things might have gotten confused. | 14:56.09 |
| tor8 | henrys: I recall not wanting it for Fitz, but robin overruled me there :) | 14:56.33 |
| Robin_Watts | tor8: Yeah, but it's turned out alright :) | 14:57.04 |
| henrys | Robin_Watts:is it really necessary we copy the stdin, stdout pointers or is this some cruft from postscript where we might fail a few tests or would some major piece of functionality would break? I can't remember the history. | 14:59.09 |
| | ray_laptop probably knows. | 14:59.25 |
| Robin_Watts | henrys: I think it's PS related. It predates me. | 15:00.03 |
| henrys | I assume if we just used the system global pointers this wouldn't be an issue. | 15:00.06 |
| Robin_Watts | henrys: Right, but for the API stuff you want to be able to trap stdin/stdout etc. | 15:00.28 |
| | If I have multiple instances in a server, then I want them kept separate. | 15:00.52 |
| henrys | well 8:00 let's do paulgardiner's business and leave that for the next meeting. | 15:01.00 |
| ray_laptop | I'm about to take the kids to school -- I'll check the question when I get back -- about 30 min. | 15:01.22 |
| henrys | Robin_Watts:yeah I guess we can just leave it with that. | 15:01.28 |
| | paulgardiner:not much to talk about this week so maybe this will go quickly | 15:02.06 |
| Robin_Watts | paulgardiner: Build now seems to be working. I blame VS. Sorry. | 15:03.03 |
| paulgardiner | Henrys: Yeah. This afternoon I've been looking at the android app problem where madly dragging the page slider can run the device out of memory. I may have fixed it. sebras says he may have a chance to test the new version later. | 15:04.58 |
| henrys | oh okay great. I guess more of us should get android devices | 15:05.53 |
| Robin_Watts | I can't remember when we last had a meeting; the forms stuff has all been pulled down onto master now. | 15:06.09 |
| henrys | was this a phone and tablet? | 15:06.12 |
| | in the report can we separate out what is needed for the october release in item 8. Simply an asterisk or something. I know we wanted print. | 15:07.02 |
| paulgardiner | I think it was a phone, but potentially it could have happened on any device | 15:07.06 |
| Robin_Watts | I have 2 android phones and a tablet I can try it on, if I know what I'm looking for. | 15:07.31 |
| | will be 3 when helen gets her new Samsung S3 on thursday. | 15:07.47 |
| henrys | tor8:I thought it would be okay to use this meeting to talk about the viewer. Any issues? | 15:08.42 |
| | tor8:if involving sebras would accelerate things let's do it. | 15:09.24 |
| paulgardiner | henrys: Yes, that's a good point. I think we can leave most of them. | 15:09.29 |
| henrys | paulgardiner:I don't see much else to discuss. Do you need anything? | 15:11.23 |
| tor8 | henrys: no news on the viewer | 15:11.30 |
| paulgardiner | Robin_Watts: thanks. I haven't managed to provoke the problem. I think it occurs only with documents that are slow to draw. Then dragging the page slider back and forward causes a crash. | 15:11.57 |
| henrys | seems to me Robin_Watts must have a closet full of gadgets | 15:12.34 |
| | Robin_Watts:My old kindle's button broke is the new one you just got recently any good? | 15:13.40 |
| tor8 | henrys: tor/viewer has the gtk+ viewer, but it's a very rough UI. no keybindings and the widget focus is all broken so it's basically impossible to use. | 15:13.50 |
| paulgardiner | henrys: No, don't think so, thanks. | 15:13.52 |
| tor8 | but it does resizing and continuous scrolling | 15:14.03 |
| Robin_Watts | henrys: yeah, it's great. | 15:14.08 |
| tor8 | and has the outline view, and search is halfway hooked up | 15:14.21 |
| Robin_Watts | Sometimes you can mis hit the screen and zap off into hyperspace, but other than that, it's perfect :) | 15:14.30 |
| paulgardiner | henrys: I guess it might be useful for somebody other than me to try out the forms build on a few files, just to give a second oppinion on whether we are approaching something releasiable | 15:16.25 |
| henrys | tor8:because we are going to call it GSPrint I don't think it is appropriate to release alpha, it really needs to be done when we get it out ther. | 15:16.43 |
| | s/ther/there | 15:16.50 |
| Robin_Watts | Well, when we do the forms alpha release thing, we don't need to call it gsprint there. | 15:17.54 |
| henrys | paulgardiner:I sort of took for granted tor8 and Robin_Watts were keeping an eye on things. | 15:17.55 |
| | I think both should take a look when you ask for review. Or did you want someone else on the staff to have a look? | 15:18.46 |
| tor8 | henrys: I thought you wanted gsview? | 15:18.54 |
| | what's this gsprint thing? | 15:19.07 |
| henrys | tor8:yes sorry. | 15:19.11 |
| | gsview | 15:19.15 |
| | we are going to do gsprint also but that is completely separate from this. | 15:19.34 |
| tor8 | henrys: we aren't calling anything that until next year though | 15:19.35 |
| henrys | yes the January limitation | 15:19.55 |
| Robin_Watts | henrys: We watch the commits (and review those before pushing), but I haven't actually experimented with entering data onto many forms myself (certainly not recently) | 15:20.29 |
| paulgardiner | henrys: I think the code is getting well reviewed, but I don't know if anyone is giving the windows app a try on test forms. | 15:20.36 |
| henrys | tor8:if you were to finish it next week thought we'd just pay russel :-) | 15:20.54 |
| | it's hard to do really good review without running the code, let's get someone if Robin_Watts and tor8 are busy give it to sebras and we'll pay him. | 15:22.46 |
| Robin_Watts | Well, I have it running next to the chatzilla window and I can enter figures etc on this form. | 15:25.48 |
| | I'd need to spend time digging through the examples to find files that stretch the coverage. | 15:26.42 |
| | but mujstest does that for us on every commit. | 15:26.50 |
| paulgardiner | Of course, releasing the alpha should give us lots of free testing. | 15:27.27 |
| Robin_Watts | and that drives pauls development. | 15:27.35 |
| henrys | that's true but a human should look at the app from time to time and enter some stuff. | 15:28.25 |
| paulgardiner | Robin_Watts: I guess just the fact you have just used it and didn't notice anything untoward is a good start. The only differences in other files are likely to be to do with validation and calculation. In an alpha, we'd probably expect a few problems here and there with those aspects anyway. | 15:29.57 |
| Robin_Watts | paulgardiner: Yeah. If you can forward me the names of some files with validation and calculation in, I'll give them a play later. | 15:30.36 |
| tor8 | I need to go soon, anything else? | 15:31.20 |
| Robin_Watts | Certainly the existing windows viewer seems to be working just fine - with the proviso that it's using native dialogues for data entry rather than doing it inline. | 15:31.22 |
| | tor8: not from me. | 15:32.20 |
| paulgardiner | or me. | 15:32.28 |
| henrys | yes all done for me as well | 15:33.05 |
| Robin_Watts | Turns out that the version of valgrind/helgrind on peeves doesn't have the "ignore this area of memory when looking for races" which I need for the gs_debug block. | 15:36.22 |
| | So I'm running locally on my Ubuntu Precise VM. | 15:36.35 |
| henrys | is it much slower? | 15:36.59 |
| Robin_Watts | Supposedly helgrind can be up to 100 times as slow. | 15:37.35 |
| henrys | I have 11.10 if you want an account here. | 15:39.21 |
| Robin_Watts | I have 12 here. | 15:39.38 |
| | upgraded my VM the other day - went smoothly with no problems (he says with crossed fingers) | 15:39.58 |
| | In gsinit.c, why do we call gs_malloc_init before memsetting gs_debug to 0? | 15:40.52 |
| | gs_malloc_init includes code that checks the gs_debug flags. | 15:41.10 |
| henrys | I looked at that sometime ago and recall there was a reason but don't remember. | 15:42.46 |
| chrisl | Is gs_debug on the stack? | 15:43.33 |
| Robin_Watts | gs_debug is a static block. | 15:43.49 |
| | no, not static. | 15:44.00 |
| | char gs_debug[128]; | 15:44.14 |
| | it's the values of the debug flags. | 15:44.30 |
| chrisl | So, it might be initialised to zeros in a debug build anyway? | 15:44.42 |
| Robin_Watts | In a debug build, yes. | 15:44.51 |
| | But gs_debug exists (and is used) in release builds too. | 15:45.03 |
| chrisl | I didn't think it was used in a normal release build | 15:45.20 |
| Robin_Watts | It is. There are certain debugging flags that have meaning in release builds too. | 15:45.47 |
| | (but don't ask me which offhand) | 15:45.54 |
| chrisl | Oh, I thought we disabled them all so as not to slow stuff down | 15:46.25 |
| henrys | yes like -Z: | 15:46.27 |
| | time and memory stats. | 15:46.46 |
| Robin_Watts | Some macros (if_debug() for example) compile away to nothing. | 15:46.56 |
| | but others (gs_debug_c) don't. | 15:47.07 |
| chrisl | So it should probably be initialised immediately on startup, then....... | 15:47.56 |
| Robin_Watts | I would have thought so. hence the question. | 15:48.17 |
| chrisl | Do we need anything done during gs_malloc_init for the memory stats output? | 15:48.59 |
| henrys | kens:page 8 has an 8 not not a 5 in the merged file on the mac 10.6.8 so it looks right to me. | 15:54.17 |
| Robin_Watts | Hmm. The gs_debug nulling seems to be done in several places. I wonder why we can't just move it into gs_malloc_init and be done with it. | 15:54.52 |
| | Cos everything calls that. | 15:54.56 |
| chrisl | Ghostscript policy: never do things once when eight times will suffice? ;-) | 15:55.45 |
| kens | henrys well I don't know how to tackle that. Can you send me the two PDF files ? | 15:57.29 |
| Robin_Watts | kens: Unless I'm misunderstanding, henrys is saying you have fixed the bug. | 15:58.12 |
| henrys | kens:tackle what the result is correct and I have no idea why the customer is saying it is wrong on the mac. | 15:58.16 |
| kens | Oh sorry, henrys Robin_Watts I completely misunderstood | 15:58.37 |
| | I'm at a loss in that case. It works for us... | 15:59.00 |
| henrys | would it be something that might be affected by fontconfig? | 16:00.00 |
| kens | henrys I can't see how | 16:00.09 |
| | The PS files contain the fonts embedded in them | 16:00.19 |
| chrisl | It's much more likely that they've failed to apply, or mis-applied the patch on the Mac machine | 16:00.50 |
| henrys | no clue, hopefully a cockpit error where he hasn't built the code proberly. | 16:00.53 |
| kens | I would be more inclined to think they made a mistake. | 16:00.56 |
| | I might know more if they had sent the PDF files instead of repeating the PS files. | 16:01.12 |
| henrys | need coffee before we start. | 16:01.19 |
| kens | Just got mine :-) | 16:01.29 |
| mvrhel | I am here | 16:02.50 |
| kens | Hi Michael | 16:02.59 |
| henrys | okay we actually have stuff to talk about. | 16:03.48 |
| | alexcher left the meeting without a project with the shelving of the mooscript so it seems like the luratech allocation stuff should go to him, although that's a small project. | 16:04.45 |
| alexcher | OK | 16:05.00 |
| Robin_Watts | henrys: I fear there may be several places in gs that are using malloc/free | 16:05.13 |
| | we should probably grep the source and check. | 16:05.20 |
| ray_laptop | on the stdio pointers, besides allowing for callback capture (embedded systems often need this) we also allow for the -sstdout=___ and -sstderr=___ Was there some other question about the stdio pointers I didn't understand ? | 16:05.37 |
| henrys | Robin_Watts:a bug would be useful to track it. | 16:05.38 |
| mvrhel | alexcher's big thing was to get the soft mask stuff finished up | 16:05.58 |
| Robin_Watts | oooh yeah. | 16:06.05 |
| alexcher | I know. | 16:06.12 |
| mvrhel | since Robin's stuff is waiting on it | 16:06.13 |
| Robin_Watts | henrys: I can make a bug if you'd like. | 16:06.14 |
| henrys | Robin_Watts:thanks | 16:06.21 |
| ray_laptop | Robin_Watts: I know jasper used malloc/free -- I had to fix that for cust 532 (which we didn't need after going to luratech) | 16:06.25 |
| henrys | mvrhel:oh right. | 16:06.31 |
| ray_laptop | I haven't checked if any of our libs use malloc/free directly | 16:07.25 |
| henrys | so alexcher both of those are on your plate - the luratech stuff should be easy. | 16:07.32 |
| alexcher | Do we plan to extend PS integer type to 64 bits? This will be detected by CET tests. | 16:08.11 |
| ray_laptop | cust 532 has their own memory allocation scheme and the system malloc/free space is VERY limited | 16:08.15 |
| chrisl | alexcher: I was going to ask about that - frankly, I don't care if it affects CET tests, since that's an invalid test | 16:08.59 |
| henrys | I was going to suggest we review the agenda but I guess if everyone just agrees to reads it we should be good. | 16:09.14 |
| ray_laptop | alexcher: if we extend PS integers to 64 bits, at the very least we should (IMHO) have a build option | 16:09.16 |
| chrisl | ray_laptop: why? | 16:09.28 |
| ray_laptop | chrisl:some customers DEMAND the CET passes | 16:09.44 |
| henrys | alexcher:harkens back to the discussion with Gigs - which bug was that? | 16:09.46 |
| chrisl | ray_laptop: but as I said, it's an invalid test | 16:10.13 |
| kens | ray_laptop : experience has been that if you *explain* why this is a 'fail' or difference, customers will accept it | 16:10.24 |
| alexcher | ray_laptop: We've already introduced non-standard max size of composite objects. | 16:11.14 |
| chrisl | ray_laptop: also, it would be a pain to have a build that passes CET and one that can read *big* PDF files...... | 16:11.27 |
| henrys | is there a reason to do this other than the PDF interpreter is written in PS? Is there another way to fix the issue that motivated type change? | 16:11.40 |
| chrisl | henrys: that's the primary driver, yes | 16:12.06 |
| ray_laptop | sorry phone call ... bbiab | 16:12.11 |
| Robin_Watts | Do we use floats or doubles? | 16:12.18 |
| chrisl | Doubles | 16:12.24 |
| | oh, I think..... | 16:12.31 |
| kens | depends for what | 16:12.33 |
| Robin_Watts | Cos we could add 0.5 to every int, to force it to use doubles to store it :) | 16:12.34 |
| henrys | this was the post_eof_count overflowing right, alexcher? | 16:12.41 |
| kens | Mostly the PS interpreter uses fixed point | 16:12.50 |
| chrisl | Oh, no, sorry, PS reals are floats | 16:13.31 |
| alexcher | henrys: I don't know about pst_eof_count. Currently gs has architectural limit on the PDF size. | 16:13.41 |
| henrys | we are looking at 692757 | 16:13.44 |
| | yes it's a mupdf bug but see comment #7 | 16:14.20 |
| | sorry #6 | 16:14.27 |
| chrisl | henrys: the main thing is, if we fix the stream code so that pdfwrite can output >4Gb PDF files, we'll be producing files we can't consume | 16:14.32 |
| kens | Lol | 16:14.46 |
| chrisl | I feel that would be poor..... | 16:15.22 |
| kens | Might lead to questions.... | 16:15.35 |
| henrys | well what I'd like to know is if there is a workaround to depending on a PS int type while interpreting PDF. | 16:15.40 |
| Robin_Watts | kens: Just ask for people to cut the problem file down to a single page :) | 16:15.55 |
| kens | Implement the PDF itnerpreter in C ? :-) | 16:15.56 |
| alexcher | Another approash is to have 2 integer types in gs. | 16:16.09 |
| Robin_Watts | henrys: Well, presumably we could write a bignum library in postscript, but that would be SLOW. | 16:16.24 |
| henrys | kens:yes we tried that for 10 years I'd like to try something that we can possibly do. | 16:16.26 |
| chrisl | It's not unheard of for Postscript files to be >4Gb, too. | 16:17.22 |
| kens | Well yes but they are read sequentailly, we don't need to store pointers into them | 16:17.41 |
| henrys | I don't have any sense how many places break. It could just be a few and we could handle it with a bignum workaround that only affected a few places. | 16:17.58 |
| Robin_Watts | With pdf we have to seek to the end of the file, then seek backwards looking for a trailer etc. | 16:18.07 |
| chrisl | kens: Except that most people call Ghostscript with a file name as a parameter | 16:18.09 |
| kens | chrisl does that matter ? | 16:18.27 |
| Robin_Watts | henrys: I'd assume that it's anywhere which handles offsets into the file. | 16:18.34 |
| chrisl | kens: yes, we then do a (filename) run on it | 16:18.49 |
| henrys | floats? | 16:18.52 |
| kens | chrisl yes, but it doens't store any offsets does it ? | 16:19.03 |
| alexcher | chrisl: Bug ps files work fine. fileposition doesn't. | 16:19.04 |
| Robin_Watts | floats are only 24 bits - even worse. | 16:19.12 |
| chrisl | OKay, so most ps files will be fine | 16:19.57 |
| henrys | well postscript floating point type is debatably single precision but it doesn't have to be. | 16:19.58 |
| Robin_Watts | doubles would be better (48 bits if memory serves) | 16:20.03 |
| kens | Robin_Watts : we use fixed precision arithmetic mostly I beleive, for perrfoormance | 16:20.29 |
| chrisl | henrys: give me a another day or so, and I'll have something I can clusterpush with 64 bit integer objects, and then we can see what breaks | 16:20.30 |
| | kens: we store PS real numbers as floats | 16:20.53 |
| henrys | chrisl:okay a list of breakage would really help us understand what we are in for. | 16:20.58 |
| chrisl | henrys: FWIW, I seriously doubt it's more than a few CET tests, if any | 16:21.22 |
| | 32 bit integers are *not* part of the Postscript language! | 16:21.43 |
| kens | Quite so, they are a XPSI architectural limit | 16:22.10 |
| | CPSI | 16:22.14 |
| alexcher | chrisl: Before CET, hs had long integers on 64-bit platforms. | 16:22.17 |
| | chrisl: Before CET, gs had long integers on 64-bit platforms. | 16:22.43 |
| chrisl | alexcher: well, I reckon it wouldn't be a big problem to have runtime checks for handling the CET cases | 16:23.13 |
| kens | personally I don;t see it as a problem, we should go to 64-bits | 16:23.15 |
| | If customers ask why the CET tests fail we explain its because they are testing an Adobe limitation that we don't suffer from | 16:23.45 |
| henrys | kens:strongly agree | 16:24.14 |
| Robin_Watts | kens: Sounds reasonable to me. And moving to 64bit ints in general sounds fine, unless we a) find it's much slower, b) find it uses much more memory, or c) find that we have people using gs on machines with no 64bit support. | 16:24.58 |
| henrys | we should look at the damage though does somebody want to do a clusterpush with 64 bit ints. | 16:25.03 |
| ray_laptop | back now, sorry. | 16:25.16 |
| Robin_Watts | chrisl has volunteered for that I think. | 16:25.20 |
| kens | henrys chrisl said he would do that soon | 16:25.22 |
| chrisl | Everybody types faster than me...... | 16:25.35 |
| henrys | oh okay | 16:25.41 |
| Robin_Watts | chrisl: You use capitals and everything :) | 16:25.52 |
| ray_laptop | 64-bit ints _will_ be slower on something like cust 532's old PPC | 16:25.57 |
| marcosw | for the CET we could detect the input file and output a prestored bitmap. Would improve performance as well. | 16:26.09 |
| Robin_Watts | We are nearing the end of the half hour... | 16:26.39 |
| kens | We could probably write an idiom for the CET tests | 16:26.39 |
| henrys | cust 532 is only exposed to a slowdown with interpreter PDF is that really a bottleneck ray_laptoop? | 16:26.40 |
| | ray_laptop ^^ | 16:26.58 |
| chrisl | ray_laptop: I though the PPC603 had hardware support for 64 bit data types | 16:27.03 |
| ray_laptop | marcosw: might increase our memory footprint a bit, particularly since CET customers are often 600 or 1200 dpi | 16:27.03 |
| kens | Idiom! | 16:27.22 |
| ray_laptop | henrys: cust 532 only PDF for no | 16:27.30 |
| kens | I'm sure I could write one to detect the CET etst | 16:27.33 |
| ray_laptop | for now | 16:27.34 |
| chrisl | Anyway, I'm not against having a build time option for 32 bit integers, I just don't think it should be for passing the CET..... | 16:27.59 |
| Robin_Watts | Before ken has to dive off, does anyone object to the "huge gs change" I mailed about yesterday? (subject to me tweaking the if_debugXm macros to take the memory pointer before the char as requested by tor8 and henrys) | 16:28.11 |
| kens | Sure, we may find embedded cases where it matters | 16:28.17 |
| alexcher | The main loop does a hundred operations per PS operator. A few more operations won't be significant. | 16:28.29 |
| ray_laptop | chrisl: if we have a 32-bit build option (that is not the default) I am fine with it | 16:28.38 |
| chrisl | ray_laptop: Okay, I feel we have to cater for crappy old systems, too ;-) | 16:29.13 |
| ray_laptop | alexcher: it increases the size of a ref from 8 to 12 bytes, right ? | 16:29.28 |
| kens | Hmm, Miranda doesn't like auto-complete on Robin_Watts for some reason, it crashes.... | 16:29.29 |
| chrisl | Robin_Watts: your patch looks okay to me - although I didn't go through it line-by-line | 16:29.43 |
| kens | ray_laptop : I thought we already did that for arrays and stuff | 16:29.44 |
| ray_laptop | kens: did what ? | 16:29.56 |
| kens | changed hte ref size | 16:30.02 |
| alexcher | ray_laptop: ref is already 16 bytes everywhere. | 16:30.14 |
| Robin_Watts | chrisl: I wasn't expecting people to go through line by line - just to quickly check the bits of code they 'own'. | 16:30.21 |
| henrys | mvrhel:did you have anything for the meeting? | 16:30.29 |
| kens | Robin_Watts : It all looks fine from my POV | 16:30.34 |
| ray_laptop | alexcher: oh, right -- when we removed the 64k limit ? | 16:30.41 |
| Robin_Watts | kens, chrisl: thanks. | 16:30.45 |
| chrisl | Robin_Watts: Oh, actually, I think I have a non-labour intensive solution to the UFST problem. I'll get to that at some point | 16:31.08 |
| Robin_Watts | chrisl: Ah, nice. | 16:31.17 |
| alexcher | ray_laptop: shortly after 9.06 release. | 16:31.27 |
| chrisl | Robin_Watts: still not confident UFST will work, though! | 16:31.43 |
| henrys | marcosw:you seemed to have lots of todo's on the tech agenda I noticed while doing the followup. | 16:31.44 |
| ray_laptop | alexcher: yes, I recall now why we went to 16 (vs. 12) | 16:32.00 |
| kens | marcosw did my timeout change for me | 16:32.07 |
| Robin_Watts | chrisl: Yeah, well, that's another bridge to cross and/or set fire too. | 16:32.08 |
| marcosw | henrys: true, but I think most of them are pretty straightforward. | 16:32.10 |
| henrys | marcosw:if it's too much we can reassign, let me know. | 16:32.22 |
| chrisl | Robin_Watts: well, at least if *our* code does it right, I can punt it back to Monotype | 16:32.46 |
| kens | Can we (quickly) talk about bigtiff support ? | 16:32.52 |
| chrisl | I created a 9.6Gb tiff this morning, from tiff32nc..... | 16:33.18 |
| kens | Wow | 16:33.27 |
| alexcher | ray_laptop: 12-byte refs disagree with the allocator granularity and we decided that padding is too difficult to implement. | 16:33.30 |
| chrisl | er, tiff24nc, I mean | 16:33.34 |
| kens | new switch chrisl ? | 16:33.40 |
| henrys | chrisl:I though that didn't work. | 16:33.48 |
| chrisl | I haven't put the switch in, I just proved it would work. | 16:34.00 |
| kens | Ah OK | 16:34.04 |
| | So it shoudl be straight forward to implement then | 16:34.16 |
| chrisl | henrys: bigtiff is an extension which uses 64 bit offsets in the tiff file | 16:34.18 |
| henrys | oh I thought it was a completely separate library. | 16:34.34 |
| kens | henrys cf the support email from Western Australia Land Office this morning | 16:34.35 |
| chrisl | Yeh, I wasn't kidding when I said 20 minutes! | 16:34.39 |
| henrys | chrisl:good news | 16:34.43 |
| chrisl | henrys: libtiff implemented support in v 4.0.0 | 16:34.52 |
| henrys | kens:yes that should go to scott and miles if it hasn't already. | 16:35.05 |
| kens | henrys yes, lots of discussion on that one. | 16:35.14 |
| ray_laptop | alexcher: yes, I recall that reason. | 16:35.20 |
| kens | Looks like the MapScript people *might* be in violation of GPL | 16:35.27 |
| mvrhel | henrys: I dont have anything for the meeting. hoping to get the stuff done with the deviceN profile for the customer this week | 16:35.33 |
| chrisl | henrys: the only *small* issue is that it has to be a user option whether we write ordinary tiff or bigtiff - there's not support in libtiff for automatically switching when the file gets big. | 16:36.11 |
| henrys | mvrhel:we'll try to convince alexcher to keep the soft mask stuff at the front of the queue also, it would be nice to get that wrapped up. | 16:36.33 |
| kens | chrisl can we guestimate the file size from the page size and colour depth ? | 16:36.49 |
| mvrhel | sounds good | 16:36.53 |
| chrisl | kens: not once compression is involved, no | 16:37.16 |
| kens | chrisl I know, I was thinking we could write it bigtiff if it looked likely to overflow | 16:37.38 |
| henrys | chrisl:I think an option is fine for now. | 16:37.55 |
| kens | Automatically that is | 16:37.56 |
| henrys | default 32 bit. | 16:38.05 |
| kens | Sounds fine to me | 16:38.16 |
| chrisl | Well, I'm open to persuasion, but I reckon people that need bigtiff will mostly know that they need bigtiff! | 16:38.25 |
| kens | Automatic woudl be nice, but I cna see why its not feasible | 16:38.26 |
| Robin_Watts | chrisl: If you have gs put out an error like "This file is too big for tiff. Rerun with -dUseBigTiff=1." | 16:39.23 |
| chrisl | Robin_Watts: yes, that makes sense | 16:39.40 |
| kens | Is that possible to detect ? | 16:39.53 |
| | Sounds like a nice solution | 16:40.00 |
| henrys | ray_laptop:when can we get our pdf files from 532? | 16:40.15 |
| ray_laptop | I agree that an option like -dUseBigTiff or -dUseBigTiff=true would be nice. | 16:40.19 |
| henrys | the ats | 16:40.20 |
| Robin_Watts | kens: yes, I think so. | 16:40.35 |
| chrisl | Of course, once the output is *that* big, we'll be using the clist, so we could just ditch the overflowing file, and rerender (nice and slooowwww!) | 16:40.51 |
| ray_laptop | henrys: did we get the info from Dennis and purchased the ATS ? | 16:41.03 |
| | chrisl: Since some readers can't handle bigtiff, I think we want people to enable it explicitly | 16:42.30 |
| henrys | ray_laptop:I got the okay from QL but I can't imagine miles paid this fast and we haven't received the tests. | 16:42.32 |
| ray_laptop | henrys: I didn't know you got the OK from QL. Did you send something I missed ? | 16:43.10 |
| henrys | ah just got an email from miles - "checks in the mail" so a few days. | 16:43.18 |
| chrisl | ray_laptop: yeh, I agree with that - not sure many readers can read bigtiff. | 16:43.35 |
| henrys | yeah I think Dave wrote back to just me and miles for some reason. Anyway let's wait until we have the check cleared. | 16:44.00 |
| ray_laptop | henrys: OK. Then we can forward that email to Dennis. | 16:44.30 |
| henrys | ray_laptop:it ended up being steve clark that contacted ql | 16:45.05 |
| ray_laptop | chrisl: on the option, I think it should be bool, not numeric, and like our other bool options -dUseBigTiff implies -dUseBigTiff=true | 16:45.38 |
| | henrys: that works. | 16:45.52 |
| chrisl | ray_laptop: that's exactly what I wrote in the e-mail this morning | 16:46.03 |
| ray_laptop | chrisl: haven't plowed through email yet -- but Robin_Watts had the -dUseBigTiff=1 above | 16:47.10 |
| Robin_Watts | ray_laptop: Sorry, that was me. I haven't seen chris' email. | 16:47.33 |
| ray_laptop | mvrhel: I need to chat with you about cust 532's RGB OP simulation | 16:47.43 |
| chrisl | Oh, right. No it would definitely be a boolean | 16:47.44 |
| kens | Need to go put dinner on, back in 5 minutes | 16:48.05 |
| Robin_Watts | ray_laptop: Did you have any objection to my 'huge' change ? | 16:48.06 |
| | (mvrhel, alexcher: same question) | 16:48.36 |
| chrisl | If we're all happy with that, I'll do the -dUseBugTiff change tomorrow | 16:48.36 |
| henrys | ray_laptop:I sent you the mail you missed. | 16:49.00 |
| ray_laptop | Robin_Watts: no, but (unlike tor) I like the flag BEFORE the memory, but don't feel strongly | 16:49.08 |
| | henrys: thanks. | 16:49.13 |
| | chrisl: or UseBugTuff ? | 16:49.40 |
| chrisl | I just noticed the Freudian Slip ;-) | 16:49.55 |
| alexcher | Robin_Watts: looks fine for me. | 16:50.07 |
| henrys | so let's call it adjourned. | 16:50.43 |
| Robin_Watts | alexcher, ray_laptop: Thanks. | 16:52.32 |
| ray_laptop | chrisl: BTW, automatic switching to BigTiff is a two-fold problem since it may occur after the first page was written. | 16:53.03 |
| | chrisl: and the header in the is a different size | 16:53.29 |
| ray_laptop | can't type today | 16:53.44 |
| chrisl | ray_laptop: indeed, I don't think it's worth tackling - too many variables involved | 16:54.04 |
| henrys | I find it interesting that the 2nd and 3rd largest economies in the world are clashing swords and the only news I hear is about is Libya and Afganistan. I think our news media has become obsessed with the muslim world to exclusion of more important issues. | 16:55.21 |
| Robin_Watts | henrys: Which two are they? China and California or something? | 16:56.41 |
| | (Actually, I think California is 4th...) | 16:56.56 |
| apineda | Hey guys how y'all doing... Im getting a black line in my display device images. I'm pretty sure it's a bad config on my end but I haven't been able to get to the bottom of it. | 16:57.24 |
| henrys | http://www.washingtonpost.com/world/asia_pacific/anti-japan-protesters-clash-with-riot-police-in-china/2012/09/17/d5352a99-f3dc-40ae-bc5e-486f0b9dda3d_video.html | 16:57.25 |
| Robin_Watts | Ah. Fighting over those little islands? | 16:57.40 |
| apineda | yeah that island situation is fucked up | 16:57.41 |
| | guberment knows how to steer anger though thats for sure! | 16:57.53 |
| ray_laptop | henrys: the US and China are also in a WTO confrontation | 16:58.12 |
| Robin_Watts | henrys: I think judging anything from the behaviour of crowds in china is a doomed to failure: http://www.youtube.com/watch?v=DsouYCY8wX0 | 17:01.15 |
| henrys | It's alarming when you see large Japanese companies announcing factory shutdowns in fear of violence. The world economy could become a lot smaller very quickly if this situation gets out of hand. | 17:07.32 |
| ray_laptop | henrys: I just read the email from QL. Dave said "Once we receive a PO from you for the PDF 1.7 ATS, we have given them the OK to share files from that test with you." | 17:09.12 |
| | henrys: which is a bit confusing. If he has the verb tense correct, then he already has given them the OK. I'll ask the customer if that's OK. | 17:09.14 |
| henrys | ray_laptop:yes the ambiguity is why I suggested just wait until we have the QL application tests, then we know the dust has settled. | 17:09.59 |
| | would getting it now save you a trip? | 17:11.00 |
| mvrhel | ray_laptop : just stepped out for a sec | 17:12.51 |
| | I am back | 17:12.56 |
| henrys | bbiab | 17:14.56 |
| Robin_Watts | ray_laptop: I'd read that as "We have given them the OK to share files from the PDF 1.7 ATS with you, as soon as we receive a PO for that test from you." | 17:19.02 |
| mvrhel | Robin: a question about your patch | 17:22.42 |
| Robin_Watts | mvrhel: Sure. | 17:22.50 |
| mvrhel | so does it matter what memory you are sending to emprintf* or if_debug*m? i.e. stable, non_gc etc? | 17:23.41 |
| Robin_Watts | (While doing the patch, I spotted (and fixed) a small bug in gsicc_manage. I think you meant return gs_rethrow1(); rather than just gs_rethrow1(); ) | 17:23.57 |
| | mvrhel. | 17:24.00 |
| | mvrhel: No, it doesn't matter at all. | 17:24.07 |
| mvrhel | ok | 17:24.09 |
| Robin_Watts | Every mem has a pointer to the lib_ctx in it. | 17:24.22 |
| mvrhel | Robin_Watts: yes. I have a bunch of throw fixes I have to do | 17:24.31 |
| Robin_Watts | so we just use mem to get the lib_ctx. | 17:24.33 |
| mvrhel | but if you fixed some of them, thanks! | 17:24.39 |
| | Robin_Watts: ok. I see | 17:24.48 |
| Robin_Watts | I fixed one that was giving me a warning with my new code :) | 17:24.51 |
| mvrhel | Robin_Watts: I don't have any issues with your patch | 17:25.24 |
| Robin_Watts | mvrhel: Fab, thanks. | 17:25.45 |
| | Bah. Looks like gsicc_lcms{,2}.c are using gs_lib_ctx_get_non_gc_memory_t(). I'll have to find a way around that. | 17:26.58 |
| | mvrhel: OK. Stupid question time I'm afraid. | 17:36.06 |
| | The malloc/free/init callbacks that get called from lcms have a 'ContextID' as their first arg. | 17:36.34 |
| | This is a void *. | 17:36.37 |
| | So I'm guessing that I want to somehow arrange to get the required mem pointer from that. | 17:36.55 |
| | BUT... I can't see where that void * is ever created. Do you know anything about this? | 17:37.14 |
| mvrhel | Robin_Watts: is this something in lcms or something that I wrote? | 17:39.32 |
| Robin_Watts | In lcms. | 17:39.45 |
| | Well, in the usage of lcms. | 17:39.59 |
| mvrhel | Robin_Watts: then I know as much or less than you :) | 17:40.04 |
| Robin_Watts | OK. I shall dig. | 17:40.17 |
| | I have a note in the interface code about needing to use a global and that I should talk to you about it. | 17:40.40 |
| mvrhel | if you need to drag me in, let me know. working now on creating some DevN profiles for this customer project | 17:40.41 |
| Robin_Watts | For getting colorant names. | 17:40.47 |
| | I'll try and understand my note before bothering you though :) | 17:41.00 |
| mvrhel | really? | 17:41.01 |
| | ok | 17:41.07 |
| ray_laptop | mvrhel: calling to chat about RGB OP | 17:43.00 |
| | mvrhel: but got voicemail | 17:43.17 |
| | mvrhel: please call when you get a chance. | 17:45.13 |
| Robin_Watts | mvrhel: Ah, I understand my note now. Please let me know when you can spare a couple of minutes (after ray). I know what needs doing, but want your blessing. | 17:45.55 |
| | Oh, hell. I pushed the commit with the macro the wrong way round. I'll do a commit to fix it tomorrow. | 18:05.38 |
| henrys | Maybe I'm being difficult about 693337 but it seems little things like that mount up and soon enough the code is like hacking through a jungle. | 18:14.35 |
| ray_laptop | bbaib | 18:17.23 |
| mvrhel | hehe | 18:18.24 |
| | ray_laptop: you there? | 18:18.30 |
| henrys | mvrhel:he just said bbiab | 18:18.59 |
| mvrhel | right. we keep missing one another | 18:19.22 |
| | Robin_Watts: ok. we can chat now | 18:19.33 |
| henrys | happy anniversary, Sabrina and I were both reminded of our anniversary by receiving a card from her mom, we both completely spaced it this year... yikes | 18:20.28 |
| mvrhel | henrys: when was your anniversary? | 18:20.56 |
| henrys | back in june | 18:21.13 |
| mvrhel | ah ok. | 18:21.17 |
| henrys | I need a google calendar alert | 18:21.51 |
| mvrhel | I need one about a month early that says, order present now | 18:22.11 |
| Robin_Watts | mvrhel: neverforget.com | 18:23.22 |
| | actually that's not the one. | 18:24.16 |
| | paulgardiner: ? | 18:24.18 |
| paulgardiner | neverforget.net I think | 18:24.54 |
| | Or never-forget.net | 18:24.58 |
| Robin_Watts | Someone should do a web based service to help people remember urls. | 18:25.36 |
| mvrhel | :) | 18:25.46 |
| Robin_Watts | And now I have to go fix the fence that my dog just broke through. joy. | 18:25.57 |
| | mvrhel: Sorry, with the dog and all I missed you saying we could chat. | 18:40.45 |
| | Is now a good time? | 18:40.50 |
| mvrhel | Robin_Watts: hold on 2 minutes | 18:42.47 |
| | Robin_Watts: ok | 18:45.51 |
| | I am here now | 18:45.53 |
| Robin_Watts | OK. If I could trouble you to look at gs/base/gsicc_lcms2.c | 18:46.27 |
| | At gscms_get_clrtname | 18:46.47 |
| | That expects to be able to get a string from a profile, and not to have to free it etc. | 18:47.15 |
| mvrhel | ok hold on | 18:47.26 |
| | ok | 18:48.57 |
| Robin_Watts | So currently it's implemented by getting the name into a static buffer and returning a pointer to that name. | 18:49.03 |
| mvrhel | yes I see that | 18:49.10 |
| | we could change that | 18:49.16 |
| Robin_Watts | Which obviously doesn't play nicely for multiple threads. | 18:49.19 |
| | Right. We could pass a buffer in? | 18:49.26 |
| mvrhel | yes. that would be my preference | 18:49.35 |
| Robin_Watts | OK. I'll have a look at that. | 18:49.45 |
| mvrhel | ok. thanks | 18:49.49 |
| Robin_Watts | One thing that occurs to me while looking at this whole gsicc interface is that we don't make it easy for people to get to the context pointers. | 18:50.14 |
| | I'm looking at gsicc_cms.h | 18:50.49 |
| | We 'create' and 'destroy' and let the CMS keep it's private state (whatever it may be) in contextptr. | 18:51.28 |
| | Shouldn't gs be passing that back into the other functions? | 18:51.44 |
| mvrhel | you mean the other ones like get_link etc | 18:52.36 |
| Robin_Watts | yes. | 18:53.08 |
| | (unless it's available as part of gcmmhprofile_t or something) | 18:53.50 |
| mvrhel | well yes | 18:53.57 |
| | most cmms have it packed in the link and profile objects | 18:54.05 |
| | this interface is what I have run across with almost every cmm | 18:54.20 |
| Robin_Watts | Is a gcmmhprofile_t intended to be something that the CMS in question (or the gs wrapper for it) implements? | 18:55.21 |
| | If so, how is the context pointer supposed to get into it ? | 18:55.41 |
| mvrhel | that is an opaque type | 18:55.58 |
| | the cmm will put what ever it needs into it | 18:56.07 |
| | I think my non color managed case does it | 18:56.28 |
| Robin_Watts | OK. So what call creates a gcmmhprofile_t ? | 18:56.45 |
| mvrhel | what creates the object? | 18:57.14 |
| | the cmm does | 18:57.19 |
| Robin_Watts | gscms_get_profile_handle_{mem,file} ? | 18:57.25 |
| mvrhel | oh you mean what procedure? | 18:57.45 |
| Robin_Watts | yes. | 18:57.50 |
| mvrhel | well the get profile | 18:57.55 |
| | procedueres | 18:57.57 |
| Robin_Watts | gscms_get_profile_handle_{mem,file} ? | 18:58.08 |
| mvrhel | which get a pointer from the cmm | 18:58.14 |
| | yes | 18:58.16 |
| | which is basically a void | 18:58.36 |
| Robin_Watts | Right. How are they supposed to get the contextpointer to put it into the opaque type then? | 18:58.36 |
| mvrhel | as far as gs is concerned | 18:58.43 |
| | they already did it | 18:58.53 |
| Robin_Watts | ? | 18:58.58 |
| mvrhel | when I asked for the profile handle | 18:59.00 |
| | ok. so I ask for a profile handle with those procedures | 18:59.16 |
| | and I get back a pointer | 18:59.22 |
| | the cmm puts whatever it needs in there | 18:59.30 |
| | I don't now what that is | 18:59.34 |
| Robin_Watts | No, too late already. | 18:59.39 |
| | Follow me through... (Sorry, maybe I'm being really dim) | 19:00.00 |
| | We're in a multithreaded world, so the cms is not allowed to have any local state. | 19:00.23 |
| mvrhel | the profile type and the link type are opaque to gs | 19:00.27 |
| Robin_Watts | Yes, I get that. | 19:00.35 |
| | We start up, and gs calls gscms_create() | 19:00.47 |
| | and that creates a contextPointer, which is a void * to a structure where the cms can keep all it's state. | 19:01.11 |
| mvrhel | ok | 19:01.12 |
| Robin_Watts | What is the next call gs makes to the cms? | 19:01.28 |
| mvrhel | well. that is only for information that it may need for shut down | 19:01.39 |
| | not for getting profiles and links | 19:01.46 |
| Robin_Watts | oh. | 19:01.58 |
| | Such as? | 19:02.13 |
| mvrhel | I have not seen a cmm that needed a context pointer for every link and profile request. that is not to say though that they are not needed | 19:02.23 |
| | for some cmm out that | 19:02.28 |
| | out there | 19:02.30 |
| Robin_Watts | Right. | 19:02.33 |
| | I was expecting us to have to pass the context pointer into the get_profile_handle calls. | 19:02.51 |
| | I think it's reasonable to expect the cmm to pickle that into the gcmmhprofile_t if it's going to need it in the link requests. | 19:03.31 |
| mvrhel | that was my thought | 19:03.49 |
| Robin_Watts | but it seems a gap in our API not to provide it to the get_profile stuff. | 19:03.51 |
| mvrhel | I really have not see a need for it in any cmm interface | 19:04.18 |
| Robin_Watts | And yet you have seen a need for a context pointer for startup/shutdown? | 19:04.50 |
| mvrhel | no. I have not seen that either. | 19:05.05 |
| | the whole start up and shut down was not needed until recently | 19:05.20 |
| kens | marcosw ping | 19:05.21 |
| Robin_Watts | That seems odd to me, because what can it need to startup/shutdown that it doesn't need to use at some point during the middle? :) | 19:05.25 |
| mvrhel | Robin_Watts: I agree. | 19:05.54 |
| Robin_Watts | Would you object to me adding it to the get_profile calls? | 19:06.00 |
| mvrhel | I worry about it being messy and understanding where you are getting the context pointer | 19:06.41 |
| | where are you storing and getting it? | 19:07.02 |
| Robin_Watts | I'm not storing anywhere. You're already storing it in the iccmanager | 19:07.25 |
| mvrhel | I worry about it not really being testable | 19:07.26 |
| | you added that I think | 19:07.31 |
| | How does this work in the clist case? | 19:07.44 |
| | the iccmanager is created a new with each band (or can be) | 19:08.01 |
| | with each imager state | 19:08.09 |
| | what is the context manager initialized to for these objects? | 19:08.19 |
| | context pointer I mean | 19:08.30 |
| Robin_Watts | Ok, so gscms_create will be called for every band and will get a new context pointer. | 19:08.39 |
| | Then every get_profile_handle call in that band will get the context pointer passed to it. | 19:09.26 |
| | And when the iccmanager is finalised, gscms_destroy() is called and the context pointer goes away. | 19:09.42 |
| mvrhel | Robin_Watts: and what about get_link? | 19:10.15 |
| | you should probably do it for that too | 19:10.24 |
| Robin_Watts | I could if you want. | 19:10.40 |
| mvrhel | why would you do it for the profile and not the link request? | 19:11.02 |
| Robin_Watts | or we could assume that if people need it, they'll pickle it into the gcmmhprofile_t they get at the get_profile stage. | 19:11.07 |
| henrys | marcosw:for the logs, I think the GPL business is not enforcible as you said at the staff meeting, we have accepted many contributions under the GPL I don't think it reasonable that we apply a new meaning to that code. | 19:11.13 |
| mvrhel | Robin_Watts: ok fair enough | 19:11.25 |
| | so the get profile would be the only one | 19:11.36 |
| Robin_Watts | At the moment, we're in this half and half state (which may well be my fault) where we have a context pointer, but it's not of any use. | 19:11.53 |
| | yes, I think so. | 19:12.01 |
| mvrhel | Robin_Watts: ok. I am fine with that change | 19:12.04 |
| Robin_Watts | Fab. | 19:12.08 |
| henrys | we can only enforce what is the understood meaning of the GPL whatever that is. | 19:12.13 |
| mvrhel | make sure you propagate it into the named color stuff too | 19:12.23 |
| Robin_Watts | Is it reasonable to assume that no colorant is more than 256 bytes long ? | 19:12.28 |
| mvrhel | Robin_Watts: I think so | 19:12.35 |
| Robin_Watts | mvrhel: What named color stuff? | 19:12.42 |
| | gscms_get_name2device_link ? | 19:12.51 |
| mvrhel | Robin_Watts: oh never mind | 19:13.17 |
| Robin_Watts | That takes gcmmhprofile_t's so shouldn't need any changes. | 19:13.18 |
| mvrhel | I was thinking I had a special call to get a named color profile | 19:13.28 |
| Robin_Watts | ok. | 19:13.54 |
| mvrhel | Robin_Watts: so we are all set then? I am going back to work on ICC DeviceN fun] | 19:15.18 |
| | but lunch first | 19:15.26 |
| Robin_Watts | mvrhel: We are. Thanks | 19:15.27 |
| | Hmm. LCMS2 looks to be broken in multithreaded form :( | 23:36.12 |
| | But it's a 3 line fix. | 23:41.10 |
| mvrhel | Robin_Watts: that might make Marti hold up his release | 23:49.12 |
| Robin_Watts | He's released. | 23:49.20 |
| mvrhel | oh | 23:49.25 |
| Robin_Watts | Never mind, if no one has spotted it until now... | 23:49.52 |
| mvrhel | I do know that we can't share profiles nor links amongst bands in multithreaded rendering. but you are talking about something different? | 23:50.20 |
| Robin_Watts | yeah. | 23:50.33 |
| mvrhel | different instances of gs? | 23:50.46 |
| Robin_Watts | In order to make multithreading work with gs, we have to pass a gs_memory_t into lcms for it to pass back to us to use in our allocators. | 23:51.27 |
| | which we can do by passing it as the "cmsContext" (it's a void *, just like you'd expect). | 23:51.59 |
| | For each tag, he gets a tag handler from an array of them, and writes the icc value into the tag handler struct before calling the tag handler function. | 23:52.53 |
| | if 2 threads are using the same tag handler at the same time, we collide and it falls over. | 23:53.23 |
| mvrhel | ok | 23:54.58 |
| Robin_Watts | oh, and my fix doesn't work. D'Oh. | 23:55.44 |
| | But I think I know how. Will do it tomorrow when I am more awake. | 23:56.12 |
| mvrhel | have a good night | 23:56.24 |
| Robin_Watts | Thanks. | 23:56.30 |
| | Forward 1 day (to 2012/09/19)>>> | |
IRC Logs