| | <<<Back 1 day (to 2014/04/20) | 2014/04/21 |
| Robin_Watts_ | morning | 08:39.50 |
| kens | Mornign Robin_Watts_ | 08:39.56 |
| pedro__ | hi Robin | 09:12.58 |
| paulgardiner_lap | morning | 09:13.36 |
| pedro__ | morning Paul | 09:14.18 |
| paulgardiner_mac | Robin_Watts_: pick-file commit looks good to me | 09:48.13 |
| Robin_Watts_ | paulgardiner_mac: Thanks. | 09:48.25 |
| | paulgardiner: Ordered a new cable for my torphones yesterday. Arrived today. | 10:24.48 |
| | I got the android control cable. (mic, volume, pause/play etc) | 10:29.06 |
| paulgardiner_lap | Robin_Watts_: Oh. Didn't know such thing existed. I may get one too. | 10:31.42 |
| Robin_Watts_ | http://www.amazon.co.uk/gp/product/B00EZV4HEA/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1 | 10:32.20 |
| | I was hoping they might be a bit more chunky than the original bose cables, but they seem exactly the same spindly cable. | 10:32.54 |
| | Oh, but the buttons don't work on the S2. | 10:33.20 |
| | So possibly pointless unless you nook your S2. | 10:33.43 |
| | But I was somewhat amazed by the "order on easter sunday, arrive on easter monday". | 10:35.15 |
| kens | impressive | 10:35.25 |
| Robin_Watts_ | So it turns out that with a tiny tweak to our makefiles, I can get them past the problems that jom was having. | 10:40.46 |
| | but when I try to use it to build in parallel stuff falls over - i think because our makefiles assume ordering. | 10:41.25 |
| paulgardiner_lap | Robin_Watts_: that is impressive. What time did you place the order? | 10:46.11 |
| | Most surprising delivery I ever had was placing an order at 8pm on a Fri evening and getting the delivery at 7am Sat!! | 10:49.18 |
| Robin_Watts_ | paulgardiner_lap: I got the order confirmation email at 13:04. | 10:51.56 |
| | oh, jeez. | 11:51.34 |
| | In windows builds, every compilation gets extra flags from the ccf32.tr file. | 11:52.03 |
| | which means that every target *ought* to have a dependency on the ccf32.tr file. | 11:55.51 |
| kens | This is Ghostscript ? | 12:03.24 |
| Robin_Watts_ | yes. | 12:03.39 |
| kens | Ah sorry, I thought you were talking about MuPDF or SOT, not paying enough attention... | 12:03.55 |
| Robin_Watts_ | I've been looking into ways to get parallel builds working. | 12:04.08 |
| | jom looks like the easiest. | 12:04.16 |
| kens | It would be nice to have, but not vital | 12:04.21 |
| Robin_Watts_ | Indeed. | 12:04.24 |
| | I suspect that we need to introduce new macros CCDEPS, CCAUXDEPS etc. | 12:04.49 |
| | and the unix builds can leave them undefined. | 12:05.05 |
| kens | THat's one to put to chrisl | 12:05.06 |
| Robin_Watts_ | Yeah. | 12:05.21 |
| | Currently, the MS makefiles are 'wrong', in that there are dependencies that aren't mentioned. | 12:05.47 |
| kens | So, would we then have to mandate building with jom, or would nmake still work ? | 12:05.57 |
| Robin_Watts_ | It's a big edit, but a systematic one to fix it. | 12:06.03 |
| | nmake would still work. | 12:06.06 |
| kens | THat sounds like a good solution then. | 12:06.14 |
| Robin_Watts_ | jom is just 'nmake with parallel abilities'. | 12:06.22 |
| kens | I suspect the makefiles are a long way short of having all the dependencies accurately defined | 12:06.34 |
| Robin_Watts_ | It looks like there is a difference, in that jom and nmake handle lines with continuations (i.e. ending in \) that are immediately followed by make directives (like !if etc) differently. | 12:07.25 |
| | but that's easily worked around in a way that works for both nmake and jom. | 12:07.45 |
| kens | Well, possibly we could come up with a way to deal with that | 12:07.45 |
| Robin_Watts_ | The ccf32.tr problem is the latest problem I've run into, and it looks like it will be a big edit to fix. | 12:08.26 |
| | chrisl is off today, right? | 12:08.30 |
| kens | I think he saiod he was yes | 12:08.41 |
| | He was on first thing but has been away a while | 12:08.55 |
| henrys | now if I just had parallel autoconf ;-) | 12:15.21 |
| Robin_Watts_ | kens: Do you know of any tool for generating panose numbers from a font ? | 12:27.11 |
| kens | Nope, sorry | 12:28.02 |
| | I can't even think of anything that uses it | 12:28.30 |
| henrys | Robin_Watts_: I guess you thought of and dismissed using gnu make to invoke the MS compiler | 12:28.32 |
| | ? | 12:28.35 |
| kens | That would require people to use GNU make henrys | 12:29.01 |
| Robin_Watts_ | henrys: gnu make uses a different format for directives like include. | 12:29.02 |
| | and the if/endif/else stuff is all different. | 12:29.11 |
| | I spent saturday hacking gnu make so that it would accept !include !if !else !endif etc. | 12:29.33 |
| | and then discovered that gnu make is *astoundingly* crap, in that you can't say: if a || b | 12:29.56 |
| | I rewrote the makefiles to get around that. | 12:30.10 |
| | Then I discovered that you can't say: if a < 800 etc. | 12:30.25 |
| | and it's just not feasible to rewrite the makefiles nicely to get around that. | 12:30.41 |
| | So I went back to looking at jom. | 12:30.53 |
| | But the fact is that whatever parallel make system we use, we need to fix the dependencies. | 12:31.14 |
| kens | Robin_Watts_ : somoene is claiming that the OS/2 table of a TrueType font contains the PANOSe number | 12:31.14 |
| Robin_Watts_ | kens: Ah, I was just firing up fontforge to check :) | 12:31.28 |
| henrys | yup I thought that might be a quagmire | 12:31.31 |
| pedro__ | ran into some issues with Qt4's build system using jom with ms compiler - ended up leaving some files locked - looked like it wasn't cleaning up properly. Don't think jom was the problem, but it did end up with me reverting the build system to use nmake | 12:31.36 |
| Robin_Watts_ | henrys: I'm not sure it's actually that bad to fix. It's a large edit, but it's a systematic one. | 12:33.09 |
| | Awesome. The panose number in the font is unset :( | 12:33.33 |
| kens | Looking at the spec, and unearthign some old memories, I don't think you can reliably have software generate panose numbers, its a bit 'subjective' for that. | 12:34.48 |
| | Possibly FreeType could make a stab at it. | 12:35.00 |
| Robin_Watts_ | kens: I was hoping for something better than picking one out of thin air, but I think that wins for me. | 12:35.24 |
| henrys | Robin_Watts_, kens: I guess unix is kept more up to date with marcosw1 doing the cluster in parallel | 12:35.37 |
| Robin_Watts_ | henrys: MSVC builds and unix builds share the bulk of the makefiles. | 12:36.05 |
| | So on the whole the dependencies are fine. | 12:36.12 |
| | It's just that *every* cc target should (on windows) depend on ccf32.tr too. | 12:36.32 |
| | So it's a change to every target in every makefile. A change that will make no difference on unix. | 12:37.00 |
| henrys | Robin_Watts_: so a quick fix is to invoke nmake on ccf32.tr first than the parallel build? | 12:38.09 |
| Robin_Watts_ | ccf32.tr is created as one of the early steps of the build. | 12:38.39 |
| kens | Robin_Watts_ : as far as I can see panose is effectively dead, the company behind it was sold to HP< and the panose stuff to Agfa-Monotype | 12:39.15 |
| Robin_Watts_ | kens: In picsels font mapping files, we include panose numbers. | 12:42.07 |
| | Not entirely sure why. Presumably they intended to support face matching by panose numbers, but I don't think they ever implemented it. | 12:42.42 |
| henrys | paulgardiner_lap: I'm on to a new diet thing, consuming this pond scum http://www.gardenoflife.com/Products-for-Life/Foundational-Nutrition/RAW-Meal.aspx, it is quite filling though and I thought it might work with what you are doing on fast days. | 12:43.06 |
| kens | Possibly because most font vendors don't supply the info, or set it to 0-0-0... | 12:43.07 |
| | FWIW hte company behinf panose (elseware) was sold in 1993 | 12:44.03 |
| | IIRC one of the big problems was that it didn't address the actual glyphs available in the font, which could make it a poor replacement. | 12:44.50 |
| | I think that was one of the things panose 2 was supposed to deal with | 12:45.01 |
| paulgardiner_lap | henrys: Interesting. I've been far too long on my unimaginative veg and chicken breast fast-day regime. Pond scum sounds positively delicious. | 12:46.14 |
| Robin_Watts_ | henrys: soylent green. | 12:46.37 |
| kens | thinks probably not as tasty | 12:46.50 |
| | People liked soylent green | 12:47.05 |
| Robin_Watts_ | So I mailed the VisualGDB people asking how tied their licenses were. Wondered if we could buy a copy for the company and then install/uninstall it so that only one of us was using it at a time. | 12:47.44 |
| | Licenses are tied to a single user/machine. If you want to move machines, email them. | 12:48.12 |
| kens | Why would I want gcc/gdb in VS ? | 12:48.37 |
| Robin_Watts_ | kens: Well, I can debug an android app in VS, that's the big attraction. | 12:49.25 |
| henrys | Robin_Watts_: it wasn't that expensive though? | 12:49.32 |
| kens | That's a good reason | 12:49.33 |
| | Not for me, but still a good reason | 12:49.44 |
| | ultimate is $256 | 12:50.03 |
| Robin_Watts_ | kens: Also, I can launch gs on peeved and step through it on my windows machine. | 12:50.03 |
| | will make linux debugging MUCH less painful. | 12:50.18 |
| kens | Hmm, could I launch it on my VM and step through on windows ? | 12:50.26 |
| paulgardiner_lap | henrys: Seems to be easily available over here | 12:50.28 |
| Robin_Watts_ | kens: *yes* | 12:50.32 |
| kens | THen I want one :-) | 12:50.36 |
| Robin_Watts_ | I was thinking that you and michael would be the obvious candidates for wanting to share a copy. | 12:50.54 |
| kens | Sorry that was 256 euros, $349 | 12:51.26 |
| | 'custom' which does everything except android is $219 | 12:51.55 |
| Robin_Watts_ | "Linux" edition is $109 | 12:51.59 |
| kens | chrisl could use the gcb window :-) | 12:53.04 |
| | Hmm what version of vs does it support ? Looks horribly like 2013 | 12:53.27 |
| Robin_Watts_ | kens: 2005,2008,2010,2012,2013 | 12:53.45 |
| kens | That'll do nicelyh | 12:53.53 |
| Robin_Watts_ | I've only tried it with 2010. | 12:54.01 |
| | There is a free 30 day trial. | 12:54.08 |
| kens | Yeah I see that | 12:54.14 |
| Robin_Watts_ | I've not tried linux, just android so far. | 12:54.30 |
| kens | Could have used it this morning, had I known | 12:54.31 |
| | I'd like to give it a try running VS on my PC and debugging GS on my Linux VM, might take a bit of configuring though | 12:55.47 |
| | I'll try and remember to give it a whirl when I finish this problem | 12:56.12 |
| Robin_Watts_ | Morning mvrhel_laptop, marcosw | 14:02.31 |
| ray_laptop | morning, all | 14:12.05 |
| kens | Morning | 14:12.09 |
| ray_laptop | catching up on my morning email. Some people read the newspaper over coffee -- I read email | 14:12.44 |
| | chrisl_away: (for the logs) thanks for the work on cust 532. I'm waiting for the updated simulator so I can see if the problem is cured by your gs_fapi changes | 14:15.42 |
| | Until hearing it on NPR this AM, I didn't know that "Easter Monday" is a European holiday. | 14:16.22 |
| | (at least for the stock market) | 14:16.55 |
| pedro__ | stock markets, banks and civil service ;) | 14:17.15 |
| Robin_Watts_ | and *sane* software engineers :) | 14:20.30 |
| ray_laptop | Robin_Watts_: that's sort of an oxymoron | 14:23.43 |
| Robin_Watts_ | oh, joy. | 14:32.21 |
| | The customer has requested a particular arabic font. | 14:32.29 |
| | and it uses a cmap format that we don't support. | 14:32.38 |
| | ah, the main font code handles it, it's "just" the font stripper that doesn't. | 14:34.49 |
| ray_laptop | Robin_Watts_: so give them the full fonts ? | 14:36.05 |
| Robin_Watts_ | ray_laptop: That would mean bloating their lib by 2Meg rather than 1Meg. | 14:36.25 |
| | It may be an easy enough fix. | 14:36.50 |
| ray_laptop | Robin_Watts_: then you can be a hero IF the size is too big (which they haven't said) | 14:36.57 |
| | iirc, this | 14:37.18 |
| | 'customer' is still in negotiation | 14:37.40 |
| Robin_Watts_ | from what miles has said this potential customer is following along the steps to becoming a customer pretty well. | 14:38.34 |
| ray_laptop | I hope so! | 14:38.49 |
| | that | 14:39.44 |
| | that"s what we thought with 801 | 14:40.10 |
| | sorry about all of the extra \n -- I was holding my laptop and trying to type with just one hand on the unsteady kB | 14:41.31 |
| Robin_Watts_ | ray_laptop: Yeah. I like to think that the pain we've been through with these first few customers is the steep part of the learning curve. | 14:42.32 |
| ray_laptop | I FINALLY located what is making the 'fast thresholding' work so poorly. | 14:42.40 |
| Robin_Watts_ | It should get easier. (Please God!) | 14:42.42 |
| ray_laptop | Robin_Watts_: amen to that | 14:42.49 |
| Robin_Watts_ | hides | 14:42.52 |
| ray_laptop | heavy clouds collect ... | 14:43.10 |
| | now I have to do it 'right' without killing performance (the fast thresholding approach to image scaling is the issue) | 14:44.10 |
| kens | ray_laptop : could you open a enhancement bug report for me about the getdeviceparams and attach tje customer file you've been using please ? I looked briefly at it over the weekend and I've got some ideas but I'll need a real file to test with | 14:45.45 |
| ray_laptop | kens: the file WWTTN1CT was attached to Len's email of 4/2, Subject: Performance Issue | 14:51.17 |
| kens | Ah OK I'll go look three | 14:51.25 |
| | there* | 14:51.31 |
| ray_laptop | kens: if you need me to send it again, let me know | 14:51.33 |
| kens | NP I'll have it filed | 14:51.39 |
| ray_laptop | kens: by "right" I assume doing it in a way that prevents the frequent getdeviceparams, but will still work when the device changes during a page (or changes the setting of the param) | 14:54.14 |
| kens | ray my current idea is to allow for a single parameter to be requested, instead of gathering the whole dictionary | 14:54.51 |
| ray_laptop | kens: PreserveTrMode, and PreserveSMask are the concerns, and possibly WantsToUnicode | 14:54.52 |
| | kens: uh... that won't work I don't think | 14:55.18 |
| kens | THere are others 'HighLevelDevice' springs to mind | 14:55.25 |
| | ray_laptop : as a different C call, probably using spec_ops | 14:55.36 |
| ray_laptop | at the very least, it's a MAJOR design change to add a 'get_single_param' call. Easier to make spec_op available to PS, IMHO | 14:56.07 |
| kens | ray_laptop : that's essentially waht I'm considering, the spec_op would be a 'get this paramter' one. At teh moment I'm thinking I can return a param_ object in much the same way as the getdeviceparams does (but only for one parameter) | 14:57.13 |
| ray_laptop | kens: for spec_op from PS, the only problem is the names to enum mapping. For that we could have a call fill a dict with key==name and value == enum at gs_init time. | 14:57.33 |
| kens | I haven't looked at the spec_ops yet. | 14:58.09 |
| ray_laptop | kens: if we have spec_op, from PS, then we don't need 'get_single_param'. | 14:58.17 |
| kens | I'm in the middle of outline processing at the moment | 14:58.22 |
| sebras | Robin_Watts_: yo? | 14:58.40 |
| ray_laptop | kens: OK. Have fun | 14:58.46 |
| kens | Yeah, its 'complicated'.... | 14:58.56 |
| Robin_Watts_ | kens, ray_laptop: I would not be in favour of a generic exposure of dev_spec_op into postscript. | 14:58.59 |
| ray_laptop | Robin_Watts_: why not ? | 14:59.18 |
| Robin_Watts_ | Exposing single dev_spec_op's via individual new custom operators is fine. | 14:59.21 |
| kens | Robin_Watts_ : that wasn't exactly my intention, but I'm not really in a position to talk about ti at the moment | 14:59.23 |
| Robin_Watts_ | but a generic call would be bad, IMHO. | 14:59.38 |
| ray_laptop | Robin_Watts_: WHY ? | 14:59.50 |
| ray_laptop | prefers general solutions | 15:00.03 |
| Robin_Watts_ | ray_laptop: the values used for a dev_spec_op are subject to compile time change. | 15:00.24 |
| ray_laptop | Robin_Watts_: do you mean the spec_op enum that it is invoked with ? | 15:00.49 |
| Robin_Watts_ | and not all dev_spec_op's will be suitable for calling from postscript. | 15:00.57 |
| | some dev_spec_op's fiddle with pointers they are passed. | 15:01.13 |
| ray_laptop | Robin_Watts_: I agree that not all may not be suitable | 15:01.23 |
| Robin_Watts_ | Right. So exposing single ones (or possibly a subset) is fine, but a generic 'call any dev spec op you like' method is bad. | 15:01.55 |
| kens | My current thinking is that a PS operator woudl do a 'getsingledevparam' which would result in a dev_spec_op. THat would return (in *data) a param_ object (param_book, string, etc) which the PostScript interpreter woudl turn into a PostScript object and stick on the stack. | 15:01.56 |
| | s/book/bool/ | 15:02.16 |
| | But I need ot try that and see how slow it is | 15:02.40 |
| ray_laptop | Robin_Watts_: it's easy enough to restrict operators from PS -- if they aren't enumerated in the dict of enums, they will be "invisible" | 15:02.45 |
| Robin_Watts_ | kens: Not sure why you need to mix param objects and dev_spec_ops? | 15:02.54 |
| | sebras: yo yo yo! | 15:03.14 |
| ray_laptop | kens: all you are looking for is bools | 15:03.31 |
| kens | Robin_Watts_ : because the devices already have code to deal with params, and I think it would be easier to reuse it. Also some parmeters may return comoiund objects | 15:03.31 |
| | ray_laptop : at the moment, yes | 15:03.39 |
| | But I'd prefer not to restrict this | 15:03.50 |
| ray_laptop | kens: the code to deal with params is all designed for get_params to return ALL the params in a plist. That is where the performance hit is coming from | 15:04.15 |
| Robin_Watts_ | I'd do bools as bools, and only introduce more complex stuff when it's required. | 15:04.16 |
| | IMHO, but then this is your baby, so... | 15:04.31 |
| kens | ray_laptop : yes, but I can reuse the bits that turn parameters into param objects, or whatever. If I can't then I'll find out fast enough when I look into this in detail | 15:04.53 |
| | I can immediately forsee a likely requirement for integers, reals and strings. arrays and dicts are the hard ones | 15:05.31 |
| ray_laptop | kens: just collecting the bools you need is simple enough. I'm not sure why you want "objects" | 15:05.41 |
| kens2 | network hiccup :( | 15:07.11 |
| ray_laptop | kens: not sure about the 'requirement' for other objects | 15:09.13 |
| kens2 | ray_laptop : there is currently no 'requirement', I'm thinking to the future | 15:09.30 |
| kens2 | is aware this is contrary to historical precedent.... | 15:09.43 |
| ray_laptop | kens: I have no objection to a general solution, but each element that is to be collected as a 'singleparam' means that the device has to implement the spec_op -- which is NOT implemented for most devices. | 15:11.08 |
| sebras | Robin_Watts_: we discussed looking into clusterpush at some point. | 15:11.32 |
| | Robin_Watts_: is now a good time? | 15:11.38 |
| ray_laptop | so the call will, in general, fail (return null or whatever the "can't do this result is) | 15:11.39 |
| Robin_Watts_ | sebras: Sure. | 15:11.42 |
| kens2 | ray_laptop : to date the only devices which implement the parameters we care about are the high level ones | 15:11.43 |
| sebras | Robin_Watts_: I don't have any cool patches waiting though. | 15:11.57 |
| kens2 | and yes, the 'null' return (or boolean flase, whatever) will be the general case | 15:12.01 |
| Robin_Watts_ | sebras: No worries. So are you working from windows, or from unix ? | 15:12.26 |
| sebras | Robin_Watts_: unix. should we go PM to not pollute ray/kens disussion? | 15:12.47 |
| Robin_Watts_ | ok. | 15:12.52 |
| kens2 | THe spec ops are already implemented for the high level devices, if it turns out we need this for other devices then we can either add teh spec ops to those devices, or just live with slowly collecting all the parameters | 15:12.56 |
| ray_laptop | sebras: that's OK -- I'm used to interleave :-) | 15:13.15 |
| kens2 | Me too | 15:13.20 |
| | we do this all the time on Tuesday meetings | 15:13.29 |
| | Its only when I'm trying to participate in mutliepl threads that I get confused | 15:13.42 |
| sebras | ok, still, bettero to go PM. :) | 15:14.09 |
| mvrhel_laptop | morning | 15:14.09 |
| | brb | 15:14.10 |
| ray_laptop | kens2: yeah, or when there are others chiming in -- I get the prefix wrong | 15:14.17 |
| | morning, mvrhel_laptop | 15:14.25 |
| | having PS be able to call spec_op (or at least a 'safe' subset, allowing for Robin_Watts point) seems more general | 15:16.06 |
| | kens2: ^ | 15:16.13 |
| kens2 | ray_laptop : at the moment I'm with robin on calling spec_ops generally, I'd prefer to see a single operator for each 'op' | 15:16.47 |
| Robin_Watts_ | Given that dev_spec_op's are by their nature all specific, I would rather see them exposed into postscript as specific cases. | 15:17.45 |
| ray_laptop | kens2: well, it does prevent 'mischief' better -- a PS passing an integer that is used as the enum allows PS to invoke arbitrary spec_ops. But if the PS invoked by name/string then the C code could restrict which were allowed | 15:18.49 |
| | Robin_Watts_: just pollutes the PS systemdict more is all. Not sure what the performance hit on that is | 15:19.40 |
| kens2 | I guess I could implement it as a name passing operator | 15:19.51 |
| | ray_laptop : how pollued is the systemdict already ? :-/ | 15:20.10 |
| ray_laptop | kens2: A *LOT* -- I guess 'bind' takes care of most of it | 15:20.40 |
| | I hope | 15:20.45 |
| kens2 | wIt doesn't 'seem' to be a problem at the moment.... | 15:21.00 |
| ray_laptop | kens2: I like that contraction "wlt" for "well it" :-) | 15:22.15 |
| kens2 | extra w... | 15:22.24 |
| | was meant o be just 'it' | 15:22.32 |
| | but that works too | 15:22.45 |
| ray_laptop | the font I used has l and I the same :-( | 15:23.22 |
| kens2 | I hate that.... | 15:23.36 |
| ray_laptop | kens2: yeah but my only other choice is 'serif' and that's hard to read | 15:24.44 |
| kens2 | :-( | 15:24.55 |
| Robin_Watts_ | ray_laptop: Having a .myspecialop pollutes the systemdict? | 15:24.59 |
| kens2 | Robin_Watts_ : I think ray felt one operator per special op would | 15:25.18 |
| | But using one operator, and a name to select *which* operator would seem logical | 15:25.39 |
| ray_laptop | Robin_Watts_: no, I meant having ".getPreserveTRMode" and ".getWantsToUnicode" and, ... | 15:25.39 |
| Robin_Watts_ | I didn't realise that all the inbuilt ops were in the systemdict. | 15:25.49 |
| kens2 | ray_laptop : I wasn't going to do that, I was going to pass the key as a parameter | 15:26.01 |
| ray_laptop | kens2: So .getSpecialParam or something ? | 15:26.26 |
| kens2 | My suggestion was getsingledeviceparam, but any name is OK | 15:26.48 |
| ray_laptop | kens2: I'm not in favor of confusing it with getdeviceparams if it only works through the spec_op mechanism | 15:27.33 |
| kens2 | Putting both suggestions together we could have "/PreservTrMode /GetSingleDeviceParam .devspecop" | 15:27.34 |
| | Then if we wanted other 'spec ops' exposed we would add keys for those | 15:28.17 |
| Robin_Watts_ | given the speed (or lack of it) in the PS interpreter, avoiding unnecessary args/arg decoding seems smarter to me. | 15:28.28 |
| kens2 | We have to pass the arg somehow | 15:28.43 |
| Robin_Watts_ | Hence I'm still lobbying for .getPreserveTRMode | 15:28.48 |
| ray_laptop | kens2: well, true. In the spirit of "true compromise", nobody is perfectly happy :-) | 15:28.52 |
| kens2 | Robin_Watts_ : I'm with ray on not having one operator for each parameter, we have 5 or so already, maybe more | 15:29.14 |
| ray_laptop | Robin_Watts_: the problem wasn't the speed of the interp. It was the speed of zgetdeviceparams itself (the C code) | 15:29.39 |
| Robin_Watts_ | ray_laptop: But in general, we're up against speed limitations in the interpreter. | 15:30.17 |
| kens2 | Robin_Watts_ : but that's not the case with this particular problem | 15:30.33 |
| ray_laptop | Robin_Watts_: that isn't as much of an issue. | 15:30.38 |
| | pushing a name onto the opstack is really fast | 15:31.25 |
| kens2 | I'd be happy with a single operator to select 'spec ops' and a name object to specify which one we wanted | 15:31.57 |
| ray_laptop | now if we only had a PDF interpreter in C ... | 15:31.59 |
| kens2 | ray_laptop : give us time.... | 15:32.08 |
| | OK so given that nobody is going to be 100% happy.... Do we prefer | 15:36.22 |
| | 1) .getparamter1 .getparamter2 .getparamater3..... | 15:36.22 |
| | 2) /Name .get_param_spec_op, /name .some_other_spec_op... | 15:36.22 |
| | 3) /Name /GetDevice .specop | 15:36.22 |
| | Personalyy I prefer 3 | 15:36.44 |
| ray_laptop | kens2: the general case of (3) is <data> <spec_op_name> .specop This corresponds to the C code: (dev, op, data, data_size). PS gets the data_size from the ref, and the 'currentdevice' is from the pgd | 15:39.00 |
| | s/pgd/pgs/ | 15:39.08 |
| kens2 | Yes, you put it better than me, but that's the case | 15:39.55 |
| ray_laptop | kens2: I'm not sure why there is so many places in the PS code where we have to pass in the 'currentdevice' since there really aren't devices exposed or used much by PS | 15:40.13 |
| kens2 | ray_laptop : well it seemed to be required at the time | 15:40.29 |
| | or do you mean other than the getdeviceparams ? | 15:40.58 |
| ray_laptop | kens2: lost in the murkiness of GS history. Peter probably remembers | 15:40.59 |
| kens2 | Hmm, well I guess, I certainly don;t know. | 15:41.13 |
| ray_laptop | kens2: well, yes -- why do we always need to pass currentdevice to getdeviceparams | 15:41.33 |
| kens2 | To be honest, I've only really been looking at the PostScript interpreter code for a relatively short while. | 15:41.42 |
| | ray_laptop : Off the top of my head I don;t know, but I think getdeviceparams takes the device as an argument | 15:42.11 |
| | presumably so that you can interrogate devices other than the current one | 15:42.23 |
| kens2 | is at a loss to think of a reason why you would want to, but.... | 15:42.41 |
| ray_laptop | PLRM doesn't even have a 'currentdevice' so it is a GS specific one | 15:44.18 |
| kens2 | O.O | 15:44.25 |
| ray_laptop | ooh. that's a cool looking smiley | 15:44.52 |
| kens2 | supposed to be buig eyes | 15:45.08 |
| ray_laptop | kens2: yeah -- that's what it looks like :-) | 15:45.22 |
| kens2 | :-) | 15:45.46 |
| ray_laptop | If that works in text on my kid's phones, I'm going to use it :-) | 15:46.13 |
| kens2 | Actually I htink I remember that currentdevice is GS-specific, it surprised me last time too | 15:46.15 |
| | Also o.O | 15:46.36 |
| ray_laptop | kens2: yeah. There is a PS 'currentpagedevice' but that's more than just the device object | 15:47.01 |
| kens2 | Ah, interesting | 15:47.09 |
| ray_laptop | and PLRM doesn't even have a 'device' object | 15:47.55 |
| kens2 | I guess that's not surprising | 15:48.06 |
| ray_laptop | kens2: It was probably there to allow for .getdevparams to be used with IODevice (to implement "currentdevparams" which IS PLRM standard) | 15:56.12 |
| kens2 | Hmm could be, its all a bit convoluted | 15:56.42 |
| | Anyway, back to pounding head against named destinations, I fear this is going to linger into tomorrow | 15:58.38 |
| ray_laptop | kens2: anyway, I'm happy with the more general approach 3. The only question is whether it should be /SpecOpName <data> .devspecop or <data> /SpecOpName .devspecop | 15:59.41 |
| | kens2: and I'll leave that up to you. | 16:00.01 |
| kens2 | I'd prefer the specopname comelast, because there could be variable numbers of parameters | 16:00.11 |
| ray_laptop | kens2: thanks for the discussion. | 16:00.22 |
| kens2 | No thanks for the thoughts, now all I have to do is code it :-) | 16:00.38 |
| | Which might take a little longer..... | 16:00.49 |
| | OK that's enough for a technical holiday, goodnight all | 16:15.04 |
| sebras | Robin_Watts_: typo fixed. | 17:30.08 |
| Robin_Watts_ | mucbz.c too ? | 17:32.09 |
| | Looks like you only fixed the one. | 17:34.55 |
| sebras | Robin_Watts_: oh. | 18:24.41 |
| | Robin_Watts_: fixed. | 18:25.44 |
| Robin_Watts_ | sebras: Looks good to me. | 18:45.48 |
| sebras | Robin_Watts_: how many times are you supposed to run you interface call if we thorw FZ_ERROR_TRYLATER? | 22:01.49 |
| | Robin_Watts_: tor8: http://pastebin.com/wCgMpJmF + my new patch over at sebras/master | 22:51.09 |
| | basically they solve the case where you enter mupdf-x11-curl 'http://' which is a bogus case, but we entered an eternal loop because we never checked error codes from curl. | 22:51.50 |
| | when setting curl options curl may also run out of memory, but we never check that. now that means that strdup() must return NULL, which probably means that malloc() must return NULL, which is or isn't a case we ought to take into account? | 22:53.24 |
| | also I'm a bit confused. pdfapp_open_progressive() seems to open app->stream, but if it fails fz_catch() will just rethrow and then we end up in pdfapp_error() without closing the stream. is this correct? valgrind detects this as a leak. | 22:54.38 |
| Robin_Watts_ | sebras: In theory as many as you like. | 23:33.59 |
| | You're expected to have some cunning code watch data arrive so that you don't rerun until more data has arrived than was there before. | 23:34.30 |
| | But I could easily have screwed up. | 23:34.37 |
| | Forward 1 day (to 2014/04/22)>>> | |
IRC Logs