February 2019 - Pharo-users

Re: [Pharo-users] Slots doc

by Vitor Medina Cruz

I couldn't find examples of Slot usage. Is there any ackage I can load that use it so that I can look as an example? On Mon, Feb 4, 2019 at 6:17 PM webwarrior <reg(a)webwarrior.ws> wrote: > Vitor Medina Cruz wrote > > Thanks, I had already read this paper, which got me interested in the > > concept of slots :) . Is it a prototype in Pharo or is ready to use? it > > will become as an official part of it? > > > > > > On Sun, Feb 3, 2019 at 10:13 AM Ben Coman < > > > btc@ > > > > wrote: > > > >> > >> > >> On Sun, 3 Feb 2019 at 17:50, Todd Blanchard via Pharo-users < > >> > > > pharo-users@.pharo > > >> wrote: > >> > >>> Seems like an opportunity...I have no idea what the addition of slots > >>> does but I would like to learn. > >>> > >>> On Feb 3, 2019, at 1:33 AM, ducasse < > > > stepharo@ > > > > wrote: > >>> > >>> Hello, > >>> > >>> Where I can find documentation for slots? > >>> > >>> I am trying to access the pharo books site but it is unreachable from > my > >>> network right now, I got a connection time out (It works from my 3G > >>> though > >>> (??) ), but if I remember correctly the is no slot description in any > >>> book. > >>> > >>> Regards, > >>> Vitor > >>> > >>> > >>> Hello victor > >>> > >>> There is no documentation about slots that I know. Iâm sorry. > >>> Marcus may want to write one in the future. > >>> > >>> Stef > >>> > >>> > >> I believe its an implementation of this paper... > >> > >> > https://rmod.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayout… > >> > >> > >> cheers -ben > >> > > Slots are already part of Pharo and are totally useable. > Some example slots are buggy though. > > Explore Slot and subclasses, their class comments and methods. > > One thing to note is if you change #emitStore: or #emitValue: methods in > your slot class, you need to trigger change in classes that use it. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Feb. 6, 2019

Re: [Pharo-users] Non-greedy RegEx?

by Manuel Leuenberger

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 <leuenberger(a)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/RePl… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/RePl…>). 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(a)samadhiweb.com <mailto: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(a)stfx.eu <mailto: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. >> >> >> >

Feb. 6, 2019

Re: [Pharo-users] Non-greedy RegEx?

by Manuel Leuenberger

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/RePl… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/RePl…>). 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(a)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(a)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. > > >

Feb. 6, 2019

Re: [Pharo-users] Non-greedy RegEx?

by Esteban Lorenzano

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(a)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(a)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. > > >

Feb. 6, 2019

Re: [Pharo-users] Why DirectoryIsNotEmpty on FileReference>>deleteAll ?

by Albrecht Baur

thank you! That is good news. best, Albrecht On 06.02.19 09:34, Alistair Grant wrote: > Hi Albrecht, > > On Tue, 5 Feb 2019 at 15:26, Albrecht Baur <baur.albrecht(a)googlemail.com> wrote: >> Hi Alistair, >> >> here the system report output: >> >> ... > Thanks for the info. Please see: > > Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 > PR: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/371 > > Assuming the CI build passes, I'll wait a day or so to give the VM > guys a chance to review the changes and comment before merging. > > Cheers, > Alistair >

Feb. 6, 2019

Re: [Pharo-users] SQLite3 [UDBC2] - "Could not coerce arguments" error for UTF8 chars

by Petr Fischer

> On Tue, Feb 05, 2019 at 08:20:22PM +0100, Petr Fischer via Pharo-users wrote: > > But still... I do not expect anyone to create tables through binding > > values (like in your example), so following SQL command is still > > broken: > > db execute: 'create table A (ID INTEGER, T TEXT DEFAULT ''Ã¡ÄÅ¡ÅÄÃ¡'')'. > > Your original mail was about insert, not create. > > Anyhow, I think I see the problem: SQLite's APIs accept UTF8-encoded SQL > input strings. UDBCSQLite just uses UFFI's String to char* conversion to > pass strings in Pharo to the FFI calls. But 'Ã¡ÄÅ¡ÅÄÃ¡' is a WideString. > Judiciously sending #utf8Encoded to the input SQL string seems to do the > trick. > > | db | > db := UDBCSQLite3Connection openOn: '/tmp/u.db'. > [ | rs | > db execute: 'create table a (k, v varchar default ''ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©ÃºÅ¯ÄÅ ÄÅÅ½ÃÃÃÃÃÅ®'')'. > db execute: 'insert into a (k) values (NULL)'. > rs := db execute: 'select k, v from a'. > rs next inspect. > ] ensure: [ db close ] > > Above snippet evaluates to an inspector on a UDBCSQLite3Row instance > with the expected data. See screenshot. > > I should be able to fix this in UDBCSQLite over the next two days as it > is Chinese New Year long holiday here. > > Btw, you mentioned UDBC2. Not speaking for Torsten but I believe UDBC2 > is WIP experimental stuff. Better to use UDBCSQLite. Easiest way to load > is to install GlorpSQLite via the Catalog Browser. Ignore the warning > that the package is not tested for Pharo 7 - that's a Catalog Browser > bug. Ok - I will go with UDBC via GlorpSQLite - thanks for your advice. I am never sure which of the SQLite drivers should be used and CatalogBrowser does not help at all... pf

