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

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

by Igor Stasenko

On 25 August 2010 22:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 August 2010 21:11, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: >> From the design point of view, I like the idea, a selector is not a symbol >> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel >> said, implements messages that are related to selector behavior... Why >> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors >> responsibilities... not all symbols are selectors... so for me, it is a good >> idea. > > not all symbols are selectors... > but you never tell, that they could not be, once you load new package > or write more code. > > I see the need of having a separate subclass for Symbol , instead of > stopping at String, > because it have to maintain uniqueness and immutability. > > String + uniqueness + immutability => Symbol > > so, there is a strong reason for having a separate class for it, but > > Symbol + ??? => Selector > > give me a strong reason. > > i like the idea of shrinking a Symbol's protocol and putting it into > lean and clean place - Symbol. oops, clean place is obviously Selector here. > But this is not strong enough. > In practice, such shrinking, could lead to explosion of complexity in > many other places. > > > 'foo' = #foo Â ->true > #foo = 'foo' -> true > > #foo asSelector = #foo ?? > > if so, then > #foo hash = #foo asSelector hash ? > > and , obviously > #foo == #foo asSelector Â => false > > which means, that mixing selectors and symbols in a single collection > will be very bad idea, > and source of bugs and confusion. > But what gives us a uniqueness of symbols is, that we don't need to > use #= for comparing them, > but #== , which is much faster. Right? > > Now, if you introduce selectors, there is no uniqueness anymore, since > selector is a symbol (since it is a subclass of it), and must honor > the rules of its ancestor.. > but its not. > The only way how to deal with that is to make particular symbol > (sub)instance to be either > an instance of Symbol or Selector but not both. > This means that in system you could have either > #foo > or > #foo asSelector > but not both, otherwise you will violate the uniqueness rule. > > Objects could play many roles, depending on their use. Just take a > look at Object protocol, and answer yourself, how > many of these methods is userful in some specific case (such as an > object used to identify a message - selector). > So, if you want to dissect all roles onto a set of specific > (sub)classes, i propose to start from an Object class, > and then, gradually get to a Symbol. > >> This idea brings implementation challenges of course, but nothing new :-) >> On Wed, Aug 25, 2010 at 2:05 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> :) >>> >>> Your previous mail was what the bee I had in my bonnet :) >>> >>> Stef >>> >>> On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: >>> >>> > Actually I think is one of the better ideas I've read in this list. >>> > Too bad nobody seems interested in semiotics :( >>> > >>> > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> 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 >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> >> -- >> HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 11 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site:Â http://www.10Pines.com >> >> _______________________________________________ >> 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. > -- Best regards, Igor Stasenko AKA sig.

Aug. 25, 2010

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

by Igor Stasenko

On 25 August 2010 21:11, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > From the design point of view, I like the idea, a selector is not a symbol > and we can see that clearly in the Symbol protocol, like Mariano and Gabriel > said, implements messages that are related to selector behavior... Why > symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors > responsibilities... not all symbols are selectors... so for me, it is a good > idea. not all symbols are selectors... but you never tell, that they could not be, once you load new package or write more code. I see the need of having a separate subclass for Symbol , instead of stopping at String, because it have to maintain uniqueness and immutability. String + uniqueness + immutability => Symbol so, there is a strong reason for having a separate class for it, but Symbol + ??? => Selector give me a strong reason. i like the idea of shrinking a Symbol's protocol and putting it into lean and clean place - Symbol. But this is not strong enough. In practice, such shrinking, could lead to explosion of complexity in many other places. 'foo' = #foo ->true #foo = 'foo' -> true #foo asSelector = #foo ?? if so, then #foo hash = #foo asSelector hash ? and , obviously #foo == #foo asSelector => false which means, that mixing selectors and symbols in a single collection will be very bad idea, and source of bugs and confusion. But what gives us a uniqueness of symbols is, that we don't need to use #= for comparing them, but #== , which is much faster. Right? Now, if you introduce selectors, there is no uniqueness anymore, since selector is a symbol (since it is a subclass of it), and must honor the rules of its ancestor.. but its not. The only way how to deal with that is to make particular symbol (sub)instance to be either an instance of Symbol or Selector but not both. This means that in system you could have either #foo or #foo asSelector but not both, otherwise you will violate the uniqueness rule. Objects could play many roles, depending on their use. Just take a look at Object protocol, and answer yourself, how many of these methods is userful in some specific case (such as an object used to identify a message - selector). So, if you want to dissect all roles onto a set of specific (sub)classes, i propose to start from an Object class, and then, gradually get to a Symbol. > This idea brings implementation challenges of course, but nothing new :-) > On Wed, Aug 25, 2010 at 2:05 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> :) >> >> Your previous mail was what the bee I had in my bonnet :) >> >> Stef >> >> On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: >> >> > Actually I think is one of the better ideas I've read in this list. >> > Too bad nobody seems interested in semiotics :( >> > >> > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> 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 >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 11 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site:Â http://www.10Pines.com > > _______________________________________________ > 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.

