| | <<<Back 1 day (to 2014/11/16) | 20141117 |
| avih | hmm :/ | 04:00.26 |
| | > String.fromCharCode(65,0,97).length; | 04:00.30 |
| | 1 | 04:00.30 |
| | > String.fromCharCode(65,66,97).length; | 04:01.47 |
| | 3 | 04:01.47 |
| tor8 | avih: the catch variable shadowing is a bug that only applies to 'light weight' functions, | 10:53.30 |
| | if you add an eval() call or inner functions then it will behave as expected. I'll fix the bug. | 10:53.57 |
| avih | tor8: if you mean that it does shadow global vars, then yes, noticed it too. still, looks like a bug, isn't it? | 10:54.12 |
| tor8 | no, the catch argument should shadow everything, but in light weight functions local variables shadow it instead | 10:54.54 |
| | which is wrong | 10:54.57 |
| | strings have no hardcoded length limit, but I do cheat and use zero-terminated strings so embedded zeroes won't work | 10:55.23 |
| | typed arrays -- not implemented but there's nothing to prevent you from implementing them using the extension API | 10:55.44 |
| avih | yeah, noticed it. that kinds of limits applications with binary data, even if strings are not as good for it as typed arrays are | 10:55.58 |
| tor8 | (if you're talking about WebGL and asm.js style arrays of typed data) | 10:56.12 |
| | I'd not use strings for binary data; the strings are UTF-8 unicode data | 10:56.35 |
| avih | yeah, that kind of typed data, though for plain binary data, unrelated to asm or webgl | 10:56.46 |
| tor8 | yeah. I think both asm.js and WebGL use the same basic data type interfaces though | 10:57.02 |
| | basically a chunk of memory, initialized somehow, with differently typed 'view' objects on the same chunk | 10:57.28 |
| avih | it's basically a buffer with views of different fixed types | 10:57.32 |
| tor8 | I guess the difficulty with typed array is how to make the array accesses in the views use a C function | 10:59.20 |
| | normally you have a prototype object with get/set property accessors | 11:00.12 |
| avih | so why wouldn't this work here? | 11:00.31 |
| tor8 | for typed arrays you'll need a way to override *all* property accessors with a function | 11:00.32 |
| | since you don't want to add a get/set property for *every* possible numeric index | 11:00.50 |
| avih | are there other property accessors other than index? | 11:01.17 |
| tor8 | all object and array accesses eventually fall down to two primitive operations in the JS spec: HasProperty and PutProperty | 11:02.10 |
| avih | i don't recall exactly what's allowed with typed arrays TBH, but it's more limited than arrays iirc | 11:02.13 |
| tor8 | allowing userdata objects to override the has/putproperty accesses with a function pointer would let you implement typed arrays trivially using the public API | 11:03.05 |
| avih | though yeah, it shouldn't be hard to expose some opaque buffer type with access functions if i really need to use binary data | 11:03.31 |
| tor8 | the other way would be to add typed arrays to the core MuJS but that's not really where I want the project to go | 11:03.38 |
| | much rather give the flexibility to the API | 11:03.45 |
| | avih: yeah, if you can live with get() and put() functions rather than the syntactic sugar of [] you can do the equivalent today already | 11:04.16 |
| avih | yup | 11:04.40 |
| tor8 | just make a userdata object for the buffer and add putU8, getU8, getF32() functions to its prototype | 11:04.58 |
| avih | why do you say that's not where you want mujs to go? as embedded implementation, accessing c buffers could come quite useful imo | 11:05.18 |
| tor8 | it's going beyond the scope of the ES5 spec | 11:05.40 |
| avih | true, but is very useful for embedding, and more recent spec does define it | 11:06.06 |
| tor8 | if by more recent spec you mean that monstrosity ES6? | 11:06.36 |
| avih | :) | 11:06.40 |
| tor8 | but I expect typed arrays would be a minimal addition and possible well worth adding | 11:06.54 |
| avih | hey, you already support-ish parts of it which you considered useful/easy to implement :) | 11:06.59 |
| | but that probably shouldn't come before proper error info, possibly with stack traces ;) being able to trace errors is an important tool during dev, and if your only test env is via mujs, then it's a non trivial limitation to not have this | 11:08.41 |
| tor8 | avih: yes. better debugging info is #1 | 11:09.16 |
| | string garbage collection #2 | 11:09.25 |
| avih | hmm.. i like your priorities :) | 11:09.39 |
| tor8 | and customizable has/setproperty #3 | 11:09.47 |
| | though #3 is probably the easiest of the two | 11:09.55 |
| | ahem. I can't count today it seems :) | 11:10.09 |
| avih | :) | 11:10.43 |
| tor8 | and with #3, an example typed array extension should be a trivial addition | 11:10.52 |
| avih | it's monday. doesn't count. | 11:11.01 |
| | pardon the pun. | 11:11.15 |
| tor8 | :) | 11:11.21 |
| avih | :) | 11:11.26 |
| | tor8: btw, i mentioned it in the past, i think you could really benefit from allowing people to file issues on githug. i assume you want users, and i'm guessing github users could be good for you. even if it creates management overhead for yourself. | 11:16.57 |
| tor8 | avih: okay, the try/catch shadowing is a trivial fix but it does mean using catch() will make a function somewhat slower (due to needing to set up the full environment record for chained variable lookups) | 11:17.09 |
| | avih: bugs.ghostscript.com not enough? | 11:17.46 |
| avih | i think correctness is better, though that depends how much slower it actually is. if it's 10x slower, then personally i think i'd live with this as a documented bug.. maybe | 11:18.17 |
| tor8 | avih: yeah. fixing it with lightweight functions would be non-trivial. | 11:18.41 |
| | so it's probably just that I forgot this case when analyzing whether a function can be lightweight (and cheat with fast local variable accesses) | 11:19.04 |
| avih | tor8: bugs.ghostscript is good for you. from users it requires registration, and takes them out of their "home" which is the github echosystem. i'd think | 11:19.36 |
| kens | thinks 'echosystem' is a wonderful description of Github | 11:20.12 |
| avih | was that sarcasm? | 11:20.27 |
| kens | No, seriously | 11:20.34 |
| | I like it :-) | 11:20.45 |
| avih | :) i just came up with it | 11:20.54 |
| | anyway, gotta go now. later. | 11:21.37 |
| tor8 | echosystem is hilariously accurate for large parts of github :) | 11:21.45 |
| | avih: fix for the try/catch issue is live. | 11:22.19 |
| avih | cool. cheers :) | 11:22.28 |
| | tor8: btw, while i'm not familiar with the internal representation and (probably) therefore the exact meaning of lightweight functions, could that non-lightweight mode be applied only to the catch block? | 11:23.52 |
| tor8 | avih: sadly not | 11:24.02 |
| avih | k | 11:24.11 |
| tor8 | all lightweight does is make all local variable accesses into direct stack accesses | 11:24.21 |
| avih | and this mode doesn't support shadowing? | 11:24.56 |
| tor8 | and heavyweight means we have to create an environment record object to hold the local variables because they might be used from closures created by inner functions or eval | 11:25.01 |
| avih | like, the name resolution is.. "random" or flat? | 11:25.17 |
| tor8 | avih: yeah. it makes name access completely flat. | 11:25.24 |
| avih | k | 11:25.37 |
| tor8 | so it only works for a subset of functions | 11:25.39 |
| avih | anyway, really gotta run. later :) | 11:25.46 |
| tor8 | lookups for variables that are not part of the local scope are looked up using the environment records | 11:26.16 |
| | and the spec says the catch() block adds a new environment record | 11:26.32 |
| | so we can't flatten that into the 'lighweight' variable stack | 11:26.57 |
| avih | tor8: btw, JSLint errors on catch variable shadow, apparently since some (old?) implementation do exactly what your (pre patch) code does. | 14:13.21 |
| | but jslint is known to be super strict when it comes to known compatibility issues | 14:14.12 |
| | though i think most modern implementations get it right. didn't research though. | 14:14.49 |
| | also, just in case you missed it last time, there are some warnings you might wanna handle. https://pastebin.mozilla.org/7349066 and the win32/unix ifdefs (preferably start with unix and put the win32 part as elif rather than a new ifdef) for cygwin compatibility | 14:18.21 |
| | iirc only on jsdate.c | 14:18.56 |
| | so the js_newerror and the inst/save are trivial. not sure how to prevent the overflow warnings | 14:20.28 |
| | maybe a directive? sine i think it's probable safe as it is. | 14:21.17 |
| tor8 | avih: I'll fix newerror. inst/save are just gcc being stupid (or are you using another compiler?) | 14:21.45 |
| avih | gcc | 14:21.56 |
| | is it stupic? didn't actually look at the code it warns about | 14:22.22 |
| | d | 14:22.25 |
| tor8 | yeah. gcc fails at flow analysis when looking for warnings. | 14:22.26 |
| | the inst warning might be impossible for it to know about (since the condition is impossible, but that's set up in a different function) | 14:23.03 |
| | but it should be smart enough to catch the save, at least | 14:23.34 |
| | still, it's easy to shut them up | 14:23.43 |
| avih | maybe it's too old? 4.8.2 | 14:24.11 |
| | though it's not that old... | 14:24.29 |
| tor8 | no. gcc is just a steaming pile :) | 14:24.33 |
| avih | heh | 14:24.37 |
| tor8 | avih: does jsdate.c build with cygwin if you change #ifdef _WIN32 to #ifdef MSC_VER ? | 14:28.05 |
| | in both locations of _WIN32 | 14:28.25 |
| avih | and ms vc2013 compiler gives some "different const qualifier" warnings | 14:28.29 |
| tor8 | or does that break msys? | 14:28.31 |
| avih | i don't have an msys environment. only cygwin | 14:29.06 |
| tor8 | changing the order might be more robust | 14:29.07 |
| avih | (and msvc..) | 14:29.23 |
| | isn't MSC_VER only for msvc? | 14:29.44 |
| | with cygwin it compiles using gcc | 14:29.51 |
| tor8 | MSC_VER is only for MSVC, yes | 14:30.06 |
| avih | oh, i see your point | 14:30.17 |
| tor8 | I'm wondering if MSYS supports both time.h and timeb.h | 14:30.18 |
| | since cygwin according to your report only supports time.h | 14:30.32 |
| avih | it supports both, but a function definition was missing | 14:30.55 |
| | _timeb iirc? | 14:30.59 |
| | let me try to remove my patch and give you the exact issues. | 14:31.25 |
| tor8 | avih: or pull from tor/master and see if the latest patch solves the problem for cygwin | 14:31.47 |
| avih | compiles with msvc. checking cygwin/gcc | 14:34.24 |
| | cygwin/gcc works too. let me see what the patch does. | 14:35.14 |
| | yeah, identical to my own patch. thx | 14:35.51 |
| | hmm.. gcc didn't give any warnings.. oh, i compiled manually instead of via the mpv build script which sets all the warnings on | 14:37.08 |
| tor8 | avih: thanks. | 14:37.26 |
| avih | np | 14:37.29 |
| | hmm.. i think the catch fix does make it slower... maybe 2x slower for function calls with catch. possibly more. | 14:48.24 |
| | though of course the actual slowdown depends on the application. | 14:50.13 |
| wordToDaBird | Are there any known crash issues for mupdf crashing on devices running Android 4.4? | 15:57.49 |
| | I checked the bug tracker and didn't notice anything, but... | 15:58.04 |
| kens | If its not in the bug tracker, its not known | 15:58.24 |
| | If you think you've found a bug, best to report it | 15:59.03 |
| wordToDaBird | what's the github? | 15:59.24 |
| kens | I don't remember, best to report it at bugs.ghostscript.com, I'm not certain its even possible to report bugs at gihub | 16:00.02 |
| wordToDaBird | Best for me to do a little investigation. Better to be sure of the scenario and circumstances before raising a false flag. | 16:00.12 |
| kens | Well, I admit we'd be appreciative :-) | 16:00.31 |
| wordToDaBird | Want the github so I can check the source. I have the stack trace. | 16:00.34 |
| kens | Urgh, tor8 Robin_Watts ? Github sources for MuPDF ? | 16:00.54 |
| wordToDaBird | !source | 16:01.08 |
| kens | You can get them from git.ghostscript.com, but I know little about Github | 16:02.15 |
| Robin_Watts | wordToDaBird: There is no github. We have our own git repo. | 16:04.19 |
| wordToDaBird | just grabbed it | 16:04.32 |
| | ty | 16:04.33 |
| Robin_Watts | wordToDaBird: We are not aware of any 4.4 specific problems. | 16:04.42 |
| wordToDaBird | 4.3 forward I see it, but 4.4 it goes crazy | 16:05.17 |
| kens | I'm afraid its not really my project, you really need tor8 to wake up and discuss it, or failing that Robin_Watts | 16:05.55 |
| wordToDaBird | It seems like its the bug that was fixed in 1.6 that happened when the processing was kind of behind. | 16:06.10 |
| | I'll keep looking around. | 16:06.44 |
| | kens I am not sure what ghostscript is, please enlighten me. | 16:07.31 |
| kens | Oh its a PostScript (and PDF) interpreter | 16:07.46 |
| | There are also fonte end interpreters for XPS and PCL | 16:08.08 |
| | s/fonte/front/ | 16:08.17 |
| Robin_Watts | wordToDaBird: So you're saying that a bug fix in 1.6 has broken operation on 4.4 ? | 16:08.50 |
| tor8 | kens: if it's got to do with android, Robin_Watts or paulgardiner are the best bet for sane answers | 16:20.15 |
| kens | Well it was Github that I was asking about :-) | 16:20.37 |
| tor8 | kens: right. I have a private mirror of mupdf on github, but we don't have an actual official presence there | 16:20.58 |
| chrisl | It's not often I see "Android" and "sane" in the same sentence....... | 16:21.09 |
| kens | That's sort of what I thought | 16:21.11 |
| | Forward 1 day (to 2014/11/18)>>> | |
IRC Logs