| | <<<Back 1 day (to 2011/10/03) | 2011/10/04 |
| chrisl | kens: does Acrobat refer to annotations as "Comments", do you know? | 07:02.25 |
| kens | No idea, is there some context ? | 07:02.57 |
| chrisl | I've been taking a quick look at Bug 689450, and it seems that the annotations are defined by forms whose resources are broken, but Acrobat doesn't seem to notice - even if I change the forms. | 07:04.36 |
| kens | Hmm, I'll read the thread. | 07:04.51 |
| | OK< so it probably is referring to these annotations as comments. I'm not sure that Adobe used the 'annotation' word in marketing. | 07:06.07 |
| chrisl | I'm suspicious that Acrobat is just ignoring the broken annotations. | 07:06.48 |
| kens | It may well be, it does that sort of thing a lot. | 07:07.08 |
| | If the forms are the appearance stream, it may also geenerate its own appearance instead. | 07:07.25 |
| chrisl | Ah, the forms are AcroForms and rendered separately to the annotations, but with the same content streams...... | 07:08.08 |
| kens | Yes, looks that way. | 07:08.59 |
| | Icky but legal | 07:09.04 |
| chrisl | Well, not legal because the font resource is broken! | 07:09.42 |
| kens | Yes, I meant reusing the content stream was legal, but the font resource is wrong. | 07:10.00 |
| | I would suggest that Acrobat is ignoring the broken stream. The only way to tell would be to point the form at a different stream and see if it changes. | 07:11.14 |
| chrisl | So, removing the AcroForm causes the display in Acrobat to change (content disappears), removing the annotations has no effect. | 07:11.36 |
| kens | NB, if I close the PDF file from Acrobat it asks to 'save changes ?', a sure sign the file is broken | 07:11.50 |
| | I'm inclined to try it and see what Acrobat saves. | 07:12.07 |
| chrisl | I checked that yesterday, but I can't remember what the result was! | 07:13.34 |
| kens | It re-orders a lot of dictionaries, rewrites the xref and inserts a big block of appearnce streams. | 07:14.07 |
| chrisl | And repairs the broken "/Helv /" to be "/Helv 921 0 R" | 07:15.26 |
| kens | So many diffs it would take some analysis to work out exactly what its doing, but it looks like it might be creating new duplicate streams | 07:15.31 |
| chrisl | I feel that this is a demonstrably broken file (despite what Acrobat Pre-Sh*te claims!) and we, at most, could just issue a warning, and use a fallback font - as a "it's broken, but we'll do our best" measure. I don't see why we have to try to mimic Acrobat in these cases. | 07:17.41 |
| kens | I'm inclined to agree. The pre-flight is meaningless (and hasn't been updated for years), the fact that Acrobat wants to save teh changes indicates the file is broken. | 07:18.33 |
| chrisl | There *is* an issue which is that we don't seem to correctly handle inherited resources for AcroForm content streams - we don't seem to follow the ParentField, only Parent entry. | 07:19.57 |
| kens | Seems like one for Alex, maybe that was what his comment in the thread was about | 07:20.23 |
| chrisl | Yeh, but the broken resource dictionary, I think, is a red herring - I don't think Acrobat is actually using it. | 07:21.18 |
| kens | Quite possibly not. Would make it easier if we can ignore it too :-) | 07:21.44 |
| Robin_Watts | Wow. Not quite e-ink... http://www.sciencefriday.com/videos/watch/10397 | 09:16.44 |
| kens | chromatophores are good things. | 09:35.51 |
| | OK another fix for pdfwrite and text rendering, lets see how many diffs this one fixes..... | 09:38.55 |
| | BTW there seem to be some long-standing issues coming out with this stuff where pdfwrite is using the wrong colour. I expect I'll have to fix those too. | 09:40.53 |
| Robin_Watts | tor8: I have a new idea about fz_var | 11:34.55 |
| | We have a global void *volatile fz_trickery; | 11:35.32 |
| | and #define fz_var(VAR) fz_trickery = (void *)&(VAR) | 11:35.58 |
| | No warnings, minimal overhead. | 11:36.19 |
| Nitesh | #exit | 11:53.44 |
| kens | #bye ;-) | 11:54.00 |
| Robin_Watts | I think he meant #kevorkian | 11:54.11 |
| kens | Ah, exit with extreme prejudice | 11:54.29 |
| Robin_Watts | discovers that if you highlight a section in VS and hit TAB, it indents it all. | 11:56.04 |
| kens | Interesting.... | 11:58.11 |
| | I have a place I can try that. | 11:58.18 |
| | OK, lets see if *this* fix avoids breaking 99% of all files..... | 12:15.42 |
| Robin_Watts | I fear this commit will touch 90%+ of mupdfs source. | 12:29.10 |
| kens | OK so that solved the bug, didn't introduce a failure in all regression files with text, and had an unexpected progression in QL CET file. So a plus.... | 13:18.16 |
| | On to the next category of failures :-( | 13:18.41 |
| tor8 | Robin_Watts: volatile rules make me confused | 13:19.37 |
| Robin_Watts | tor8: Taking the address of a variable and passing it out of scope (i.e. into a global variable) means that the code cannot assume that the value will remain unchanged between uses (certainly uses over function calls). | 13:43.14 |
| | So it always gets flushed back to memory. | 13:43.33 |
| | which is precisely what we want. | 13:43.42 |
| tor8 | right. so no need for a volatile on the fz_trickery global then? | 13:43.50 |
| | wonder what the optimizer will do if you have multiple fz_var statements though | 13:44.17 |
| Robin_Watts | The volatile is there to avoid it changing: fz_var(fred); fz_var(george); into just fz_var(george); | 13:44.18 |
| tor8 | right | 13:44.35 |
| Robin_Watts | The volatile is there precisely to stop the optimiser ;) | 13:44.38 |
| tor8 | Robin_Watts: I don't get volatile typecast warnings for regular pointers | 13:48.19 |
| | ie passing a "fz_obj * volatile p" to a function doesn't give me any warnings with gcc | 13:48.44 |
| Robin_Watts | The case I see it is if I have: fz_obj * volatile obj; | 13:48.50 |
| | and then pass that as a fz_obj **. This is msvc. | 13:49.03 |
| tor8 | only when I start messing with pointers to pointers | 13:49.05 |
| | Robin_Watts: do you mean passing &obj? | 13:53.11 |
| Robin_Watts | yes. | 13:53.16 |
| tor8 | yeah, that's a valid warning | 13:53.21 |
| | I don't see where we need to do that stuff though... | 13:53.30 |
| Robin_Watts | There are a couple of places at least. | 13:53.46 |
| tor8 | we should rewrite the few places where we do return pointers through the first argument to return the pointer | 13:53.54 |
| Robin_Watts | I am doing that at the moment | 13:54.05 |
| tor8 | they're only **pointers because we need to return errors | 13:54.13 |
| Robin_Watts | indeed. | 13:54.19 |
| | tor8: Mupdf style... If we have an if with only one line, you're happy to drop the { } ? | 14:08.57 |
| tor8 | yes | 14:09.13 |
| | unless it's followed by an else that needs {}, in which case I like the balance of both blocks being braced | 14:09.40 |
| Robin_Watts | I think I'm with you on that. | 14:09.58 |
| tor8 | but in general, braces are one of the few things where I don't actually have a strong opinion :) | 14:10.22 |
| | I'm perfectly happy with both the Allman (current mupdf style) and K&R styles | 14:10.39 |
| Robin_Watts | I'm sure that GNU style is wrong, but otherwise I'm easy. | 14:11.18 |
| | With MSVC I get warning C4090: 'function' : different 'volatile' qualifiers | 14:15.45 |
| | when passing a fz_shade *volatile shade as an fz_shade * | 14:16.15 |
| henrys | watches the mercury rise in chicago - I can't seem to find a cool marathon lately with the global warming - maybe alaska. | 14:57.10 |
| Robin_Watts | pictures henrys doing the iditerod... | 14:57.43 |
| henrys | worse sabrina geared up with new fall fashions for chicago so now I'm going to be hot and broke. | 15:01.01 |
| Robin_Watts | When is the Chicago marathon? 10th ? | 15:03.31 |
| ray_laptop | why not have mupdf follow the same gnuindent style as the rest of the code ? | 15:03.47 |
| henrys | the 9th | 15:03.58 |
| Robin_Watts | ray_laptop: Cos then tor8 wouldn't be able to use tabs. | 15:04.25 |
| ray_laptop | I thought tor8 was one of the ones arguing for spaces only ? | 15:04.48 |
| ray_laptop | was in favor of tabs | 15:05.09 |
| tor8 | I only argue against mixing tabs and spaces. given a choice, I pick tabs only. | 15:05.31 |
| ray_laptop | tor8: so you don't have the indents at 4 spaces ? | 15:06.18 |
| tor8 | I have indents at tab stops. no alignment of non-indentation text. | 15:06.43 |
| | let me rephrase: I indent with tabs, and don't line anything else up. | 15:07.13 |
| ray_laptop | I have to take the kids to school in a few minutes -- I'll be back online at about 8:45 (in about 35 minutes)... | 15:09.59 |
| henrys | Yesterday I had periodic networking problems, the cable modem was unplugged and operating on battery power, I didn't notice it for quite some time. I guess the battery operation is not good enough to keep the device running properly, the lights seemed bright and not dimmed. | 15:14.00 |
| Robin_Watts | henrys: Your cable modem has a battery in it? Or it's on a UPS ? | 15:14.48 |
| henrys | it has a battery | 15:15.01 |
| ray_laptop | I'd need UPS so that my wi-fi router would be live as well -- when we were without power at home for the whole day I thought about it (barn door after horse gone) | 15:41.56 |
| | I was hoping mvrhel would be here today -- it looks like the pdf14 device can't handle the screwy cups RGBW colorspace, but I thought he had that working :-/ | 15:56.40 |
| Robin_Watts | Isn't it 5am or so where he is at the moment? | 15:57.10 |
| ray_laptop | Robin_Watts: 6am -- but he emailed that he wouldn't be available at all today | 15:57.42 |
| Robin_Watts | ah. | 15:57.58 |
| henrys | is Till using the no-banding workaround for that? | 15:58.03 |
| | wait if it works with non banding is this specific to the pdf14 clist contraption? | 15:59.14 |
| | meeting time | 16:00.02 |
| ray_laptop | henrys: we discussed that yesterday -- for 600 dpi he needs -dMaxBitmap=700000000 | 16:00.13 |
| henrys | I've got nothin' | 16:00.14 |
| ray_laptop | I'm thinking that RGBW is really just inverted CMYK and that pdf14 should treat it as such | 16:01.03 |
| henrys | yeah that's too big I guess. but it must be something with the pdf14 clist stuff right? Maybe michael only fixed the non clist code? | 16:01.23 |
| ray_laptop | i.e., fudge the color space to CMYK but encoded backwards | 16:01.29 |
| henrys | anybody have anything for the meeting? | 16:02.06 |
| kens | Not really, still working on the text rendering modes | 16:02.19 |
| Robin_Watts | don't think so. | 16:02.33 |
| chrisl | I commented on Bug 689450, I'd be interested if anyone (esp Alex) has any other opinions...... | 16:02.44 |
| alexcher | henrys: There was a bug that happens only on Sparc. Where can we get it? | 16:03.13 |
| ray_laptop | chrisl: I agree that we don't have to emulate the way Acrobat handles missing info in PDF's as long as we make a reasonable guess | 16:03.28 |
| | chrisl: and emit a "*** Warning ..." complaint | 16:04.10 |
| henrys | alexcher:I don't know where to get a sparc - are you sure it ins not a big endian bug? | 16:04.16 |
| alexcher | chrisl: i'll check the patch. | 16:04.23 |
| chrisl | ray_laptop: the patch does cause a warning to be printed. | 16:04.34 |
| | alexcher: thanks. | 16:04.37 |
| alexcher | henrys: I've tried ppc32. It was OK. | 16:04.51 |
| ray_laptop | chrisl: right. | 16:04.52 |
| henrys | alexcher which bug | 16:05.04 |
| | ? | 16:05.06 |
| ray_laptop | are they still making SPARC chips ? | 16:05.32 |
| henrys | marcosw_:miles (the machine) seems to be down regularly. | 16:05.37 |
| chrisl | alexcher: If you want to throw the Sparc bug at me, I've got a couple of Sparc machines here - but they're not easy to make available to the outside world | 16:05.42 |
| alexcher | henrys: bug 692550 | 16:06.00 |
| chrisl | ray_laptop: they just launched a brand-spanking new uber-sparc | 16:06.02 |
| marcosw_ | I know, I ran it in my house for 10 days and it ran fine. Miles took it to the office, it ran for a couple of hours before crashing. | 16:06.05 |
| ray_laptop | marcosw_: BTW, did you ever notify Raed about "Handle leak" fix ? | 16:06.20 |
| | marcosw_: if you did I missed it in the flood of 'CLOSED' emails you did | 16:06.50 |
| marcosw_ | ray_laptop: I've been going through the resolved but not closed bugs in reverse order, I don't think I've done that one one yet. | 16:06.56 |
| henrys | marcosw_:also pcl customers need notifications. | 16:07.37 |
| ray_laptop | marcosw_: it's relatively recent so if you are doing reverse order it should have been done | 16:07.40 |
| marcosw_ | henrys: there only appears to be one pcl bug that is resolved: 692311, this seems odd, perhaps is my query broken... | 16:09.10 |
| ray_laptop | marcosw_: bug 692372 | 16:09.14 |
| henrys | marcosw_:right and I assigned another back to you because I couldn't reproduce it on the 4700 I was hoping that would be pushed back. | 16:10.19 |
| alexcher | marcosw_: Let's move the miles box to my basement. I can restart every day if needed. | 16:10.34 |
| marcosw_ | alexcher: presumably you won't have to restart it if it's in your basement. it works fine when it's not in Miles' office :-) | 16:11.18 |
| Robin_Watts | wonders if it's 'environmental factors'. | 16:11.35 |
| kens | its down right now | 16:11.42 |
| marcosw_ | it's been down for 5 days. | 16:12.00 |
| Robin_Watts | There is a (possibly apocryphal) story about how hospital administrators noticed that you were much more likely to die in the ICU if you were in the bed by the door. | 16:12.20 |
| henrys | alexcher:the sparc issue looks to be near mvrhel2's new halftoning code. Perhaps sse2 is being enabled. Can you request the config.log and a debug build with a backtrace would also be useful. | 16:12.23 |
| ray_laptop | marcosw_: I see 70 customer bugs still in the 'RESOLVED' state (63 are RESOLVED FIXED -- the others are INVALID or WORKSFORME or WONTFIX) | 16:12.24 |
| alexcher | henrys: OK | 16:12.59 |
| marcosw_ | ray_laptop: your count is correct, I'm going through the bugs in reverse order. I think I did 10 or 15 over the weekend. | 16:13.00 |
| Robin_Watts | They searched for ages for a reason, and eventually found that every day the cleaner would arrive, unplug a machine to plug in the hoover, clean, then replug the machine and leave... | 16:13.12 |
| kens | Robin_Watts : heard that one abot mainframes 2 decades ago | 16:13.39 |
| marcosw_ | Always mount a spare monkey. | 16:13.42 |
| Robin_Watts | tor8: How would you feel about us making destructors always able to accept NULL? | 16:14.31 |
| | For instance fz_drop_obj(NULL) should do nothing rather than asserting. | 16:14.48 |
| | Makes cleanup code much simpler. | 16:15.12 |
| henrys | joanne is vacuuming - damn. | 16:15.14 |
| ray_laptop | that corresponds to gs_free_object accepting NULL pointers. I don't think it's ever caused any problems or confusion | 16:15.28 |
| Robin_Watts | Indeed, free accepts NULL. As does realloc. | 16:15.50 |
| | marcosw_: Does miles' motherboard support any of that voltage measuring stuff ? | 16:17.27 |
| marcosw_ | Robin_Watts: probably, it's a high-end ASUS motherboard. | 16:18.05 |
| Robin_Watts | might it be that there are voltage issues etc in Miles office? | 16:18.32 |
| | http://openhardwaremonitor.org/ ? | 16:19.45 |
| henrys | miles and kilometers are twins right? why would only one machine be effected? Are they on different circuits? | 16:19.49 |
| kens | Are we done with teh meeting today ? | 16:20.55 |
| henrys | I was done, yes. | 16:21.35 |
| marcosw_ | the same computer ran reliably for 9 months or so in Miles' office. It failed and I went and rebooted it and it come up fine but crashed after a few hours. I took it home and it ran fine for over a week, Miles took it back to his office plugged it in and it crashed after a less than 6 hours. | 16:21.44 |
| kens | Then I will make myself scarce. Goodnight everyone. | 16:22.04 |
| henrys | bye kens | 16:22.12 |
| | tor8:how's ios stuff coming? | 16:22.40 |
| marcosw_ | so a power issue may be it. I guess I'll swap the power supply out and see if that helps; I have a spare one and in any case they are cheap. If only Miles' office weren't 1.5 hours away from my house. | 16:24.24 |
| Robin_Watts | marcosw_: I was thinking that it might be the particular socket in miles' office. | 16:24.49 |
| | Leaving the openhardwaremonitor running on both miles and kilometers and comparing the min/max values might be worthwhile. | 16:25.23 |
| | Can be done remotely. | 16:25.26 |
| | But it might point to PSU problems too. | 16:25.38 |
| marcosw_ | all three machines are running from one power strip. | 16:25.56 |
| | I have to run. I'll be back later tonight. | 16:26.10 |
| Robin_Watts | tor8: Did you get back to company K about text extraction? | 16:28.35 |
| ray_laptop | why the heck is there so much DEBUG2 junk from cups ??? | 16:45.57 |
| | does this happen with debug builds on linux, or is it just linux ? | 16:46.37 |
| chrisl | ray_laptop: the cups debug crap is the same everywhere - I find it a pain...... | 16:47.45 |
| ray_laptop | chrisl: well, we "own" it, so I'm going to fix it. | 16:48.19 |
| chrisl | ray_laptop: Till specifically asked me not to change that a while back. | 16:49.09 |
| Robin_Watts | chrisl: It's unreasonable in it's current state,IMHO. | 16:49.36 |
| ray_laptop | chrisl: I wasn't going to rip it out. Just make it dependent on defined(CUPS_DEBUG2) | 16:50.13 |
| chrisl | Robin_Watts: well, I agree, but at the time, we were trying to avoid taking (full) responsibility for the cups device. | 16:50.58 |
| ray_laptop | tkamppeter: we are going to change it unless you can give us a good reason why not | 16:51.03 |
| | chrisl: yeah, look how well that worked | 16:51.19 |
| chrisl | ray_laptop: I know..... :-( | 16:51.35 |
| ray_laptop | chrisl: tkamppeter has now been amply warned. A consensus of the rest of us hating that noise is enough justification | 16:52.24 |
| chrisl | ray_laptop: cool, have at it! | 16:53.03 |
| | I must admit, I can't remember *why* tkamppeter asked me not to change it - it was some time ago | 16:53.49 |
| ray_laptop | chrisl: I searched the entire cups tree and all of the noise comes from gdevcups.c: find cups -type f -exec grep -l DEBUG2 "{}" \; 2> /dev/null | 16:53.50 |
| | so it's not like it will be hard for tkamppeter or anyboday else to just through in a #define CUPS_DEBUG2 at the top of the file | 16:54.28 |
| chrisl | ray_laptop: yes, the irritation was all in the device - I'd be very happy to see it changed..... | 16:54.46 |
| ray_laptop | s/through/throw/ | 16:54.59 |
| henrys | isn't there a debug letter we can make them all dependent on with if_debug... is 's' (shit) reserved? | 16:55.58 |
| | seriously, we are out of debug letters, need a better scheme. | 17:01.12 |
| Robin_Watts | henrys: We have a 256 wide array of debug flags, right? | 17:02.01 |
| | We could use a larger one, and enable it using -x1ff or something. | 17:02.56 |
| henrys | it is declared char 128 | 17:03.31 |
| Robin_Watts | Oh, OK. so we can make it 256 with no problems, and then just add a new command line thing for setting one of the top bitset ones. | 17:04.03 |
| | -ZL and -zL could set bottom and top bit set ones for example ? | 17:04.26 |
| henrys | I was thinking of something more radical like going to strings instead of characters. | 17:05.23 |
| | but that looks like a lot of work. | 17:06.03 |
| Robin_Watts | Right, but that's more radical :) | 17:06.06 |
| henrys | but it would be mechanical - change ' to " in the if debug statement the compiler will find them all. and then change the gs_debug_c code. | 17:07.30 |
| tor8 | Robin_Watts: yes, I think destructors being able to accept null makes sense for easier clean-up | 17:08.06 |
| | Robin_Watts: yes, I sent an email to company K | 17:08.35 |
| henrys | anyway not very important relatively, back to pcl. | 17:08.37 |
| tor8 | henrys: having hissy fits with Xcode and reading up on iOS development | 17:09.06 |
| ray_laptop | henrys: changing the command line to accept things like --debug_alloc_fill wouldn't be hard (it could still set gs_debug[] elements and the array could be any size) | 17:11.29 |
| Robin_Watts | ray_laptop: That would be nicer, yes. | 17:12.59 |
| | There would presumably be a table internally that mapped from 'alloc_fill' to 'x' (or whatever) | 17:13.28 |
| ray_laptop | that way existing code doesn't need to change | 17:13.29 |
| | Robin_Watts: right | 17:13.37 |
| Robin_Watts | I don't think I like henrys idea of changing from 'x' to "alloc_fill" in the code though. | 17:14.03 |
| ray_laptop | Robin_Watts: the hard part would be for us to come up with long debug flag names that we all agree on ;-) | 17:14.12 |
| | Robin_Watts: no, just keeping the existing ['@'] is fine | 17:14.36 |
| Robin_Watts | string comparisons are much heavier at runtime. | 17:14.38 |
| henrys | good point | 17:14.54 |
| Robin_Watts | ray_laptop: Right, but that's not what henrys was suggesting, as I understood it. | 17:14.55 |
| ray_laptop | Robin_Watts: but if we wanted to use #define alloc_fill '@' that would be OK | 17:15.15 |
| Robin_Watts | ray_laptop: I'd rather see an enum of flags in the headerfile. | 17:15.46 |
| ray_laptop | then for new flags it would be #define cups_debug_noise 129 | 17:16.00 |
| Robin_Watts | enum { gs_debug_alloc_fill = 0, gs_debug_alloc_free ... } gs_debug_flags; | 17:16.15 |
| | Using #defines when we could use enums would be bad. | 17:16.38 |
| | #defines are fundamentally nastier things. | 17:16.58 |
| ray_laptop | Robin_Watts: that would mean touching all of the code that has single character constants e.g. '@' | 17:17.12 |
| Robin_Watts | Also, it would be much better to avoid polluting the namespace by giving them all a sane prefix. gs_debug_whatever. | 17:17.41 |
| | ray_laptop: No, not at all. | 17:17.48 |
| | We can arrange for the enum values to match the single char constants. | 17:18.12 |
| | so no code needs to change. | 17:18.18 |
| ray_laptop | I was looking for a way that wouldn't REQUIRE touching everything, but you are right, we can mix enum and constants as the array inde | 17:18.32 |
| Robin_Watts | but NEW code should written using the enum names for clarity. | 17:18.33 |
| ray_laptop | x | 17:18.33 |
| | Robin_Watts: so I agree enum is OK (not sure why #define is "nasty", but that's OK) | 17:19.54 |
| Robin_Watts | #defines are source code transformations. | 17:20.14 |
| | They are a hugely powerful tool, but they are 'outside' the language, and bring their own set of pitfalls. | 17:20.34 |
| ray_laptop | so who wants to develop a list on long names for the debug flags ??? | 17:20.48 |
| | s/on/of/ | 17:21.05 |
| henrys | nobody use '{' for cups. | 17:21.14 |
| Robin_Watts | If we have such a list, it would be nice to be able to say: "gs --help-debug" and get a list of all the flags and what they do. | 17:21.15 |
| | (which shouldn't be hard). | 17:21.36 |
| ray_laptop | Robin_Watts: that would be easy since we need an array of strings for the names | 17:21.51 |
| Robin_Watts | Adding short documentation for each flag in the same table would therefore be easy as part of the same edit. | 17:22.22 |
| | Hence lazy programmers (like me) would have no excuse for not documenting new flags when they are added. | 17:22.48 |
| ray_laptop | Robin_Watts: and "gs --help-debug debug_alloc_fill " would just list that one flag | 17:22.51 |
| Robin_Watts | ray_laptop: gs --help-debug_alloc_fill would (I suspect) be easier to code for. | 17:23.25 |
| ray_laptop | doubts one is particularly easier than the other | 17:23.53 |
| Robin_Watts | Having to cope with --help-debug taking 0 or 1 arguments sounds harder than --help-debug always taking 0 and -help-debug-xxxx always taking 0 too. | 17:24.45 |
| ray_laptop | it might be more user friendly to have just --help {topic} so --help debug_alloc_fill would explain that flag and --help debug would be general help and --help gives other general topics | 17:25.20 |
| Robin_Watts | ray_laptop: Right, but that sounds really hard :) | 17:25.57 |
| ray_laptop | coping with optional arguments is easy. Note that --help ONLY does help, doesn't run gs (like -h does now) | 17:26.58 |
| | so EVERYTHING after --help are arguments/topics requested for help | 17:27.37 |
| Robin_Watts | fair enough. Dealers choice etc. | 17:27.41 |
| ray_laptop | bye, chrisl_away | 17:27.53 |
| | leaving coffee shop. back to work on RGBW mode.... | 17:38.16 |
| Robin_Watts | tor8: I now have a version of mupdf building (and at least pdfdraw is working, it seems), using exception handling throughout, and passing results in the return values rather than passing pointers in. | 17:48.40 |
| | I've pushed it to my repo on casper if you want to look. | 17:50.43 |
| tor8 | Robin_Watts: I think we can mostly work around the "RJW: lost debugging" cases by printing a stack trace in fz_throw | 17:54.45 |
| | I know how to do it with gcc, but not with MSVC though | 17:55.03 |
| Robin_Watts | tor8: Well, I suspect that when we come to squeeze it with memento (which we should be able to do RSN) we'll find we need to add some more cleanup. | 17:57.35 |
| | And as we do that, some of that lost debugging can be put back in. | 17:57.52 |
| tor8 | I noticed there was a lot of missing cleanups in ghostxps | 17:57.54 |
| Robin_Watts | I don't think I've lost any during this process... | 17:58.19 |
| | oh, you mean beforehand ? | 17:58.24 |
| tor8 | before hand | 17:58.28 |
| Robin_Watts | yeah, possibly. | 17:58.33 |
| tor8 | I've been more careful in mupdf, but I know there are a few places in muxps where I've slipped up | 17:58.58 |
| Robin_Watts | It's hard to get right. | 17:59.28 |
| | but with memento we can actually test it, so we should be OK. | 17:59.52 |
| tor8 | did you get the volatile stuff sorted, or this builds with warnings? | 18:00.36 |
| | in pdf_load_function, I think that volatile is not necessary (but we may want to keep it for documentation) since the value doesn't change after the setjmp | 18:01.52 |
| | and you're betting that none of the fz_dict_ and array functions don't throw (or you'll leak the func pointer) | 18:03.36 |
| | this stuff is tricky :( | 18:03.44 |
| Robin_Watts | tor8: This builds with warnings. | 18:03.59 |
| | tor8: The volatile may be unnecessary. | 18:04.25 |
| | and yes, I rushed the conversion though with the intention of using memento to squeeze it and go back and fix leaks like that, rather than to do it agonisingly slowly and then still miss some. | 18:05.19 |
| tor8 | that's fine | 18:05.49 |
| Robin_Watts | tor8: Do you have a suggested name for a version of fz_malloc that doesn't throw? | 18:11.43 |
| tor8 | fz_try_malloc ? | 18:11.52 |
| Robin_Watts | I won't be able to remember which is which :( | 18:12.15 |
| | fz_malloc_null? | 18:12.24 |
| | fz_malloc_nothrow? | 18:12.29 |
| tor8 | fz_malloc_or_null? | 18:12.31 |
| | fz_maybe_malloc :) | 18:12.39 |
| | fz_malloc_no_throw is probably best | 18:13.09 |
| Robin_Watts | OK. | 18:13.15 |
| tor8 | it's at least unambiguous | 18:13.40 |
| norbertj | henrys: hello, still looking for a sparc to test on? I have one still working at work. | 18:13.54 |
| Robin_Watts | tor8: Another random idea. | 18:54.28 |
| | Sometimes it would be nice to be able to 'break' out of the fz_try() | 18:54.46 |
| | How about I amend the fz_try macro to have: "do {" at the end and the fz_catch macro to start with "} while (0==1);" | 18:55.58 |
| | That way a break; would have the expected result. | 18:56.14 |
| tor8 | where should you end up in the break case? | 18:57.18 |
| Robin_Watts | After the fz_catch() | 18:57.31 |
| | Let me find an example... | 18:57.47 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git/.git;a=blame;f=pdf/pdf_image.c;h=1eff510a3f526c5f695eff5d2df4ec4416dd02eb;hb=1cc3bf432a6d94e6f8411b55ee0f591d098f2062 | 18:59.16 |
| | Line 66 | 18:59.18 |
| | I have to resort to 'goto end;' where end: is a label at the end of the fz_try() | 18:59.42 |
| | With my tweak, we can safely do 'break' there, to mean 'break out of the try'. | 19:00.05 |
| | That seems reasonable to me - what do you reckon ? | 19:00.16 |
| tor8 | right. | 19:00.20 |
| | goto across try/catch block is possible but will wreak havoc | 19:00.40 |
| Robin_Watts | Inded. | 19:00.54 |
| | Indeed. | 19:00.56 |
| | The golden rule is that you MUST NOT return from within the try section. | 19:01.09 |
| tor8 | I'm just worried about the non-obvious nature of it. still, it makes sense to have break there. | 19:01.47 |
| Robin_Watts | In what way is it non-obvious? | 19:02.05 |
| tor8 | but please, while (0). | 19:02.08 |
| Robin_Watts | The break alternative seems clearer than encouraging a crop of gotos. | 19:02.27 |
| tor8 | while (stuff) { try .... break; catch ... } | 19:02.38 |
| Robin_Watts | In that case, you really want the break after the catch. | 19:03.09 |
| tor8 | reading that at first glance makes you think the break will break out of the while, unless you know that try/catch is a break-scope | 19:03.11 |
| Robin_Watts | try/catch should be inseparable. | 19:03.27 |
| tor8 | exactly. the goto out of a scope rule still applies, and that case, without the do/while(0) will break things | 19:03.47 |
| | pun not intended | 19:03.51 |
| Robin_Watts | but I take your point. | 19:04.00 |
| tor8 | so I think adding do/while(0) to establish a break scope is the right thing to do anyway | 19:04.15 |
| Robin_Watts | I wish there was some way to catch people doing returns in there... | 19:06.01 |
| tor8 | apple's gcc might, with the whole inner anonymous function stuff | 19:07.47 |
| | or blocks or whatever they call it | 19:07.53 |
| | not that I want to go down that route | 19:08.00 |
| Robin_Watts | That's generic gcc, not apple specifically, I believe. | 19:08.31 |
| | (though that maybe defaults to being disabled in some ports) | 19:08.54 |
| tor8 | gcc has nested functions, blocks are apple's extension that adds closures | 19:09.57 |
| | ...and the latest spec of C++ adds lambdas... | 19:10.40 |
| Robin_Watts | "continue" within a do {...} while(0) will do the same as a break, right? | 19:12.38 |
| tor8 | yes | 19:19.56 |
| henrys | norberj:thanks much but I think it got reassigned to chris and he's going to have a look. | 20:06.18 |
| | norbertj ^^^ | 20:06.30 |
| | Forward 1 day (to 2011/10/05)>>> | |
IRC Logs