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

Re: [Pharo-users] Voyage and instances retrieving

by Hilaire

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

Re: [Pharo-users] Voyage and duplicated entry

by Norbert Hartl

> Am 06.03.2017 um 18:10 schrieb jtuchel(a)objektfabrik.de: > > Hilaire, > > as soon as the hash of an object changes because you change an attribute that is used in the hash function, the object is not identical to its older ego any more, so Voyage cannot know it still is the same object (nor any other caching solution). > Or am I wrong about this whole hash/= thing? > Yes :) You are mixing equality and identity. An object is identical if the memory location is the same. An object is equal whatever is defined in =/hash. In the default case classes do not overwrite =/hash so = and == return the same value. If you change the state of an object you might change the hash but not the identityHash. So it is identical but different to the version in the database hence should update the existing object and not creating a new one. > The only thing I could imagine is that Voyage somewhere uses = where it should use ==. But wouldn't many more people have problems then? > The problem is that we often use equality based collections where we should use identity based ones. These problems are hidden because = and == are the same for normal classes. As soon as you overwrite =/hash you experience problems because of that. So I have the impression that in general overwriting =/hash is not a good idea. Most of the time you mean "equal regarding to some context". In this case it is better to have your own equality selector like #isSameX:, #hasSameX: etc. Because the kernel classes rely on = equality you tear the semantics apart if yoou overwrite. Norbert > Joachim > > > > Am 06.03.17 um 18:03 schrieb Hilaire: >> The more I think the more it seems wrong to me. Whenever you ask an >> instance to save itself, if already in repo it should not duplicate >> itself whenever hash/= is overrided in this object. It does not sound as >> an expected behaviour. >> >> Hilaire >> >> Le 05/03/2017 Ã 14:51, Hilaire a Ã©crit : >>> Understood. >>> My use/understanding of hash and =, true in DrGeo, was more like unique >>> identifier regarding its ontological characteristics (what distinguish >>> it from other). So an exact same Point in DrGeo will have different hash >>> value depending on its position on the plane, or it being free on a >>> line, etc. May be I got it biased here. >>> >>> Anyway problem solved, comparing protocol was just rampant code. > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 6, 2017

Re: [Pharo-users] Voyage and duplicated entry

by Norbert Hartl

Hilaire, I think you are right and I wonder why we didn't change it, yet. I can remember talking with Esteban about it. The culprit is that in VOCache the reversedObjects instance variable is a WeakKeyDictionary and not a WeakIdentityKeyDictionary. That is the reason why #isNew on an object returns true if equality is not the same. And this leads to object duplication. The whole purpose of the VOCache is to keep "identity" for the objects. So using an equality based collection is plain wrong. Norbert > Am 06.03.2017 um 18:03 schrieb Hilaire <hilaire(a)drgeo.eu>: > > The more I think the more it seems wrong to me. Whenever you ask an > instance to save itself, if already in repo it should not duplicate > itself whenever hash/= is overrided in this object. It does not sound as > an expected behaviour. > > Hilaire > > Le 05/03/2017 Ã 14:51, Hilaire a Ã©crit : >> Understood. >> My use/understanding of hash and =, true in DrGeo, was more like unique >> identifier regarding its ontological characteristics (what distinguish >> it from other). So an exact same Point in DrGeo will have different hash >> value depending on its position on the plane, or it being free on a >> line, etc. May be I got it biased here. >> >> Anyway problem solved, comparing protocol was just rampant code. > > -- > Dr. Geo > http://drgeo.eu > >

March 6, 2017

Re: [Pharo-users] Voyage and duplicated entry

by jtuchel＠objektfabrik.de

What about a simple test? Load one of those objects anad assign it to a variable. Then change one of ist values and check if the one you have now is still == the other. ..it's a bit hard to explain, but I guess you know what I mean. Joachim Am 06.03.17 um 18:03 schrieb Hilaire: > The more I think the more it seems wrong to me. Whenever you ask an > instance to save itself, if already in repo it should not duplicate > itself whenever hash/= is overrided in this object. It does not sound as > an expected behaviour. > > Hilaire > > Le 05/03/2017 Ã 14:51, Hilaire a Ã©crit : >> Understood. >> My use/understanding of hash and =, true in DrGeo, was more like unique >> identifier regarding its ontological characteristics (what distinguish >> it from other). So an exact same Point in DrGeo will have different hash >> value depending on its position on the plane, or it being free on a >> line, etc. May be I got it biased here. >> >> Anyway problem solved, comparing protocol was just rampant code. -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 6, 2017

Re: [Pharo-users] Voyage and duplicated entry

by jtuchel＠objektfabrik.de

Hilaire, as soon as the hash of an object changes because you change an attribute that is used in the hash function, the object is not identical to its older ego any more, so Voyage cannot know it still is the same object (nor any other caching solution). Or am I wrong about this whole hash/= thing? The only thing I could imagine is that Voyage somewhere uses = where it should use ==. But wouldn't many more people have problems then? Joachim Am 06.03.17 um 18:03 schrieb Hilaire: > The more I think the more it seems wrong to me. Whenever you ask an > instance to save itself, if already in repo it should not duplicate > itself whenever hash/= is overrided in this object. It does not sound as > an expected behaviour. > > Hilaire > > Le 05/03/2017 Ã 14:51, Hilaire a Ã©crit : >> Understood. >> My use/understanding of hash and =, true in DrGeo, was more like unique >> identifier regarding its ontological characteristics (what distinguish >> it from other). So an exact same Point in DrGeo will have different hash >> value depending on its position on the plane, or it being free on a >> line, etc. May be I got it biased here. >> >> Anyway problem solved, comparing protocol was just rampant code. -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 6, 2017

Re: [Pharo-users] Voyage and duplicated entry

by Hilaire

The more I think the more it seems wrong to me. Whenever you ask an instance to save itself, if already in repo it should not duplicate itself whenever hash/= is overrided in this object. It does not sound as an expected behaviour. Hilaire Le 05/03/2017 Ã 14:51, Hilaire a Ã©crit : > Understood. > My use/understanding of hash and =, true in DrGeo, was more like unique > identifier regarding its ontological characteristics (what distinguish > it from other). So an exact same Point in DrGeo will have different hash > value depending on its position on the plane, or it being free on a > line, etc. May be I got it biased here. > > Anyway problem solved, comparing protocol was just rampant code. -- Dr. Geo http://drgeo.eu

March 6, 2017

[ANN] Pharo Tech Talk March 28

by denker

A regular chat about Pharo. Happens on Discord. The Tech talks are open to both members and non-members! Topic: Round-Table Pharo 6 https://association.pharo.org/event-2487224

March 6, 2017

[ANN] Pharo Sprint March 31

by denker

Pharo Sprint March 31 We will organize a Pharo sprint / Moose dojo March, 31, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Clean issue tracker to prepare for release Pharo6 â¢ Prepare Pharo 7 https://association.pharo.org/event-2487210

March 6, 2017

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

by Ben Coman

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

MOOC english subtitles

by Ben Coman

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. 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. cheers -ben [1] https://github.com/SquareBracketAssociates/PharoMooc/blob/master/Subtitles/…

March 6, 2017