March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Automatic code refactoring in Pharo 5.0?

by Paul DeBruicker

It sounds like the changes file for your image is missing. Could that be possible? Marco Naddeo wrote > Hi, > > I'm using Pharo 5.0 and sometimes looking to code I previously wrote, I > realize that all local variables have been renamed as tmp1, tmp2, tmp3, > and so on; or that the arguments of a block have been renamed as arg1, > arg2, arg3, and so on. > > I don't understand if some automatic refactoring of the code is enabled > (and when it would be eventually executed, because such renaming of > variables does not happen immediately after saving), I had a look to the > System Settings but I could not figure it out. > > Could you please help me? > > Marco -- View this message in context: http://forum.world.st/Automatic-code-refactoring-in-Pharo-5-0-tp4937505p493… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 6, 2017

Re: [Pharo-users] adding messages dinamically to a single instance object

by Pablo R. Digonzelli

Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "stepharong" <stepharong(a)free.fr> Para: "Pablo Digonzelli" <pdigonzelli(a)gmail.com> CC: "Steven Costiou" <steven.costiou(a)kloum.io>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: Lunes, 6 de Marzo 2017 17:39:08 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object On Mon, 06 Mar 2017 05:19:35 +0100, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: Hi Stef. I was reading your link. I found it very interesting . Black magic is seductive :) But it burns your soul :) Look like a good black sabbath song BQ_BEGIN I think i will working in that direction having in mind your advise. Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "stepharong" <stepharong(a)free.fr> Para: "Steven Costiou" <steven.costiou(a)kloum.io>, "Pablo Digonzelli" <pdigonzelli(a)gmail.com>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: SÃ¡bado, 4 de Marzo 2017 6:18:24 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object It is really possible and we are working on a new implementation of talents based on anonymous classes. Now what you should know is that - i would use this mechanism for debugging/tooling - i would try to avoid this as much as possible for domain modeling because it breaks all the hidden assumptions we have. stef BQ_BEGIN Hi Steven . For the moment i just want to understand how it is possible. In the future may be i can apply this mechanism for future projects. Pablo Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Steven Costiou" <steven.costiou(a)kloum.io> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: "Pablo Digonzelli" <pdigonzelli(a)gmail.com> Enviados: Viernes, 3 de Marzo 2017 11:03:23 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object Hi, could you describe why you need this ? Do you have a usecase ? Just interested to know, as i work on similar mechanisms. Steven. Le 2017-03-03 14:55, Pablo R. Digonzelli a Ã©crit : BQ_BEGIN Thanks Denis, I will take a look . I think this is what i need. Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 De: "Denis Kudriashov" <dionisiydk(a)gmail.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: Viernes, 3 de Marzo 2017 10:11:53 Asunto: Re: [Pharo-users] adding messages dinamically to a single instance object Hi. Look at project Talents https://github.com/tesonep/pharo-talents . Idea is to implement behaviour (also with state) in normal way with classes and then dynamically install it to any existing objects 2017-03-03 14:07 GMT+01:00 Pablo R. Digonzelli < pdigonzelli(a)gmail.com > : BQ_BEGIN Hi all. I need to know how can i do if i want add new behaviour ( a new method ) to a single instance object of a class. It means not to add new selector to the class but i want a single instance responds that mesage. Where can i read about it? Tia Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 BQ_END BQ_END -- kloum.io BQ_END -- Using Opera's mail client: http://www.opera.com/mail/ BQ_END -- Using Opera's mail client: http://www.opera.com/mail/

March 6, 2017

Re: [Pharo-users] adding messages dinamically to a single instance object

by stepharong

