Re: Adding a Builtin to EUPHORIA
- Posted by jimcbrown (admin) Apr 01, 2014
- 1527 views
I don't think [regex] would have been that much slower. It's how we handle a lot of the stuff in the stdlib, like msgboxes and mmap.
There would be *a lot* more manual memory management. And not just the stuff we have to do to convert a sequence into a C string, but a lot of the structures and things that get passed around. Stuff that goes right on the stack in C (very fast) would be allocated on the heap. For one off stuff, it's not a big deal, but regexes are often used (I know I do) for processing lots of data, over and over.
I don't understand why the existing type system (with regexes being a unique type) wouldn't work with PCRE being a shared library. Jeremy easily went back and forth on this in the code when we were debating this issue.
Oh, yeah, it would work to put our be_pcre.c code into the library along with the actual PCRE code. I got the impression that Shawn was talking about having a euphoria wrapper for a normal PCRE library, though.
Oh, I think what Jeremy did used a normal PCRE library with a shim. Anyways, I think we're on the same page here now.
We can still do that. Just carry around both the shared and static versions of the PCRE library. If py2exe can turn a Python app (and all its required runtimes) into a single executable, I don't see why we'd have so much trouble with just one library.
This sounds like a completely losing proposition to me. We've just complicated our build and distribution (and probably users' build and distribution of their own programs) for pretty much no gain.
Matt
Running py2exe is not complicated. We're talking about an extra flag to euc and bind, and maybe a few extra files in the bin directory. If done right, it doesn't have to be complicated. (For backwards copmatibility, euc and bind would probably default to sticking the static PCRE into the final executable, and you'd have flags to use a shared version or to kick regex out altogether.)