Feb. 6, 2019

Re: [Pharo-users] Why DirectoryIsNotEmpty on FileReference>>deleteAll ?

by Alistair Grant

Hi Albrecht, On Tue, 5 Feb 2019 at 15:26, Albrecht Baur <baur.albrecht(a)googlemail.com> wrote: > > Hi Alistair, > > here the system report output: > > ... Thanks for the info. Please see: Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 PR: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/371 Assuming the CI build passes, I'll wait a day or so to give the VM guys a chance to review the changes and comment before merging. Cheers, Alistair

Feb. 6, 2019

Re: [Pharo-users] SQLite3 [UDBC2] - "Could not coerce arguments" error for UTF8 chars

by Pierce Ng

On Tue, Feb 05, 2019 at 08:20:22PM +0100, Petr Fischer via Pharo-users wrote: > But still... I do not expect anyone to create tables through binding > values (like in your example), so following SQL command is still > broken: > db execute: 'create table A (ID INTEGER, T TEXT DEFAULT ''Ã¡ÄÅ¡ÅÄÃ¡'')'. Your original mail was about insert, not create. Anyhow, I think I see the problem: SQLite's APIs accept UTF8-encoded SQL input strings. UDBCSQLite just uses UFFI's String to char* conversion to pass strings in Pharo to the FFI calls. But 'Ã¡ÄÅ¡ÅÄÃ¡' is a WideString. Judiciously sending #utf8Encoded to the input SQL string seems to do the trick. | db | db := UDBCSQLite3Connection openOn: '/tmp/u.db'. [ | rs | db execute: 'create table a (k, v varchar default ''ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©ÃºÅ¯ÄÅ ÄÅÅ½ÃÃÃÃÃÅ®'')'. db execute: 'insert into a (k) values (NULL)'. rs := db execute: 'select k, v from a'. rs next inspect. ] ensure: [ db close ] Above snippet evaluates to an inspector on a UDBCSQLite3Row instance with the expected data. See screenshot. I should be able to fix this in UDBCSQLite over the next two days as it is Chinese New Year long holiday here. Btw, you mentioned UDBC2. Not speaking for Torsten but I believe UDBC2 is WIP experimental stuff. Better to use UDBCSQLite. Easiest way to load is to install GlorpSQLite via the Catalog Browser. Ignore the warning that the package is not tested for Pharo 7 - that's a Catalog Browser bug.

Feb. 6, 2019

Re: [Pharo-users] Non-greedy RegEx?

by Pierce Ng

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(a)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.

Feb. 6, 2019

Re: [Pharo-users] Non-greedy RegEx?

by Richard O'Keefe

PCRE has exponential worst-case time. See for example https://www.regular-expressions.info/catastrophic.html but searching for PCRE exponential time or worst case will find more. That's not the problem. The problem is that it isn't *obvious* which regexps are safe and that people are taught that regular expressions can be matched in linear time, which is sort of the point of them. But PCRE patterns *aren't* regular expressions. On Wed, 6 Feb 2019 at 04:54, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Wed, Feb 06, 2019 at 12:26:00AM +1300, Richard O'Keefe wrote: > > Please DON'T move to PCRE. > > "Outside world standards"? There are so many. > > There are two important things to know about > > PCRE: (1) it is a popular open source regexp > > library for Perl-style regexps, (2) because of > > that, it is prone to truly horrendous performance > > problems. There are alternatives, such as re2, > > https://github.com/google/re2 , > > which are not subject to PCRE's intrinsic > > performance pathologies. As it happens, re2 > > supports *? +? and ??. > > Can you share some examples of PCRE's bad performance? > > Pierce > >

Feb. 6, 2019