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

Re: [Pharo-project] Meaning of the name "Pharo"

by Norbert Hartl

Am 27.01.2012 um 08:17 schrieb Max Leske <maxleske(a)gmail.com>: > I always enjoy it if a product / project with a "funny" name explains that name somewhere (origin, intention). I think it says a lot about the kind of project it is (how dedicated are the people? If the name is crap, the product will probably be tooâ¦). So I thought, it might be cool to introduce a paragraph (in the "About" section maybe) that explains the origins of the name "Pharo". > > Any thoughts? > Named after its inventor smalltalk had only a k-light [1] to shed some light into the dark territory called programming. We recognized that we need something bigger to guide our way. That's how the lighthouse idea was born. Although it's spelled wrongly the name pharo refers to the famous pharos of alexandria [2] which is also the required size the lighthouse needs to have in order to make us see anything. [1] http://www.what-if.com/SECURE/pisat/klight-p-1.html [2] http://en.wikipedia.org/wiki/Lighthouse_of_Alexandria

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by StÃ©phane Ducasse

Yes! > Hi, > > I like the "withBackLink:" one more because the other solution exposes > how books are implemented on Library by passing the collection > through. Better to let library manage books than to add it directly. > >> Library>>addBook: aBook >> aBook addToLibrary: self. >> >> Book>>addToLibrary: aLibrary >> aLibrary addBook: self withBackLink: [ :backlinkValue | library := >> backlinkValue ]. >> >> Library>>addBook: aBook withBackLink: setBacklinkBlock >> books ifNil: [ books := OrderedCollection new ]. >> books add: aBook. >> setBacklinkBlock value: self. > > However, I'm not sure that you are adding *that* much value by using > the "withBackLink:" because this reads a bit easier: > > Book>>addToLibrary: aLibrary > aLibrary protectedAddBook: self. > library := aLibrary > > Library>>protectedAddBook: aBook > books add: aBook > > We build in a bit of an integrity framework that helps: > > Book>>checkIntegrity > self assert: (library hasBook: self) > > Library>>checkIntegrity > books do: [ :book | self assert: book library == self ] > > After each test, in the tearDown, we call this on all objects created > in the test. Also, we run this daily on production databases and fix > failures (not often enough though!). > > Cheers > Otto >

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by StÃ©phane Ducasse

I guess that in naked objects book they discussed some patterns for relationships. What I would love to have is first class slots so that we can easily express relationships like the ones you describe. But I have too busy. I'm rereading the paper of toon, camillo et all to see what we could reasonably do. Stef On Jan 27, 2012, at 6:11 AM, Ben Coman wrote: > StÃ©phane Ducasse wrote: >> Welcome >> >> >> >>> Hi, I have one begginer question. It is may be simple, but it very baffles me. >>> >>> I am reading Pharo by Example (great book btw, thanks!). I'm in chapter two where I'm creating Lights Out game. There is this simple code http://pastebin.com/eQregZ35. What baffles me is line 10. I assign "Block of code" to mouseAction variable of LOCell. In this Block, there is "self", that obviously refers to LOGame object in that time. But when is this Block actualy EVALUATED (when I click on Cell), "self" should be reffering to LOCell object, isn't it? If I inspect one LOCell, inspector shows that it has instance variable >>> >> >> Here is a draft of a next chapter on block :) >> But I should finish it :) >> ------------------------------------------------------------------------ >> >> >> But I want to add how block are implemented at the bye code level so it take times because not that many people are helping, so I have to learn first. >> >> Stef >> > Thanks Stef. A very enlightening read. Its has helped in an example I'll relate for other neophytes, and in case there are any traps or patterns I am missing. > > I have been struggling with how to implement a bidirectional relationship between two classes such that consistency is enforced. Take for instance the following classes... > Object subclass: #Book instanceVariableNames: 'bookTitle library' > Object subclass: #Library instanceVariableNames: 'libraryName books' > > I want both the 'books' and 'library' instvars to remain private - meaning that I don't want the default accessors providing direct access to either. Then a method like 'Library>>addBook: aBook' which can update its internal state modifying the 'books' collection cannot update the internal 'library' state of 'aBook' - without Book having a setter method to directly change the 'library' instvar - which I want to avoid having. Trying to resolve this led me into recursion hell with too much cross checking and guarding code. > > What I was wanting was a way to expose the private state of one object to another object in a controlled manner. So now I think this might be achieved like this... > > Library>>addBook: aBook > aBook addToLibrary: self. > > Book>>addToLibrary: aLibrary > aLibrary addBook: self withBackLink: [ :backlinkValue | library := backlinkValue ]. > > Library>>addBook: aBook withBackLink: setBacklinkBlock > books ifNil: [ books := OrderedCollection new ]. > books add: aBook. > setBacklinkBlock value: self. > > Now having done that, I think I missed an alternative implementation... > > Library >> addBook: aBook > aBook addToLibrary: self withInternalCollection: books > > Book>>addToLibrary: aLibrary withInternalCollection: libraryInternalBooksCollection > libraryInternalBooksCollection add: self. > library := aLibrary. > > > Book>>addToLibrary: aLibrary > aLibrary addBook: self. > > and I'm not really sure of the pros & cons of each approach. Thoughts anyone? >

