If cre2 meets the standard and community agree, I do not care to be honest, I just mentioned PCRE because it is the âde facto standardâ and we are tired of not being compatible :) About an in-image solutions in general: Yes, it is better than rely in a solution like that. Also about in-image solutions in general: It is harder to maintain them. We are a small community and we cannot allow us to have everything we need implemented in image. Using an FFI solution is a perfect valid way and IMO is preferred many times because of this maintainability issue. Of course, it does not applies to all cases with same intensity :) I donât know the cost of maintain a regex lib in-image. I know at the moment is infinite because there is no-one there doing it (and I know I do now have the time). So we stay for years with a suboptimal solution :( Anyway I want to point to some things I (In my âarchitectâ role, or whatever is what I do here) I always think: 1- This solution is state-of-the-art? 2- is it maintained or the cost to maintain it can be absorbed ? 2.1- Is maintained by whom? 2.2- Will this kick us back if maintainers leave? 3- is it well tested? 4- is it well documented? People often forgets that making libraries is a commitment with your user community, is a lot more than âI do this and then I forgetâ. Of course you can proceed like that (and not few of my own projects are of use-and-throw), but we as âpharo makersâ need to take this into account with priority to other variables. Notice that âperformanceâ is not in this list. I care a lot about performance, but I care a lot more about the other points. Now, that does not means we do not make decisions we later regret (we are humans, after all⦠and this is a learning process). Cheers, Esteban
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.