- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] RBPattern matching dynamic array expressions

by Nicolai Hess

2016-12-11 0:46 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > On 12/10/2016 02:37 AM, Nicolai Hess wrote: > > Question : how should a pattern with three variables >> (first/second/third) look like to match the expression >> { (1@2) . Color red . 3} and assign the (sub)-expressions >> 1@2 >> Color red >> 3 >> to the three variables first/second/third ? >> > > The RB was written before the {} array syntax. It appears that are a few > bugs in the pattern matching for the arrays. The first is that it needs to > reset the isList variable of RBPatternVariableNode when it is part of a > dynamic array. You can fix that by adding this to the end of > RBPatternVariableNode>>parent: method: > > parent isDynamicArray > ifTrue: [ self isStatement > ifFalse: [ isList := false ] ] > Yes, that works > > I think this will make the matching work like what you are expecting. If > you want to match multiple statements, you need to add a ".", but if you > just have "`@first", it will only match any expression node. > > While testing I noticed an error in the RBArrayNode>>match:inContext:. The > method doesn't test the lengths of the nodes before sending the #with:do: > message. If you try to match two arrays of different sizes, you get an > error. This should be changed back to be: > > match: aNode inContext: aDictionary > aNode class = self class > ifFalse: [ ^ false ]. > ^ self matchList: statements against: aNode statements inContext: > aDictionary > Yes, I used the call that is used in RBMessageNodes #match:in:Context:, but RBMessageNode indirectly checks for the different size of arguments by comparing the selector. For the RBArrayNode this size comparsion isn't done. But with your fix, the change in this method isn't needed. Thank you John. nicolai > > > John Brant > >

Dec. 12, 2016

Re: [Pharo-dev] About traits

by tesonep＠gmail.com

Hi, my implementation is in https://github.com/tesonep/pharo-talents . It does not have enough documentation, although the tests have working examples. I have as an objective of this week write more documentation. Any comment will be gratefully received. thanks, Pablo On Sun, Dec 11, 2016 at 9:05 AM, stepharong <stepharong(a)free.fr> wrote: > > > Dale > > I missed your remark about traits. > I think that traits are nice because they act as a kind of static macro > expansion and really help to get multiple inheritance into single one. > > Now ideally I would like to have > > (I hate so much this google nonUI) > > - state with traits with a nice initialization process. > - Now Pablo did a nice and simple implementation of Talents (dynamic > traits). I should have a look because if we could unify it and have > either a trait statically applied to a class (what we have now) and a > trait being applicable to an instance then it would be really good. > > > Where is this Talents implementation? > > I should ask pablo. > It is better than the one of jorge because it is not based on reflectivity > but anonymous class. > We will document it. > > Stef > > > thanks, > > Norbert > > > > Now making the tools traits-aware is much more than just having traits in > the language. > - change > - loading > - editing > - overloading when we compile a method that comes from a trait we > should be able to say that it overrides..... > > What we did with the "unification" of traits and classes and the use of > traits inside the kernel is a mistake (in Squeak andreas if I recall made > Trait a subclass of classDescription > and this is not good either - even if he marketed it as a good idea) and > we will iterated to remove the use of traits from Class and friends. > Then ideally I would like to iterate over the > - reflective API (because we should be able to simply access the > "class" of a compiledMethod from where the traits is coming from or where > it is installed > - revisite the implementation because the clause composition. > > I think that the tools should not manipulate traits as classes because > traits are not classes. > Then doing this we will clarify that the traits and classes must not be > polymorphic because they are not. > > > > Stef > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Pablo Tesone. tesonep(a)gmail.com

Dec. 12, 2016

Re: [Pharo-dev] [Pharo-users] A little prototype kernel in 9 methods :)

by Pavel Krivanek

