Cryptographic Primitives
Locked
1234
1234
Re: When is a closure a real one? [was: Real closures]
 
|
J J schrieb:
> > Yes I know. What I meant was: I think the presence of ^ means your > block can't be a complete closure. I.e. you can't return it from a > method and invoke it later, since it might try to return to a place > that no longer exists. I think the way ^ works is wonderful, but if > the compiler sees one in a block it can treat that block differently > then if one wasn't present. Actually, the presence of a ^ does not matter much. It just means that the return statement within that block can be used only once(*). But the block can be used any number of times before and after that. (*) In the presence of continuations and stack saving/restoring mechanisms such as seaside, it might even make sense to return from a method context more than once - if the reincarnation of the context is the same object. In seaside, it actually is so (the complete chain of contexts is saved when a continuation is created, and is repopulated with its saved values including caller linkage when it is re-evaluated). A method return from a block is valid exactly if the home context of the block is in the current context's call chain. Whether the method context has been returned from in a previous life does not matter. Cheers, Hans-Martin |
Decompiler [was: Real closures]
|
|
In reply to this post by stephane ducasse-2
On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote:
... > If people wants to help we need the decompiler also working well. Can I have a specification (sufficient, please) that describes what source construct emits what bytecode(s). I cannot promise that I will then be able to work on the decompiler but I promise to give it a try. > Mathieu also worked on fixing the way comments are attached in the tree > (before this was kind of random). Can't wait to see this in action :) /Klaus > Stef |
Re: When is a closure a real one? [was: Real closures]
|
|
In reply to this post by Klaus D. Witzel
On 08.10.2006, at 10:51, Klaus D. Witzel wrote: > Thank you Mathieu and Phillipe for you pointers and example. > > Just out of curiosity (and as input for writing accurate yes/no > test cases :) let me ask what is expected by the community > (apologies if this sounds like a silly question ;-) when is a > closure a real one: > > 1] after #fixTemps (or equivalent) no, fixtemps just copies the home context. Here is a quote from a mail that I send someone to explain this: ============== This brings some of the properties of a closure, but not all. In a way, it's too much. blocks1 := (1 to: 10) collect: [:ea | [ea]]. blocks1 collect: [:each | each value] If you execute this in VW, you get #(1 2 3 4 5 6 7 8 9 10). But in Squeak, the :ea is just a temp in the method, so the blocks all reference the same variable. Thus you get #(10 10 10 10 10 10 10 10 10 10) Now that is sometimes really not what you like, so they implemented a hack (they are good at that!) called "fixTemps": blocks1 := (1 to: 10) collect: [:ea | [ea] fixTemps]. blocks1 collect: [:each | each value] fixTemps "Fix the values of the temporary variables used in the block that are ordinarily shared with the method in which the block is defined." home _ home copy. home swapSender: nil Of course, this does not give you Closure semantics, too, as this now makes one new environment per block for all temps of the block... whereas with Closures, this is not always the case, e.g. when referencing outer temps: |a| a := 1. b1 := [a]. b2 := [a] fixTemps. a := 3. b1 value + b2 value is Wrong: The fixTemps makes the a in b2 it's own variable, but even with Closures, it's the a of the method itself. Another aspect is that Block Locals like [ | a | ] are from the code that is generated indistiguishable from having the | a | defined as temps of the method. myMethod | a | [a]. same as myMethod [ | a | a] Some versions ago, Lex Spoon at least fixed the compiler to not allow you to reference the block locals and arguments outside the block. which was perfectly ok before. But nevertheless, the semantics of scoping is Wrong: tt2 | a b | a := [ | t | t := 1]. b := [ | t | t ]. a value. ^b value. returns 1, even if each block defines their own (new, completely different) t. =================== > > 2] after #blockCopy: (is this equivalent to 1?) > blockCopy: is the way to do generate BlockContexts in Squeak. No Clusures. Not equivalent to 1). blockCopy: numArgs "Primitive. Distinguish a block of code from its enclosing method by creating a new BlockContext for that block. The compiler inserts into all methods that contain blocks the bytecodes to send the message blockCopy:. Do not use blockCopy: in code that you write! Only the compiler can decide to send the message blockCopy:. Fail if numArgs is not a SmallInteger. Optional. No Lookup. See Object documentation whatIsAPrimitive." <primitive: 80> ^ (BlockContext newForMethod: self home method) home: self home startpc: pc + 2 nargs: numArgs > 3] after #createBlock: (is this equivalent to 1? to 2?) > This gets you a real closure block (this is from the newcompiler's runtime): createBlock: env ^ BlockClosure new env: env; method: self So: old compiler generates code with 2, people add 1 by hand (randomly, as bugs show up). Newcompiler generates code with 3, 1 is not needed anymore. Marcus |
Re: Decompiler [was: Real closures]
|
|
In reply to this post by Klaus D. Witzel
Klaus D. Witzel a écrit :
> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: > ... >> If people wants to help we need the decompiler also working well. > > Can I have a specification (sufficient, please) that describes what > source construct emits what bytecode(s). I cannot promise that I will > then be able to work on the decompiler but I promise to give it a try. Thanks Klaus :) you can read this: http://www.iam.unibe.ch/~scg/Teaching/Smalltalk/Slides/11Bytecode.pdf http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter26.html#TheCompiler26 and try this: http://www.iam.unibe.ch/~scg/Teaching/Smalltalk/Exercises/STExercise11-Bytecode.pdf > >> Mathieu also worked on fixing the way comments are attached in the >> tree (before this was kind of random). > > Can't wait to see this in action :) :) That is not yet add to the tool but you can load my package from: http://www.squeaksource.com/NewCompilerPragma and inpesct this: (SqueakParser parseMethod: (SqueakParserTest>>#methodDescribeWithAllComment:And:) getSource) addComment Math > > /Klaus > >> Stef > > > |
Re: Decompiler [was: Real closures]
|
|
In reply to this post by Klaus D. Witzel
Klaus D. Witzel a écrit :
> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: > ... >> If people wants to help we need the decompiler also working well. > > Can I have a specification (sufficient, please) that describes what > source construct emits what bytecode(s). I cannot promise that I will > then be able to work on the decompiler but I promise to give it a try. > Forgot to tell if you want to see exacly what happen you can use #>> and see the bytecode Object>>#haltIf: -> 45 <10> pushTemp: 0 46 <D0> send: isSymbol 47 <AC 17> jumpFalse: 72 49 <89> pushThisContext: 50 <69> popIntoTemp: 1 51 <11> pushTemp: 1 52 <D1> send: sender 53 <D2> send: isNil 54 <A8 0F> jumpTrue: 71 56 <11> pushTemp: 1 57 <D1> send: sender 58 <81 41> storeIntoTemp: 1 60 <D3> send: selector 61 <10> pushTemp: 0 62 <B6> send: = ... >> Mathieu also worked on fixing the way comments are attached in the >> tree (before this was kind of random). > > Can't wait to see this in action :) > > /Klaus > >> Stef > > > |
Re: When is a closure a real one? [was: Real closures]
|
|
In reply to this post by Marcus Denker
Thank you master for making this crystal clear!
I think that distiguishing block locals and also scope of locals could have been solved by the old (current) compiler+decompiler, but for the rest I don't think so. /Klaus On Mon, 09 Oct 2006 12:13:15 +0200, Marcus Denker wrote: > > On 08.10.2006, at 10:51, Klaus D. Witzel wrote: > >> Thank you Mathieu and Phillipe for you pointers and example. >> >> Just out of curiosity (and as input for writing accurate yes/no test >> cases :) let me ask what is expected by the community (apologies if >> this sounds like a silly question ;-) when is a closure a real one: >> >> 1] after #fixTemps (or equivalent) > > no, fixtemps just copies the home context. > > Here is a quote from a mail that I send someone to explain this: > > ============== > > This brings some of the properties of a closure, but not all. In a way, > it's too much. > > blocks1 := (1 to: 10) collect: [:ea | [ea]]. > blocks1 collect: [:each | each value] > > If you execute this in VW, you get #(1 2 3 4 5 6 7 8 9 10). But in > Squeak, the :ea > is just a temp in the method, so the blocks all reference the same > variable. Thus you get #(10 10 10 10 10 10 10 10 10 10) > > Now that is sometimes really not what you like, so they implemented a > hack (they are good at that!) called "fixTemps": > > blocks1 := (1 to: 10) collect: [:ea | [ea] fixTemps]. > blocks1 collect: [:each | each value] > > fixTemps > "Fix the values of the temporary variables used in the block > that are > ordinarily shared with the method in which the block is defined." > > home _ home copy. > home swapSender: nil > > > Of course, this does not give you Closure semantics, too, as this now > makes one new environment per block for all temps of the block... > whereas with > Closures, this is not always the case, e.g. when referencing outer > temps: > > |a| > a := 1. > b1 := [a]. > b2 := [a] fixTemps. > a := 3. > b1 value + b2 value > > is Wrong: The fixTemps makes the a in b2 it's own variable, but even > with Closures, it's the a of the method itself. > > Another aspect is that Block Locals like [ | a | ] are from the code > that is generated indistiguishable from having the | a | defined as > temps of the method. > > myMethod > | a | > [a]. > > same as > > myMethod > [ | a | a] > > Some versions ago, Lex Spoon at least fixed the compiler to not > allow you to reference the block locals and arguments outside the > block. which was perfectly ok before. But nevertheless, the semantics > of scoping is Wrong: > > tt2 > | a b | > a := [ | t | t := 1]. > b := [ | t | t ]. > a value. > ^b value. > > returns 1, even if each block defines their own (new, completely > different) t. > > =================== > >> >> 2] after #blockCopy: (is this equivalent to 1?) >> > > blockCopy: is the way to do generate BlockContexts in Squeak. No > Clusures. > Not equivalent to 1). > > blockCopy: numArgs > "Primitive. Distinguish a block of code from its enclosing method by > creating a new BlockContext for that block. The compiler inserts into > all > methods that contain blocks the bytecodes to send the message > blockCopy:. Do not use blockCopy: in code that you write! Only the > compiler can decide to send the message blockCopy:. Fail if numArgs is > not a SmallInteger. Optional. No Lookup. See Object documentation > whatIsAPrimitive." > > <primitive: 80> > ^ (BlockContext newForMethod: self home method) > home: self home > startpc: pc + 2 > nargs: numArgs > > >> 3] after #createBlock: (is this equivalent to 1? to 2?) >> > > This gets you a real closure block (this is from the newcompiler's > runtime): > > createBlock: env > > ^ BlockClosure new > env: env; > method: self > > > So: old compiler generates code with 2, people add 1 by hand (randomly, > as > bugs show up). Newcompiler generates code with 3, 1 is not needed > anymore. > > > Marcus > > > > |
Re: When is a closure a real one? [was: Real closures]
|
|
On 09.10.2006, at 12:54, Klaus D. Witzel wrote: > Thank you master for making this crystal clear! > > I think that distiguishing block locals and also scope of locals > could have been solved by the old (current) compiler+decompiler, Yes, it just needs to do a real scope analysis and understand that variables can be different even is the name is different. The new compiler does this, even when in compatibility mode (thus generating old style non-closure code). The problem is that lexical scoping was kind of new when Smalltalk was invented... so from today's perspective it is easy to critize. > but for the rest I don't think so. > Indeed. Marcus |
Re: Decompiler [was: Real closures]
|
|
In reply to this post by Mathieu SUEN
Hi Mathieu,
on Mon, 09 Oct 2006 12:43:58 +0200, you wrote: > Klaus D. Witzel a écrit : >> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: >> ... >>> If people wants to help we need the decompiler also working well. >> >> Can I have a specification (sufficient, please) that describes what >> source construct emits what bytecode(s). I cannot promise that I will >> then be able to work on the decompiler but I promise to give it a try. >> > > Forgot to tell if you want to see exacly what happen Yes I want to see, but must look into the opposite direction :| Let me ask further: which component of the framework (the slides in 11Bytecode.pdf are excellent, thank you!) is responsible for pretty print? The latter is what the browser usually requests from the decompiler. /Klaus > you can use #>> and see the bytecode Yes, thank you :) > Object>>#haltIf: > > -> > 45 <10> pushTemp: 0 > 46 <D0> send: isSymbol > 47 <AC 17> jumpFalse: 72 > 49 <89> pushThisContext: > 50 <69> popIntoTemp: 1 > 51 <11> pushTemp: 1 > 52 <D1> send: sender > 53 <D2> send: isNil > 54 <A8 0F> jumpTrue: 71 > 56 <11> pushTemp: 1 > 57 <D1> send: sender > 58 <81 41> storeIntoTemp: 1 > 60 <D3> send: selector > 61 <10> pushTemp: 0 > 62 <B6> send: = > ... > >>> Mathieu also worked on fixing the way comments are attached in the >>> tree (before this was kind of random). >> >> Can't wait to see this in action :) >> >> /Klaus >> >>> Stef >> >> >> > > > |
Re: Decompiler [was: Real closures]
|
|
Klaus D. Witzel a écrit :
> Hi Mathieu, > > on Mon, 09 Oct 2006 12:43:58 +0200, you wrote: >> Klaus D. Witzel a écrit : >>> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: >>> ... >>>> If people wants to help we need the decompiler also working well. >>> >>> Can I have a specification (sufficient, please) that describes what >>> source construct emits what bytecode(s). I cannot promise that I will >>> then be able to work on the decompiler but I promise to give it a try. >>> >> >> Forgot to tell if you want to see exacly what happen > > Yes I want to see, but must look into the opposite direction :| Let me > ask further: which component of the framework (the slides in > 11Bytecode.pdf are excellent, thank you!) is responsible for pretty > print? The latter is what the browser usually requests from the decompiler. Normaly it's RBFormatter who suppose to pretty print it(you can install other pretty printer like gutenberg). And the compilation stop at the AST representation so you don't need to compile it completly. see: Compiler>>format:in:notifying:decorated: You also have to understand the Visitor but this one it's a bit strange beceause when visitMethodNode is expected you will see acceptMethodNode... (HTH) Math > > /Klaus > >> you can use #>> and see the bytecode > > Yes, thank you :) > >> Object>>#haltIf: >> >> -> >> 45 <10> pushTemp: 0 >> 46 <D0> send: isSymbol >> 47 <AC 17> jumpFalse: 72 >> 49 <89> pushThisContext: >> 50 <69> popIntoTemp: 1 >> 51 <11> pushTemp: 1 >> 52 <D1> send: sender >> 53 <D2> send: isNil >> 54 <A8 0F> jumpTrue: 71 >> 56 <11> pushTemp: 1 >> 57 <D1> send: sender >> 58 <81 41> storeIntoTemp: 1 >> 60 <D3> send: selector >> 61 <10> pushTemp: 0 >> 62 <B6> send: = >> ... >> >>>> Mathieu also worked on fixing the way comments are attached in the >>>> tree (before this was kind of random). >>> >>> Can't wait to see this in action :) >>> >>> /Klaus >>> >>>> Stef >>> >>> >>> >> >> >> > > > > |
|
|
In reply to this post by Klaus D. Witzel
+1. Great email. Thanks.
>From: "Klaus D. Witzel" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: [hidden email] >Subject: Re: When is a closure a real one? [was: Real closures] >Date: Mon, 09 Oct 2006 12:54:53 +0200 > >Thank you master for making this crystal clear! > >I think that distiguishing block locals and also scope of locals could >have been solved by the old (current) compiler+decompiler, but for the >rest I don't think so. > >/Klaus > >On Mon, 09 Oct 2006 12:13:15 +0200, Marcus Denker wrote: >> >>On 08.10.2006, at 10:51, Klaus D. Witzel wrote: >> >>>Thank you Mathieu and Phillipe for you pointers and example. >>> >>>Just out of curiosity (and as input for writing accurate yes/no test >>>cases :) let me ask what is expected by the community (apologies if this >>>sounds like a silly question ;-) when is a closure a real one: >>> >>>1] after #fixTemps (or equivalent) >> >>no, fixtemps just copies the home context. >> >>Here is a quote from a mail that I send someone to explain this: >> >>============== >> >>This brings some of the properties of a closure, but not all. In a way, >>it's too much. >> >>blocks1 := (1 to: 10) collect: [:ea | [ea]]. >>blocks1 collect: [:each | each value] >> >>If you execute this in VW, you get #(1 2 3 4 5 6 7 8 9 10). But in >>Squeak, the :ea >>is just a temp in the method, so the blocks all reference the same >>variable. Thus you get #(10 10 10 10 10 10 10 10 10 10) >> >>Now that is sometimes really not what you like, so they implemented a >>hack (they are good at that!) called "fixTemps": >> >>blocks1 := (1 to: 10) collect: [:ea | [ea] fixTemps]. >>blocks1 collect: [:each | each value] >> >>fixTemps >> "Fix the values of the temporary variables used in the block >>that are >> ordinarily shared with the method in which the block is defined." >> >> home _ home copy. >> home swapSender: nil >> >> >>Of course, this does not give you Closure semantics, too, as this now >>makes one new environment per block for all temps of the block... >>whereas with >>Closures, this is not always the case, e.g. when referencing outer >>temps: >> >>|a| >>a := 1. >>b1 := [a]. >>b2 := [a] fixTemps. >>a := 3. >>b1 value + b2 value >> >>is Wrong: The fixTemps makes the a in b2 it's own variable, but even >>with Closures, it's the a of the method itself. >> >>Another aspect is that Block Locals like [ | a | ] are from the code >>that is generated indistiguishable from having the | a | defined as >>temps of the method. >> >>myMethod >> | a | >> [a]. >> >>same as >> >>myMethod >> [ | a | a] >> >>Some versions ago, Lex Spoon at least fixed the compiler to not >>allow you to reference the block locals and arguments outside the >>block. which was perfectly ok before. But nevertheless, the semantics >>of scoping is Wrong: >> >>tt2 >> | a b | >> a := [ | t | t := 1]. >> b := [ | t | t ]. >> a value. >> ^b value. >> >>returns 1, even if each block defines their own (new, completely >>different) t. >> >>=================== >> >>> >>>2] after #blockCopy: (is this equivalent to 1?) >>> >> >>blockCopy: is the way to do generate BlockContexts in Squeak. No >>Clusures. >>Not equivalent to 1). >> >>blockCopy: numArgs >> "Primitive. Distinguish a block of code from its enclosing method by >> creating a new BlockContext for that block. The compiler inserts into >>all >> methods that contain blocks the bytecodes to send the message >> blockCopy:. Do not use blockCopy: in code that you write! Only the >> compiler can decide to send the message blockCopy:. Fail if numArgs is >> not a SmallInteger. Optional. No Lookup. See Object documentation >> whatIsAPrimitive." >> >> <primitive: 80> >> ^ (BlockContext newForMethod: self home method) >> home: self home >> startpc: pc + 2 >> nargs: numArgs >> >> >>>3] after #createBlock: (is this equivalent to 1? to 2?) >>> >> >>This gets you a real closure block (this is from the newcompiler's >>runtime): >> >>createBlock: env >> >> ^ BlockClosure new >> env: env; >> method: self >> >> >>So: old compiler generates code with 2, people add 1 by hand (randomly, >>as >>bugs show up). Newcompiler generates code with 3, 1 is not needed >>anymore. >> >> >> Marcus >> >> >> >> > > > |
Re: Decompiler [was: Real closures]
|
|
In reply to this post by Mathieu SUEN
Three things:
1) found a todo list in CompilerTODO, is this up to date 2) is it expected that a full decompile takes all the steps as in #testDecompileBlockParam (from aCompiledMethod via BytecodeDecompiler via IRDecompiler to AST-Nodes and friends) 3) afterComment, beforeComment and insideComment are Undeclared (the dev.image comes with AST-ms.88?) /Klaus On Mon, 09 Oct 2006 19:26:27 +0200, Mathieu wrote: > Klaus D. Witzel a écrit : >> Hi Mathieu, >> >> on Mon, 09 Oct 2006 12:43:58 +0200, you wrote: >>> Klaus D. Witzel a écrit : >>>> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: >>>> ... >>>>> If people wants to help we need the decompiler also working well. >>>> >>>> Can I have a specification (sufficient, please) that describes what >>>> source construct emits what bytecode(s). I cannot promise that I will >>>> then be able to work on the decompiler but I promise to give it a try. >>>> >>> >>> Forgot to tell if you want to see exacly what happen >> >> Yes I want to see, but must look into the opposite direction :| Let me >> ask further: which component of the framework (the slides in >> 11Bytecode.pdf are excellent, thank you!) is responsible for pretty >> print? The latter is what the browser usually requests from the >> decompiler. > > Normaly it's RBFormatter who suppose to pretty print it(you can install > other pretty printer like > gutenberg). > And the compilation stop at the AST representation so you don't need to > compile it completly. > > see: Compiler>>format:in:notifying:decorated: > > You also have to understand the Visitor but this one it's a bit strange > beceause when > visitMethodNode is expected you will see acceptMethodNode... (HTH) > > Math > >> >> /Klaus >> >>> you can use #>> and see the bytecode >> >> Yes, thank you :) >> >>> Object>>#haltIf: >>> >>> -> >>> 45 <10> pushTemp: 0 >>> 46 <D0> send: isSymbol >>> 47 <AC 17> jumpFalse: 72 >>> 49 <89> pushThisContext: >>> 50 <69> popIntoTemp: 1 >>> 51 <11> pushTemp: 1 >>> 52 <D1> send: sender >>> 53 <D2> send: isNil >>> 54 <A8 0F> jumpTrue: 71 >>> 56 <11> pushTemp: 1 >>> 57 <D1> send: sender >>> 58 <81 41> storeIntoTemp: 1 >>> 60 <D3> send: selector >>> 61 <10> pushTemp: 0 >>> 62 <B6> send: = >>> ... >>> >>>>> Mathieu also worked on fixing the way comments are attached in the >>>>> tree (before this was kind of random). >>>> >>>> Can't wait to see this in action :) >>>> >>>> /Klaus >>>> >>>>> Stef >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > |
Re: Decompiler [was: Real closures]
|
|
On 10.10.2006, at 16:41, Klaus D. Witzel wrote: > Three things: > > 1) found a todo list in CompilerTODO, is this up to date > I should remove that class... the todo list used now is http://smallwiki.unibe.ch/newcompiler/ > 2) is it expected that a full decompile takes all the steps as in > #testDecompileBlockParam (from aCompiledMethod via > BytecodeDecompiler via IRDecompiler to AST-Nodes and friends) > Yes. But Bytecode --> IR is already done, AST-> text, too. The only thing missing is IR->AST > 3) afterComment, beforeComment and insideComment are Undeclared > (the dev.image comes with AST-ms.88?) > You need AST-md.100, it's on SqueakSource, project AST Marcus > /Klaus > > On Mon, 09 Oct 2006 19:26:27 +0200, Mathieu wrote: >> Klaus D. Witzel a écrit : >>> Hi Mathieu, >>> >>> on Mon, 09 Oct 2006 12:43:58 +0200, you wrote: >>>> Klaus D. Witzel a écrit : >>>>> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote: >>>>> ... >>>>>> If people wants to help we need the decompiler also working well. >>>>> >>>>> Can I have a specification (sufficient, please) that describes >>>>> what >>>>> source construct emits what bytecode(s). I cannot promise that >>>>> I will >>>>> then be able to work on the decompiler but I promise to give it >>>>> a try. >>>>> >>>> >>>> Forgot to tell if you want to see exacly what happen >>> >>> Yes I want to see, but must look into the opposite direction :| >>> Let me >>> ask further: which component of the framework (the slides in >>> 11Bytecode.pdf are excellent, thank you!) is responsible for pretty >>> print? The latter is what the browser usually requests from the >>> decompiler. >> >> Normaly it's RBFormatter who suppose to pretty print it(you can >> install other pretty printer like >> gutenberg). >> And the compilation stop at the AST representation so you don't >> need to compile it completly. >> >> see: Compiler>>format:in:notifying:decorated: >> >> You also have to understand the Visitor but this one it's a bit >> strange beceause when >> visitMethodNode is expected you will see acceptMethodNode... (HTH) >> >> Math >> >>> >>> /Klaus >>> >>>> you can use #>> and see the bytecode >>> >>> Yes, thank you :) >>> >>>> Object>>#haltIf: >>>> >>>> -> >>>> 45 <10> pushTemp: 0 >>>> 46 <D0> send: isSymbol >>>> 47 <AC 17> jumpFalse: 72 >>>> 49 <89> pushThisContext: >>>> 50 <69> popIntoTemp: 1 >>>> 51 <11> pushTemp: 1 >>>> 52 <D1> send: sender >>>> 53 <D2> send: isNil >>>> 54 <A8 0F> jumpTrue: 71 >>>> 56 <11> pushTemp: 1 >>>> 57 <D1> send: sender >>>> 58 <81 41> storeIntoTemp: 1 >>>> 60 <D3> send: selector >>>> 61 <10> pushTemp: 0 >>>> 62 <B6> send: = >>>> ... >>>> >>>>>> Mathieu also worked on fixing the way comments are attached in >>>>>> the >>>>>> tree (before this was kind of random). >>>>> >>>>> Can't wait to see this in action :) >>>>> >>>>> /Klaus >>>>> >>>>>> Stef >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > |
|
|
Wow, I just have to say the weekly squeak is looking very nice and up to
date. Wonderful work guys. I hope you keep it up. I'm very impressed. |
|
|
Il giorno gio, 12/10/2006 alle 17.26 +0000, J J ha scritto:
> Wow, I just have to say the weekly squeak is looking very nice and up to > date. Wonderful work guys. I hope you keep it up. I'm very impressed. Hi J J, many thanks for your good words from me and the other members of the News team: Ron, Giovanni, Michael. I'd also like to say a public "thank you" to all that have sent their congrats either with a private message, or as a comment on the blog, or in the #squeak channel. Giovanni |
|
|
You're very welcome. This sort of thing is exactly what smalltalk/squeak needs. Also, does squeak.org have any links pointing at the weekly squeak? We should get some if not (remember: having more then one link to the same site is not bad. Different people have different ideas about how something would be organized) so people see (1) all the cool things that are going on and (2) the community is very much alive and doing cool things every week. >From: Giovanni Corriga <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: Weekly squeak >Date: Thu, 12 Oct 2006 19:46:55 +0200 > >Il giorno gio, 12/10/2006 alle 17.26 +0000, J J ha scritto: > > Wow, I just have to say the weekly squeak is looking very nice and up to > > date. Wonderful work guys. I hope you keep it up. I'm very impressed. > >Hi J J, > >many thanks for your good words from me and the other members of the >News team: Ron, Giovanni, Michael. > >I'd also like to say a public "thank you" to all that have sent their >congrats either with a private message, or as a comment on the blog, or >in the #squeak channel. > > Giovanni > > |
|
|
Il giorno gio, 12/10/2006 alle 18.18 +0000, J J ha scritto:
> You're very welcome. This sort of thing is exactly what smalltalk/squeak > needs. > > Also, does squeak.org have any links pointing at the weekly squeak? We > should get some if not (remember: having more then one link to the same > site is not bad. Different people have different ideas about how something > would be organized) so people see (1) all the cool things that are going on > and (2) the community is very much alive and doing cool things every week. http://news.squeak.org does an HTTP redirect to TWS' site. At the moment, this should be enough. In the future we could have some more integration, maybe when we'll have some more volunteers ;-) Giovanni |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |