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

ZnCharacterWriteStream â is it a WriteStream?

by Andrew P. Black

Iâm making a stream to write on a file using outputFile := FileLocator home / 'Desktop' / classBeingTranslated name , '.grace'. outputFile writeStreamDo: [ :s | ... ] Is that OK? When I do the above, in the writeStreamDo: block, s is bound to an instance of ZnCharacterWriteStream. But that class does nt understand many methods from WriteStream. For example, #contents is not understood, and nor is #ensureASpace. To put things another way: I wrote tests using a stream created with String streamContents: [ :s | ... ], and everything worked fine. Then, for production use, I switch to a stream created using outputFile writeStreamDo: [ :s | ... ] and everything breaks. I know that ZnCharacterWriteStream is fairly new. Am I doing something wrong, or is ZnCharacterWriteStream still under development? Andrew

July 31, 2018

Re: [Pharo-users] [ANN] Pharo Git Thermite Release

by Andrew Black

Hi Ronie, These visualizations look great! But I donât know what they /mean/. When one hovers the mouse over the visualizations, does help text appear explaining what one is looking at? For example, I guess that the red and green segments in âLines of Codeâ refer to lines deleted and added. But what are the green and yellow for âClassesâ. And whatâs a âFunctionâ in Pharo? The more complicated diagram for âRoassal2â I canât even begin to guess at! Donât make the mistake of thinking that because you know what the diagram means, after working on it for months, that other programmers will also know. Andrew

July 31, 2018

Re: [Pharo-dev] Charting in Roassal2

by Alexandre Bergel

Hi! Roassal supports Whisker plots, but not exactly candlestick. You can try this: -=-=-=-=-=-=-=-=-=-=-=-= | b createList r | r := Random new. createList := [ :size :d1 :d2 | (1 to: size) collect: [ :i | d1 + (r next * (d2-d1))] ]. b := RTGrapher new. (1 to: 10) do: [ :i | | ds | ds := RTBoxPlotDataSet new. ds points: (createList value: 20 value: 0 value: 20). b add: ds.]. b -=-=-=-=-=-=-=-=-=-=-=-= Which produces: Another example: =-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-= | b ds | b := RTGrapher new. b extent: 400 @ 200. RTShape withAllSubclasses do: [ :cls | ds := RTBoxPlotDataSet new. ds points: (cls rtmethods collect: #numberOfLinesOfCode). b add: ds ]. ^ b =-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-==-=-= Which shows the distribution of methods size in Roassal Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jul 27, 2018, at 8:47 PM, Shaping <shaping(a)uurda.org> wrote: > > Hi Folks. > > Can anyone tell me whether we have candlestick-charting ability in Roassal2? > > > Shaping

July 31, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Damien Pollet

On Tue, 31 Jul 2018 at 18:28, Damien Pollet <damien.pollet+pharo(a)gmail.com> wrote: > Hi Svenâ¦ a couple questions: > For context, I'm considering options in Clap, for providing accessors to Stdio that: - are convenient in most cases - discourage users from explicitly referencing the Stdio global (so that one can inject other streams instead if needed) For instance, it seems to make sense to provide stdout already wrapped with ZnNewLineWriterStream, but that precludes users from buffering. - is there a preferred order of composition between the encoding and > buffering streams ? If yes, it the same for read and write stream, or > reversed ? > E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, > but buffering it as well would be a problem for interactive applications. > > - what's your opinion on convenience composition messages, e.g. > aBinaryStream buffered decoded: 'utf-8' ? > > > > On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> >> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > Stdio stdout and friends just return a binary stream, hence they need >> wrapping for encoding. >> > >> > Maybe >> > >> > Stdio stdoutAsText >> > >> > might be an idea, but this is so uncommon that I am not sure this is a >> good idea. >> >> Given all remarks and comments (thanks BTW), I now think that >> >> - textual stdio streams are the more common case >> - binary stdio streams are the primitive ones that are seldom used >> - another encoding than UTF-8 seems uncommon >> - these are streams that exist and need no real opening/closing >> >> So, >> >> Stdio stdout >> >> should return return a character write stream with UTF-8 encoding while >> >> Stdio binaryStdout >> >> should be the lower level binary one. >> This would be more in line with the other streams. >> A non-UTF-8 encoding can be used as per Pavel's example. >> >

July 31, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Damien Pollet

Hi Svenâ¦ a couple questions: - is there a preferred order of composition between the encoding and buffering streams ? If yes, it the same for read and write stream, or reversed ? E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, but buffering it as well would be a problem for interactive applications. - what's your opinion on convenience composition messages, e.g. aBinaryStream buffered decoded: 'utf-8' ? On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Stdio stdout and friends just return a binary stream, hence they need > wrapping for encoding. > > > > Maybe > > > > Stdio stdoutAsText > > > > might be an idea, but this is so uncommon that I am not sure this is a > good idea. > > Given all remarks and comments (thanks BTW), I now think that > > - textual stdio streams are the more common case > - binary stdio streams are the primitive ones that are seldom used > - another encoding than UTF-8 seems uncommon > - these are streams that exist and need no real opening/closing > > So, > > Stdio stdout > > should return return a character write stream with UTF-8 encoding while > > Stdio binaryStdout > > should be the lower level binary one. > This would be more in line with the other streams. > A non-UTF-8 encoding can be used as per Pavel's example. >

July 31, 2018

Re: [Pharo-users] a basic hash question

by James Foster

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 <mailto:wkassens@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 > > >

July 31, 2018

Re: [Pharo-users] [Moose-dev] Moose Java AST?

by Tudor Girba

Hi, There is one in the SmaCC that ships with Moose: JavaParser. Cheers, Doru > On Jul 31, 2018, at 10:44 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a Java AST parser in Pharo? > > I imagine that jdt2famix must have something inside, but as far as I understand, it just extracts some information from the source code and throws the AST away. > > Thanks, > Peter > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

July 31, 2018

Pillar Book Tester

by Quentin DUCASSE (CI_2020)

Hello everyone! I am currently in an internship within the RMoD team and would like to present my work. My internship subject was the following: âHow to test documents (books, slides) written in Pillar?â. Let me first introduce Pillar then what I managed to implement and what is left to do. -What is Pillar? Pillar is a markup syntax and associated tools to write and generate documentation, books, slide-based presentations or websites. Pillar syntax is similar to Markdownâs one but its emphasis is stressed on publishing to different formats/languages (Markdown, html, LateX, pdf). -What does it mean to âtest a bookâ? -- Display code within the book Pillar syntax allows you to write codeblocks, showing a part of code. The inside of a codeblock allows one to display any part of code you might want to. For example: [[[ YourClass >> yourMethod ^ âblaâ ]]] This codeblock presents a method definition, the other two possible codeblocks are the following: Class definition [[[ Object subclass: #YourClass instanceVariableNames: '' classVariableNames: '' package: YourPackage' ]]] Example [[[ 1+1 >>> 2 ]]] -- How to test it? The use of â>>>â and parameters in the codeblock will help us to test the code within it. The BookTester will turn examples into tests. Testing examples: [[[testcase=true 3+4 becomes self assert: (3+4) equals: 7 >>>7 ]]] Testing methodDefinitions and classDefinitions: Testing method or class definitions resumes is the same as testing if the compilation of the method does not raise any error. It can help make sure your book is up to date with the latest Pharo version. Those tests are done the same way as testing an example: stating methodDefinition=true or classDefinition=true as code block parameters will make them elible for tests. Now, we are adding more features to code block or Pillar to help book writers. -Additional Features In Pillar, several annotations can be used for different purposes like including columns/tables/citations/figures/linksâ¦ -- Loading code: loader ${loader:account=QDucasse|project=TestBook|tag=Chapter1}$ allows you to load the github project as it was in the commit tagged Chapter1. This will help you test every chapter of your code with its current progression and also allow you to test the objects you are defining in your book. - Executing Tests: run ${run:testClass=YourClassTest}$ runs the test defined in the class testClass. And of course this testClass can be Other annotations have been added to help you write your book: - Display a class definition: showClass: ${showClass:className=YourClass}$ displays a codeblock with the class definition within it This helps you quickly include a class definition you want to display in your book. Combined with the loader it means that the code can be the source of your book. - Display a method definition: showMethod: ${showMethod:className=YourClass|methodName=yourMethod}$ will display a codeblock with the method definition within it This helps you quickly include a method definition you want to display in your book. - Screenshot: ${showMethod:packageName=yourPackage|className=YourClass|methodName=yourMethod|caption|width|label}$ saves a screenshot of a Calypso browser open at the selected package, class and method and includes it in both your book (using the designated Pillar figure reference) and the figures subfolder in the pillar book folder (saved as PNG). -Future objectives One of the future improvements would be to make everyone able to write examples and test them in the comments of method definitions. It is already partially possible â3+4 >>> 7â will be highlighted differently and if printed will display â7->7â. However, an automation or UI improvement would be nice. I hope this gave you the will to write something you had in mind. Are there any books you want to try the tools on? Feel free to ask ! Quentin Ducasse

July 31, 2018

Re: [Pharo-users] Moose Java AST?

by PBKResearch

Peter How about PPJavaParser or SmaCC-Java? Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Peter UhnÃ¡k Sent: 31 July 2018 09:44 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; Moose-related development <moose-dev(a)list.inf.unibe.ch> Subject: [Pharo-users] Moose Java AST? Hi, is there a Java AST parser in Pharo? I imagine that jdt2famix must have something inside, but as far as I understand, it just extracts some information from the source code and throws the AST away. Thanks, Peter

July 31, 2018

Moose Java AST?

by Peter UhnÃ¡k

Hi, is there a Java AST parser in Pharo? I imagine that jdt2famix must have something inside, but as far as I understand, it just extracts some information from the source code and throws the AST away. Thanks, Peter

July 31, 2018

Re: [Pharo-users] transactions on pharo objects

by tesonep＠gmail.com

Hello, A lot of time ago, we have implemented a basic support for STM in Java (it is written in Scala... dark dark dark ages). We have used aspect oriented programming to intercept the reading and writing of the instance variables of the classes that support the transactions. We kept a dictionary with the values for the transactions in course and a version, and the original object has the "commited" values. On a commit you can apply the changes to the object iff there is no conflict version. I think a similar implementation could be done in Pharo using Slots in a couple of hours. Also, you should use process specific values to detect and handle in witch transaction you are. Depending how much you want to guarantee ACID properties, you will have simpler or complex implementation. In those days, we only wanted only isolation. Sadly, the details of the implementation are in a Master Thesis in Spanish, I doubt they will be useful, but still I can point you to the source code of the solution. By the way, this is still in use as a part of a tool to teach UI design. https://github.com/uqbar-project/arena/tree/master/arena-pot Cheers, Pablo On Tue, Jul 31, 2018 at 8:48 AM 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 >> > > -- Pablo Tesone. tesonep(a)gmail.com

July 31, 2018

Re: [Pharo-users] a basic hash question

by John Pfersich

This inconsistent naming convention has me wishing for an updated ANSI Standard. There has been much change, wasnât that standard from the 90s? /ââââââââââââââââââââ/ For encrypted mail use jgpfersich(a)protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org > On Jul 30, 2018, at 22:59, 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 >

July 31, 2018

Re: [Pharo-users] transactions on pharo objects

by Norbert Hartl

> 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 >

July 31, 2018

Re: [Pharo-users] transactions on pharo objects

by Norbert Hartl

> Am 30.07.2018 um 16:02 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > Peter UhnÃ¡k wrote >> is there some library or approach how to do transactionsâ¦ directly in >> memory on Pharo >> objects > > Magritte? It uses the Memento pattern to verify all changes before > committing to real object. > This only works for simple use cases where there is one flow that creates the memento and keeps it like in a web form. The problem with the memento is that it is hard to make all objects give a memento when they are aquired. Norbert > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 31, 2018

Re: [Pharo-users] transactions on pharo objects

by Norbert Hartl

> Am 30.07.2018 um 15:16 schrieb Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > 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. > Should this work image wide or per process? Norbert

July 31, 2018

Re: [Pharo-users] a basic hash question

by Richard O'Keefe

+1 to what Andreas Valloud (Mr "how to hash in Smalltalk") said. On 31 July 2018 at 10:34, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > The interval > > 1 to: (10 raisedTo: 100) > > can be created just fine, yet hashing its elements won't compute. > > A generous interpretation of the intent of #=, where any wisp of > equivalence is promoted to full fledged equality, is problematic in the > long run. Here's another one: > > 17/20 = 0.85, therefore (17/20) hash = 0.85 hash > > Never mind there's no floating point value that is equal to 17/20 in the > first place. It just snowballs from there. For instance, should > collections like these be equal? > > (0.0 to: 1.0 by: 0.3) = #(0.0 0.3 0.6 0.9) > > Sometimes it's just better if different things stay different. > > Andres. > > > On 7/30/18 8:27 , Henrik Sperre Johansen wrote: > >> jgfoster wrote >> >>> Werner, >>> >>> I would say that you are right, this is a problem. A (not un-common) >>> source of subtle bugs in Smalltalk is missing this rule that equivalent >>> objects must have the same hash. In GemStone the objects are not >>> equivalent (Iâm not arguing that this is right, just that it avoids the >>> problem you identify). >>> >>> I wonder what would happen if the hash comparison were added to the >>> equivalence operator (#â=â)! >>> >>> James >>> >>> On Jul 30, 2018, at 5:07 AM, werner kassens < >>>> >>> >> wkassens@ >>> >> >> > 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 >>>> >>>> >>>> >>>> >> +1, this is a bug. >> Either Interval >> #hash needs to change*, or the equivalency be broken**. >> >> Fun fact: >> #(1 2 3 4) = #[1 2 3 4] false >> You'd think they might be more similar than an Interval and an Array, or a >> LinkedList containing ValueLinks and an Interval, but no ;) >> >> Cheers, >> Henry >> >> *Interval >> hash >> "Hash is reimplemented because = is implemented. >> Since we are equivalent to other collections of our species, we >> must also >> hash equivalently" >> | hash | >> >> hash := self species hash. >> start to: stop by: step do: [:element | hash := (hash + element >> hash) >> hashMultiply]. >> ^hash >> >> **both ways, which is challenging, if one neither wants to: >> - change species of Interval (which has bad consequences) >> - add hash comparison to sequenceablecollection = (which slows it down >> even >> further) >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> . >> >> >

July 31, 2018

Re: [Pharo-users] a basic hash question

by Richard O'Keefe

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 > > >

July 31, 2018

Re: [Pharo-users] a basic hash question

by werner kassens

Hi Andres, <g> that is the kind of argument i was looking for, as i thought i would have a similar situation as in my small example and wondered whether i could keep my slightly incongruent definition of #= and #hash, but in a way your examples show that my problem is different, iow i should change my implementation & i have changed it. werner On 07/31/2018 12:34 AM, Andres Valloud wrote: > The interval > > Â Â Â Â 1 to: (10 raisedTo: 100) > > can be created just fine, yet hashing its elements won't compute. > > A generous interpretation of the intent of #=, where any wisp of > equivalence is promoted to full fledged equality, is problematic in > the long run.Â Here's another one: > > Â Â Â Â 17/20 = 0.85, therefore (17/20) hash = 0.85 hash > > Never mind there's no floating point value that is equal to 17/20 in > the first place.Â It just snowballs from there.Â For instance, should > collections like these be equal? > > Â Â Â Â (0.0 to: 1.0 by: 0.3) = #(0.0 0.3 0.6 0.9) > > Sometimes it's just better if different things stay different. > > Andres.

July 31, 2018

Re: [Pharo-users] transactions on pharo objects

by Richard O'Keefe

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. 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 >

July 31, 2018

Re: [Pharo-users] a basic hash question

by Andres Valloud

The interval 1 to: (10 raisedTo: 100) can be created just fine, yet hashing its elements won't compute. A generous interpretation of the intent of #=, where any wisp of equivalence is promoted to full fledged equality, is problematic in the long run. Here's another one: 17/20 = 0.85, therefore (17/20) hash = 0.85 hash Never mind there's no floating point value that is equal to 17/20 in the first place. It just snowballs from there. For instance, should collections like these be equal? (0.0 to: 1.0 by: 0.3) = #(0.0 0.3 0.6 0.9) Sometimes it's just better if different things stay different. Andres. On 7/30/18 8:27 , Henrik Sperre Johansen wrote: > jgfoster wrote >> Werner, >> >> I would say that you are right, this is a problem. A (not un-common) >> source of subtle bugs in Smalltalk is missing this rule that equivalent >> objects must have the same hash. In GemStone the objects are not >> equivalent (Iâm not arguing that this is right, just that it avoids the >> problem you identify). >> >> I wonder what would happen if the hash comparison were added to the >> equivalence operator (#â=â)! >> >> James >> >>> On Jul 30, 2018, at 5:07 AM, werner kassens < > >> wkassens@ > >> > 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 >>> >>> >>> > > +1, this is a bug. > Either Interval >> #hash needs to change*, or the equivalency be broken**. > > Fun fact: > #(1 2 3 4) = #[1 2 3 4] false > You'd think they might be more similar than an Interval and an Array, or a > LinkedList containing ValueLinks and an Interval, but no ;) > > Cheers, > Henry > > *Interval >> hash > "Hash is reimplemented because = is implemented. > Since we are equivalent to other collections of our species, we must also > hash equivalently" > | hash | > > hash := self species hash. > start to: stop by: step do: [:element | hash := (hash + element hash) > hashMultiply]. > ^hash > > **both ways, which is challenging, if one neither wants to: > - change species of Interval (which has bad consequences) > - add hash comparison to sequenceablecollection = (which slows it down even > further) > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > . >

July 30, 2018

Re: [Pharo-users] a basic hash question

by werner kassens

Hi, thank you all for your answers. CÃ©drick BÃ©ler wrote: > But it raises the question if : > (1 to:4)hash = #(1 2 3 4)hash should return true instead ?? principally yes, but it would slow down the Interval>>hash implementation considerably. id guess one would first make SequentialCollection>>hash a bit faster & shorter or one could very fast get a memory overflow. i mean the trick with Intervals is not so much (1to:4), but (-100000000000 to: 100000000000) which doesnt use any space and time. jgfoster wrote: > In GemStone the objects are not > equivalent (Iâm not arguing that this is right, just that it avoids the > problem you identify). i see, yes, it can happen that hash has its own idea what equivalence _really means. > I wonder what would happen if the hash comparison were added to the > equivalence operator (#â=â)! you probably mean something like this: #= ^(doWhatYouveDoneBefore)and:[self hash = object hash] of course that would eliminate the problem but it would need to be implemented everywhere. if not, #= could become not symmetric which produces the same problems (actually i stumbled upon this question because i implemented #= for a subobject of Array and gave it the species Array, problematic because with my implementation it opened the possibility of myObject~=anArray but anArray=myObject). actually #= in pharo is symmetric (and transitive, which also is necessary for hash to work) because it is more or less carefully designed , the symmetry is not somehow automatically incorporated in the language, and as i noticed its not too difficult to break that symmetry with ones own objects <stupid grin> On 07/30/2018 05:27 PM, Henrik Sperre Johansen wrote: > +1, this is a bug. > Either Interval >> #hash needs to change*, or the equivalency be broken**. > > Fun fact: > #(1 2 3 4) = #[1 2 3 4] false > You'd think they might be more similar than an Interval and an Array, or a > LinkedList containing ValueLinks and an Interval, but no ;) <g> i guess it is difficult to juggle & balance everything between all the different kinds of collections. thanks again folks werner

July 30, 2018

Re: [Pharo-users] a basic hash question

by Henrik Sperre Johansen

jgfoster wrote > Werner, > > I would say that you are right, this is a problem. A (not un-common) > source of subtle bugs in Smalltalk is missing this rule that equivalent > objects must have the same hash. In GemStone the objects are not > equivalent (Iâm not arguing that this is right, just that it avoids the > problem you identify). > > I wonder what would happen if the hash comparison were added to the > equivalence operator (#â=â)! > > James > >> On Jul 30, 2018, at 5:07 AM, werner kassens < > wkassens@ > > 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 >> >> >> +1, this is a bug. Either Interval >> #hash needs to change*, or the equivalency be broken**. Fun fact: #(1 2 3 4) = #[1 2 3 4] false You'd think they might be more similar than an Interval and an Array, or a LinkedList containing ValueLinks and an Interval, but no ;) Cheers, Henry *Interval >> hash "Hash is reimplemented because = is implemented. Since we are equivalent to other collections of our species, we must also hash equivalently" | hash | hash := self species hash. start to: stop by: step do: [:element | hash := (hash + element hash) hashMultiply]. ^hash **both ways, which is challenging, if one neither wants to: - change species of Interval (which has bad consequences) - add hash comparison to sequenceablecollection = (which slows it down even further) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 30, 2018

Re: [Pharo-users] transactions on pharo objects

by Esteban A. Maringolo

El lun., 30 jul. 2018 a las 11:03, Sean P. DeNigris (<sean(a)clipperadams.com>) escribiÃ³: > > Peter UhnÃ¡k wrote > > is there some library or approach how to do transactionsâ¦ directly in > > memory on Pharo > > objects > > Magritte? It uses the Memento pattern to verify all changes before > committing to real object. But you need Magritte, and define descriptions, and references, and access the objects via Magritte Accessors, etc. I think that works for an UI of a somehow limited form, but not as a general purpose (as I guess Peter is looking for). Also for forms, but without metadata, Dolphin used a "BufferedModel" object, which means that if you have an MVP/MVC, instead of using your original model, you work on this "buffer", which internally has the original and a copy, and all messages are sent to the copy and once you "apply" the changes they are applied back to the original model, and if you don't apply, the copy is discarded and the original model left unmodified. But again, I guess Peter is looking for something else. Regards!

July 30, 2018

Re: [Pharo-users] transactions on pharo objects

by Sean P. DeNigris

Peter UhnÃ¡k wrote > is there some library or approach how to do transactionsâ¦ directly in > memory on Pharo > objects Magritte? It uses the Memento pattern to verify all changes before committing to real object. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 30, 2018

Re: [Pharo-users] transactions on pharo objects

by Serge Stinckwich

Maybe you can have a look to this paper : https://www.sciencedirect.com/science/article/pii/S1477842408000237 On Mon, Jul 30, 2018 at 2:17 PM 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 > -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

July 30, 2018