January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] subexpression precedence

by Jan Vrany

Hi, I'm afraid this is not specified. There's no language specification (*) as such of PharoÂ or anyÂ other available smalltalk - at least not that I knowÂ (prove me ifÂ I'm wrong). Order in which subexpressions are evaluated is rarely specified. IIRC, JVM Spec doesn't specify it either. If the question was rather "How does it work inÂ current PharoÂ implementation?", then it's easy toÂ check, just add some sideffectsÂ to subexpressions (like Transcript show) and see in what orderÂ they're executed :-) (*) Specification in a sense of Java Language Spec,Â C# Language Specification, C99 Spec and so on. Jan On Wed, 2017-01-11 at 16:16 -0800, James Ladd wrote: > Hi Pharo People, > > I know Smalltalk has precedence rules when subexpressions () are > involved. > > 2 + (Â Â (3 * 4) - 1Â Â ) > evaluated last (Â Â Â (evaluated first)Â Â evaluated secondÂ Â ) > > That is the inner most subexpression is evaluated first. > > Given the following made up expression for the purposes of my > question: > > self at: (self offset) - 1 put: (2 * (12 / 4)). > > Are there precedence rules for the subexpressions that are part of > the > keyword expression? > ie: Should (self offset) - 1 be evaluated before (2 * (12 / 4)). > > My thinking is that with keywords the arguments are evaluated left to > right > - that isÂ > at: before put: but within each the regular subexpression precedence > applies? > > - James. > > > > > > > -- > View this message in context: http://forum.world.st/subexpression-pre > cedence-tp4929398.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. >

Jan. 12, 2017

subexpression precedence

by James Ladd

Hi Pharo People, I know Smalltalk has precedence rules when subexpressions () are involved. 2 + ( (3 * 4) - 1 ) evaluated last ( (evaluated first) evaluated second ) That is the inner most subexpression is evaluated first. Given the following made up expression for the purposes of my question: self at: (self offset) - 1 put: (2 * (12 / 4)). Are there precedence rules for the subexpressions that are part of the keyword expression? ie: Should (self offset) - 1 be evaluated before (2 * (12 / 4)). My thinking is that with keywords the arguments are evaluated left to right - that is at: before put: but within each the regular subexpression precedence applies? - James. -- View this message in context: http://forum.world.st/subexpression-precedence-tp4929398.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 12, 2017

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

by Sven Van Caekenberghe

OK, thanks, you are right; I was confused by the new filter option in senders, somehow I assumed the list was not longer (and I ignored the scroll bar) - weird. I see them now. Yes, both should be changed together. > On 11 Jan 2017, at 12:33, Henrik Nergaard <draagren(a)outlook.com> wrote: > > Both #head and #tail is used by MorphTreeNodeMorph (#expandPath: and #matchPath:) to select items deeper inside the tree structure and then expanding to this. > ------------------------------------------------------------------------- > | model morph | > model := ClassTreeExample new. > model openOn: Morph. > model selectItems: { Morph -> BorderedMorph -> AlignmentMorph }. > ------------------------------------------------------------------------- > > Changing one should not be done without the other. > > Best regards, > Henrik > > -----Opprinnelig melding----- > Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Sven Van Caekenberghe > Sendt: 11 January 2017 11:56 > Til: Pharo Development List <pharo-dev(a)lists.pharo.org> > Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell > > All good and well, but maybe its me, but I can't see where it is being used ... > >> On 11 Jan 2017, at 11:46, Henrik Nergaard <draagren(a)outlook.com> wrote: >> >> And Object/Association >> #tail >> >> Best regards, >> Henrik >> >> -----Opprinnelig melding----- >> Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Esteban Lorenzano >> Sendt: 11 January 2017 10:13 >> Til: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell >> >> >>> On 11 Jan 2017, at 10:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> at least we should rename it as âtreeMorphHeadââ¦ just âheadâ is too generic. >> >> âtreeNodeHeadâ I meant. >> >>> >>> Esteban >>> >>> >>>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> >>>>> On 11 Jan 2017, at 09:55, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> >>>>>> But why the hell would there be a Object>>#head ?! >>>>>> >>>>>> IMHO such general selectors at this level should not be used unless there is a very good reason to do so. >>>>>> >>>>> >>>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in >>>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke it. >>>>> >>>>> Thx >>>>> T. >>>> >>>> Looking in a 6 image, there is also an even uglier implementation in >>>> >>>> Association>>#head >>>> >>>> ^ (key isKindOf: Association) >>>> ifTrue: [ key head ] >>>> ifFalse: [ key ] >>>> >>>> Duh. >>>> >>>> And I can't seen any senders... >>>> >>>> >>> >> >> > >