Nice! Is there any good reason why during cloning you do not set the delegation too? -- Pavel 2016-12-11 21:13 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > I sent the wrong file of course. Here is the chapter :) > > > On Sun, Dec 11, 2016 at 8:52 PM, <serge.stinckwich(a)gmail.com> wrote: > >> Great works ! I will add some contents for Actalk chapter. >> >> BTW I update a little bit the PolyMath book. There was some sections >> missing. >> >> >> EnvoyÃ© de mon iPhone >> >> > Le 11 dÃ©c. 2016 Ã 20:33, stepharong <stepharong(a)free.fr> a Ã©crit : >> > >> > Hi guys >> > >> > I'm thinking to package some of my language design knowledge in a kind >> of book. Probably to be used to give a lecture on >> > OOP languages. I have class-based reflective kernel. This is several >> years that I was thinking about prototype kernels >> > and I decided to relax and implement one for fun over the week-end. >> > I will probably look at mixins, traits, talents, split objects in the >> future. >> > >> > Since I cannot compile the book on jenkins, I join the pdf. >> > >> > Stef >> > >> > PS: I will finish Pharo by example now and focus on Learning OOP with >> Pharo. >> > >> > -- >> > Using Opera's mail client: http://www.opera.com/mail/ >> > <book.pdf> >> >> >

Dec. 11, 2016

Re: [Pharo-dev] protocol pane "no messages" Re: [Pharo-users] setter method

by Nicolas Passerini

I will add that I doubt that any filetree repository (or at least its metadata-less versions) repository is capable of remembering an empty protocol. 2016-12-10 20:27 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Hi Ben, > > Yes and no. > Because you can add a protocol right away without any method and end up in > my layout. > > Pedantically yours, > Phil > > On Sat, Dec 10, 2016 at 2:17 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Nope. I'll see your pedantic, and raise you... >> >> Clicking on "no messages" and adding a method you get... >> --all-- >> as yet unclassified. >> >> So "no protocols" goes away, but there are still no protocols. >> >> (pedantic poker, fun for all the family) >> cheers -ben >> >> >> On Sat, Dec 10, 2016 at 2:56 AM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> > To be pedantic it should be "no protocols" because as soon as you add >> one, >> > you get >> > >> > --all-- >> > someaddedprotocol >> > >> > even if there is no method. >> > >> > Phil >> > >> > On Fri, Dec 9, 2016 at 7:21 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> [Forwarded to pharo-dev for side discussion...] >> >> >> >> On Sat, Dec 10, 2016 at 2:15 AM, Ben Coman <btc(a)openinworld.com> >> wrote: >> >> > On Sat, Dec 10, 2016 at 1:39 AM, Kateryna Aloshkina >> >> > <aloshkina(a)ucu.edu.ua> wrote: >> >> >> Hi everybody! >> >> >> >> >> >> I've just joined the community:) and have a question >> >> >> How to write the method count: such that, when invoked on an >> instance >> >> >> of >> >> >> Counter, instance variable is set to the argument given to the >> message? >> >> >> so that >> >> >> Counter new count: 7 >> >> >> would set the value of a new Counter instance to 7 >> >> >> (It is a little exercise from >> >> >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exo-Cou >> nter.pdf) >> >> >> >> >> >> >> >> >> Best wishes, >> >> >> Kateryna >> >> > >> >> > Welcome Kateryna, >> >> > I hope you are having fun and Pharo changes the way you think about >> >> > programming. >> >> > >> >> > Referring to Figure 1.2, assuming you've already created the class, >> >> > first make sure you are on the instance-side rather than the >> class-side >> >> > of the class such that the class definition in the bottom (code) pane >> >> > looks just like Figure 1.2. Click the <Class> button to toggle which >> >> > side you look at. >> >> > >> >> > Now in the third (protocols) pane on "no messages" >> >> > and you will get a method template in the code pane >> >> > >> >> > Change... messageSelectorAndArgumentNames >> >> > to... count: >> >> > >> >> > then change.... statements >> >> > to an assignment to the instance variable. >> >> > and <Accept> the the code to save & compile the method. >> >> >> >> To be pedantic, shouldn't "no messages" actually be "no methods" >> >> But maybe even better would be... "click for method template" ? >> >> >> >> cheers -ben >> >> >> > >> >> >

