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

Re: [Pharo-users] Invoking external processes/IPC

by Marcin Tustin

John, Do you have any intention of commenting on this, even to confirm that you are content for Alien to be incompatible with current versions of Pharo? Marcin On Mon, Aug 23, 2010 at 11:15 PM, Marcin Tustin <mm3(a)zepler.net> wrote: > John, > > That is the installation recipe I was following, as should have been > apparent from my description of the process followed given in my previous > email. My problem occurred on the first step after loading the > ConfigurationOfAlien package. > > For completeness, I tried loading ConfigurationOfAlien using Gofer, and the > exact same thing occurred. I also note that Gofer>>addPackage is deprecated. > > Marcin > > > > > On Mon, Aug 23, 2010 at 10:40 PM, John M McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >> LIkely the installation process is wrong, look at the >> http://squeaksource.com/@EGv-75Ct7JEKFz5m/rnvjMef8 >> and follow the instructions for installing there. >> >> On 2010-08-23, at 2:08 PM, Marcin Tustin wrote: >> >> Following Mariano's advice, I just tried installing Alien (using >> Pharo-1.1-11406-rc3 with the Seaside RC3 image; this is a sane version, not >> affected by previous package loading problems). >> >> I loaded ConfigurationOfAlien (ConfigurationOfAlien-KenTreis.26) using >> Monticello, then executed ConfigurationOfAlien loadCore (as per the >> instructions). That resulted in an error: >> 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible' raised >> from ensureInSpecialObjectsArray. The cause appears to be that Alien wants >> to be in the special objects array at 53, but the array is created to be >> size 50. >> >> Proceeding through the error results in the predictable subscript out of >> bounds error. >> >> running loadCore once more (second time) does the same thing. Doing it a >> third time results in a message not understood 'initScannerForTokenization' >> from Parser>>ParseSelector:. >> >> Any ideas? >> >> >> On Mon, Aug 23, 2010 at 8:41 PM, Marcin Tustin <mm3(a)zepler.net> wrote: >> >>> Mariano, >>> >>> Thanks for this. I belive CommandShell depends on OSProcess. I am using >>> windows, so I guess neither is a runner anyway. I'll try FFI/AlienFFI. >>> >>> Marcin >>> >>> >>> On Mon, Aug 23, 2010 at 8:19 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Mon, Aug 23, 2010 at 7:45 PM, Marcin Tustin <mm3(a)zepler.net> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm an occasional squeak/pharo dabbler, and I'm wondering what the >>>>> recommended way of interacting with external processes is these days? >>>>> >>>>> Should I go through the process of getting all the VMMaker and >>>>> OSProcess stuff, and build the OSProcess plugin, or is there some other way >>>>> in Pharo to interact with the OS environment? >>>>> >>>>> >>>> Hi. Which OS are you? because I think OSProcess is not working on >>>> Windows. And I also think there are binaries for it, so you don't need to >>>> generate .c from VMMaker neither compile c code to binary. >>>> But I may be wrong. >>>> >>>> CommandShell ? >>>> >>>> Maybe using normal FFI or AlienFFI? They will let you invoke shared >>>> libraries of the OS from Pharo. >>>> >>>> >>>>> Alternatively, are people doing something (easy) with IPC mechanisms >>>>> like named sockets or TCP streams? >>>>> >>>>> The "project" I'm working on is putting figlet on a website, just for >>>>> fun. >>>>> >>>>> Marcin >>>>> >>>>> -- >>>>> Marcin Tustin >>>>> Mobile: 07773787105 >>>>> Office: 020 3400 3259 >>>>> >>>>> _______________________________________________ >>>>> Pharo-users mailing list >>>>> Pharo-users(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >>>> >>> >>> >>> -- >>> Marcin Tustin >>> Mobile: 07773787105 >>> Office: 020 3400 3259 >>> >> >> >> >> -- >> Marcin Tustin >> Mobile: 07773787105 >> Office: 020 3400 3259 >> >> >> -- >> >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> >> =========================================================================== >> >> >> >> >> > > > -- > Marcin Tustin > Mobile: 07773787105 > Office: 020 3400 3259 > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 25, 2010