Jan. 27, 2012

Re: [Pharo-project] Zodiac Alpha Release 2012-01-26

by StÃ©phane Ducasse

Excellent. We should announce that on the news of the web site. Stef On Jan 26, 2012, at 11:23 PM, Sven Van Caekenberghe wrote: > Hi, > > I uploaded a new, updated version of Pharo 1.3 One-Click containing the latest Zinc HTTP Components and Zodiac code, as well as the necessary SSL VM plugin, for a good out-of-the-box experience for those interested in TLS/SSL secure socket streams. > > http://dl.dropbox.com/u/16235440/Pharo-1.3-Zodiac-OneClick.app.zip (~25Mb) > > Features: > > - ZnSecureSocketStream > - HTTPS client access > - HTTPS server (not on Mac OS X though) > - ZdcSecureSMTPClient > - ZdcSecurePOP3Client > > I tested this on Mac OS X 10.7, Ubuntu 11.10 and Windows 8. > > This is a stock #13315 Pharo image customized as follows: > > "Update Zinc HTTP Components" > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-HTTP'; > package: 'Zinc-Tests'; > load. > > "Load Zodiac including extras" > > Gofer it > squeaksource: 'Zodiac'; > package: 'Zodiac-Core'; > package: 'Zodiac-Tests'; > package: 'Zodiac-Extra'; > load. > > "Load extra Zinc support for Zodiac" > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-Zodiac'; > load. > > Pharo 1.4 does not need the Zn update since it contains the latest version of Zn already. > > For more information, visit http://zdc.stfx.eu > > Enjoy, > > Sven > > PS: Zodiac development was partly sponsored by ESUG > >

Jan. 27, 2012

Re: [Pharo-project] Meaning of the name "Pharo"

by Serge Stinckwich

On Fri, Jan 27, 2012 at 2:17 PM, Max Leske <maxleske(a)gmail.com> wrote: > I always enjoy it if a product / project with a "funny" name explains that name somewhere (origin, intention). I think it says a lot about the kind of project it is (how dedicated are the people? If the name is crap, the product will probably be tooâ¦). So I thought, it might be cool to introduce a paragraph (in the "About" section maybe) that explains the origins of the name "Pharo". > > Any thoughts? A lighthouse for a brighter future ;-) -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Jan. 27, 2012

[Pharo-project] Meaning of the name "Pharo"

by Max Leske

I always enjoy it if a product / project with a "funny" name explains that name somewhere (origin, intention). I think it says a lot about the kind of project it is (how dedicated are the people? If the name is crap, the product will probably be tooâ¦). So I thought, it might be cool to introduce a paragraph (in the "About" section maybe) that explains the origins of the name "Pharo". Any thoughts? Cheers, Max

Jan. 27, 2012

Re: [Pharo-project] This is so cool, and we can compute it !

by StÃ©phane Ducasse

this is probably the result of the constant effort of nicolas and a couple of others :) On Jan 26, 2012, at 8:44 PM, Sven Van Caekenberghe wrote: > This is so cool, and we can compute it using Pharo Smalltalk. > > Try inspecting or printing the result of these expressions: > > 1/9801 asScaledDecimal: 200 > > 1/998001 asScaledDecimal: 3000 > > And have a good look at the regularity in the digits of the fraction. > > Amazing ! > > Sven >

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by Otto Behrens

Hi, I like the "withBackLink:" one more because the other solution exposes how books are implemented on Library by passing the collection through. Better to let library manage books than to add it directly. > Library>>addBook: aBook > Â aBook addToLibrary: self. > > Book>>addToLibrary: aLibrary > Â aLibrary addBook: self withBackLink: [ :backlinkValue | library := > backlinkValue ]. > > Library>>addBook: aBook withBackLink: setBacklinkBlock > Â books ifNil: [ books := OrderedCollection new ]. > Â books add: aBook. > Â setBacklinkBlock value: self. However, I'm not sure that you are adding *that* much value by using the "withBackLink:" because this reads a bit easier: Book>>addToLibrary: aLibrary aLibrary protectedAddBook: self. library := aLibrary Library>>protectedAddBook: aBook books add: aBook We build in a bit of an integrity framework that helps: Book>>checkIntegrity self assert: (library hasBook: self) Library>>checkIntegrity books do: [ :book | self assert: book library == self ] After each test, in the tearDown, we call this on all objects created in the test. Also, we run this daily on production databases and fix failures (not often enough though!). Cheers Otto

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by Ben Coman

