| | <<<Back 1 day (to 2020/02/22) | Fwd 1 day (to 2020/02/24)>>> | 20200223 |
| avih | ator: i worked on it a bit more and i think i have a fairly complete patch with good infrastructure, but i'm not happy with it because 1. it's delicate-ish and more importantly 2. it changes the internal storage only for the C-API to be utf8, which means conversion has to take place (or at least tested) while running js code. i now think a different approach is better - make the conversion only at th C-API boundaries which will be quite cheap and will have zero | 08:31.47 |
| | effect on performance and existing code fragility while actually running js code. because current internal mujs code uses the C-API extensively, the api will have to be split to external and internal. the external one will do conversions, the internal would not. what do you think? for the most part no actual conversion would be required and no memory would be allocated. where it would be required, it would be managed by the gc normally (this already works now | 08:31.47 |
| | with my code, very clean approach) | 08:31.47 |
| | (this means no need for a virtual chartorune and no code has to be modified except at the external C-API wrappers) | 08:45.34 |
| | that's my current patch: https://0x0.st/iNox.txt but with my new api-only approach all the changes inside functions will go away, while all the new functions (all related to conversion) would remain and would instead be used only at the external api wrappers | 08:48.27 |
| | and, this can also maintain api backward compatibility, because the mapping to the conversion wrappers is decided at mujs.h, which could depend on a define of MUJS_API_UTF8, where if it's 1 then you get the wrapper, and otherwise you get the unwrapped functions. so the internal code (e.g. at jsi.h) would define it to 0, and external code can choose, and it should probably default to utf8 (breaking change by default, which can be overridden) | 08:56.48 |
| | (i don't mind throwing (my code) away even if i worked on it for a while, i definitely now thing the api-only approach is way cleaner, and the infrastructure of conversions remains, and i now have a better model of where the storage format is important, so good by me) | 09:01.37 |
| | think* | 09:01.49 |
| | ator: it is not pretty :( example of the split to functions and "automating" utf8 input conversion https://0x0.st/iN2I.txt | 15:45.26 |
| | (js_cesu8_len(utf8) returns 0 if no conversion is required) | 15:46.23 |
| | <<<Back 1 day (to 2020/02/22) | Forward 1 day (to 2020/02/24)>>> | |
Log of #mupdf at irc.freenode.net.