September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Period at end of message pattern ?

by StÃ©phane Ducasse

We should clean all these places. Now the problem is that if the compiler is sloppy then we may have to redo that several times. So we should probably do that with opal (even if I do not like to postpone until it is there). Stef On Sep 30, 2010, at 8:25 AM, Lukas Renggli wrote: > The Pharo compiler (even more for the Squeak one) accepts all kind of > strange syntactic constructs. I remember having fixed the refactoring > engine parser dozens of times in the past years to accommodate such > abnormalities. And of course, there more code than you actually think > that uses these constructs (mostly accidental). > > Btw, there is a Code Critics rule in Grease that finds the > repeated/mis-placed dots in Smalltalk. In most other Smalltalk such > code doesn't load. > > Lukas > > > On 30 September 2010 05:46, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hmm , whats wrong with period? >> Its an empty nil-statement >> >> try evaluate: >> ....................... >> >> Of course, if such patter is then followed by temps declaration: >> >> foo. >> | a b c | >> >> then this could lead to error. >> >> But message pattern with just period? >> I don't feel its wrong. >> >> On 30 September 2010 06:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> So that's a method that is empty except for ending in a period? That probably should be an error. If the point is to have the last line of a "real" method never end in a period, then I would have a problem. >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of James Ladd [james_ladd(a)hotmail.com] >>> Sent: Wednesday, September 29, 2010 6:28 PM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: [Pharo-project] Period at end of message pattern ? >>> >>> Hi All, >>> >>> While filing in some sources form a friend into Redline Smalltalk the compiler generated an >>> error on the following message pattern (method signature): >>> >>> initializeBetween: aPitcher and: aBatter events: aCollectionOfEvents. >>> >>> The error was the trailing period "." >>> >>> This is acceptable in Pharo but not in the Blue Book definition. >>> >>> I think it should be an error in Pharo as well. What do you think? >>> >>> Rgs, James. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2010

Re: [Pharo-project] About open lively community vs a closed, withdrawn group of programmers

by George Herolyants

2010/9/30 Igor Stasenko <siguctua(a)gmail.com>: > No, but we are working together towards improving our system. > This is what you can't have in .net and/or java where community don't > have a chance to participate in development > process, but have to wait till vendor release new version, and then > start using it. Yes. But it relates mostly to .NET because MS aggressively tries to substitute all the open source libraries with their own "standard" ones (XML, ORM, even unit testing!). But in Java world the situation is a bit different. While users can't affect the language itself, the community makes plenty of libraries just to compensate the poorness of the language. And Sun (now Oracle) does not bother itself with inventing their own. I think the difference between these communities and Smalltalk community results from the nature of Smalltalk language where you can implement some system functionality as a library, while in other lanugages this would require changes made by vendor in the core. George

Sept. 30, 2010

[Pharo-project] some fixes of Undeclared

by Pavel Krivanek

Hi, I added issues 3016-3018 that fixes some Undeclared in latest Pharo 1.2. That makes Undeclared empty. Cheers -- Pavel

Sept. 30, 2010

Re: [Pharo-project] Period at end of message pattern ?

by Lukas Renggli

The Pharo compiler (even more for the Squeak one) accepts all kind of strange syntactic constructs. I remember having fixed the refactoring engine parser dozens of times in the past years to accommodate such abnormalities. And of course, there more code than you actually think that uses these constructs (mostly accidental). Btw, there is a Code Critics rule in Grease that finds the repeated/mis-placed dots in Smalltalk. In most other Smalltalk such code doesn't load. Lukas On 30 September 2010 05:46, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hmm , whats wrong with period? > Its an empty nil-statement > > try evaluate: > ....................... > > Of course, if such patter is then followed by temps declaration: > > foo. > | a b c | > > then this could lead to error. > > But message pattern with just period? > I don't feel its wrong. > > On 30 September 2010 06:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> So that's a method that is empty except for ending in a period? Â That probably should be an error. Â If the point is to have the last line of a "real" method never end in a period, then I would have a problem. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of James Ladd [james_ladd(a)hotmail.com] >> Sent: Wednesday, September 29, 2010 6:28 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Period at end of message pattern ? >> >> Hi All, >> >> While filing in some sources form a friend into Redline Smalltalk the compiler generated an >> error on the following message pattern (method signature): >> >> initializeBetween: aPitcher and: aBatter events: aCollectionOfEvents. >> >> The error was the trailing period "." >> >> This is acceptable in Pharo but not in the Blue Book definition. >> >> I think it should be an error in Pharo as well. What do you think? >> >> Rgs, James. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch

Sept. 30, 2010

Re: [Pharo-project] Period at end of message pattern ?

by Igor Stasenko

Hmm , whats wrong with period? Its an empty nil-statement try evaluate: ....................... Of course, if such patter is then followed by temps declaration: foo. | a b c | then this could lead to error. But message pattern with just period? I don't feel its wrong. On 30 September 2010 06:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > So that's a method that is empty except for ending in a period? Â That probably should be an error. Â If the point is to have the last line of a "real" method never end in a period, then I would have a problem. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of James Ladd [james_ladd(a)hotmail.com] > Sent: Wednesday, September 29, 2010 6:28 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Period at end of message pattern ? > > Hi All, > > While filing in some sources form a friend into Redline Smalltalk the compiler generated an > error on the following message pattern (method signature): > > initializeBetween: aPitcher and: aBatter events: aCollectionOfEvents. > > The error was the trailing period "." > > This is acceptable in Pharo but not in the Blue Book definition. > > I think it should be an error in Pharo as well. What do you think? > > Rgs, James. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 30, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by Igor Stasenko

On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > "A proper error handling is an important part of infrastructure-level > project (such as NativeBoost), since then people who using it, > can quickly determine what's wrong with their code." > > Well said!!!! Â Still working on that grant proposal; I'll be glad when it's submitted. Â Do you have any sense of when callbacks will be available? Â Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them. > I'd like to see someone, like you to start using it. And during it, i can start receiving feedback and so, NB could improve in quality and feature set :) See, i did most stuff , what i would need , but apparently i could miss something which may be userfull as well. > One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was > > void LogOnePlus(double * data, unsigned long size) > /* > Â Â Â Â Add one and take log10() over the buffer; in-place transformation! > */ > { > Â Â Â Â for(unsigned long i=0; i<size; i++){ > Â Â Â Â data[i] = log10(data[i]+1); > Â Â Â Â } > } > > That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :) > Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code. > Bill -- Best regards, Igor Stasenko AKA sig.

Sept. 30, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by Schwab,Wilhelm K

Sig, "A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code." Well said!!!! Still working on that grant proposal; I'll be glad when it's submitted. Do you have any sense of when callbacks will be available? Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them. One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } } That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, September 29, 2010 6:31 PM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] NativeBoost and Cog. A working protype. Hello, just wanna tell you that i adopted NativeBoost under Cog and have a first running prototype. It still lacks callbacks support, but its already can be used for callouts and to run native code. NativeBoost-CogPlugin does not requires patched for platform-specific code. Just load it into Cog VMMaker image, generate & build vm and you done! Thanks Eliot for providing necessary bits for controlling memory execution protection. The NativeBoost-CogPlugin will have some additional functionality, comparing to its Squeak VM cousin. - it using a primitive failure codes, so when primitive fails , you can determine why and where your native call fails. The primitive error codes still not handled/used by language side, so its a work to do: - a marchalling code can use error codes to report that primitive fails due to coercion error, and it even will tell which exactly argument failed to coerce. - of course, you will be able to add own custom error codes, and handle them as you like to. By default, a plugin could report following problems: "execution of native code is not enabled by plugin" ErrNotEnabled "failed to find a native code for primitive method" ErrNoNativeCodeInMethod "native code generated for different platform" ErrInvalidPlatformId I wanna say thanks to Eliot for providing primitive fail codes in VM. A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 30, 2010