StÃ©phane Ducasse wrote: > Welcome > > > >> Hi, I have one begginer question. It is may be simple, but it very baffles me. >> >> I am reading Pharo by Example (great book btw, thanks!). I'm in chapter two where I'm creating Lights Out game. There is this simple code http://pastebin.com/eQregZ35. What baffles me is line 10. I assign "Block of code" to mouseAction variable of LOCell. In this Block, there is "self", that obviously refers to LOGame object in that time. But when is this Block actualy EVALUATED (when I click on Cell), "self" should be reffering to LOCell object, isn't it? If I inspect one LOCell, inspector shows that it has instance variable >> > > Here is a draft of a next chapter on block :) > But I should finish it :) > ------------------------------------------------------------------------ > > > But I want to add how block are implemented at the bye code level so it take times because not that many people are helping, so I have to learn first. > > Stef > Thanks Stef. A very enlightening read. Its has helped in an example I'll relate for other neophytes, and in case there are any traps or patterns I am missing. I have been struggling with how to implement a bidirectional relationship between two classes such that consistency is enforced. Take for instance the following classes... Object subclass: #Book instanceVariableNames: 'bookTitle library' Object subclass: #Library instanceVariableNames: 'libraryName books' I want both the 'books' and 'library' instvars to remain private - meaning that I don't want the default accessors providing direct access to either. Then a method like 'Library>>addBook: aBook' which can update its internal state modifying the 'books' collection cannot update the internal 'library' state of 'aBook' - without Book having a setter method to directly change the 'library' instvar - which I want to avoid having. Trying to resolve this led me into recursion hell with too much cross checking and guarding code. What I was wanting was a way to expose the private state of one object to another object in a controlled manner. So now I think this might be achieved like this... Library>>addBook: aBook aBook addToLibrary: self. Book>>addToLibrary: aLibrary aLibrary addBook: self withBackLink: [ :backlinkValue | library := backlinkValue ]. Library>>addBook: aBook withBackLink: setBacklinkBlock books ifNil: [ books := OrderedCollection new ]. books add: aBook. setBacklinkBlock value: self. Now having done that, I think I missed an alternative implementation... Library >> addBook: aBook aBook addToLibrary: self withInternalCollection: books Book>>addToLibrary: aLibrary withInternalCollection: libraryInternalBooksCollection libraryInternalBooksCollection add: self. library := aLibrary. Book>>addToLibrary: aLibrary aLibrary addBook: self. and I'm not really sure of the pros & cons of each approach. Thoughts anyone?

Jan. 27, 2012

Re: [Pharo-project] Zodiac Alpha Release 2012-01-26

by Guillermo Polito

:3 Sweet! Thanks Sven! :D On Thu, Jan 26, 2012 at 7:23 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Hi, > > I uploaded a new, updated version of Pharo 1.3 One-Click containing the > latest Zinc HTTP Components and Zodiac code, as well as the necessary SSL > VM plugin, for a good out-of-the-box experience for those interested in > TLS/SSL secure socket streams. > > http://dl.dropbox.com/u/16235440/Pharo-1.3-Zodiac-OneClick.app.zip (~25Mb) > > Features: > > - ZnSecureSocketStream > - HTTPS client access > - HTTPS server (not on Mac OS X though) > - ZdcSecureSMTPClient > - ZdcSecurePOP3Client > > I tested this on Mac OS X 10.7, Ubuntu 11.10 and Windows 8. > > This is a stock #13315 Pharo image customized as follows: > > "Update Zinc HTTP Components" > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-HTTP'; > package: 'Zinc-Tests'; > load. > > "Load Zodiac including extras" > > Gofer it > squeaksource: 'Zodiac'; > package: 'Zodiac-Core'; > package: 'Zodiac-Tests'; > package: 'Zodiac-Extra'; > load. > > "Load extra Zinc support for Zodiac" > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-Zodiac'; > load. > > Pharo 1.4 does not need the Zn update since it contains the latest version > of Zn already. > > For more information, visit http://zdc.stfx.eu > > Enjoy, > > Sven > > PS: Zodiac development was partly sponsored by ESUG > > >

Jan. 27, 2012