December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] On not unnecessarily closing down the language

by Vassili Bykov

I don't think you guys see that what Lukas is proposing is not necessarily a change of the language, but a better stratification of the system. Arguments don't have to be writable in a Smalltalk program if tradition dictates they shouldn't be. But a good language platform would still support that under the hood. Janko already pointed out that VisualWorks suggests but does not enforce variable capitalization rules. VisualWorks also supports assigning to method arguments. It's a compiler flag, and it's off by default when compiling Smalltalk methods, but you can implement a different language with different rules and still use the same code generator simply by flipping that switch. The VM supports that too, despite being much more advanced. And let me once again explain that this has nothing to do with the ability to restart a context. As long as a message is sent by computing argument values and pushing them on the stack in the sender context, and as long as there is a context reflection facility (and I can't imagine a decent implementation without one regardless of how the contexts are really managed), the debugger can always restore the original values from the sender context. --Vassili On Mon, Dec 29, 2008 at 2:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I agree and to me looks like a change for a change. > There are so much things I would like to see better in Pharo... > > > On Dec 29, 2008, at 2:51 AM, Igor Stasenko wrote: > >> 2008/12/29 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: >>> Frankly speaking, I am left unconvinced that allowing argument to be >>> writable will increase the quality of Pharo. >>> >> me too. >> It would be better to keep distinction between arguments and temps and >> do not rely on implementation. >> I think that in stack-based VM , an assignable arguments could be >> problematic, because if you want to restart a method, you will be >> unable to recover original values because they are not copied in >> context but lying on stack. >>

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Janko MivÅ¡ek

Hi Stef, StÃ©phane Ducasse wrote: > I checked and > - pharo does not complain for what seems good. So no bugs from our > side. > > - SwazooBenchmarks seems to have an instance class variable with > uppercase > Singleton > > can you check and confirm. I tried to load beta2.2 > Thanks Yep, that's it! And it seems it comes from VW definition, where since 7.x you don't have class variables anymore but just shared ones. It seems I wrongly put this Singleton as the class instance variable and porting to Squeak ported that mistake too. Sorry for that and the error will be corrected in the next release. In the meantime you can safely just ignore it. Best regards Janko > > On Dec 29, 2008, at 5:16 PM, Janko MivÅ¡ek wrote: > >> Hi Ramon, >> >> Ramon Leon wrote: >> >>>>> Yes I contacted Janko if he can fix that >>>> I can fix of course but I'm a bit surprised that in Squeak the class >>>> variables are supposed to be lower case. I have in mind back >>>> from 1996 >>>> that they must be uppercase. >>> Janko, I'm pretty sure Lukas was talking about a class instance >>> variable, >>> not a class variable. Class instance variables should be lowercase >>> while >>> class vars are uppercase. Swazoo apparently contains a class- >>> instance >>> variable that is uppercased, which regardless of the outcome of this >>> discussion, should probably be fixed. >> Here is the exact definition of a Swazoo class in question: >> >> Object subclass: #SwazooServer >> instanceVariableNames: 'sites servers watchdog' >> classVariableNames: 'Singleton' >> poolDictionaries: '' >> category: 'Swazoo-Core' >> >> And here the same definition of Swazoo SiteRegistry in VW 3.0 back >> from >> 2000: >> >> Object subclass: #SiteRegistry >> instanceVariableNames: 'sites servers ' >> classVariableNames: 'Singleton ' >> poolDictionaries: '' >> category: 'Swazoo' >> >> So, this is obviously a class variable definition and not an instance >> one. Where is the problem then? I don't find any class instance >> variables in other classes and in any way the Singleton should be only >> class variable in use in Swazoo. >> >> Best regards >> Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Ramon Leon

