August 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] a basic hash question

by James Foster

@Richard OâKeefe: Iâm trying to find the place in the ANSI Standard you are citing. All Iâve found so far is at 5.3.1.1: The meaning of "equivalent" cannot be precisely defined but the intent is that two objects are considered equivalent if they can be used interchangeably. Conforming protocols may choose to more precisely define the meaning of "equivalentâ. Can you provide a reference for your assertion that objects must be of the same class in order to be equivalent? How about other comparisons between objects of different classes? Is 1.9 < 2? Is 2.1 > 2? How about 2.0 = 2? Is #a < âbâ? is #b > âaâ? How about #a = âaâ? It seems strange to suggest that an object can be less than or greater than, but not equal to! James > On Jul 31, 2018, at 9:24 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > @James Foster: 100%. There are no exceptions > > On 1 August 2018 at 02:05, James Foster <Smalltalk(a)jgfoster.net <mailto:Smalltalk@jgfoster.net>> wrote: > To what extent is it required by ANSI that objects be of the same class?

Aug. 1, 2018

Re: [Pharo-users] a basic hash question

by Richard O'Keefe

@James Foster: 100%. There are no exceptions. @John Pferisch: the GNU Smalltalk web site hosted an attempt to update the ANSI standard for a while. I was on the mailing list. I had to be away from it for a bit and when I came back wanting to upload my contribution it had all gone. There *is* a lot that is already shared or could be shared at low cost, but trawling through Smalltalks is pretty labour- intensive so such a project needs money. We are still seeing crazy date & time classes and even Complex classes purporting to inherit Magnitude. On 1 August 2018 at 02:05, James Foster <Smalltalk(a)jgfoster.net> wrote: > To what extent is it required by ANSI that objects be of the same class? > Does Pharo treat a String and a Symbol as equivalent if they have the same > characters? > > James > > > On Jul 30, 2018, at 10:59 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I do not think that (1 to: 4) and #(1 2 3 4) should be equal. > Let me put it a little more strongly: it's a bug. > Taking > a := 1 to: 4. > b := Array withAll: a. > c := OrderedCollection withAll: b. > in the two other Smalltalk systems I just tried, > no two of these are equal. This is what the ANSI > Smalltalk standard requires. Ceteris paribus, > two sequences are equivalent if and only if > 1. they are instance of the same class > 2. they have the same size > 3. corresponding elements are equivalent. > It is fairly common for Smalltalk systems to distinguish > between "these sequences are equivalent" and "these > sequences have the same elements in the same order", > with no consensus on the name of the second method. > One calls it #sameContentsAs:, Squeak #hasEqualElements:. > > > On 31 July 2018 at 00:07, werner kassens <wkassens(a)libello.com> wrote: > >> Hi, >> i guess i can subsume almost everything i know about hashes in one >> sentence: >> it is my understanding that two objects that are equal (obj1=obj2. >> -->true) have to have the same hash value (which is used for some >> collection types), whereas objects where obj1=obj2 returns false should >> have different hash values although it may happen that they have the >> same one. >> >> now here things don't turn out exactly like that: >> (1 to:4) = #(1 2 3 4). "true" >> (1 to:4)hash = #(1 2 3 4)hash. "false" >> well ok, actually these results make - pfffh, in a certain way - sense >> to me, but i wonder what arguments the people in the know would use to >> defend that result, if i would have another opinion? >> werner >> >> >> > >

Aug. 1, 2018

Re: [Pharo-users] transactions on pharo objects

by Richard O'Keefe

Norbert Hartl wrote: > the biggest problem with a copy approach is that all identity checks fail with the copied objects The scheme I proposed *hides* the (shallow) copies. The only thing ever done with them is to copy their contents back into the original objects. There are therefore no "identity checks ... with the copied objects" for anyone to care about. On 31 July 2018 at 18:47, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 31.07.2018 um 06:57 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > Basically, what you are talking about is Software Transactional Memory. > According to https://en.wikipedia.org/wiki/Software_transactional_ > memory#Smalltalk > there *is* STM support for Pharo at > http://source.lukas-renggli.ch/transactional/ > although the last version there is from 2012, and there have been major > changes to Pharo > since then, so it probably doesn't work any longer. > > You could probably make a TransactionalObject class with a > 'lastTransaction' > instance variable, and a noteChange method that checks if lastTransaction > == > Transaction current, and if not, pushes self -> self shallowCopy onto a > stack > inside Transaction and sets lastTransaction to Transaction current. Then > to > roll back a transaction, peel back original -> backup records from the > stack > and do original copyFrom: backup for each of them. > > Please don't ask me to think about combining this with concurrency. > > You could delegate the transaction list and other objects to a process > specific variable. But the biggest problem with a copy approach is that all > identity checks fail with the copied objects > > Norbert > > On 31 July 2018 at 01:16, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> is there some library or approach how to do transactions in pharo? >> And I don't mean database transactions, but directly in memory on Pharo >> objects... e.g. >> >> p := Person new. >> >> transaction do: [ >> p name: 'Nobody'. >> p age: 70. >> ] on: Error do: [ >> transaction rollback. >> ]. >> >> self assert: p name equals: 'Nobody'. >> self assert: p age equals: 70. >> >> transaction do: [ >> p name: 'Somebody'. >> p age: 1 / 0. >> ] on: Error do: [ >> transaction rollback. >> ]. >> >> self assert: p name equals: 'Nobody'. >> self assert: p age equals: 70. >> >> Any pointers appreciated. >> >> Thanks, >> Peter >> > >

Aug. 1, 2018