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

Re: [Pharo-project] Explicit return in []

by Eliot Miranda

On Thu, Sep 15, 2011 at 12:38 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > As Lukas says, not if one has exceptions. But Smalltalk-80 V2 didn't > have exceptions, and so needed ^-return. > > Yes this is really what I was thinking too. > > > Personally I find ^-return elegant and a vital part of the language's > simplicity. > > I agree but I wanted to really understand it because lars is not a fool. > > > If ^-return is not allowed in blocks then blocks are special-cases, must > be explained, and avoided in certain cases, etc. Getting rid of it pushes > the language in a more traditional convenient-for-the-language-implementor > direction that I think is a serious mistake. Language should serve the > author/reader, *not* the implementor. > > In my question came when I realized stupidly that "home" or the stuff to > jump (to a context) was a context and not a compiled method. Because we need > to jump to an activation > and not just a bytecode holder. So I tried to understand the jumping > behavior implication. > > In fact my real question was would not having ^-return in [] change the > closure implementation and in particular implementation of home. Would home > be required to return a context and if needed. I guess not. I should look > at home senders. > Indeed. Not having ^-return means closures wouldn't need a home. In VisualWorks this is at the heart of the full/non-full block distinction. Full blocks have a home context, non-full (copying & clean) blocks don't have a home. So instantiating copying blocks is quicker since it doesn't involve instantiating the block's enclosing context. You'll see in my closure implementation that I took a short-cut and just ate the cost of instantiating the enclosing context (outerContext) to avoid having a) to implement the analysis in the compiler and b) to keep the number of bytecodes down). In a later image format/bytecode format I could revisit that decision. In particular, BlockClosure needs separate method and receiver inst vars so that it can be activated independently. Right now the value[:value:*] primitives fetch method and receiver from outerContext. But look, once the new object representation/GC is finished everything will be significantly faster anyway. So I wouldn't worry too much about this. Right now things are simple; we have only one kind of block, and performance in some cases is slightly sub-optimal. That's an acceptable price for now, no? When I coded a simple (probably too simple) scheme/lisp interpreter, > closures were trivial (got an alist chained to nested environment) and it > was it. > Now I was trying to understand (this is why I'm looking at the block > implementation) is the next question: if removing ^- was leading to a > if removing ^- was like removing upward funargs. > > Now I implemented call/cc in a probably bad ways (CSP) so fast versions > probably introduces context too. since this is just copying the activation > stack and jumping to it. > > > Q1 When are they absolutely required? > > Q2 What replacing mechanisms would be needed? > > Q3 What would we gain from an implementation stand point? > > > > Some simplicity, certainly. But (IMO) ^-return isn't as complex as > method lookup and message cacheing so you're not reducing complexity > overall. > > > > It seems that in resilience lars removed them and more. > > > > Yes, IIRC he got rid of first-class blocks. They can only be downward > funargs (passed as parameters), not upward funargs (stored in inst vars, > returned as results and hence used after their enclosing activation has > returned). > > Yes exactly. So I wanted to know if removing ^- was like removing upward > funargs. > Well, one can't remove upward fiunarg support without removing ^-return. But one can implement downward funargs in a number of ways, so this isn't the only issue. > > > > > > Stef > > > > for Q1 I see > > > > foo > > x isZero ifTrue: [^ 33]. > > self continue > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Sept. 15, 2011

Re: [Pharo-project] [squeak-dev] Re: Issue 4538 and CompiledMethod equality

by Eliot Miranda

