- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Glass] Bug in Regex?

by Max Leske

On 21 Feb 2019, at 13:40, Mariano Martinez Peck wrote: > Vassili Bykov Hi Max, > > It looks like it was fixed on a later version of VBRegex. I was able > to > extract the 2 little changes to make it work. Do you know if there is > an > issue already open for this so that I can submit the changes? > > BTW, I am trying to understand the history of Regex. It's clear that > the > original implementation was done by Vassili Bykov and the packages > were > called VBRegex and that was in VW under the Public Store. I guess, at > some > point, that code was ported to Pharo. In Pharo 1.1 the packages are > still > called 'VB-Regex' but on recent ones its called "Regex". > The package name changed between Pharo 1.1.2 and Pharo 1.2.2, as far as I can tell from the images I have on my machine. > What I cannot confirm is which version Pharo (or maybe this was even > en > Squeak before Pharo forked) ported from VW. All I could find is a > class > comment on RxMatcher saying "-- Regular Expression Matcher v 1.1 (C) > 1996, > 1999 Vassili Bykov". As you can see, that is 1999. VW has newer > versions > from 1.2.x to 1.4.x, latest commit being on 2014. The oldest images I have is Squeak3.9 of 7 November 2006 update 7067, and that already contains VBRegex. > > The particular problem we are discussing in this thread was fixed in > 1.3.1. > > So I am not sure if someone ever tried porting again a newer version > to > Pharo? It doesn't seem the case. It would certainly be great to get those fixes! > > Anyone knows a bit more the history here? > > Thanks > > > On Thu, Feb 21, 2019 at 5:18 AM Max Leske <maxleske(a)gmail.com> wrote: > >> Hi Mariano, >> >> Yes, there is indeed such a bug (if it hasn't been fixed in an update >> to >> VBRegex that is). The bug is simple to work around though, as all you >> have >> to do is sort your branch (|) terms by length. Here's the comment >> I've >> written for a regex generating method is use: >> >> " The sorting is very important because VB-Regex aborts early on >> branches. >> Example: 'bl' matchesRegex: 'b|bl' --> false The solution is to sort >> by >> length (longest first), then alphabetically, with the short group >> optimization at the end. " >> >> Cheers, >> Max >> >> On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote: >> >> >> >> On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass < >> glass(a)lists.gemtalksystems.com> wrote: >> >>> What a good case to have GToolkit visualizations help debugging this >>> RX >>> tree ;) >>> >>> >> Oh yeah..And look Doru, they have some stuff on the top right >> "Explanation" panel: https://regex101.com/r/MqVXz8/1 >> >> >> -- >> Mariano >> https://twitter.com/MartinezPeck >> http://marianopeck.wordpress.com >> >> > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com

Feb. 21, 2019

Re: [Pharo-dev] [Glass] Bug in Regex?

by Mariano Martinez Peck

Vassili Bykov Hi Max, It looks like it was fixed on a later version of VBRegex. I was able to extract the 2 little changes to make it work. Do you know if there is an issue already open for this so that I can submit the changes? BTW, I am trying to understand the history of Regex. It's clear that the original implementation was done by Vassili Bykov and the packages were called VBRegex and that was in VW under the Public Store. I guess, at some point, that code was ported to Pharo. In Pharo 1.1 the packages are still called 'VB-Regex' but on recent ones its called "Regex". What I cannot confirm is which version Pharo (or maybe this was even en Squeak before Pharo forked) ported from VW. All I could find is a class comment on RxMatcher saying "-- Regular Expression Matcher v 1.1 (C) 1996, 1999 Vassili Bykov". As you can see, that is 1999. VW has newer versions from 1.2.x to 1.4.x, latest commit being on 2014. The particular problem we are discussing in this thread was fixed in 1.3.1. So I am not sure if someone ever tried porting again a newer version to Pharo? It doesn't seem the case. Anyone knows a bit more the history here? Thanks On Thu, Feb 21, 2019 at 5:18 AM Max Leske <maxleske(a)gmail.com> wrote: > Hi Mariano, > > Yes, there is indeed such a bug (if it hasn't been fixed in an update to > VBRegex that is). The bug is simple to work around though, as all you have > to do is sort your branch (|) terms by length. Here's the comment I've > written for a regex generating method is use: > > " The sorting is very important because VB-Regex aborts early on branches. > Example: 'bl' matchesRegex: 'b|bl' --> false The solution is to sort by > length (longest first), then alphabetically, with the short group > optimization at the end. " > > Cheers, > Max > > On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote: > > > > On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass < > glass(a)lists.gemtalksystems.com> wrote: > >> What a good case to have GToolkit visualizations help debugging this RX >> tree ;) >> >> > Oh yeah..And look Doru, they have some stuff on the top right > "Explanation" panel: https://regex101.com/r/MqVXz8/1 > > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com > > -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 21, 2019

Host window icon

by Cyril Ferlicot

Hi, Currently, the CI of Pharo has two non random test failures. windows-32 / Tests-windows-32 / testHostWindowIcon â Windows32.Graphics.Tests.Primitives.DisplayScreenTest windows-32 / Tests-windows-32 / testHostWindowIconWrongTypeOfArgument â Windows32.Graphics.Tests.Primitives.DisplayScreenTest I know this was a part of the system was improved during Pharo 7 to be able to display a custom icon at the top of the window. Does someone knows why it is failing? Or should we investigate? -- Cyril Ferlicot https://ferlicot.fr

Feb. 21, 2019

Re: [Pharo-dev] [Glass] Bug in Regex?

by Max Leske

Hi Mariano, Yes, there is indeed such a bug (if it hasn't been fixed in an update to VBRegex that is). The bug is simple to work around though, as all you have to do is sort your branch (|) terms by length. Here's the comment I've written for a regex generating method is use: " The sorting is very important because VB-Regex aborts early on branches. Example: 'bl' matchesRegex: 'b|bl' --> false The solution is to sort by length (longest first), then alphabetically, with the short group optimization at the end. " Cheers, Max On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote: > On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass < > glass(a)lists.gemtalksystems.com> wrote: > >> What a good case to have GToolkit visualizations help debugging this >> RX >> tree ;) >> >> > Oh yeah..And look Doru, they have some stuff on the top right > "Explanation" > panel: https://regex101.com/r/MqVXz8/1 > > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com

Feb. 21, 2019

Re: [Pharo-dev] [Glass] Bug in Regex?

by Mariano Martinez Peck

On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass < glass(a)lists.gemtalksystems.com> wrote: > What a good case to have GToolkit visualizations help debugging this RX > tree ;) > > Oh yeah..And look Doru, they have some stuff on the top right "Explanation" panel: https://regex101.com/r/MqVXz8/1 -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 21, 2019

Re: [Pharo-dev] [Glass] Bug in Regex?

by Esteban Maringolo

What a good case to have GToolkit visualizations help debugging this RX tree ;) Regards! Esteban A. Maringolo El miÃ©., 20 feb. 2019 a las 17:44, Mariano Martinez Peck via Glass (< glass(a)lists.gemtalksystems.com>) escribiÃ³: > And..as Esteban Maringolo points out, it also happens with sequence of > chars... > > 'bb' matchesRegex: '([a-z]|[b-z][a-z])' --> false. > > Cannot be simpler than this: > > '25' matchesRegex: '(\d\d|\d)' --> true > '25' matchesRegex: '(\d|\d\d)' --> false > > So there is something related to the OR. > > Thoughts? > > > > On Wed, Feb 20, 2019 at 5:33 PM Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> BTW, I am CCing GemStone mailing list too because it answers false there >> too. >> >> On Wed, Feb 20, 2019 at 5:26 PM Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> Look at this case: >>> >>> `'25' matchesRegex: '([0-9]|[1-9][0-9])' -> false` >>> `'25' matchesRegex: '([1-9][0-9]|[0-9])' -> true` >>> >>> That is, ( a | b ) is not euqal to ( b | a ) " a or b is not equal to b >>> or a" and should describe a range of 0 to 99. >>> >>> I don't understand why the first sentence answers false. Even Pharo 1.1 >>> answers false (so this is very very old behavior). I checked on other >>> dialects and it answers true. I then checked here [1] and it also find >>> matches. >>> >>> So...do you see some rational explanation or sounds like a bug? >>> >>> [1] https://regex101.com/r/MqVXz8/1 >>> >>> -- >>> Mariano >>> https://twitter.com/MartinezPeck >>> http://marianopeck.wordpress.com >>> >> >> >> -- >> Mariano >> https://twitter.com/MartinezPeck >> http://marianopeck.wordpress.com >> > > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com > _______________________________________________ > Glass mailing list > Glass(a)lists.gemtalksystems.com > http://lists.gemtalksystems.com/mailman/listinfo/glass >

Feb. 20, 2019

Re: [Pharo-dev] Bug in Regex?

by Mariano Martinez Peck

And..as Esteban Maringolo points out, it also happens with sequence of chars... 'bb' matchesRegex: '([a-z]|[b-z][a-z])' --> false. Cannot be simpler than this: '25' matchesRegex: '(\d\d|\d)' --> true '25' matchesRegex: '(\d|\d\d)' --> false So there is something related to the OR. Thoughts? On Wed, Feb 20, 2019 at 5:33 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > BTW, I am CCing GemStone mailing list too because it answers false there > too. > > On Wed, Feb 20, 2019 at 5:26 PM Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys, >> >> Look at this case: >> >> `'25' matchesRegex: '([0-9]|[1-9][0-9])' -> false` >> `'25' matchesRegex: '([1-9][0-9]|[0-9])' -> true` >> >> That is, ( a | b ) is not euqal to ( b | a ) " a or b is not equal to b >> or a" and should describe a range of 0 to 99. >> >> I don't understand why the first sentence answers false. Even Pharo 1.1 >> answers false (so this is very very old behavior). I checked on other >> dialects and it answers true. I then checked here [1] and it also find >> matches. >> >> So...do you see some rational explanation or sounds like a bug? >> >> [1] https://regex101.com/r/MqVXz8/1 >> >> -- >> Mariano >> https://twitter.com/MartinezPeck >> http://marianopeck.wordpress.com >> > > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com > -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 20, 2019

Re: [Pharo-dev] Bug in Regex?

by Mariano Martinez Peck

BTW, I am CCing GemStone mailing list too because it answers false there too. On Wed, Feb 20, 2019 at 5:26 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > Look at this case: > > `'25' matchesRegex: '([0-9]|[1-9][0-9])' -> false` > `'25' matchesRegex: '([1-9][0-9]|[0-9])' -> true` > > That is, ( a | b ) is not euqal to ( b | a ) " a or b is not equal to b or > a" and should describe a range of 0 to 99. > > I don't understand why the first sentence answers false. Even Pharo 1.1 > answers false (so this is very very old behavior). I checked on other > dialects and it answers true. I then checked here [1] and it also find > matches. > > So...do you see some rational explanation or sounds like a bug? > > [1] https://regex101.com/r/MqVXz8/1 > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com > -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 20, 2019

Bug in Regex?

by Mariano Martinez Peck

Hi guys, Look at this case: `'25' matchesRegex: '([0-9]|[1-9][0-9])' -> false` `'25' matchesRegex: '([1-9][0-9]|[0-9])' -> true` That is, ( a | b ) is not euqal to ( b | a ) " a or b is not equal to b or a" and should describe a range of 0 to 99. I don't understand why the first sentence answers false. Even Pharo 1.1 answers false (so this is very very old behavior). I checked on other dialects and it answers true. I then checked here [1] and it also find matches. So...do you see some rational explanation or sounds like a bug? [1] https://regex101.com/r/MqVXz8/1 -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 20, 2019

Re: [Pharo-dev] Question on KmGlobalDispatcher

by ducasse

Thanks Ben. This is cool. I proposed to David to do a pair screen session but my agenda will return soon to chaos :). Stef > On 20 Feb 2019, at 16:58, Ben Coman <btc(a)openinworld.com> wrote: > > Hi David, > > I invite you to consider this an opportunity to submit a PR to fix it. > I'm happy to walk you though the process if you ping me on Discord chat. > I remember it felt cool to have my first code integrated. > Pharo is yours. > > cheers -ben > > On Wed, 20 Feb 2019 at 02:16, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > Hello David > > Indeed this is a good catch. > Can you open a bug entry on github? > Else I will do it but this is cool to get involved that way > >> On 19 Feb 2019, at 17:37, David Richards <david.i.richards.iii(a)gmail.com <mailto:david.i.richards.iii@gmail.com>> wrote: >> >> Why does the class name KmGlobalDispatcher have a small 'm'? >> >> Should it be more consistently named KMGlobalDispatcher, as all other classes in package: 'Keymapping-Core'? >> >> Object subclass: #KmGlobalDispatcher >> instanceVariableNames: 'dispatcher' >> classVariableNames: '' >> package: 'Keymapping-Core' >> >> Just curious why this name seems inconsistent. I don't recall seeing an inconsistency with class name prefixes in any other package group. Is this just a mistake, or rather an opportunity to learn something interesting about how classes should be named in Pharo? As a beginner, I'm not sure which. >> >> Thanks >> David >

Feb. 20, 2019