[Pharo-users] Non-greedy RegEx?
leuenberger at inf.unibe.ch
Wed Feb 6 05:48:35 EST 2019
As an in-image solution, refactoring the SmaCC scanner to a standalone regex engine might be pretty efficient to gain more RE features, but I cannot really judge how big this effort would be.
> On 6 Feb 2019, at 11:42, Manuel Leuenberger <leuenberger at inf.unibe.ch> wrote:
> An in-image regex engine would always be preferable by me, but creating a fully-flegged engine with all the fancy lookarounds, named/non-capturing groups, non-greedy matches, Unicode support, etc. sounds like a six-month-length full-time project. Any volunteers? ;)
> I am all for a pragmatic approach: If there is a solution that allows to reuse Smalltalk streams and strings without much memory copying combined with a library dependency that is battle-proven and maintained by capable people - why not?
> Funny enough, PCRE already seems to be used in the RePlugin (https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/RePlugin/RePlugin.c#L356 <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/RePlugin/RePlugin.c#L356>). Why is this not used in the image, am I missing something?
> Regarding third-party dependencies, my only beef is that I do not particularly like that they are distributed and linked together with a copy by the VM. This makes it very portable, but I do not need another copy of a library that I have already installed on my system (git/SSH/SSL/png/FreeType/Cairo). On Linux some libs (Cairo/FreeType/PNG) are already linked to system libs, I would like to have Pharo as an installable package in apt and MacPorts/brew with declared dependencies, which would make it even more lightweight. But that is only marginally related for this thread.
>> On 6 Feb 2019, at 02:38, Pierce Ng <pierce at samadhiweb.com <mailto:pierce at samadhiweb.com>> wrote:
>> On Tue, Feb 05, 2019 at 07:25:07PM +0100, Norbert Hartl wrote:
>>>> Am 05.02.2019 um 16:16 schrieb Sven Van Caekenberghe <sven at stfx.eu <mailto:sven at stfx.eu>>:
>>>> Still, there are advantages to an in-image solution, can't says this
>>>> enough, these external lib dependencies pose their own problems ...
>> Libraries like libgit2, libssh2 and quite a few more are already a core
>> part of Pharo, so I'd say philosophically might as well go all in to
>> make FFI to external libraries an intrinsic part of computing with
>> Pharo, not just for developing Pharo itself. The more people use UFFI,
>> the better it will become.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users