On Mon, 06 Mar 2017 05:19:35 +0100, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > Hi Stef. I was reading your link. > I found it very interesting . Black magic is seductive :) But it burns your soul :) Look like a good black sabbath song > I think i will working in that direction having in mind your advise. > Tia > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Dividato SA 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > De: "stepharong" <stepharong(a)free.fr> > Para: "Steven Costiou" <steven.costiou(a)kloum.io>, "Pablo Digonzelli" > <pdigonzelli(a)gmail.com>, "Any question about pharo is >welcome" > <pharo-users(a)lists.pharo.org> > Enviados: SÃ¡bado, 4 de Marzo 2017 6:18:24 > Asunto: Re: [Pharo-users] adding messages dinamically to a single > instance object > > > It is really possible and we are working on a new implementation of > talents based on anonymous classes.Now what you should know is that- i > would use this mechanism for debugging/tooling > - i would try to avoid this as much as possible for domain modeling > because > it breaks all the hidden assumptions we have. > stef > > >> Hi Steven . For the moment i just want to understand how it is possible. >> In the future may be i can apply this mechanism for future projects. >> >> Pablo >> >> Ing. Pablo Digonzelli >> Software Solutions >> IP-Solutiones SRL >> Dividato SA 25 de Mayo 521 >> San Miguel de TucumÃ¡n >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> >> De: "Steven Costiou" <steven.costiou(a)kloum.io> >> Para: "Any question about pharo is welcome" >> <pharo-users(a)lists.pharo.org> >> CC: "Pablo Digonzelli" <pdigonzelli(a)gmail.com> >> Enviados: Viernes, 3 de Marzo 2017 11:03:23 >> Asunto: Re: [Pharo-users] adding messages dinamically to a single >> instance object >> >> >> Hi, >> >> could you describe why you need this ? Do you have a usecase ? >> >> Just interested to know, as i work on similar mechanisms. >> >> Steven. >> >> >> Le 2017-03-03 14:55, Pablo R. Digonzelli a Ã©crit : >>> Thanks Denis, I will take a look . I think this is what i need. >>>Tia >>>Ing. Pablo Digonzelli >>> Software Solutions >>> IP-Solutiones SRL >>> Dividato SA 25 de Mayo 521 >>> San Miguel de TucumÃ¡n >>> Email: pdigonzelli(a)softsargentina.com >>> pdigonzelli(a)gmail.com >>> Cel: 5493815982714 >>> >>> De: "Denis Kudriashov" <dionisiydk(a)gmail.com> >>> Para: "Any question about pharo is welcome" >>> <pharo-users(a)lists.pharo.org> >>> Enviados: Viernes, 3 de Marzo 2017 10:11:53 >>> Asunto: Re: [Pharo-users] adding messages dinamically to a single >>> instance object >>> >>> Hi. >>> Look at project Talents https://github.com/tesonep/pharo-talents. >>> Idea is to implement behaviour (also with state) in normal way with >>> classes and then dynamically install it to any existing objects >>> >>> 2017-03-03 14:07 GMT+01:00 Pablo R. Digonzelli <pdigonzelli(a)gmail.com>: >>>> Hi all. I need to know how can i do if i want add new behaviour ( a >>>> new method ) to a single instance object of a class.It means not to >>>> add new selector to the class but i want a single instance responds >>>> that mesage.Where can i read about it? >>>> Tia >>>> >>>> Ing. Pablo Digonzelli >>>> Software Solutions >>>> IP-Solutiones SRL >>>> Dividato SA 25 de Mayo 521 >>>> San Miguel de TucumÃ¡n >>>> Email: pdigonzelli(a)softsargentina.com >>>> pdigonzelli(a)gmail.com >>>> Cel: 5493815982714 >> >>--kloum.io >> > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Using Opera's mail client: http://www.opera.com/mail/

March 6, 2017

Re: [Pharo-users] MOOC english subtitles

by stepharong

> May I do a pass over the english subtitles for the MOOC? > With the limited space and reading time you get with subtitles, > I see some things I could fine-tune. Of course. A company did them and we were really happy because french :) Now I wonder how we can make sure that we keep the modified file clearly distinguishable from the old one. I suggest that you copy the file and add a -v2.srt Stef > > One query on content, from [1] it says there are "good comments" > when I'd guess it would say "poor comments" from there being no class > comment > > 16 > 00:00:49,830 --> 00:00:51,920 > The system searches a little > and says that there are > 17 > 00:00:53,200 --> 00:00:56,290 > good comments. We will see this later. > For the moment, we donât care. probably wrong :) > > cheers -ben > > [1] > https://github.com/SquareBracketAssociates/PharoMooc/blob/master/Subtitles/… > -- Using Opera's mail client: http://www.opera.com/mail/

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Martin McClure

