[Pharo-users] Non-greedy RegEx?

Manuel Leuenberger leuenberger at inf.unibe.ch
Wed Feb 6 05:42:00 EST 2019


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> 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>:
>>> Still, there are advantages to an in-image solution, can't says this
>>> enough, these external lib dependencies pose their own problems ...
>> +1
> 
> 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...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190206/fc003092/attachment.html>


More information about the Pharo-users mailing list