On Thu, Sep 15, 2011 at 1:00 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Thu, Sep 15, 2011 at 9:45 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> Ok, I understand. But > >> > >> On Thu, Sep 15, 2011 at 6:05 PM, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >>> > >>> On 15.09.2011 17:27, Mariano Martinez Peck wrote: > >>> > >>> Hi guys. I am having a problem with the integration of issue 4538: > >>> http://code.google.com/p/pharo/issues/detail?id=4538 > >>> > >>> I am serializing CompiledMethods with Fuel and then I materialize them. > >>> To test they are correct, I use #= > >>> So far it was working correctly, but now for the materialized method it > >>> says they are not equal. The problem is that #= is failing in > >>> > >>> (self sameLiteralsAs: aCompiledMethod) > >>> > >>> And inside that method, it is failing because (literal1 == literal2 > >>> or: [ literal1 literalEqual: literal2 ]) > >>> answers false. > >>> > >>> So... why literal1 literalEqual: literal2 answers false? from what I > can > >>> say, having that selector: "literalEqual", then both MUST be equal, > because > >>> they are. > >>> The problem is that it was added: > >>> > >>> Association >> literalEqual: otherLiteral > >>> "Answer true if the receiver and otherLiteral represent the same > >>> literal. > >>> Variable bindings are literally equals only if identical. > >>> This is how variable sharing works, by preserving identity and > >>> changing only the value." > >>> ^self == otherLiteral > >>> > >>> > >>> So....I am not sure I agree with this change. > >>> > >>> Any idea how can we deal with this problem? > >>> > >>> Cheers > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >>> The change is correct, here's an example: > >>> > >>> Create a global: > >>> Global := 1 > >>> > >>> Create a method: > >>> foo > >>> ^Global > >>> > >>> Serialize method, deserialize > >>> > >>> Change value of global: > >>> Global := 5. > >>> > >>> foo should return 5, not 1. > >>> Unless it's actually the same association as in the SystemDictionary, > >>> this will not be true. > >>> > >> > >> I understand that. In fact, in Fuel we use exactly the same association > of > >> SystemDictionary for globals. Look this test example: > >> > >> testGlobalVariableMethod > >> > >> | materializedCompiledMethod | > >> Smalltalk globals at: #TestGlobalVariableMethod2 put: false. > >> (self class compileSilently: 'globalVariableForTestingMethod > >> Transcript name. > >> ^ GlobalVariableForTesting.'). > >> > >> materializedCompiledMethod := self materializedCompiledMethod: (self > >> class >> #globalVariableForTestingMethod). > >> Smalltalk globals at: #GlobalVariableForTesting put: true. > >> self assert: (materializedCompiledMethod valueWithReceiver: self > >> arguments: #()). > >> > >> > >> > >> BUT, it doesn't mean that Association is always used for globals. > >> CompiledMethod equality is failing because of the last literal, the one > that > >> maps class name (symbol) and point to the real class. So...when I > >> materialize, both CMs have non-identical associations for the last > literal, > >> but equal. > > > > As Henrik says the last literals are ideally #== to each other. However, > no > > Squeak dialect makes any attempt to keep the class0side associations > equal. > > Look at a class-side method and you'll see it's last literal is > > nil->SomeClass class. Now since this association doesn't exist in > Smalltalk > > (unlike last literals on the instance side) the compiler merely creates > > distinct ones for each class-side method. > > Personally I don't think one can defend the position where method > equality > > is different for instance-side or class-side methods so there must be > some > > solutions: > > Hmm, good catch. > A metaclass is never accessed by dictionary lookup, but only by > sending #class to a class, so there is no point in maintaining a > unique Association. > (otherwise, we could maintain such Association in inst. var. thisClass). > Having a nil key is a clear indication that lookup is pointless. > > The question is why having an association at all in the CompiledMethod ? > For handling super sends ? > Yes, but two reasons. One is super sends and the other is being able to answer the methodClass (e.g. for CompiledMethod>>printOn: and for the debugger). One doesn't need to use an association, but one can't change that without changing al the VMs /and/ changing the ClassBuilder so that when it becomes a class on class redefinition the methodsa are updated. Indeed VisualWorks does exactly this. In any case, the super send implementation in the VM means we can't change this overnight :) > I think a simple reference to the class would be enough. > IMHO, the purpose was to simplify implementation. > > And I don't think the example of Henrik is worth : > Lets just change it a bit: > > Object subclass: #SuperFoo.! > Object subclass: #Bar.! > SuperFoo subclass: #Foo.! > > SuperFoo compile: 'bar ^1'. > Foo compile: 'bar > ^super bar *2'. > foo := Foo new. > Smalltalk at: #Foo put: Bar. > ^foo bar > > Could you predict the result (will it try to invoke super Bar bar) ? > Yes, since the last association is shared, we just broke (foo > class>>bar) for no reason... > Right. But Rube Goldberg machines work like Rube Goldberg machines. Tis the nature of the beast. Doctors say "don't do that", and in Smalltalk we should say "what did you expect"? :) Being able to change the system is worth the cost of it behaving contrary to common-sense. Just like the physical world :) > Nicolas > > > 1. special case comparison of the last literal (the methodClass literal), > > comparing keys and insisting that the keys be #== and the values be #== > > (can't just define it as keys #== since all similar class-side methods > will > > be equal irrespective of their actual class). > > 2. special case comparison of the last literal (the methodClass literal), > > insisting only that the class of the literal be the same if it > > isVariableBinding. > > 3. make the compile unique class-side methodClass literals. i.e. if a > class > > already has a class-side method then the compiler or method dictionary > > insertion code must find that existing association and reuse it > > Other ideas? > > > >> > >> >From my point of view, that literal, the last one does not need to be > >> identical to assume 2 CMs are equal. They just need to be equal. > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > -- best, Eliot

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Frank Shearar

