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). 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@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@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.