Re: [Pharo-users] first draft of a pharo zen

by StÃ©phane Ducasse

I will let it sleeps for now... Stef On Aug 25, 2010, at 10:25 AM, laurent laffont wrote: > > On Tue, Aug 24, 2010 at 11:07 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Those are duplicates of the first one (easy to understand....), no ? > * There is no unimportant fix > * Examples to learn from > * A system with robust abstractions that a single person can understand > > I like > â¢ Explicit is better than implicit > â¢ Magic only at the right place > because I feel that's part of the essence of Pharo / Smalltalk, and a real difference compared to C, Perl, Ruby, PHP .... > > I'm not sure about Classes, Messages, Tests, Polymorphism, Abstraction items... IMHO these complexify the manifesto. > > (I like to put this one in mails: > "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery) > > I was thinking that a slogan for Pharo can be: > > Pharo: Beautiful. Easy. Open. > > Replying to myself > > Beautiful > - in code > - in abstractions > - in simplicity > > Easy > - to understand > - to learn from > - to fix > > Open > - to participation > - to improvement > - to future > > Laurent > > > Indeed it's how I resume the manifersto (but I'm doing software development, not marketing, so may be crap :) > > Laurent > > On Tue, Aug 24, 2010 at 9:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > New version > > â¢ Easy to understand, easy to learn from, easy to fix > â¢ Examples to learn from > â¢ Fully dynamic and malleable > â¢ Beauty in the code, beauty in the comments > â¢ Simplicity is beautiful > â¢ Communication is key > â¢ Classes structure our vocabulary > â¢ Messages are our vocabulary > â¢ Polymorphism is our esperanto > â¢ Better a number of small polymorphic classes than a large ugly one > â¢ Tests are important but can be changed > â¢ Abstraction and composition are our friends > â¢ Explicit is better than implicit > â¢ Magic only at the right place > â¢ Simple processes to support progress > â¢ One step at a time > â¢ There is no unimportant fix > â¢ Quality is a emerging property > â¢ Lovely objects are everything and everything is an object. > â¢ A system with robust abstractions that a single person can understand > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 25, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by StÃ©phane Ducasse

I;m sorry that I raised a stupid idea. Don;t bash people for me :) On Aug 23, 2010, at 10:26 PM, stephane ducasse wrote: > Hi guys > > I'm thinking aloud... > I was wondering if we could not take advantage of a new class: Selector. > MethodDict would only contain selectors and not symbols. > > I remember that I talked about that with hernan. > > Stef > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 25, 2010

Re: [Pharo-users] first draft of a pharo zen

by laurent laffont

On Tue, Aug 24, 2010 at 11:07 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > Those are duplicates of the first one (easy to understand....), no ? > * There is no unimportant fix > * Examples to learn from > * A system with robust abstractions that a single person can understand > > I like > â¢ Explicit is better than implicit > â¢ Magic only at the right place > because I feel that's part of the essence of Pharo / Smalltalk, and a real > difference compared to C, Perl, Ruby, PHP .... > > I'm not sure about Classes, Messages, Tests, Polymorphism, Abstraction > items... IMHO these complexify the manifesto. > > (I like to put this one in mails: > "Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away." Antoine de Saint-Exupery) > > I was thinking that a slogan for Pharo can be: > > Pharo: Beautiful. Easy. Open. > Replying to myself Beautiful - in code - in abstractions - in simplicity Easy - to understand - to learn from - to fix Open - to participation - to improvement - to future Laurent > > Indeed it's how I resume the manifersto (but I'm doing software > development, not marketing, so may be crap :) > > Laurent > > On Tue, Aug 24, 2010 at 9:10 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> New version >> >> â¢ Easy to understand, easy to learn from, easy to fix >> â¢ Examples to learn from >> â¢ Fully dynamic and malleable >> â¢ Beauty in the code, beauty in the comments >> â¢ Simplicity is beautiful >> â¢ Communication is key >> â¢ Classes structure our vocabulary >> â¢ Messages are our vocabulary >> â¢ Polymorphism is our esperanto >> â¢ Better a number of small polymorphic classes than a large ugly >> one >> â¢ Tests are important but can be changed >> â¢ Abstraction and composition are our friends >> â¢ Explicit is better than implicit >> â¢ Magic only at the right place >> â¢ Simple processes to support progress >> â¢ One step at a time >> â¢ There is no unimportant fix >> â¢ Quality is a emerging property >> â¢ Lovely objects are everything and everything is an object. >> â¢ A system with robust abstractions that a single person can >> understand >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > >

Aug. 25, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by HernÃ¡n Morales Durand

It always strikes me why some concepts are thought and included as innate (like Time) and others not (like Space). This is the same for Reference and Meaning. This is the part when the human takes part of the system, try to infer the use of the following undocumented method >>doSomething ^ #beActive you cannot tell if it is intended to use as an selector or not, even Active doesn't tell us anything about the reference (active? who? self?) or the meaning (active a state right? which one?). Looking at both classes: Symbol doesn't carry a meaning (because it is used as a Sign) Selector does carry a meaning (because it is used as Significantum) and Smalltalk serves as the mediator between the naming and its usage. Looking at the instances aSymbol includes a name, could be meaningless, possibly without a reference, say #ewrewrjew (or we may not recognize if actually have a reference) aSelector includes a name plus an idea, probably with a reference (which is its the raison d'Ãªtre). You could "solve" the impractical problem of modeling the roles just using new names: Create a class Sign which could be used as Name or Selector or both. Having a Selector class only serves (to me, and now :) if one wants to ask things like #name senders (exception, name is not used as sender) #name implementors (idem) ... #selector senders (answer a list of references where selector is used as sender) #selector implementors (idem as implementors) #selector events (idem for named events) #selector isSender ... and get the answers faster than the tools today. But the last case is a proof (why not Event class?) that the same way we may model universals... so it's really a question of efficency and usefullness, that's one of the reasons why humans are included in the system, we cannot dream of modelling everything. Cheers, HernÃ¡n 2010/8/23 stephane ducasse <stephane.ducasse(a)free.fr>: > Hi guys > > I'm thinking aloud... > I was wondering if we could not take advantage of a new class: Selector. > MethodDict would only contain selectors and not symbols. > > I remember that I talked about that with hernan. > > Stef > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 25, 2010

Re: [Pharo-users] MethodName

by Benjamin Van Ryseghem

Hi everybody I came back with a new version of Method Name with a better Package Chooser and more choices about the search :) I hope it's useful but if there is some behaviour you would like the Method Name implements, just let me know Gofer new squeaksource: 'PharoTaskForces'; package: 'MethodName'; load. Thank you Ben

Aug. 24, 2010

Pharo by Example - Lights Out

by Phil Lewis

Hi, I'm trying to work through PBE, and have got to the LightsOut chapter. It appears that SimpleSwitchMorph is not part of the image. I found some old posts in the archive about this, but they just seemed to be mentioning something about putting a disclaimer in the book. Is there any way I can progress with this tutorial? Thanks -- Ram Ram

Aug. 24, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by StÃ©phane Ducasse

that a fun one. BTW I know that david simmons introduced == and === on symbol and === was checking the namespace in which the symbol was defined and this way he implemented selector namespace. On Aug 24, 2010, at 4:00 PM, Igor Stasenko wrote: > On 24 August 2010 16:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> we often use symbols for identity keys. >> Now I was just dreaming. >> > I had a long discussion with my friend, who was learning smalltalk, > where we argued about 'selector is not a symbol'. > > The difference between a bare string and symbol is uniqueness. > Literally, a symbol is just a string, which having additional, implied > semantics, that > same symbolic strings refer to a single, unique object. (Another minor > one is immutability). > > The difference between a symbol and selector is less significant. > A simple example. Suppose you have two different classes, one Symbol, > other is Selector. > Now, suppose that compiler creating an instance of Symbol each time it > sees following: > > self foo. > > where 'foo' is selector (and instance of Selector). > > but now, lets put it in another way: > > self perform: #foo. > > A #foo is, obviously a symbol, and must be an instance of Symbol class, isnt? > > So, in #perform: you must somehow convert a symbol into selector and > then find the implementation > of method with given selector. > This obviously kills an idea of having distinction between selectors > and symbols, because implementation > of #perform: will be awfully slow and awkward. > >>>> Hi guys >>>> >>>> I'm thinking aloud... >>>> I was wondering if we could not take advantage of a new class: Selector. >>>> MethodDict would only contain selectors and not symbols. >>>> >>>> I remember that I talked about that with hernan. >>>> >>> >>> Hmm.. i don't see obvious advantages. Do you? >>> Most symbols (90% of cases), used as selectors, so it is likely that >>> such refactoring will be nothing more, >>> but just renaming the class :) >>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 24, 2010