On 15 September 2011 20:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> As Lukas says, not if one has exceptions. Â But Smalltalk-80 V2 didn't have exceptions, and so needed ^-return. > > Yes this is really what I was thinking too. > >> Personally I find ^-return elegant and a vital part of the language's simplicity. > > I agree but I wanted to really understand it because lars is not a fool. > >> Â If ^-return is not allowed in blocks then blocks are special-cases, must be explained, and avoided in certain cases, etc. Â Getting rid of it pushes the language in a more traditional convenient-for-the-language-implementor direction that I think is a serious mistake. Â Language should serve the author/reader, *not* the implementor. > > In my question came when I realized stupidly that "home" or the stuff to jump (to a context) was a context and not a compiled method. Because we need to jump to an activation > and not just a bytecode holder. So I tried to understand the jumping behavior implication. > > In fact my real question was would not having ^-return in [] change the closure implementation and in particular implementation of home. Would home > be required to return a context and if needed. I guess not. I should look at home senders. > > When I coded a simple (probably too simple) scheme/lisp interpreter, closures were trivial (got an alist chained to nested environment) and it was it. > Now I was trying to understand (this is why I'm looking at the block implementation) is the next question: if removing ^- was leading to a > Â if removing ^- was like removing upward funargs. > > Now I implemented call/cc in a probably bad ways (CSP) so fast versions probably introduces context too. since this is just copying the activation stack and jumping to it. Do you mean CPS/continuation passing style? I've been thinking about how to do CPS on Smalltalk, these past few weeks, precisely for (delimited) continuations. I'd like to contrast the technique with my current implementation, using exceptions. How are you finding it? Delimited continuations are superior to call/cc at any rate: it's trivial to express call/cc in terms of delimited continuations (wrap your entire process in a prompt and you're done), but the converse isn't true. You can fake delimited continuations a la call/cc + mutable cell, but it's messier. Also, undelimited continuations can't be treated like functions, and can't compose. Oleg Kiselyov's written a fair about the issue, and continuations in general: * http://lambda-the-ultimate.org/node/4313 * http://okmij.org/ftp/continuations/undelimited.html * http://lambda-the-ultimate.org/node/86 * http://okmij.org/ftp/continuations/index.html frank >> Q1 When are they absolutely required? >> Q2 What replacing mechanisms would be needed? >> Q3 What would we gain from an implementation stand point? >> >> Some simplicity, certainly. Â But (IMO) ^-return isn't as complex as method lookup and message cacheing so you're not reducing complexity overall. >> >> It seems that in resilience lars removed them and more. >> >> Yes, IIRC he got rid of first-class blocks. Â They can only be downward funargs (passed as parameters), not upward funargs (stored in inst vars, returned as results and hence used after their enclosing activation has returned). > > Yes exactly. So I wanted to know if removing ^- was like removing upward funargs. >> >> >> Stef >> >> for Q1 I see >> >> foo >> Â Â Â Â x isZero ifTrue: [^ 33]. >> Â Â Â Â self continue >> >> >> >> -- >> best, >> Eliot >> > > >

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by StÃ©phane Ducasse

why do you use 14112? especially in alpha this is good to move close to the edge but not too close :) Stef On Sep 15, 2011, at 7:54 PM, Mariano Martinez Peck wrote: > mmmm which image? I am in 14112 and it doesn't work for me :( > > On Thu, Sep 15, 2011 at 7:42 PM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > But it works for me in 1.4 > Alain > > > On 15/09/2011 16:48, Mariano Martinez Peck wrote: > Hi guys. I cannot live without smart characters or whatever they are > called. What I mean is when you select/surround something (a piece of > text) and when you press '(' or '[', or whatever opening symbol, it adds > both, the opening and the closing one to what you have selected. > > So...how can I have that in Pharo 1.4 ? > > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by StÃ©phane Ducasse

> As Lukas says, not if one has exceptions. But Smalltalk-80 V2 didn't have exceptions, and so needed ^-return. Yes this is really what I was thinking too. > Personally I find ^-return elegant and a vital part of the language's simplicity. I agree but I wanted to really understand it because lars is not a fool. > If ^-return is not allowed in blocks then blocks are special-cases, must be explained, and avoided in certain cases, etc. Getting rid of it pushes the language in a more traditional convenient-for-the-language-implementor direction that I think is a serious mistake. Language should serve the author/reader, *not* the implementor. In my question came when I realized stupidly that "home" or the stuff to jump (to a context) was a context and not a compiled method. Because we need to jump to an activation and not just a bytecode holder. So I tried to understand the jumping behavior implication. In fact my real question was would not having ^-return in [] change the closure implementation and in particular implementation of home. Would home be required to return a context and if needed. I guess not. I should look at home senders. When I coded a simple (probably too simple) scheme/lisp interpreter, closures were trivial (got an alist chained to nested environment) and it was it. Now I was trying to understand (this is why I'm looking at the block implementation) is the next question: if removing ^- was leading to a if removing ^- was like removing upward funargs. Now I implemented call/cc in a probably bad ways (CSP) so fast versions probably introduces context too. since this is just copying the activation stack and jumping to it. > Q1 When are they absolutely required? > Q2 What replacing mechanisms would be needed? > Q3 What would we gain from an implementation stand point? > > Some simplicity, certainly. But (IMO) ^-return isn't as complex as method lookup and message cacheing so you're not reducing complexity overall. > > It seems that in resilience lars removed them and more. > > Yes, IIRC he got rid of first-class blocks. They can only be downward funargs (passed as parameters), not upward funargs (stored in inst vars, returned as results and hence used after their enclosing activation has returned). Yes exactly. So I wanted to know if removing ^- was like removing upward funargs. > > > Stef > > for Q1 I see > > foo > x isZero ifTrue: [^ 33]. > self continue > > > > -- > best, > Eliot >

Sept. 15, 2011

[Pharo-project] Class>>asRingDescription

by Fernando Olivero

Veronica, i've started to adopt Ring in Gaucho. Very nice work, excellent tests also! A question, why does the following is true? Collection asRingDefinition methods isEmpty = true If you look at the following method, Â they should be added here right?, on the ring definition creation. Class>>asRingDefinition Â Â Â Â | ring | Â Â Â Â ring := (RGFactory current createClassNamed: self name) Â Â Â Â Â Â Â Â category: self category; Â Â Â Â Â Â Â Â superclassName: self superclass name; Â Â Â Â Â Â Â Â traitCompositionSource: self traitCompositionString; Â Â Â Â Â Â Â Â addInstanceVariables: self instVarNames; Â Â Â Â Â Â Â Â addClassVariables: self classVarNames; Â Â Â Â Â Â Â Â addPoolDictionaries: self poolDictionaryNames; Â Â Â Â Â Â Â Â comment: self organization classComment; Â Â Â Â Â Â Â Â stamp: self organization commentStamp; Â Â Â Â Â Â Â Â definitionSource: self definition; Â Â Â Â Â Â Â Â withMetaclass. Â Â Â Â ring theMetaClass Â Â Â Â Â Â Â Â traitCompositionSource: self theMetaClass traitCompositionString; Â Â Â Â Â Â Â Â definitionSource: self theMetaClass definition; Â Â Â Â Â Â Â Â addInstanceVariables: self theMetaClass instVarNames. Â Â Â Â ^ring I'm using the latest Pharo1.4 from Jenkins. Fernando

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Camillo Bruni

fresh image from jenkins, and it works ;) https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… opened workspace entered: asdfasd cmd - a cmd + shift + " result: "asdfasd" so thats working in the latest version, AFAIK it worked always with me On 2011-09-15, at 20:03, Mariano Martinez Peck wrote: > > On Thu, Sep 15, 2011 at 7:55 PM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > that's working when you press shiftâ¦ > > - select text > - press shift + [ or '"({ > > the character will surround the textâ¦ > > > Still. It does not work. Are you testing in 14112 ? > > > > On 2011-09-15, at 16:48, Mariano Martinez Peck wrote: > > > Hi guys. I cannot live without smart characters or whatever they are called. What I mean is when you select/surround something (a piece of text) and when you press '(' or '[', or whatever opening symbol, it adds both, the opening and the closing one to what you have selected. > > > > So...how can I have that in Pharo 1.4 ? > > > > Thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Mariano Martinez Peck

On Thu, Sep 15, 2011 at 7:55 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > that's working when you press shiftâ¦ > > - select text > - press shift + [ or '"({ > > the character will surround the textâ¦ > > Still. It does not work. Are you testing in 14112 ? > > > On 2011-09-15, at 16:48, Mariano Martinez Peck wrote: > > > Hi guys. I cannot live without smart characters or whatever they are > called. What I mean is when you select/surround something (a piece of text) > and when you press '(' or '[', or whatever opening symbol, it adds both, the > opening and the closing one to what you have selected. > > > > So...how can I have that in Pharo 1.4 ? > > > > Thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Camillo Bruni

that's working when you press shiftâ¦ - select text - press shift + [ or '"({ the character will surround the textâ¦ On 2011-09-15, at 16:48, Mariano Martinez Peck wrote: > Hi guys. I cannot live without smart characters or whatever they are called. What I mean is when you select/surround something (a piece of text) and when you press '(' or '[', or whatever opening symbol, it adds both, the opening and the closing one to what you have selected. > > So...how can I have that in Pharo 1.4 ? > > Thanks > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 15, 2011

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Mariano Martinez Peck

mmmm which image? I am in 14112 and it doesn't work for me :( On Thu, Sep 15, 2011 at 7:42 PM, Alain Plantec <alain.plantec(a)yahoo.com>wrote: > But it works for me in 1.4 > Alain > > > On 15/09/2011 16:48, Mariano Martinez Peck wrote: > >> Hi guys. I cannot live without smart characters or whatever they are >> called. What I mean is when you select/surround something (a piece of >> text) and when you press '(' or '[', or whatever opening symbol, it adds >> both, the opening and the closing one to what you have selected. >> >> So...how can I have that in Pharo 1.4 ? >> >> Thanks >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > > -- Mariano http://marianopeck.wordpress.com

Sept. 15, 2011