| | <<<Back 1 day (to 2018/04/23) | 20180424 |
| tor8 | Robin_Watts: tor/master is updated with the fixes we talked about yesterday | 10:13.08 |
| Robin_Watts | looking... | 10:13.26 |
| tor8 | Robin_Watts: how do you feel about renaming pdf_name_eq to pdf_obj_eq? | 10:13.31 |
| Robin_Watts | That sounds like a different thing. | 10:14.11 |
| tor8 | it is calling it what pdf_name_eq actually did. | 10:14.52 |
| Robin_Watts | tor8: Well, is pdf_obj_eq a deep compare ? | 10:15.05 |
| | i.e what is pdf_obj_eq(pdf_new_int(ctx, 1), pdf_new_int(ctx, 1)) | 10:15.45 |
| tor8 | that will be true | 10:15.56 |
| | it will be a deep-ish compare | 10:16.30 |
| | pdf_obj_eq resolves one level before comparing, but the actual comparison does not auto-resolve | 10:16.49 |
| Robin_Watts | In a way, I'd like pdf_name_eq to JUST compare names. | 10:17.18 |
| | We already have pdf_objcmp for object comparisons. | 10:17.41 |
| | and pdf_objcmp_resolve for comparisons with resolutions. | 10:18.09 |
| tor8 | the idea is for a faster objcmp that only cares for equality, not sorting | 10:18.12 |
| Robin_Watts | I see. | 10:18.25 |
| | Well, I'd support renaming pdf_name_eq to pdf_obj_eq, and then adding a proper pdf_name_eq :) | 10:18.45 |
| | tor8: So, does it need to be fixed for MSVC still? | 10:20.19 |
| | Why do you opencode bsearch ? | 10:22.00 |
| tor8 | Robin_Watts: premature optimization :) | 10:22.54 |
| | I have fixed MSVC | 10:23.07 |
| Robin_Watts | Surely the systems bsearch will be better than a simple C version? | 10:23.16 |
| | tor8: I think I'm happy then. | 10:24.39 |
| | I would suggest not committing until the cluster is back up. | 10:24.49 |
| tor8 | Robin_Watts: system bsearch is not specialized and involves a lot of function calls | 10:25.30 |
| | I can't help but think a bsearch with hardcoded steps and an inlined strcmp will be faster | 10:25.43 |
| Robin_Watts | ok. | 10:25.52 |
| tor8 | adding the comparison callback and its pointer casts is just as much typing as just doing an inline binary search | 10:26.31 |
| | Robin_Watts: hm, I have an updated commit on tor/master that does pdf_name_eq as you would like it | 10:26.47 |
| | updated the "Remove need for namedump by using macros and preprocessor." commit | 10:27.00 |
| | and maybe we should skip the pdf_obj_eq commits, they might just be adding more confusion | 10:27.23 |
| Robin_Watts | Changing all the pdf_name_eq to pdf_obj_eq now seems wrong? | 10:27.55 |
| tor8 | sorry, the fix is in the commit after that, in the Tweak ordering of constant pdf_obj enums to make PDF_NULL == NULL. | 10:28.04 |
| | though I think the strcmp might actually be equivalent but slower than what we had for the degenerate cases of comparing TRUE with FALSE, that will return true (since they're both equivalent to the 'empty' name) | 10:29.37 |
| | agh... this is all making me unhappy. | 10:29.55 |
| | pdf_obj_eq should be pdf_are_resolved_objects_equal but that's too long to type | 10:30.25 |
| | but that would state clearly what it does | 10:30.39 |
| | and I would expect pdf_obj_eq to return false for two separate indirect objects that both point to values that are equal but that's not what it would do | 10:31.12 |
| Robin_Watts | I feel your pain. | 10:32.05 |
| | I am happy with the first 2 commits on your repo, I think. | 10:32.22 |
| | The *last* 2 commits on my repo confuse me. | 10:32.36 |
| | The *last* 2 commits on your repo confuse me. | 10:32.43 |
| tor8 | okay? | 10:35.18 |
| | I don't know what I want... tell me what to do :) | 10:35.27 |
| Robin_Watts | penultimate one, changes all the pdf_name_eq's to pdf_obj_eq's. | 10:35.47 |
| | Which is wrong, cos they are name comparisons. | 10:36.06 |
| tor8 | my idea behind that commit is: do we need the distinction? | 10:37.14 |
| Robin_Watts | tor8: I like the idea of being able to be sure that both names are really names when comparing them. | 10:37.48 |
| tor8 | a more general 'is this object, or does this object point to, this other name object' | 10:37.49 |
| Robin_Watts | The fact that objs and names can be used interchangeably with the type system in place is a degree of flexibility that people should be protected from. | 10:38.39 |
| tor8 | 99.5% of comparisons are with a constant name | 10:38.39 |
| | Robin_Watts: that's life with a dynamic type system :) | 10:38.56 |
| Robin_Watts | Indeed. | 10:39.01 |
| tor8 | pdf_obj_eq checks both value and type, the only issue is if you want to compare two unknowns and also know that they are name | 10:39.24 |
| Robin_Watts | pdf_name_eq should only accept names, and should resolve if required (though it will be VERY rare), IMHO. | 10:39.30 |
| | pdf_obj_eq should do a shallow compare of type/value, with no resolution. | 10:40.02 |
| | pdf_obj_resolve_eq should do a shallow compare of type/value, with resolution. | 10:40.34 |
| | I am prepared to accept arguments that pdf_obj_eq and pdf_obj_resolve_eq should maybe do "shallowish" compares (so ints and bools etc). | 10:41.07 |
| tor8 | https://pastebin.com/raw/8AzWZUgf something like that then? | 10:41.37 |
| Robin_Watts | A hypothetical pdf_obj_deep_eq should do a deep compare of type/value etc with resolution. | 10:41.48 |
| | That seems spot on. | 10:42.04 |
| tor8 | the comment sohuld read "If either is a name constant" though | 10:42.16 |
| Robin_Watts | tor8: oh, I see. Yes. | 10:42.42 |
| tor8 | and 99% of the cases we see it used should hit that case | 10:42.51 |
| Robin_Watts | yes. | 10:43.00 |
| tor8 | if ((a > PDF_FALSE && a < PDF_LIMIT) || (b > PDF_FALSE || b < PDF_LIMIT)) would possibly be better | 10:43.49 |
| | it would use the fast case for when either argument is a constant, not just if the first argument is one | 10:44.23 |
| Robin_Watts | yes. | 10:45.50 |
| tor8 | okay, new revised commits up. I'll wait a few hours to commit to cluster. | 10:46.26 |
| | if you could do a final sanity check on VS I'd also appreciate it | 10:46.36 |
| Robin_Watts | tor8: will do. | 10:46.52 |
| moolc | Robin_Watts: "Receiving objects: 27% (170/613), 16.54 MiB | 21.00 KiB/s" | 19:35.34 |
| Robin_Watts | let me run a test here. | 19:35.58 |
| | git clone git://git.ghostscript.com/mupdf.git mupdf-test | 19:37.06 |
| | That's giving me 600k+ a second. | 19:37.15 |
| moolc | Robin_Watts: that fetching is from tor's branch | 19:37.36 |
| | if that's of any significance | 19:37.43 |
| Robin_Watts | same server, doesn't matter. | 19:37.45 |
| moolc | Receiving objects: 100% (613/613), 23.90 MiB | 33.00 KiB/s, done. | 19:38.01 |
| | Resolving deltas: 100% (317/317), completed with 85 local objects. | 19:38.01 |
| | | 19:38.01 |
| | shrug | 19:38.10 |
| | Forward 1 day (to 2018/04/25)>>> | |
Log of #mupdf at irc.freenode.net.