Dec. 11, 2016

Re: [Pharo-dev] [Pharo-users] A little prototype kernel in 9 methods :)

by Stephane Ducasse

I sent the wrong file of course. Here is the chapter :) On Sun, Dec 11, 2016 at 8:52 PM, <serge.stinckwich(a)gmail.com> wrote: > Great works ! I will add some contents for Actalk chapter. > > BTW I update a little bit the PolyMath book. There was some sections > missing. > > > EnvoyÃ© de mon iPhone > > > Le 11 dÃ©c. 2016 Ã 20:33, stepharong <stepharong(a)free.fr> a Ã©crit : > > > > Hi guys > > > > I'm thinking to package some of my language design knowledge in a kind > of book. Probably to be used to give a lecture on > > OOP languages. I have class-based reflective kernel. This is several > years that I was thinking about prototype kernels > > and I decided to relax and implement one for fun over the week-end. > > I will probably look at mixins, traits, talents, split objects in the > future. > > > > Since I cannot compile the book on jenkins, I join the pdf. > > > > Stef > > > > PS: I will finish Pharo by example now and focus on Learning OOP with > Pharo. > > > > -- > > Using Opera's mail client: http://www.opera.com/mail/ > > <book.pdf> > >

Dec. 11, 2016

Re: [Pharo-dev] [Pharo-users] A little prototype kernel in 9 methods :)

by serge.stinckwich＠gmail.com

Great works ! I will add some contents for Actalk chapter. BTW I update a little bit the PolyMath book. There was some sections missing. EnvoyÃ© de mon iPhone > Le 11 dÃ©c. 2016 Ã 20:33, stepharong <stepharong(a)free.fr> a Ã©crit : > > Hi guys > > I'm thinking to package some of my language design knowledge in a kind of book. Probably to be used to give a lecture on > OOP languages. I have class-based reflective kernel. This is several years that I was thinking about prototype kernels > and I decided to relax and implement one for fun over the week-end. > I will probably look at mixins, traits, talents, split objects in the future. > > Since I cannot compile the book on jenkins, I join the pdf. > > Stef > > PS: I will finish Pharo by example now and focus on Learning OOP with Pharo. > > -- > Using Opera's mail client: http://www.opera.com/mail/ > <book.pdf>

Dec. 11, 2016

A little prototype kernel in 9 methods :)

by stepharong

Hi guys I'm thinking to package some of my language design knowledge in a kind of book. Probably to be used to give a lecture on OOP languages. I have class-based reflective kernel. This is several years that I was thinking about prototype kernels and I decided to relax and implement one for fun over the week-end. I will probably look at mixins, traits, talents, split objects in the future. Since I cannot compile the book on jenkins, I join the pdf. Stef PS: I will finish Pharo by example now and focus on Learning OOP with Pharo. -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 11, 2016

Re: [Pharo-dev] RBPattern matching dynamic array expressions

by Yuriy Tymchuk