On 03/06/2017 11:17 AM, Igor Stasenko wrote: > You got me with this... > Hey, stop confusing people, put #== everywhere! :) > > But if seriously, #assert:equals: hides this detail from us, that's why > it looks confusing.. > IMO, for given case it would be better to use just straight #assert:, > with explicit expression that using #= for comparands. assert: (anExpression = someOtherExpression) may, in some cases, be slightly more intention-revealing than assert: anExpression equals: someOtherExpression However, I'd like to advocate for the latter, for ease of debugging. I've been in too many situations where a test fails an equality test, and the failure is not easily reproducible. In the debugger, if #assert: was used I'm left with "false" as my only clue to what happened. OTOH, if #assert:equals: was used, I have both the expected value and the actual value in the debugger, which is a much better clue as to the nature of the problem. Regards, -Martin

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Igor Stasenko

On 6 March 2017 at 15:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 6 Mar 2017, at 14:12, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > > > On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Here is a concrete proposal: > > > > https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol- > concatenation-results-in-a-Symbol-not-a-String > > > > This gives the following assertions: > > > > "Concatenating 2 symbols results in abother symbol" > > self assert: (#foo , #bar) == #foobar. > > > > "Concatenating the empty symbol does not change a symbol" > > self assert: (#foo, emptySymbol) == #foo. > > self assert: (emptySymbol, #foo) == #foo. > > > > "Strings and symbols can still be mixed, the receiver determines > the result type" > > "Symbol receiver gives symbol result" > > self assert: (#foo , 'bar') == #foobar. > > "String receiver gives string result" > > self deny: ('foo' , #bar) == #foobar. > > self assert: ('foo' , #bar) equals: #foobar. > > self assert: ('foo' , #bar) equals: 'foobar'. > > > > > > Those last two seem contradictory. > > No, Symbols and String can be used interchangeably in Pharo in lots of > contexts. Particularly when comparing them, it makes no difference, all the > following are/have always been true, independent of this change: > > #foo = 'foo' > 'foo' = #foo > #foo = #foo > 'foo' = 'foo' > > But maybe it is a bit confusing with an extra comment. > > You got me with this... Hey, stop confusing people, put #== everywhere! :) But if seriously, #assert:equals: hides this detail from us, that's why it looks confusing.. IMO, for given case it would be better to use just straight #assert:, with explicit expression that using #= for comparands. -- Best regards, Igor Stasenko.

March 6, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Sven Van Caekenberghe

Ben, I tried to avoid #isString and #isSymbol and I thought it was clear that #assert:equals: used #= but I agree that I could be more explicit. Here is the changed version of the unit test (.2 of slice): testConcatenationIsSymbol "Concatenating 2 symbols results in another symbol" self assert: (#foo , #bar) isSymbol. self assert: (#foo , #bar) == #foobar. "Concatenating the empty Symbol does not change a Symbol" self assert: (#foo , emptySymbol) == #foo. self assert: (emptySymbol , #foo) == #foo. "Strings and Symbols can still be mixed, the receiver determines the result type" "Symbol receiver gives Symbol result" self assert: (#foo , 'bar') isSymbol. self assert: (#foo , 'bar') == #foobar. "String receiver gives String result" self assert: ('foo' , #bar) isString. self assert: ('foo' , #bar) = 'foobar'. "Strings and Symbols still compare content-wise" self assert: ('foo' , #bar) = #foobar. "But Strings and Symbols are not identical" self deny: ('foo' , #bar) == #foobar. > On 6 Mar 2017, at 15:18, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Mar 6, 2017 at 9:21 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 6 Mar 2017, at 14:12, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Here is a concrete proposal: >>> >>> https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resu… >>> >>> This gives the following assertions: >>> >>> "Concatenating 2 symbols results in abother symbol" >>> self assert: (#foo , #bar) == #foobar. >>> >>> "Concatenating the empty symbol does not change a symbol" >>> self assert: (#foo, emptySymbol) == #foo. >>> self assert: (emptySymbol, #foo) == #foo. >>> >>> "Strings and symbols can still be mixed, the receiver determines the result type" >>> "Symbol receiver gives symbol result" >>> self assert: (#foo , 'bar') == #foobar. >>> "String receiver gives string result" >>> self deny: ('foo' , #bar) == #foobar. >>> self assert: ('foo' , #bar) equals: #foobar. >>> self assert: ('foo' , #bar) equals: 'foobar'. >>> >>> >>> Those last two seem contradictory. >> >> No, Symbols and String can be used interchangeably in Pharo in lots of contexts. Particularly when comparing them, it makes no difference, all the following are/have always been true, independent of this change: >> >> #foo = 'foo' >> 'foo' = #foo >> #foo = #foo >> 'foo' = 'foo' > > Ah-ha... gotchya. always something more to learn. > > So those last three lines a testing that it is a String? > This meaning is pretty well hidden in the implicit behaviour. > Why not just... > self assert: (#foo , 'bar') isString > which seems to better "says what it means" > > If such is poor form in general, > I'm curious to what degree such rules may be relaxed for unit tests. > Could it be considered something like premature optimisation > to make the test too generic?? If isString latter causes a problem later, > deal with it then. > > ==== > On another slightly different point, > this might be one case where #assert:#equals is less clear than using "=" > > Its also easy to mis-think the following is contradictory >>> self deny: ('foo' , #bar) == #foobar. >>> self assert: ('foo' , #bar) equals: #foobar. > > where the alternative here makes the distinction more clear... > self deny: ('foo' , #bar) == #foobar. > self assert: ('foo' , #bar) = #foobar. > > > cheers -ben

March 6, 2017

Re: [Pharo-users] Voyage and instances retrieving

by Esteban Lorenzano

> On 6 Mar 2017, at 18:56, Hilaire <hilaire(a)drgeo.eu> wrote: > > Ah, sorry I was not clear enough in my introduction. Obviously, I > removed all =/hash overrides on the involved objects and it is therefore > an orthogonal issue (that's why I first resolved the other issues > first). Or did you mean something I did not understand in your previous > message? no, I didnât understood you removed #= and #hash :) > > Hilaire > > Le 06/03/2017 Ã 18:45, Esteban Lorenzano a Ã©crit : >> just as a side note: >> >> you must NEVER do a hash based in an attribute that might change. You will screw not just Voyage but all collections where your object is stored (except Array). >> >> Esteban > > -- > Dr. Geo > http://drgeo.eu > >

March 6, 2017

Re: [Pharo-users] Voyage and instances retrieving

by Hilaire

Ah, sorry I was not clear enough in my introduction. Obviously, I removed all =/hash overrides on the involved objects and it is therefore an orthogonal issue (that's why I first resolved the other issues first). Or did you mean something I did not understand in your previous message? Hilaire Le 06/03/2017 Ã 18:45, Esteban Lorenzano a Ã©crit : > just as a side note: > > you must NEVER do a hash based in an attribute that might change. You will screw not just Voyage but all collections where your object is stored (except Array). > > Esteban -- Dr. Geo http://drgeo.eu

March 6, 2017

Re: [Pharo-users] Voyage and instances retrieving

by Esteban Lorenzano

just as a side note: you must NEVER do a hash based in an attribute that might change. You will screw not just Voyage but all collections where your object is stored (except Array). Esteban > On 6 Mar 2017, at 18:34, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 03/03/2017 Ã 18:09, Hilaire a Ã©crit : >> I will try to dig for more clues. > > Now that I clarified the issues regarding duplicated entries and Date. I > took another look to this problem. > > After reset of the repo, to test for sure Voyage correctly retrieves the > attributes, I face the same issue again. The attributes of an object, > itself a collection attribute of an object in the repo, are not > materialized. > > The code bellow does not work as expected. Some details on the involved > object: > someAdults is a collection of adult objects (saved in their own > Participant collection in the repo and already retrieved); expenses is > an attribute of a Contract instance (the later save in its own > collection too); owner returns an adult,and I think it is the one that > does not materialize. > >> expensesOf: someAdults >> ^ expenses select: [ :anExpense | someAdults includes: anExpense owner] > > > Voyage appears to be lazy to materialize it, and indeed the changed code > bellow makes the materialization to take place: > > >> expensesOf: someAdults >> ^ expenses select: [ :anExpense | someAdults includes: anExpense owner value ] > > Of course it can't be a solution because I will not know for sure when > selection will work or fail. So far I only see the problem in two > places, and I have a lot of selection code. > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >

March 6, 2017