> > Strange if this is really that then it is correct and the check in > wrong in pharo. > I will check and fix > > Stef I just did, I get no errors, this class Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core' Compiles just fine in Pharo, I see nothing wrong with it. Ramon Leon http://onsmalltalk.com

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Hi janko I checked and - pharo does not complain for what seems good. So no bugs from our side. - SwazooBenchmarks seems to have an instance class variable with uppercase Singleton can you check and confirm. I tried to load beta2.2 Thanks Stef On Dec 29, 2008, at 5:16 PM, Janko MivÅ¡ek wrote: > Hi Ramon, > > Ramon Leon wrote: > >>>> Yes I contacted Janko if he can fix that > >>> I can fix of course but I'm a bit surprised that in Squeak the class >>> variables are supposed to be lower case. I have in mind back >>> from 1996 >>> that they must be uppercase. > >> Janko, I'm pretty sure Lukas was talking about a class instance >> variable, >> not a class variable. Class instance variables should be lowercase >> while >> class vars are uppercase. Swazoo apparently contains a class- >> instance >> variable that is uppercased, which regardless of the outcome of this >> discussion, should probably be fixed. > > Here is the exact definition of a Swazoo class in question: > > Object subclass: #SwazooServer > instanceVariableNames: 'sites servers watchdog' > classVariableNames: 'Singleton' > poolDictionaries: '' > category: 'Swazoo-Core' > > And here the same definition of Swazoo SiteRegistry in VW 3.0 back > from > 2000: > > Object subclass: #SiteRegistry > instanceVariableNames: 'sites servers ' > classVariableNames: 'Singleton ' > poolDictionaries: '' > category: 'Swazoo' > > So, this is obviously a class variable definition and not an instance > one. Where is the problem then? I don't find any class instance > variables in other classes and in any way the Singleton should be only > class variable in use in Swazoo. > > Best regards > Janko > > > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Strange if this is really that then it is correct and the check in wrong in pharo. I will check and fix Stef On Dec 29, 2008, at 5:16 PM, Janko MivÅ¡ek wrote: > Hi Ramon, > > Ramon Leon wrote: > >>>> Yes I contacted Janko if he can fix that > >>> I can fix of course but I'm a bit surprised that in Squeak the class >>> variables are supposed to be lower case. I have in mind back >>> from 1996 >>> that they must be uppercase. > >> Janko, I'm pretty sure Lukas was talking about a class instance >> variable, >> not a class variable. Class instance variables should be lowercase >> while >> class vars are uppercase. Swazoo apparently contains a class- >> instance >> variable that is uppercased, which regardless of the outcome of this >> discussion, should probably be fixed. > > Here is the exact definition of a Swazoo class in question: > > Object subclass: #SwazooServer > instanceVariableNames: 'sites servers watchdog' > classVariableNames: 'Singleton' > poolDictionaries: '' > category: 'Swazoo-Core' > > And here the same definition of Swazoo SiteRegistry in VW 3.0 back > from > 2000: > > Object subclass: #SiteRegistry > instanceVariableNames: 'sites servers ' > classVariableNames: 'Singleton ' > poolDictionaries: '' > category: 'Swazoo' > > So, this is obviously a class variable definition and not an instance > one. Where is the problem then? I don't find any class instance > variables in other classes and in any way the Singleton should be only > class variable in use in Swazoo. > > Best regards > Janko > > > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Janko MivÅ¡ek

Hi Ramon, Ramon Leon wrote: >>> Yes I contacted Janko if he can fix that >> I can fix of course but I'm a bit surprised that in Squeak the class >> variables are supposed to be lower case. I have in mind back >> from 1996 >> that they must be uppercase. > Janko, I'm pretty sure Lukas was talking about a class instance variable, > not a class variable. Class instance variables should be lowercase while > class vars are uppercase. Swazoo apparently contains a class-instance > variable that is uppercased, which regardless of the outcome of this > discussion, should probably be fixed. Here is the exact definition of a Swazoo class in question: Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core' And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000: Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo' So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo. Best regards Janko -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Exact! And lukas is just reporting a problem with pharo since we put a check to make sure that class instance variables are lowercase and class variable are uppecased. So Janko can you check a class instance variable named Singleton that should be named singleton. Stef On Dec 29, 2008, at 4:55 PM, Ramon Leon wrote: >>> Yes I contacted Janko if he can fix that >> >> I can fix of course but I'm a bit surprised that in Squeak the class >> variables are supposed to be lower case. I have in mind back >> from 1996 >> that they must be uppercase. > > Janko, I'm pretty sure Lukas was talking about a class instance > variable, > not a class variable. Class instance variables should be lowercase > while > class vars are uppercase. Swazoo apparently contains a class-instance > variable that is uppercased, which regardless of the outcome of this > discussion, should probably be fixed. > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Ramon Leon

> > Yes I contacted Janko if he can fix that > > I can fix of course but I'm a bit surprised that in Squeak the class > variables are supposed to be lower case. I have in mind back > from 1996 > that they must be uppercase. Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class-instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed. Ramon Leon http://onsmalltalk.com

Dec. 29, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Janko MivÅ¡ek

Hi guys, Damien, Alexandre: >>> I am aware that I am talking as someone who does not maintain cross- >>> dialect applications, but we cannot trade readability for a local in >>> time commodity. >> Sure, but we could try to make the transition easier (e.g., complain >> to Janko for the moment and wait until Pharo stable to enforce >> conventions) StÃ©phane Ducasse wrote: > Yes I contacted Janko if he can fix that I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase. I just managed to open an old VisualWorks 2.5.2 image back from 1996 and exactly, class vars should be uppercase, see this class construction template: NameOfSuperclass subclass: #NameOfClass instanceVariableNames: 'instVarName1 instVarName2' classVariableNames: 'ClassVarName1 ClassVarName2' poolDictionaries: '' category: 'Collections-Unordered' But naming them lowercase is not enforced, you just got a warning: Static variable names should be capitalized. So, it seems that Squeak changed this convention or is this just a consequence of some later developed habit? From this I suggest that Lucas's proposal is considered, but only for this case regarding the class variables. Otherwise we will have the porting problems all the time. Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 29, 2008

Re: [Pharo-project] Dictionary as a Set

by StÃ©phane Ducasse

On Dec 29, 2008, at 12:23 PM, Alexandre Bergel wrote: > Dear List, > > I was wondering whether I am the only one shocked when I see this: > > (Set new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> true > (Set new add: #b -> 'B'; yourself) includes: 'B' ====> false this is correct > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' > ====> false > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> true we should check the semantics of includes: > Dictionary inherits from Set. This means that if Set would have a > contract, it would break in Dictionary. > IMO, we should have > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> > true > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> false > > No? Dictionary and Set relationship is subclassing so a lot can be strange. We should fix that in Bloc. > > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2008