Jan. 11, 2017

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

by Henrik Nergaard

Both #head and #tail is used by MorphTreeNodeMorph (#expandPath: and #matchPath:) to select items deeper inside the tree structure and then expanding to this. ------------------------------------------------------------------------- | model morph | model := ClassTreeExample new. model openOn: Morph. model selectItems: { Morph -> BorderedMorph -> AlignmentMorph }. ------------------------------------------------------------------------- Changing one should not be done without the other. Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Sven Van Caekenberghe Sendt: 11 January 2017 11:56 Til: Pharo Development List <pharo-dev(a)lists.pharo.org> Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell All good and well, but maybe its me, but I can't see where it is being used ... > On 11 Jan 2017, at 11:46, Henrik Nergaard <draagren(a)outlook.com> wrote: > > And Object/Association >> #tail > > Best regards, > Henrik > > -----Opprinnelig melding----- > Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Esteban Lorenzano > Sendt: 11 January 2017 10:13 > Til: Pharo Development List <pharo-dev(a)lists.pharo.org> > Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell > > >> On 11 Jan 2017, at 10:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> at least we should rename it as âtreeMorphHeadââ¦ just âheadâ is too generic. > > âtreeNodeHeadâ I meant. > >> >> Esteban >> >> >>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 11 Jan 2017, at 09:55, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>>> But why the hell would there be a Object>>#head ?! >>>>> >>>>> IMHO such general selectors at this level should not be used unless there is a very good reason to do so. >>>>> >>>> >>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in >>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke it. >>>> >>>> Thx >>>> T. >>> >>> Looking in a 6 image, there is also an even uglier implementation in >>> >>> Association>>#head >>> >>> ^ (key isKindOf: Association) >>> ifTrue: [ key head ] >>> ifFalse: [ key ] >>> >>> Duh. >>> >>> And I can't seen any senders... >>> >>> >> > >

Jan. 11, 2017

Looking for Pharo devs

by miron＠tutanota.de

Hello, Looking for someone with thorough Pharo experience for some experimental changes to the Pharo environment and language. Some areas you will expertise in: 1. Syntax parser.2. AST.3. Thorough overall environment knowledge. For more details send an e-mail to miron(a)tutanota.de.

Jan. 11, 2017

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

by Sven Van Caekenberghe

All good and well, but maybe its me, but I can't see where it is being used ... > On 11 Jan 2017, at 11:46, Henrik Nergaard <draagren(a)outlook.com> wrote: > > And Object/Association >> #tail > > Best regards, > Henrik > > -----Opprinnelig melding----- > Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Esteban Lorenzano > Sendt: 11 January 2017 10:13 > Til: Pharo Development List <pharo-dev(a)lists.pharo.org> > Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell > > >> On 11 Jan 2017, at 10:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> at least we should rename it as âtreeMorphHeadââ¦ just âheadâ is too generic. > > âtreeNodeHeadâ I meant. > >> >> Esteban >> >> >>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 11 Jan 2017, at 09:55, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>>> But why the hell would there be a Object>>#head ?! >>>>> >>>>> IMHO such general selectors at this level should not be used unless there is a very good reason to do so. >>>>> >>>> >>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in >>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke it. >>>> >>>> Thx >>>> T. >>> >>> Looking in a 6 image, there is also an even uglier implementation in >>> >>> Association>>#head >>> >>> ^ (key isKindOf: Association) >>> ifTrue: [ key head ] >>> ifFalse: [ key ] >>> >>> Duh. >>> >>> And I can't seen any senders... >>> >>> >> > >

