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 <leuenber...@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 <pie...@samadhiweb.com >> <mailto: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 >>>> <mailto: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. >> >> >> >