Re: [Pharo-project] Period at end of message pattern ?

by Schwab,Wilhelm K

So that's a method that is empty except for ending in a period? That probably should be an error. If the point is to have the last line of a "real" method never end in a period, then I would have a problem. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of James Ladd [james_ladd(a)hotmail.com] Sent: Wednesday, September 29, 2010 6:28 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Period at end of message pattern ? Hi All, While filing in some sources form a friend into Redline Smalltalk the compiler generated an error on the following message pattern (method signature): initializeBetween: aPitcher and: aBatter events: aCollectionOfEvents. The error was the trailing period "." This is acceptable in Pharo but not in the Blue Book definition. I think it should be an error in Pharo as well. What do you think? Rgs, James.

Sept. 30, 2010

Re: [Pharo-project] Metacello loading default (was: Updating the Alien Squeaksource page)

by Dale Henrichs

Damien Pollet wrote: > 2010/9/29 Fernando olivero <fernando.olivero(a)usi.ch>: >> Then evaluate the following to get the default installation >> (Smalltalk globals classNamed: 'ConfigurationOfAlien') >> perform:#loadLatestVersion. > > I saw that many recent Metacello configurations now define > ConfigurationOfWhatever loadDefault. > It would be nice to switch to that idiom, and maybe make a campaign of > updating existing configurations, while there are still not so many of > themâ¦ > > Damien, On the Metacello mailing list we are discussing some new features that should allow us to settle in on a set of standard methods for loading configurations. The root of the problem is that #lastVersion and #latestVersion are not quite what is needed. They are shortcuts, but they are shortcuts in the wrong model ... We are exploring the notion of a stable, development, and bleedingEdge versions which seem to make more sense than #lastVersion and #latestVersion, but the solution we are exploring goes deeper than just adding more (or different) shortcuts. We are still working through implementation details, but if the proposals pan out, Mariano and I (plus other volunteers perhaps) will make a pass through the public configurations. At this point in time it is premature to make any sweeping additions or changes... If you're interested in details, I invite you to join the conversation on the list. Dale

Sept. 29, 2010

Re: [Pharo-project] How to subclass Process and have it used by spawned blocks?

by Igor Stasenko

On 29 September 2010 12:21, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > On 29 Sep 2010, at 11:01, Igor Stasenko wrote: > >> On 29 September 2010 11:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> no idea but I want to know that too so keep us posted. >>> >> Smalltalk specialObjectsArray at: 28. >> Thats it, Process is a special object, recognized by VM. >> No other Process (sub)classes can be accepted by it. > Could you elaborate on that? No other process can be accepted for what? > Being scheduled, or being executed? > > There is also a comment in the comment of Process which suggests that it should be possible: > "(If anyone ever makes a subclass of Process, be sure to use allSubInstances in anyProcessesAbove:.)" > But even after making the change, that does not seem to be the actual problem. > Yeah, this not an issue. Sorry for wrong info. > > The process gets execute fine. With a '1 halt.' as the first statement of the aBlock block I even get a debugger. It only fails on accessing variables referenced by the closure with an index out of bound error or something similar. > >>> Erlang>>spawn: aBlock >>> Â Â Â "Answer an ErlProcess running the code given in the parameter. >>> Â Â Â Â The process is scheduled." >>> Â Â Â | proc | >>> Â Â Â proc := ErlProcess >>> Â Â Â Â Â Â Â forContext: >>> Â Â Â Â Â Â Â Â Â Â Â [1 halt. aBlock value. >>> Â Â Â Â Â Â Â Â Â Â Â Â Processor terminateActive] asContext >>> Â Â Â Â Â Â Â priority: Processor activePriority. >>> Â Â Â proc resume. >>> Â Â Â ^ proc > > > Thanks and best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 29, 2010