Jan. 11, 2017

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

by Esteban Lorenzano

in general, rule of thumb when extending classes should be âuse the most specific name possibleâ, for instance: #magritteDescription instead of #description, etc. but everybody makes mistakesâ¦ in voyage I added methods #save, #remove instead a #voyageSave, #voyageRemoveâ¦ one could argue that since that is *not* part of the image is ok, but no: is a framework so possibility of collisions are always there (of course, when doing your own project methods is another thingsâ¦ and Iâm sure I can find other exceptionsâ¦ but as I said â¦ âin generalâ) Esteban > On 11 Jan 2017, at 11:46, Henrik Nergaard <draagren(a)outlook.com> wrote: > > And Object/Association >> #tail > > Best regards, > Henrik > > -----Opprinnelig melding----- > Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Esteban Lorenzano > Sendt: 11 January 2017 10:13 > Til: Pharo Development List <pharo-dev(a)lists.pharo.org> > Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell > > >> On 11 Jan 2017, at 10:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> at least we should rename it as âtreeMorphHeadââ¦ just âheadâ is too generic. > > âtreeNodeHeadâ I meant. > >> >> Esteban >> >> >>> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 11 Jan 2017, at 09:55, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>>> But why the hell would there be a Object>>#head ?! >>>>> >>>>> IMHO such general selectors at this level should not be used unless there is a very good reason to do so. >>>>> >>>> >>>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in >>>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke it. >>>> >>>> Thx >>>> T. >>> >>> Looking in a 6 image, there is also an even uglier implementation in >>> >>> Association>>#head >>> >>> ^ (key isKindOf: Association) >>> ifTrue: [ key head ] >>> ifFalse: [ key ] >>> >>> Duh. >>> >>> And I can't seen any senders... >>> >>> >> > >

Jan. 11, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Cyril Ferlicot D.

On 04/01/2017 15:48, Stephane Ducasse wrote: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef Hi Stef, I updated MDL to be up to date. I just need to add a "CONTRIBUTING.md" file and it should be good for students. - WebPage: For now it is https://github.com/DuneSt/MaterialDesignLite - Mailing list: Pharo-user or Seaside - Bug Tracker: https://github.com/DuneSt/MaterialDesignLite/issues I still need to think of some features suitable for L3 students and to document them. I begun to add an OpenDev label if some students are interested: https://github.com/DuneSt/MaterialDesignLite/issues?q=is%3Aissue+is%3Aopen+… -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Jan. 11, 2017

Re: [Pharo-dev] Strange DNU effect on Windows with Pastell

by Henrik Nergaard

And Object/Association >> #tail Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Esteban Lorenzano Sendt: 11 January 2017 10:13 Til: Pharo Development List <pharo-dev(a)lists.pharo.org> Emne: Re: [Pharo-dev] Strange DNU effect on Windows with Pastell > On 11 Jan 2017, at 10:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > at least we should rename it as âtreeMorphHeadââ¦ just âheadâ is too generic. âtreeNodeHeadâ I meant. > > Esteban > > >> On 11 Jan 2017, at 10:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 11 Jan 2017, at 09:55, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>>> But why the hell would there be a Object>>#head ?! >>>> >>>> IMHO such general selectors at this level should not be used unless there is a very good reason to do so. >>>> >>> >>> Yes - some Morphic addition. Version says: BenjaminVanRyseghem in >>> 2013 Only used in MorphTreeNodeMorph and to me this smells. We should nuke it. >>> >>> Thx >>> T. >> >> Looking in a 6 image, there is also an even uglier implementation in >> >> Association>>#head >> >> ^ (key isKindOf: Association) >> ifTrue: [ key head ] >> ifFalse: [ key ] >> >> Duh. >> >> And I can't seen any senders... >> >> >

Jan. 11, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60343 Home: https://github.com/pharo-project/pharo-core

Jan. 11, 2017