Aug. 25, 2010

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

by Hernan Wilkinson

Could you give me an example? On Wed, Aug 25, 2010 at 3:16 PM, Marcin Tustin <mm3(a)zepler.net> wrote: > But then eliminating those methods introduces a circularity problem: What > if a symbol starts to be used as a selector part of the way through the life > of that object? It's not a fixed property of a symbol to be, or not be, a > selector. > > > On Wed, Aug 25, 2010 at 7:11 PM, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> wrote: > >> From the design point of view, I like the idea, a selector is not a symbol >> and we can see that clearly in the Symbol protocol, like Mariano and Gabriel >> said, implements messages that are related to selector behavior... Why >> symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors >> responsibilities... not all symbols are selectors... so for me, it is a good >> idea. >> This idea brings implementation challenges of course, but nothing new :-) >> >> On Wed, Aug 25, 2010 at 2:05 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> :) >>> >>> Your previous mail was what the bee I had in my bonnet :) >>> >>> Stef >>> >>> On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: >>> >>> > Actually I think is one of the better ideas I've read in this list. >>> > Too bad nobody seems interested in semiotics :( >>> > >>> > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> 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 >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> -- >> *HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 11 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 25, 2010

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

by Hernan Wilkinson

I think all the phrases should have the same "form"... or they should flow easily... for example: Simplicity is beautiful Communication is key They both have the same "form"... but they don't with: Examples to learn from Fully dynamic and malleable etc. I think we are mixing (or traiting :-) ) different goals... For example, I would change "Fully dynamic..." with something like "Fully dynamic to learn fast"... so maybe we could have: Simplicity to achieve beauty Communication to avoid repetition Fully dynamic to learn fast so all share the same "form"... and if we want to change the "form" we should do it slowly, connecting them...anyway, an style comment that I think we should have in mind. Bye, Hernan. PS: I sent the picture :-) On Tue, Aug 24, 2010 at 4: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 > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 25, 2010

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

by Marcin Tustin

But then eliminating those methods introduces a circularity problem: What if a symbol starts to be used as a selector part of the way through the life of that object? It's not a fixed property of a symbol to be, or not be, a selector. On Wed, Aug 25, 2010 at 7:11 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > From the design point of view, I like the idea, a selector is not a symbol > and we can see that clearly in the Symbol protocol, like Mariano and Gabriel > said, implements messages that are related to selector behavior... Why > symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors > responsibilities... not all symbols are selectors... so for me, it is a good > idea. > This idea brings implementation challenges of course, but nothing new :-) > > On Wed, Aug 25, 2010 at 2:05 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> :) >> >> Your previous mail was what the bee I had in my bonnet :) >> >> Stef >> >> On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: >> >> > Actually I think is one of the better ideas I've read in this list. >> > Too bad nobody seems interested in semiotics :( >> > >> > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> 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 >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 11 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > 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

Aug. 25, 2010

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

by Hernan Wilkinson

>From the design point of view, I like the idea, a selector is not a symbol and we can see that clearly in the Symbol protocol, like Mariano and Gabriel said, implements messages that are related to selector behavior... Why symbols respond to numArgs:, precedence, isUnary, etc? those are a selectors responsibilities... not all symbols are selectors... so for me, it is a good idea. This idea brings implementation challenges of course, but nothing new :-) On Wed, Aug 25, 2010 at 2:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > :) > > Your previous mail was what the bee I had in my bonnet :) > > Stef > > On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: > > > Actually I think is one of the better ideas I've read in this list. > > Too bad nobody seems interested in semiotics :( > > > > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 25, 2010

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

by StÃ©phane Ducasse

:) Your previous mail was what the bee I had in my bonnet :) Stef On Aug 25, 2010, at 6:57 PM, HernÃ¡n Morales Durand wrote: > Actually I think is one of the better ideas I've read in this list. > Too bad nobody seems interested in semiotics :( > > 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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 >> >> >> _______________________________________________ >> 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 HernÃ¡n Morales Durand

Actually I think is one of the better ideas I've read in this list. Too bad nobody seems interested in semiotics :( 2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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 > > > _______________________________________________ > 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] Invoking external processes/IPC

by StÃ©phane Ducasse

this scripting and other processes lunaching aspect is really important for us. On Aug 23, 2010, at 7:45 PM, Marcin Tustin 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? > > 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

Aug. 25, 2010

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

by Marcin Tustin

I'm not sure that I would class the fact that Alien wants the Special Objects Array to be bigger than it actually is to be a mere installation issue. On Wed, Aug 25, 2010 at 10:13 AM, John McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Ask on the Pharo list for help or instruction on loading alien into > pharo, I didn't write any of the loader code so I can't deal with the fact > it may or may not be broken. > > Sent from my iPad > > On 2010-08-25, at 1:30 AM, Marcin Tustin <mm3(a)zepler.net> wrote: > > 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 > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 25, 2010