Hi John, thank you for our reply it is really helpful. Can you please also spend a bit of your time to talk about the âpermissiveness" of the pattern syntax. For example the string '`.head `.@tailâ is parsed into a message node with selector `.@tail and a receiver variable node `.head. To my knowledge this is not a valid syntax as the names that have a dot in the beginning should become matchers for statements. Also for example if you write `#@literal the list marker is not doing anything when combines with the literal pound as far as I know, and some people are confused about this, were the any reason why this is not simply rising a syntax error? Cheers. Uko > On 11 Dec 2016, at 00:46, John Brant <brant(a)refactoryworkers.com> wrote: > > On 12/10/2016 02:37 AM, Nicolai Hess wrote: > >> Question : how should a pattern with three variables >> (first/second/third) look like to match the expression >> { (1@2) . Color red . 3} and assign the (sub)-expressions >> 1@2 >> Color red >> 3 >> to the three variables first/second/third ? > > The RB was written before the {} array syntax. It appears that are a few bugs in the pattern matching for the arrays. The first is that it needs to reset the isList variable of RBPatternVariableNode when it is part of a dynamic array. You can fix that by adding this to the end of RBPatternVariableNode>>parent: method: > > parent isDynamicArray > ifTrue: [ self isStatement > ifFalse: [ isList := false ] ] > > I think this will make the matching work like what you are expecting. If you want to match multiple statements, you need to add a ".", but if you just have "`@first", it will only match any expression node. > > While testing I noticed an error in the RBArrayNode>>match:inContext:. The method doesn't test the lengths of the nodes before sending the #with:do: message. If you try to match two arrays of different sizes, you get an error. This should be changed back to be: > > match: aNode inContext: aDictionary > aNode class = self class > ifFalse: [ ^ false ]. > ^ self matchList: statements against: aNode statements inContext: aDictionary > > > John Brant >

Dec. 11, 2016

Re: [Pharo-dev] About traits

by Dale Henrichs

On 12/11/16 12:06 AM, stepharong wrote: > > Dale > > I missed your remark about traits. > I think that traits are nice because they act as a kind of static > macro expansion and really help to get multiple inheritance into > single one. > > Now ideally I would like to have > > (I hate so much this google nonUI) > > - state with traits with a nice initialization process. > - Now Pablo did a nice and simple implementation of Talents (dynamic > traits). I should have a look because if we could unify it and have > either a trait statically applied to a class (what we have now) and a > trait being applicable to an instance then it would be really good. > > > Now making the tools traits-aware is much more than just having traits > in the language. > - change > - loading > - editing > - overloading when we compile a method that comes from a trait we > should be able to say that it overrides..... > > What we did with the "unification" of traits and classes and the use > of traits inside the kernel is a mistake (in Squeak andreas if I > recall made Trait a subclass of classDescription > and this is not good either - even if he marketed it as a good idea) > and we will iterated to remove the use of traits from Class and friends. > Then ideally I would like to iterate over the > - reflective API (because we should be able to simply access the > "class" of a compiledMethod from where the traits is coming from or > where it is installed > - revisite the implementation because the clause composition. > >> >> I think that the tools should not manipulate traits as classes >> because traits are not classes. >> Then doing this we will clarify that the traits and classes must >> not be polymorphic because they are not. >> > Stef, > > Thanks for the clarification ... we are open to adding traits to > GemStone and perhaps we should talk a little bit more about your > ideas on a "better implementation" ... at this point GemStone 3.5 > would be the target version and that would give us time for > syncing up the implementation. > > > Sure. > This can be a good incentive for us to revisit it. Sounds like a plan...

Dec. 11, 2016

Re: [Pharo-dev] NeoUUIDGenerator>>testTwoSameGenerator - intermittent CI failure

by Sven Van Caekenberghe

> On 11 Dec 2016, at 16:50, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, Dec 11, 2016 at 7:49 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > >The timing problem might indeed be resolution dependent: 100us is probably to short sometimes. > Time microsecondClockValue gives the time in microseconds, but it does not guarantee microsecond resolution, on windows the resolution is still in milliseconds. > > Useful to know. But regardless of the resolution, the units are still microseconds. > So the majority of the time you'll assert: 3622 - 3622 < 100 > which passes, > but other times you'll cross the boundary and you'll assert: ...4622 - ...3622 < 100, > which fails. > > The important question is, what resolution of time is important for UUIDs? > If 10ms is sufficient, then ...4622 - ...3622 < 10000 easily passes on even the slowest computer.. I don't think it is terribly important, but if #microsecondClockValue has such a bad resolution on Windows (as hendrik showed), that is a general problem. It just not good. > ---------- > | col | > > col := Array new: 30000 streamContents: [ :stream | > 1 to: 30000 do: [ :x | stream nextPut: Time microsecondClockValue ] > ]. > > col asSet "a Set(3658909536504622 3658909536503622 3658909536502622)"' > > btw I forgot to mention I'm on 32-bit Linux. So thankfully I get... > col asSet size "==>16135" > > btw2, For a challenge I'm lining up to improve the VM clock "sometime", maybe end of Feb (if it proves within my capability no one else gets to it first). > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36 > > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe > Sent: Sunday, December 11, 2016 11:56 AM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] NeoUUIDGenerator>>testTwoSameGenerator - intermittent CI failure > > Hi Ben, > > Thanks for looking into this, it was bothering me for quite some time ;-) > > https://pharo.fogbugz.com/f/cases/19453/NeoUUIDGenerator-testTwoSameGenerat… > > Yes, I think the counter roll-over is the problem, stupid of me to to have seen this. > > The timing problem might indeed be resolution dependent: 100us is probably to short sometimes. > > I will provide a slice with fixes. > > Cool. Ping me from the slice. > cheers -ben > > > Thanks again ! > > Regards, > > Sven > > > On 11 Dec 2016, at 09:07, Ben Coman <btc(a)openinworld.com> wrote: > > > > For Case [1] I got an unrelated CI failure [2] for > > NeoUUIDGeneratorTests>>#testTwoSameGenerator > > > > Checking this locally by running this a dozen times... > > 1 to: 1000 do: [:n| last:=n. NeoUUIDGeneratorTests new setUp > > testTwoSameGenerator ] > > > > Two distinct failures are apparent... > > > > 1. Takes longer than expected. > > self assert: (time2 - time1) abs < 100 > > last=1 ==> a time difference of 109 > > last=1 ==> a time difference of 102 > > last=1 ==> a time difference of 155 > > last=1 ==> a time difference of 105 > > Interesting that whenever this happens its on the first iteration. > > > > 2. Invalid consecutive ids. > > self assert: (uuid1 at: 10) + 1 equals: (uuid2 at: 10). > > last=127 ==> TestFailure: Got 256 instead of 0. > > last=828 ==> TestFailure: Got 256 instead of 0. > > last=128 ==> TestFailure: Got 256 instead of 0. > > last=316 ==> TestFailure: Got 256 instead of 0. > > Maybe a problem with rollover? > > > > So instrumenting a bit: > > testTwoSameGenerator: n > > | uuid1 uuid2 consecutiveOk time1 time2 timeOk | > > .... > > "same generator, consequetive counters" > > consecutiveOk := ((uuid1 at: 10) + 1) = (uuid2 at: 10). > > "same generators, similar clock, within 100 milliseconds" > > time1 := self timeFromUUID: uuid1. > > time2 := self timeFromUUID: uuid2. > > timeOk := (time2 - time1) abs < 100. > > ( timeOk and: [ consecutiveOk ]) ifFalse: [ > > Transcript cr; > > show: 'fail n=', (n printPaddedWith: $0 to: 3) ; tab; > > show: ' time ', ((time2 - time1) printString) , '<100'; tab; > > show: ' uuid ', (((uuid1 at: 10) + 1) printString, '=', (uuid2 at: 10) printString). > > ]. > > self assert: consecutiveOk. > > self assert: timeOk. > > > > From playground running... > > 1 to: 1000 do: [:n| > > NeoUUIDGeneratorTests new setUp testTwoSameGenerator: n]. > > Transcript crShow: 'x'. > > > > Note the 'x' was not output due to one of the consecutiveOk or timeOk asserts triggered each run. > > fail n=001 time 104<100 uuid 160=160 > > fail n=269 time 2<100 uuid 256=0 > > fail n=001 time 152<100 uuid 166=166 > > fail n=117 time 3<100 uuid 256=0 > > fail n=001 time 123<100 uuid 128=128 > > fail n=278 time 3<100 uuid 256=0 > > fail n=001 time 145<100 uuid 230=230 > > fail n=673 time 1340<100 uuid 141=141 > > fail n=707 time 3<100 uuid 256=0 > > fail n=001 time 132<100 uuid 73=73 > > fail n=001 time 117<100 uuid 206=206 > > fail n=063 time 2<100 uuid 256=0 > > fail n=345 time 3<100 uuid 256=0 > > > > Now a strange thing is that after commenting out those two asserts for consecutiveOk and timeOk, the fails at n=001 stop happening. > > > > fail n=001 time 141<100 uuid 232=232 > > x > > x > > fail n=201 time 3<100 uuid 256=0 > > fail n=268 time 3<100 uuid 256=0 > > fail n=359 time 3<100 uuid 256=0 > > fail n=408 time 2<100 uuid 256=0 > > fail n=559 time 3<100 uuid 256=0 > > x > > fail n=139 time 3<100 uuid 256=0 > > fail n=854 time 7<100 uuid 256=0 > > x > > fail n=389 time 3<100 uuid 256=0 > > fail n=669 time 3<100 uuid 256=0 > > fail n=876 time 3<100 uuid 256=0 > > fail n=916 time 3<100 uuid 256=0 > > fail n=953 time 2<100 uuid 256=0 > > fail n=954 time 3<100 uuid 256=0 > > x > > fail n=148 time 3<100 uuid 256=0 > > fail n=741 time 3<100 uuid 256=0 > > x > > fail n=116 time 2<100 uuid 256=0 > > fail n=480 time 3<100 uuid 256=0 > > x > > > > After treating the rollover like this... > > consecutiveOk := ((uuid1 at: 10) + 1) \\ 256 = (uuid2 at: 10). > > running the last playground script gives... > > > > (Note the n=001 fail reoccurs after waiting a while between running the playground script again.) > > fail n=001 time 123<100 uuid 110=110 > > x > > fail n=345 time 1287<100 uuid 24=24 > > fail n=404 time 1313<100 uuid 125=125 > > x > > x > > x > > x > > x > > fail n=449 time 1290<100 uuid 24=24 > > x > > x > > x > > x > > x > > > > > > Thats looking better, so upping to 10000 iterations... > > fail n=0001 time 151<100 uuid 160=160 > > fail n=2977 time 1437<100 uuid 221=221 > > fail n=5498 time 1454<100 uuid 224=224 > > fail n=9007 time 1351<100 uuid 239=239 > > x > > fail n=3389 time 1381<100 uuid 223=223 > > fail n=7768 time 1365<100 uuid 82=82 > > fail n=9773 time 1395<100 uuid 164=164 > > x > > fail n=3325 time 1448<100 uuid 67=67 > > fail n=9930 time 1456<100 uuid 103=103 > > x > > fail n=0060 time 2914<100 uuid 159=159 > > fail n=1829 time 1438<100 uuid 32=32 > > fail n=7918 time 1436<100 uuid 182=182 > > x > > > > So the rollover looks cured. > > > > Now adding some more instrumentation to view GC Time and Time To Run > > and (see attached ST file) > > > > 0:00:00:00 TTR 0:00:00:00.001 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 > > x > > fail n=0001 time 115<100 uuid 157=157 GCTime 0 TTR 0:00:00:00 > > fail n=0001 time 2<100 uuid 255=0 GCTime 0 TTR 0:00:00:00 > > x > > fail n=0001 time 111<100 uuid 104=104 GCTime 0 TTR 0 > > x > > fail n=0001 time 120<100 uuid 204=204 GCTime 0 TTR 0 > > fail n=0001 time 1182<100 uuid 103=103 GCTime 1 TTR 1 > > x > > x > > x > > x > > x > > fail n=0001 time 3<100 uuid 255=0 GCTime 0 TTR 0 > > x > > x > > fail n=0001 time 1251<100 uuid 253=253 GCTime 2 TTR 1 > > x > > > > > > Now I wonder at the class comment saying... > > "the first 8 bytes are the *millisecond* clock value" > > but #clockOn: is using *microsecond* clock. > > Perhaps "self assert: (time2 - time1) abs < 100" > > is meant to be 100ms not 100us ?? > > > > cheers -ben > > > > [1] https://pharo.fogbugz.com/f/cases/19438 > > [2] > > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/19471//artifac > > t/validationReport.html > > <NeoUUIDGeneratorTests-testTwoSameGenerator.st> > > > >

Dec. 11, 2016