| | <<<Back 1 day (to 2014/11/28) | 20141129 |
| pratz_ | Hi, how can i use MuPDF to highlight/annotate some text in the PDF? | 06:50.03 |
| | or if any MuPDF based file viewer supports infile annotation/highlighting? | 06:52.23 |
| Robin_Watts | pratz_: The Android build of MuPDF will do highlight annotations. | 09:04.09 |
| | The core of MuPDF supports it, but it's not exposed in windows/linux viewers, currently. | 09:04.29 |
| pratz_ | Robin_Watts: Thanks | 09:04.45 |
| tor8 | avih: prototype of garbage collected strings is on http://git.ghostscript.com/?p=user/tor/mujs.git;a=summary | 12:57.27 |
| avih | tor8: yeah, noticed it earlier. nice | 12:58.51 |
| | tor8: btw, isn't this ehavior hiddenly unexpected? http://git.ghostscript.com/?p=user/tor/mujs.git;a=commit;h=0af0cc305942f952e4d245227798e841af62f0d2 | 12:59.08 |
| tor8 | it is the behaviour that caused my main headache with GC strings | 12:59.43 |
| | namely the possibility for js_tostring to invoke "toString" functions to implicitly convert objects to strings | 13:00.07 |
| | but nowhere to safely stow the result | 13:00.14 |
| | other than in the intern string table | 13:00.24 |
| | with this API change (which is a bit unclean design wise, but should not affect anybody in practice) | 13:00.53 |
| | that does not have to be the case, and is the most elegant solution I could find | 13:01.05 |
| | generally, if you want a certain stack value as a given type, you won't mind if the slot is clobbered to contain that conversion | 13:01.33 |
| | but the docs need updating | 13:01.49 |
| avih | i'd imagine it would be true most of the time. but when you expect otherwise, it would be a nasty nasty bug to find | 13:02.02 |
| tor8 | yes. | 13:02.35 |
| | so we have to be very clear in the docs that tostring/tonumber may coerce the stack slot to the given type | 13:03.16 |
| avih | you know that most people don't RTFM... | 13:03.43 |
| tor8 | you can of course guard against any such type coercions by checking js_isstring | 13:03.45 |
| avih | yeah | 13:04.19 |
| tor8 | and if you need to keep the original value (for whatever reason, such as in Date.prototype.toJSON) js_copy is your friend | 13:04.59 |
| avih | what if stack objects (or all objects/values?) could have an "auxiliary" object which should be GC'ed together with its "parent" object, and put coerced stack values there? | 13:05.12 |
| | so basically, the doc of js_tostring(J, idx) should be: "convery the stack value to string and return a pointer to it"? | 13:06.40 |
| | convert* | 13:06.47 |
| | convert - in place | 13:06.57 |
| tor8 | yes, something like that | 13:07.05 |
| avih | is it different than lua_tostring ? | 13:07.24 |
| tor8 | "convert the stack value to a string (in-place if necessary) and return a pointer to it | 13:07.29 |
| | yes, lua (being a sane language) doesn't have implicity type coercions | 13:07.39 |
| avih | dunno, this is a destructive API... | 13:07.39 |
| tor8 | I'm not thrilled about it either, so I'm going to sit on the patch for a while and think some more on it | 13:08.02 |
| avih | (i don't think my code would fall on this, but... it's a scary change imo...) | 13:08.19 |
| | well, scary outcome. | 13:08.33 |
| | what if, per stack, you keep an auxiliary object with these coerced values? (in contrast to per object/value) | 13:09.39 |
| tor8 | I could also have a secret stack just for type coercions (similar to your idea about shadow slots) | 13:10.06 |
| avih | yeah. tomato tomaato. | 13:10.26 |
| tor8 | that's going to be a pretty heavy performance impact though, I expect (doubling the amount of memory that needs to be shuffled for all stack operations) | 13:11.02 |
| | I might be able to get away with just having a 'tostring' cache for each stack slot | 13:11.27 |
| avih | what if it's instanciated the first time you need a coerced value? | 13:11.28 |
| tor8 | but then the js_Value struct would grow from 16 to 24 bytes anyway (on 64-bit platforms) | 13:12.02 |
| avih | i can't evaluate the impact it would have on real world cases | 13:12.28 |
| tor8 | given that the stack is a highly volatile place to store temporary values, I'm think the impact of js_tostring being destructive is not going to be that severe in practice | 13:13.41 |
| avih | how does it work right now (before today's patch)? you just allocate and forget about it? | 13:13.48 |
| tor8 | all use cases in the existing code just do js_tostring, use the value, then js_pop to get rid of it | 13:13.59 |
| | I stick it in the js_intern table, which means the value lives on for the lifetime of the js_state | 13:14.18 |
| avih | wait, js_tostring doesn't modify the stack... why the pop? | 13:14.33 |
| tor8 | js_getproperty(), js_tostring to extract the value, js_pop | 13:14.50 |
| avih | what if you kept a linked list of coerced objects associated with each stack? | 13:15.41 |
| tor8 | I still wouldn't know when they're safe to release | 13:15.57 |
| avih | well, coerced allocations. | 13:16.01 |
| tor8 | unless I do book-keeping on every js_push/js_pop | 13:16.26 |
| | or at the least, on every js_call | 13:16.39 |
| avih | can you tie few allocations together? such that if you free the allocation context it frees all the children? | 13:16.43 |
| tor8 | js_Values are never allocated | 13:16.57 |
| | they're copied by value on the stack | 13:17.08 |
| avih | but js_tostring allocates | 13:17.12 |
| | or.. maybe it doesn't. don't know | 13:17.30 |
| tor8 | yes, it allocates and saves the allocation in the global list for the garbage collector to sweep | 13:17.31 |
| | the issue is guaranteeing that the pointer returned to the C code doesn't get collected early | 13:18.03 |
| avih | my understanding of the implementation is just not enough to conduct a meaningful discussion.. :/ | 13:18.28 |
| | though reflecting on the api behavior is still something i can do | 13:18.54 |
| tor8 | nevermind then :) just be aware of the change that js_toxxx may be destructive | 13:19.09 |
| avih | :) if i get a bug on this i'll charge you per hour :) | 13:19.47 |
| tor8 | it will only be destructive when you call js_tostring on an object, and that invokes the toString() property on said object | 13:20.25 |
| | in the future, it may also be destructive when you call tostring on a number | 13:20.49 |
| avih | what if you instead provide an api js_getstring(J, idx), which copies it as a new string value? | 13:20.53 |
| tor8 | strdup(js_tostring()) | 13:21.15 |
| avih | ? | 13:21.36 |
| | i mean, js_getstring would push the toString() value to stack | 13:22.12 |
| | so it gets deallocated with the stack, or on pop | 13:22.27 |
| tor8 | ah, now I see what you mean | 13:22.29 |
| | similar to what js_toprimitive does now, but push instead of in-place | 13:23.04 |
| avih | never used toprimitive, but i guess yes | 13:23.20 |
| tor8 | you shouldn't need to, js_tostring calls toprimitive under the hood if the value is not a primitive | 13:23.42 |
| | something that lua doesn't have the concept of doing | 13:23.50 |
| | actually, lua does what I just changed it to do :) | 13:24.31 |
| | "If the value is a number, then lua_tolstring also changes the actual value in the stack to a string." | 13:24.40 |
| | okay, so I'm not going to fret about this anymore | 13:24.48 |
| avih | so, let's assume you implement such api. would js_getstring(J, -1); char *x=js_tostring(J, -1); js_pop(1); printf("%s", x); <-- work? how long can x be expected to hold a valid string after it's original stack object has been popped? | 13:25.41 |
| tor8 | it cannot. as soon as it's been popped, the string pointer from the corresponding stack slot is immediately invalid. | 13:26.13 |
| avih | i see | 13:26.24 |
| | yeah, if lua behaves the same, and mujs api is based on lua, i agree it's a valid move... | 13:27.15 |
| | (in 12h i have a damn long trip to portland.. so not looking forward to it.. 24h trip, 2 connections :/ ) | 13:31.53 |
| tor8 | where are you flying from? | 13:44.36 |
| | regardless, you have my sympathies! flying with 2 connections is a terrible experience. been there, done that, way too many times :( | 13:47.11 |
| avih | yeah :/ ... israel | 13:49.02 |
| tor8 | first stop in the US as well then? | 13:49.18 |
| avih | sometimes the flights are too long and the wait time between them is too short.. (been to SF about 6 weeks ago..) | 13:49.38 |
| | nah, amsterdam, seatle, portland | 13:49.50 |
| tor8 | barely enough time to recover from jetlag... | 13:50.06 |
| avih | ... sh*t happens.. :) | 13:50.21 |
| tor8 | just don't get stuck too long in immigration in seattle :( | 13:50.33 |
| | in chicago they have an express line for immigration if you're flying with carry on only | 13:50.59 |
| | so keep your eyes peeled, in case they have the same system in seattle | 13:51.15 |
| avih | "luckily", that connection is 4h.. so.. should be enough. but yeah, us immigration sucks | 13:51.20 |
| tor8 | allocate a minimum of 2h for queuing in US immigration, is my experience | 13:51.40 |
| | you're lucky if it only takes 45m | 13:51.46 |
| | miami during the strikes, 3h+ | 13:52.09 |
| avih | yeah. 6 weeks ago i barely made it .. | 13:52.23 |
| | :/ | 13:52.30 |
| | and on the way back i got a 7h connection in JFK. maybe i'll have an hour to get a coffee at the big apple :) | 13:53.37 |
| tor8 | given that it takes over an hour to get into the city from JFK, yeah, that sounds about right :) | 13:54.32 |
| avih | heh | 13:54.41 |
| | actually.. it's been a while since i've been to NYC. probably few years. | 13:55.15 |
| | but yeah, in general getting to the west coast is just a PITA... | 13:56.00 |
| tor8 | there are plenty of direct flights to the west coast from london, amsterdam, paris and frankfurt/munich | 13:56.52 |
| avih | yes, but now it's thanksgiving, so many flights were booked. on the way back it's only one connection in NY | 13:57.28 |
| tor8 | preferably london, the shortest of the long hauls by about an hour compared to the others | 13:57.38 |
| avih | yeah. /me like london. paris too :) | 13:57.58 |
| | where are you at? | 13:58.19 |
| tor8 | still, it's heathrow ... but it beats the maze that is CDG or the soul crushing boringness of frankfurt and munich | 13:58.21 |
| avih | true. | 13:58.31 |
| tor8 | southern sweden, so I fly out of denmark | 13:58.33 |
| avih | i've been at london about a year ago, when they had that shitstorm and all the trains and flights were suspended.. right on the day i had my flight back.. | 13:59.09 |
| | was damn lucky to get to the airport on time | 13:59.19 |
| | and i even missed a flight once. from paris. due to a girl though :p | 13:59.51 |
| tor8 | I dodged that storm by about a day last year :) | 13:59.51 |
| avih | heh, lucky you :) | 14:00.08 |
| tor8 | I've been hit by strikes in paris though (surprise! not...) | 14:00.32 |
| avih | merde :) | 14:00.44 |
| | oh, strikes.. yeah.. could happen.. | 14:00.55 |
| tor8 | and plenty of cockups when transferring between different airlines that didn't like to cooperate :( | 14:01.09 |
| | did I mention I hate traveling? ;) | 14:01.47 |
| avih | yeah. which is why i prefer to travel real light and take my baggage with me to on the plane | 14:01.56 |
| | :) | 14:02.11 |
| | i'm ok with traveling, if it's europe. canada and the us is just too long flights. even if it's direct | 14:02.39 |
| | waiting to your baggage while your next flight is in half an hour is a b*tch :) | 14:03.41 |
| tor8 | yeah. I stopped checking in luggage over a decade ago :) | 14:04.13 |
| avih | :) | 14:04.18 |
| tor8 | unless the trip is >3 weeks | 14:04.25 |
| avih | yup | 14:04.36 |
| | tor, your latest patch from your repo crashes for me | 15:56.25 |
| | (and the debug patch no longer applies cleanly, but it crashes also without it) | 15:56.56 |
| | tor, this is the last revision from your repo which doesn't crash for me: 4eae3ec10c4a874fe4b021b01362f6f3362a18b0 | 16:02.04 |
| | you should probably make a complex test case which exercises lots of stuff, and make sure it runs cleanly when you update the code. | 16:10.25 |
| guiniol | hello all. I've been using mupdf for a while now and I really like it, so thanks a lot ^^ I have, however, a small issue with it. Is it possible to have a continuous page view? What I mean is have the bottom of page n and the top of page n-1 shown at the same time. I haven't found the option in the man page, so I wanted to check that I didn't miss anything. | 18:01.14 |
| tor8 | avih: odd, I did not get any unusual crashes running the sputnik test suite | 18:14.28 |
| avih | tor8: well, it starts ok, and then crash at a c function which does a lot of arguments checking. not necessarily your bug, but it worked fine before this revision, and in a quick look i didn't notice an obvious bug. still, could be my bug, but i won't have time to debug it. | 18:16.32 |
| | (and bisecting before/after the js_newstate api change was not fun.. :) ) | 18:17.18 |
| | the crash seems consistent though so i could probably provide some more info if i put some time into it, but i don't know when that would be. | 18:17.59 |
| | tor8: i call from js: subprocess({args: ["ls", "-al"]}); <- which then calls subprocess_exec, and it didn't throw any error during the arguments checking. and that's subprocess and subprocess_exec: https://pastebin.mozilla.org/7641270 | 18:22.08 |
| | tor8: maybe js_pushlstring is not handled well? (pointer + length) | 18:23.27 |
| | it segfaults | 18:26.47 |
| tor8 | avih: ah, yes. my bad. pushlstring doesn't zero terminate. bad copy&paste code from my part. | 18:33.47 |
| | or rather, it doesn't cope with non-zero-terminated strings, like it ought to | 18:34.03 |
| avih | tor8: you're welcome :) | 18:34.04 |
| tor8 | @@ -120,7 +120,8 @@ void js_pushlstring(js_State *J, const char *v, unsigned int n) | 18:34.44 |
| | CHECKSTACK(1); | 18:34.44 |
| | if (n < 16) { | 18:34.44 |
| | STACK[TOP].type = JS_TSHRSTR; | 18:34.44 |
| | - strcpy(STACK[TOP].u.shrstr, v); | 18:34.44 |
| | + memcpy(STACK[TOP].u.shrstr, v, n); | 18:34.45 |
| | + STACK[TOP].u.shrstr[n] = 0; | 18:34.47 |
| | try that patch and see if it helps | 18:34.49 |
| avih | i believe you. once you know what the problem is, the fix is trivial ;) | 18:35.08 |
| | but not now. gotta start packing. | 18:35.17 |
| | also, since there can't be optional arguments, maybe use js_newstatex for the one with the extra args? I'd imagine that at least some would not need the flags arg, and maybe uctx too. and it clutters the api if it's not used, even if you typically need to have only one call to newstate at the code... | 18:48.09 |
| | tor8: the patch works. thx :) | 19:07.11 |
| | (from your repo) | 19:07.19 |
| | Forward 1 day (to 2014/11/30)>>> | |
IRC Logs