Re: [Pharo-users] WebClient

by StÃ©phane Ducasse

Ok I integrated that packages and the test packages. I also copied the packages into PharoTreatedInbox to ease future merging. I should probably copy the ones of WebClient there too for the same purpose. I integrated also your network protocol changes. BTW: I noticed that andreas a while ago (may be before starting to write webClient) refactored heavily HTTP* classes so I do not know if we want to have a look at them because may be this is better to throw away them once we redirect to webclient. Now I'm also waiting eagerly for Ocean. Stef On Aug 24, 2010, at 11:03 AM, Sven Van Caekenberghe wrote: > > On 23 Aug 2010, at 19:59, Sven Van Caekenberghe wrote: > >> I will try to do this tomorrow. > > OK, I did a new port on the lastest versions: > > http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… > > ==================== Summary ==================== > > Name: WebClient-Core-SvenVanCaekenberghe.70 > Author: SvenVanCaekenberghe > Time: 24 August 2010, 10:59:05 am > UUID: 5fecc631-281f-4be9-938a-4e6e45fda64a > Ancestors: WebClient-Core-ar.69 > > New port to PharoCore 1.2 #12108: > - added #asString where necessary > - proper use of #pathForFile with FileUrl absoluteFromText: > - use OSPlatform where necessary > - don't use #and:and:and:and: > - replace #squeakToUtf8 with convertToWithConverter: UTF8TextConverter new > > Together with: > > http://www.squeaksource.com/ADayAtTheBeach/Network-Protocols-SvenVanCaekenb… > > ==================== Summary ==================== > > Name: Network-Protocols-SvenVanCaekenberghe.56 > Author: SvenVanCaekenberghe > Time: 24 August 2010, 10:50:48 am > UUID: 7acf743b-fd1a-41b7-ae78-242b66c54c96 > Ancestors: Network-Protocols-StephaneDucasse.54 > > Switched to proper use of #pathForFile > > The results are similar: 45 run, 41 passes, 0 expected failures, 2 failures, 2 errors, 0 unexpected passes > > Regards, > > Sven > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by laurent laffont

Those are duplicates of the first one (easy to understand....), no ? * There is no unimportant fix * Examples to learn from * A system with robust abstractions that a single person can understand I like â¢ Explicit is better than implicit â¢ Magic only at the right place because I feel that's part of the essence of Pharo / Smalltalk, and a real difference compared to C, Perl, Ruby, PHP .... I'm not sure about Classes, Messages, Tests, Polymorphism, Abstraction items... IMHO these complexify the manifesto. (I like to put this one in mails: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery) I was thinking that a slogan for Pharo can be: Pharo: Beautiful. Easy. Open. Indeed it's how I resume the manifersto (but I'm doing software development, not marketing, so may be crap :) Laurent On Tue, Aug 24, 2010 at 9:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > New version > > â¢ Easy to understand, easy to learn from, easy to fix > â¢ Examples to learn from > â¢ Fully dynamic and malleable > â¢ Beauty in the code, beauty in the comments > â¢ Simplicity is beautiful > â¢ Communication is key > â¢ Classes structure our vocabulary > â¢ Messages are our vocabulary > â¢ Polymorphism is our esperanto > â¢ Better a number of small polymorphic classes than a large ugly > one > â¢ Tests are important but can be changed > â¢ Abstraction and composition are our friends > â¢ Explicit is better than implicit > â¢ Magic only at the right place > â¢ Simple processes to support progress > â¢ One step at a time > â¢ There is no unimportant fix > â¢ Quality is a emerging property > â¢ Lovely objects are everything and everything is an object. > â¢ A system with robust abstractions that a single person can > understand > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 24, 2010