| | <<<Back 1 day (to 2016/08/07) | 20160808 |
| Robin_Watts | If I apply a sheer to the control points of a bezier curve, and then plot it, do I get the same results as if I plot a bezier curve and then apply the same sheer ? | 08:45.10 |
| | Yes, must do, from the convex hull property. | 09:23.28 |
| sebras | Robin_Watts: are you fully immersed in SOT (where does the T come from?) or do you have time for a review? | 14:16.54 |
| kens | T=Technology | 14:17.05 |
| sebras | is less of a n00b. | 14:17.24 |
| kens | It cna always change :) | 14:17.45 |
| | Could be Tomfoolery | 14:18.12 |
| Robin_Watts | sebras: Sure. | 14:18.39 |
| | or "Two" | 14:18.48 |
| sebras | Robin_Watts: two patches over at sebras/master | 14:18.51 |
| Robin_Watts | Top 2 both look good, thanks. | 14:19.43 |
| sebras | Robin_Watts: cool, I see nothing new over at robin/master, so unfortunately I cannot reciprocate the review. :) | 14:21.15 |
| Robin_Watts | sebras: No, nothing there yet. | 14:21.32 |
| | I fixed a bug in the new scan converter this morning for gs though, so the bmpcmp is looking MUCH closer now. | 14:21.55 |
| sebras | Robin_Watts: you are replacing the scan converter? | 14:22.37 |
| kens | tkamppeter this bug report: | 15:54.03 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=697023 | 15:54.03 |
| | points to a Ubuntu changelog which 'seems' to indicate that, amongst other things, FreeType is being excluded because its not DSFG compliant or is 'unused'. However, the reporter includes a file which does not render correctly on his Ubuntu Ghostscript, and does with ours. The culprit looks likely to be that FreeType is absent, because he is getting Ghostscript-specific warnings about patented TrueType instructions. If the packa | 15:54.03 |
| | ge does not link Ghostscript to FreeType, then GS is going to fail, possibly spectacularly. | 15:54.03 |
| fredross-perry | sebras - I did some experimentation regarding releasing things upon failure. I believe it's sufficient to just return NULL, and GC will destroy everything. I tested this by adding finalize() to each of the new classes, and I see they are all getting called if I return NULL from getBlocks(). Thoughts? | 16:11.15 |
| sebras | fredross-perry:I'm not sure you can count on the GC running garbage collection immediately. | 16:22.11 |
| | fredross-perry: so the finalizer may not be called immediately. I'm not sure if you can trigger it to run. | 16:23.44 |
| fredross-perry | I can trigger it (for the purpose of this experiment) bu I wouldn't do it in practice. | 16:24.29 |
| | The upshot is, though, I don't think we should do anything about explicitly cleaning up. | 16:26.31 |
| sebras | fredross-perry: right now I understand: since we do not attach those new objects to any memeber variable there is nothing to clean up. Correct? | 16:27.42 |
| fredross-perry | correct. | 16:27.58 |
| sebras | fredross-perry: after rereading the code just now i agree . | 16:28.40 |
| fredross-perry | ok then. Thanks. | 16:28.50 |
| Robin_Watts | fredross-perry: Did you see my array of nitpicks from the weekend? | 16:29.19 |
| sebras | fredross-perry: but it lead me to find two similar bugs in the implementation of links and annotations. | 16:29.32 |
| Robin_Watts | (Possibly you said there was a new version for me to look at?) | 16:29.33 |
| fredross-perry | yes, I just fixed the one about getting the char's bbox twice. | 16:29.40 |
| | robin yes, just now. | 16:30.00 |
| | sebras said something about the order of declarations which I did not truly understand. Again? | 16:30.30 |
| | robin - there's a few other things on my master if you want to look at those as well. | 16:31.58 |
| Robin_Watts | fredross-perry: I can only see 1 strangeness... &(sbbox) | 16:32.07 |
| | Is there a reason for that ? | 16:32.11 |
| | I mean, it's harmless, but why not just &sbbox? Is there some cunning implicit thing there? | 16:32.48 |
| sebras | fredross-perry: I think you separated your added list of fid_ variable declarations from the other ones. And those lists are probably kept sorted. | 16:32.56 |
| fredross-perry | no reason, probably a cut/paste/edit fiasco. | 16:33.03 |
| Robin_Watts | like doing if (NULL == fred) rather than if (fred == NULL) is better, theoretically. | 16:33.08 |
| | OK, cool. | 16:33.14 |
| fredross-perry | I've seen that before, theory? | 16:33.34 |
| | I think it's less readble actually. | 16:33.43 |
| Robin_Watts | The theory is that if you make the classic C typo of doing if (NULL = fred) then the compiler warns you. | 16:33.58 |
| sebras | Robin_Watts: everything looks better in reverse polish notation? ;) | 16:34.00 |
| Robin_Watts | or rather, it's an error rather than a warning. | 16:34.12 |
| fredross-perry | Robin - I understand. | 16:34.31 |
| Robin_Watts | I prefer if (fred == NULL) personally, but purely because "it's what I'm used to". | 16:35.14 |
| | If I had to learn my C style again, I'd probably try and learn it the other way round. | 16:35.38 |
| chrisl | It's not really a C thing, though | 16:36.28 |
| malc_ | Robin_Watts: why not !fred? | 16:36.34 |
| sebras | Robin_Watts: or use another language where these things are not issues. | 16:36.41 |
| fredross-perry | do all compiler do !fred the same way? | 16:36.49 |
| Robin_Watts | malc_: !fred is evil. | 16:36.50 |
| malc_ | Robin_Watts: the world is full of evil then | 16:37.21 |
| Robin_Watts | Treat bools as bools. Treat anything that's not a bool as something other than a bool. | 16:37.41 |
| sebras | More specifically tor8 is full of evil (just like that) | 16:38.00 |
| Robin_Watts | malc_: The world is full of crap C code, yes. | 16:38.06 |
| sebras | !strcmp()... | 16:38.37 |
| Robin_Watts | because: is "if (!fred)" "if (fred == NULL)" or "if (fred != NULL)" | 16:39.03 |
| | sebras: yes. | 16:39.12 |
| Robin_Watts | shudders. | 16:39.18 |
| | I can just about live with if (fred), but if (!fred) is just evil. | 16:40.07 |
| fredross-perry | I am happier with either (fred==NULL) or (NULL==fred), but not (!fred) | 16:40.48 |
| sebras | Robin_Watts: I agree with you in theory but I often treat other types as bools. | 16:40.50 |
| fredross-perry | I think it's best to be as explicit about a type as you can in C. | 16:41.11 |
| Robin_Watts | fredross-perry: amen. | 16:41.23 |
| fredross-perry | There are also tools that can be used to analyze for and enforce coding standards, btw. | 16:41.48 |
| malc_ | It's all lost cause anyway, just stumbled upon a portion where ISO/IEC 9899:201x uses incorrect main definition | 16:42.07 |
| sebras | fredross-perry: I don't have any further comments on your code. LGTM. | 16:42.55 |
| fredross-perry | ok thanks. I am reordering the declarations and fixing &(sbbox) and that's it. | 16:43.22 |
| Robin_Watts | fredross-perry: Your first commit has "fale" in a commit, that should be "false" | 16:43.31 |
| | and in DocPageView.java you now have 3 different brace styles in 3 successive functions :) | 16:44.04 |
| | getPage/setNewScale/getCalculatedWidth. I think the last one is correct. We may be accepting the first one as a java idiom. | 16:44.49 |
| | DocView.java looks like you've untabbed it all or something? | 16:45.29 |
| | Ah, you've fixed the "fale" typo in the next commit. | 16:46.11 |
| | In the next commit, you use "setupTab(tabHost, "BLAH", R.id.blah, ...) | 16:47.31 |
| sebras | fredross-perry: oh are the other patches ready for review too? | 16:47.31 |
| Robin_Watts | Shouldn't you be using R.string.blah ? | 16:47.47 |
| | i.e. move all the strings into the resources file to ease internationalisation? | 16:48.03 |
| fredross-perry | sebras - not for JNI. Raobin's looking at a bunch of Android/java stuff now. Thanks. | 16:48.04 |
| | R.string.blah - yes | 16:48.24 |
| Robin_Watts | again, we've lost tabness. | 16:48.30 |
| fredross-perry | tabs - I need to figure out how that's happening, sorry. | 16:48.54 |
| | Android Studio settings somewhere. | 16:49.05 |
| Robin_Watts | for (int i = 0; i < getPageCount(); i++) | 16:50.37 |
| | Having function calls as loop limits is bad, Mkay. | 16:50.49 |
| fredross-perry | right. | 16:51.43 |
| Robin_Watts | scrollBoxIntoView... point.y >viewport.bottom | 16:52.50 |
| | should that be >= ? | 16:52.56 |
| | Boxes are often inclusive...exclusive. | 16:53.24 |
| | Though I generally expect top to be > bottom, and that can't be the case here, right? | 16:53.43 |
| fredross-perry | Dunno. but "if the point is outside the viewport", so that's why I am using < and > | 16:56.34 |
| Robin_Watts | Suppose I've got a 320x240 viewport. | 16:56.52 |
| | Then generally, that runs from 0 to 240. | 16:57.10 |
| | 0 is inclusive, 240 is exclusive. | 16:57.20 |
| | hence 240 is outside the viewport. | 16:57.27 |
| | Hence >= | 16:57.29 |
| | I have a stylistic objection to the right hand drift in functions like showPages and hidePages, but I think I get outvoted on that a lot. | 16:58.39 |
| fredross-perry | It's working with the result of getGlobalVisibleRect(). Is that inclusive...exclusive ? | 16:58.46 |
| Robin_Watts | I'd bet it is, but I can't produce evidence at the moment. | 16:59.56 |
| | If you assume that you can subtract left from right to get width, then yes. | 17:00.13 |
| fredross-perry | gotcha. | 17:00.34 |
| | "right hand drift" ? | 17:01.19 |
| Robin_Watts | A = getA(); | 17:02.14 |
| | if (A) { | 17:02.15 |
| | B = getB(); | 17:02.17 |
| | if (B) { | 17:02.18 |
| | C = getC(); | 17:02.20 |
| | if (C) { | 17:02.21 |
| | ... | 17:02.23 |
| | as opposed to: | 17:02.24 |
| | A = getA(); | 17:03.01 |
| | if (!A) | 17:03.03 |
| | return; | 17:03.04 |
| | B = getB(); | 17:03.06 |
| | if (!B) | 17:03.07 |
| | return; | 17:03.09 |
| | etc | 17:03.10 |
| | I claim the latter is easier to read. Also it means you have to scroll left <-> right less often to keep stuff in view in narrow windows. | 17:04.16 |
| fredross-perry | I generally agree with you. | 17:04.22 |
| Robin_Watts | With: | 17:05.18 |
| | if (A) { | 17:05.19 |
| | if (B) { | 17:05.21 |
| | ... BIG STUFF HERE ... | 17:05.22 |
| | } | 17:05.24 |
| | } | 17:05.25 |
| | I always find it hard to look for matching elses etc. | 17:05.27 |
| fredross-perry | But, rather than getting outvoted, we could publish and enforce some standards. | 17:05.47 |
| | Your favorite text editor should show you matching structures in this day/age. | 17:06.09 |
| Robin_Watts | fredross-perry: It does, but when you close a } and it helpfully tells you that that matches with a { from some indeterminate place higher in the file that you can't see cos it won't all fit in your window, it's not that much help. | 17:07.41 |
| | I think Rect.contains() is wrong for the same reason. | 17:08.56 |
| | (inclusive/exclusive, not right hand drift :) ) | 17:09.10 |
| | (Right Hand Drift, starring Vin Diesel, coming to a cinema in Summer 2017) | 17:09.36 |
| fredross-perry | ;-) | 17:09.55 |
| Robin_Watts | set/getHilight unless there is some java specific preference for Hilight over Highlight, I think we should use the latter. | 17:10.59 |
| fredross-perry | sure | 17:11.50 |
| | clearly there is a lot here. I'd prefer to do it all in a new commit if that's OK. | 17:13.05 |
| Robin_Watts | fredross-perry: And that's all I have. | 17:13.40 |
| fredross-perry | sweet, thanks! | 17:13.50 |
| Robin_Watts | fredross-perry: Sure. I might be tempted to just squash it all to a single commit? | 17:13.58 |
| | What with all the renaming and stuff, that will probably be easier to look at again. | 17:14.18 |
| fredross-perry | it's OK by me. | 17:14.23 |
| Robin_Watts | returns to figuring out WTF is going wrong with the imagemask decoding in SOT :( | 17:14.43 |
| fredross-perry | except I'll keep the JNI/Java API stuff separate. | 17:14.51 |
| | Robin - I've reword all of that into one commit now. | 18:21.37 |
| | "reworked" | 18:21.46 |
| Robin_Watts | Working my way through it. Looks great so far. | 18:27.03 |
| | private String mTagHidden ? | 18:27.14 |
| | This is just an internal string used to identify a tab, right? | 18:28.17 |
| | Does it ever change? | 18:28.27 |
| | Ah, I see it. | 18:28.54 |
| | If it's a string visible in the UI, then your new code looks perfect. | 18:29.23 |
| | (Forgive me feeling my way a bit here) | 18:29.29 |
| fredross-perry | sure, np. Yes those are visible trings. | 18:32.40 |
| Robin_Watts | } else\n{ should be {\nelse\n{ (likewise } catch ...) (can you tell, I'm struggling to find anything serious to say?) | 18:32.55 |
| fredross-perry | yes. | 18:34.13 |
| | Android Studio settings again. But that's easy to fix, looking... | 18:34.49 |
| Robin_Watts | Looks really nice. | 18:37.32 |
| fredross-perry | ok i'll fix the } else\n{ should be {\nelse\n{ (likewise } catch ...) | 18:39.46 |
| Robin_Watts | fredross-perry: There was a } finally in there too, but I suspect your automated fixing will fix that too. | 18:40.21 |
| fredross-perry | yes | 18:40.30 |
| | done | 18:41.51 |
| Robin_Watts | fred: Great. Go for it. | 19:38.10 |
| sebras | when running my latest clusterpush I got: | 19:41.10 |
| | /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init' | 19:41.12 |
| | /usr/bin/ld: final link failed: Bad value | 19:41.15 |
| | collect2: error: ld returned 1 exit status | 19:41.17 |
| | are these known issues? | 19:41.24 |
| | are these the indeterminisms that kens talked about? | 19:41.37 |
| | or that's something completely different? | 19:41.46 |
| Robin_Watts | That's something diffent | 19:42.09 |
| sebras | Robin_Watts: ok. I get this the second time too (sorry to keep you waiting ray) | 19:42.48 |
| | Robin_Watts: ok, so there's a tentative commit for .cbr-suppor on sebras/master | 19:44.24 |
| | Robin_Watts: I really dislike the ifdefs in there. I'm thinking that I should separate cbz/mucbz.c into cbz/mucb.c as well as cbz/mucbr.c and cbz/mucbz.c somehow. | 19:44.54 |
| | Robin_Watts: haven't bothered to do that yet though. and the code as it is decodes .cbr and renders .pngs inside just fine. without leaks. | 19:45.34 |
| Robin_Watts | rarhack.c looks like a .h file to me. | 19:46.17 |
| sebras | Robin_Watts: correct, it should be. | 19:46.34 |
| | Robin_Watts: because the underlying library does #include WHATEVER_THE_IDENTIFIER_WAS | 19:46.58 |
| Robin_Watts | Is there mileage in making fz_archive a base class, and having fz_zip_archive and fz_rar_archive derive from it? | 19:47.34 |
| | Then we could have fz_count_archive_entries etc work with both types? | 19:48.09 |
| | yeah, I like that idea. | 19:48.49 |
| sebras | Robin_Watts: mmm, that and the table of entries, I think the entries can be kept in the same struct. | 19:48.51 |
| | Robin_Watts: just not having filling in all fields for .cbr | 19:49.05 |
| | Robin_Watts: can do! | 19:49.18 |
| Robin_Watts | sebras: Don't need to be the same struct. Just need to start with a list of function pointers to implement the different things. | 19:49.24 |
| | sebras: Cool. That would be a really nice addition. | 19:49.37 |
| sebras | Robin_Watts: but the table of entries are actually quite similar (.cbr has offset and compressed size that .cbr does not) | 19:50.00 |
| Robin_Watts | sebras: Yeah, I'm just pondering what other archive types there are that might be useful. | 19:50.19 |
| sebras | Robin_Watts: wikipedia mentions .cbt (tar), .cb7 (7z) and .cba (ACE) | 19:51.53 |
| | Robin_Watts: I believe that libarchive supports tar and 7zip | 19:52.04 |
| | Robin_Watts: adding those wouldn't be too hard. | 19:52.32 |
| | Robin_Watts: other than those I don't think we have any good reasons to add any other archive formats..? | 19:53.00 |
| Robin_Watts | Not yet, but these things come around. | 19:53.28 |
| sebras | Robin_Watts: oh, and me working on this might seem unnecessary, but it educates me in good interface design so it pays of in the long run. :) | 19:54.07 |
| | Robin_Watts: also to make libarchive more appealing I should provide them with a patch so you can easliy replace malloc and friends. ohh! I forgot to check if they use strdup, etc... | 20:13.07 |
| | 3~/quit | 20:27.15 |
| fredross-perry | I did a cluster test. "differences form trunk" and "differences from last clusterpush" show 0 diff. But, the bmpcmp is LOADED with rendering differences. What gives? Thanks. | 20:43.11 |
| tkamppeter | kens, I have added a comment to http://bugs.ghostscript.com/show_bug.cgi?id=697023. | 20:51.45 |
| malc_`` | tkamppeter: haven't the hint patent expired a couple of years ago? | 20:58.59 |
| Robin_Watts | fredross-perry: So you ran a clusterpush. | 21:17.39 |
| | That produces the report. | 21:17.46 |
| | It doesn't update the bmpcmp unless you specifically run a bmpcmp. | 21:18.02 |
| | And if you *do* run a bmpcmp it only runs the files that had differences in the last report. | 21:18.23 |
| | If there were no differences, then it doesn't actually do anything. | 21:18.32 |
| fredross-perry | I did not run a bmpcmp, just a plain clusterpush. | 21:18.53 |
| Robin_Watts | So your bmpcmp shows whatever your previous bmpcmp run had shown. | 21:18.54 |
| | Ok. | 21:19.03 |
| fredross-perry | I see. So I'm OK | 21:19.05 |
| Robin_Watts | You are. | 21:19.08 |
| fredross-perry | Except, I have a few whitespace issues in Android-only XML files, that only turned up when I tried to push to golden. | 21:19.34 |
| | I'll fix those and then push. | 21:19.41 |
| | It would be nice if clusterpush would spot those. | 21:19.54 |
| | Forward 1 day (to 2016/08/09)>>> | |
IRC Logs