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 <pie...@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 <s...@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.
> 
> 
> 

Reply via email to