| | <<<Back 1 day (to 2018/08/02) | 20180803 |
| paulgardiner | tor8: is there any reason I should avoid use of POSIX regexp in mupdf? | 11:34.22 |
| | It's just that regexps are potentially a good way to process the path strings I'm generating when deriving the changes made by an incremental update | 11:36.40 |
| tor8 | paulgardiner: the mujs library has a javascript regexp matcher we can reuse | 11:38.39 |
| | which regexp matcher were you thinking of using? | 11:38.57 |
| paulgardiner | I wondered about that. So should I expose that in the API? | 11:39.21 |
| tor8 | I don't think POSIX regcomp, regexec are available on windows | 11:39.23 |
| paulgardiner | I wasn't sure how one should access the one in mujs from within mupdf | 11:40.50 |
| tor8 | #include "regexp.h" from thirdparty/mujs and you should have js_regcomp and js_regexec | 11:40.57 |
| paulgardiner | Oh okay. That sounds nice. Is that the POSIX flavour? | 11:41.43 |
| tor8 | almost the POSIX api and flavour | 11:41.56 |
| | it's the javascript flavour | 11:42.00 |
| paulgardiner | Yes, I should have guessed that. :-) | 11:42.18 |
| | Okay thanks. | 11:42.24 |
| tor8 | regexec takes a 'Resub' struct and fills out the 'sub' for the matches. sub[0] is the match itself, and sub[1..9] are the parenthesized groups | 11:43.12 |
| | have a look at the end of mujs/regexp.c in the #ifdef TEST to see a simple example of use | 11:43.44 |
| | it's Resub instead of nmatch and regmatch_t, but other than that it's the POSIX api with similar constants | 11:44.43 |
| | and js_regcompx takes a custom allocator | 11:45.19 |
| paulgardiner | When I looked yesterday, I think I saw calls to longjmp maybe, or am I misremembering | 11:49.02 |
| tor8 | paulgardiner: they are not exposed externally | 11:49.25 |
| paulgardiner | Ah great | 11:49.33 |
| | Forward 1 day (to 2018/08/04)>>> | |
Log of #mupdf at irc.freenode.net.