| | <<<Back 1 day (to 2016/02/05) | 20160206 |
| Robin_Watts | rayjj: We have a similar thing in SOT. | 00:28.58 |
| | Various things are generated as part of the builds (header files etc), and we don't want them to upset the rest of the build. | 00:29.24 |
| | So suppose we need to generate plotter.h | 00:29.37 |
| | we generate plotter.h as plotter-new.h (or something like that), and diff it from plotter.h. If it's different, we delete plotter.h and replace it with plotter-new.h | 00:30.07 |
| | That way the generation happens every time, but the knock on effects don't. | 00:30.23 |
| kens | For the lgos, an easy SO question for tor8 ro Robin_Watts I suspect: | 09:06.28 |
| | http://stackoverflow.com/questions/35239224/mupdf-is-not-freeing-up-the-memory | 09:06.28 |
| chrisl | rayjj: (for the logs) gsromfs1.c doesn't recreate/rebuild every time, for me. Only (correctly) when one of its dependencies has changed - which really seems like the right behaviour to me | 09:56.25 |
| sebras | tor8 (for the logs): I have now gone over the two alternatives: using a few new node types or having an alternate text for glue nodes. | 16:31.29 |
| | tor8: it seems to me that it actually was quite easy to use an alternate text. however the way I have currently done it it uses a second string pointer to which the normal ->content.text is repointed in case of that glue node breaking a line. | 16:32.42 |
| | tor8: let me play with having the glue nodes assume that they can not represent more than a single character, i.e. int instead of strings. maybe the code will be better, but I'm not sure. | 16:34.01 |
| | tor8: doing that causes measure_word() to not be able to work on the text though. and also I need to distinguish between [" ", ""] vs ["", "-"], probably by testing it explicitly but doing so just feels wrong. | 16:39.22 |
| Robin_Watts | hi sebras. | 16:41.40 |
| | How many different alternate texts might we have to have for a glue node? | 16:42.29 |
| | This is still hypenation, right? | 16:42.35 |
| | So it's "" or "-" ? | 16:42.40 |
| sebras | Robin_Watts: yes, for hyphenation. | 17:19.15 |
| | Robin_Watts: but maybe there is a language that uses more than one character for glue according to the unicode line breaking algorithm. | 17:19.38 |
| Robin_Watts | Personally, I'd be tempted to just have glue nodes with a 'hyphenate' or not bit at the moment. | 17:20.26 |
| | and if languages turn out to have more than one possible hypenate char, then we make that several hypenate bits. | 17:20.58 |
| sebras | Robin_Watts: well, actually you could do the same for spaces. if bit is set, measure " " and push the rest of the line that far forward, if at the end of the line, assume width == 0 and don't render. | 17:21.44 |
| | Robin_Watts: that way glue nodes wouldn't need any pointer at all. | 17:22.04 |
| Robin_Watts | yes, nice. | 17:22.15 |
| sebras | Robin_Watts: but I'm to inexperienced in this to see the whole picture and the full design idea. so I'm a bit wary of just changing this. | 17:22.58 |
| | Robin_Watts: my ideas are based on the idea that we can always know what characters a glue node would use, that way we can reduce it to a node type. | 17:26.34 |
| | Robin_Watts: but is that true? | 17:26.40 |
| Robin_Watts | Seems reasonable to me. | 17:27.17 |
| sebras | Robin_Watts: I doubt that it makes for any real difference though since the content already contains a pointer to fz_image. | 17:27.30 |
| Robin_Watts | which is never used for glue nodes. | 17:27.49 |
| sebras | Robin_Watts: true, but it is still there. | 17:28.05 |
| Robin_Watts | so we could switch to a variable sized node structure that just has a common flags word at the top. | 17:28.11 |
| | We've done that elsewhere. | 17:28.14 |
| sebras | Robin_Watts: agreed, but then you want to be convinced that we don't plan to stick more stuff in the content union when we start supporting more stuff. | 17:29.22 |
| | Robin_Watts: then my patch would just be unnecessary churn in the code. | 17:29.33 |
| | Robin_Watts: if you see my point..? | 17:30.37 |
| Robin_Watts | If we move to variable sized things, then the content union would disappear. | 17:31.15 |
| | and image nodes would have an image pointer. | 17:31.28 |
| | text nodes would have a text pointer etc. | 17:31.42 |
| | Churn in the code is good if it gets us closer to 'ideal' code at the end. | 17:32.12 |
| | I've given up believing that you can ever design a system perfectly the first time, so being prepared to rip stuff up and rework it (even for small gains) seems like the best approach to me. | 17:32.57 |
| | Cos those small gains add up in the long run. | 17:33.04 |
| sebras | Robin_Watts: of course. always throw away the prototype. | 17:34.11 |
| | Robin_Watts: it's just that in this scenario I'm not sure what the plans are for this data structure and what other things are left to be implemented. so I'm a bit hesistant to muck about too much unless both you and tor8 ACK that the idea is good. | 17:35.09 |
| | Robin_Watts: but yeah, we could probably just expand the type-bitfield and do away with the text-pointer for any space, soft hyphen, etc. | 17:36.02 |
| | Robin_Watts: tor8: I have two branches now, sebras/alternative-1 and sebras/alternative-2 I know that the code is a bit fugly, but please have a look and let me know about the general idea. I'll clean up the code a bit further regardless of which path we choose. | 23:36.24 |
| | Forward 1 day (to 2016/02/07)>>> | |
IRC Logs