May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Printing of BlockClosures

by Marcus Denker

On May 20, 2013, at 6:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > One of the things that always positively surprised me about Smalltalk was the fact that BlockClosures are printing showing their actual source code, you don't get that in many languages. > > But now this seems to be gone, maybe temporarily, from 3.0 > > [ :n | n + 1 ] => [â¦] > > Was this intentional ? > Yes, the old compiler does it with lots of horrible code with decompilationâ¦ so I removed it for now, the new compiler can do it very nicely. I will add it back for when Opal is running soon. Marcus

May 20, 2013

Printing of BlockClosures

by Sven Van Caekenberghe

Hi, One of the things that always positively surprised me about Smalltalk was the fact that BlockClosures are printing showing their actual source code, you don't get that in many languages. But now this seems to be gone, maybe temporarily, from 3.0 [ :n | n + 1 ] => [â¦] Was this intentional ? Sven

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Sven Van Caekenberghe

This is _very_ interesting stuff, looking forward to it. On 20 May 2013, at 17:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On May 20, 2013, at 4:44 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > >> I just started following this Dev mailing list, and I saw that 'AST >> Everywhere' and 'Reflectivity' were mentioned as very promising (I >> already know about Slots). >> Can someone in a nutshell please describe these developments? Thanks, > > Right now, the compiler uses it's own AST, Syntax highlighting uses a very minimal > token stream (and it's own parser), the refactoring engine has one, too. > And then there is Bytecode which is used by the Debugger, for example. > > As a first step we plan to use the Refactoring AST for everything > (Compiler, Refactoring, Syntax highlighting ) > > There is a AST Interpreter useful for experimenting, maybe in the future the > debugger can use this instead of relying on byte code. (but this is for far later). > > Now with the AST already there, all the tools can rely on it (Gisela Decuzzi is working on this:) > > Navigation. When selecting code or navigating expressions, the editor can do better then just using word boundaries: > > http://www.youtube.com/watch?feature=player_embedded&v=pFLyzEI0jmE > > Suggestions. When we want to do an actions on a selection, why not just show those that make sense? > Why do I need to carefully highlight a selector to browser implementors? The AST model can do much better! > > http://www.youtube.com/watch?feature=player_embedded&v=WmNKbewOXkE > > Reflectivity > ========= > > Behavioral Reflection is quite interesting.. but there is not that much in Smalltalk by default to deeply hook > into how code is executed. > > There are MethodWrappers (to be loaded as an additional tool). There is an in-image Bytecode Interpreter > (hidden in ContextPart). > > People started to want more. "In this class, all Ivar accesses should be treated differently". Things like that. > > So people tried to improve Smalltalk in the past. E.g. adding a CLOS Style MOP (Noury did that with MetaClassTalk). > But it is difficult to do it in a way that it does not get very slow (not introduce an overhead for every operation). > > And in the end, the MetaClass style MOP is quite limiting: All change of semantic is done *per Class*. Already > quite nice, but limiting... > > So in 2003 Eric Tanter finished his PhD and he invented this: > > Eric Tanter , Jacques Noye , Denis Caromel , Pierre Cointe: > Partial Behavioral Reflection: Spatial and Temporal Selection of Reification > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.8141 > > And as fate wanted, he was visiting in Bern the week before Christmas 2004, which gave me enough > time to implement a Bytecode Transformation thing in the style of Javassist that this stuff was using. > But it was cumbersomeâ¦ so at some point I thought "Bytecode Sucks", and took the Reflex model but > transported it on the AST Level. > http://scg.unibe.ch/archive/phd/denker-phd.pdf > > Soâ¦ what this means is that the AST can be annotated with so-called "meta links". When you set a link, > the system behind the scene makes sure that new code is generated on the next call. > > One way to think about this is that these links are just extremely generalized break-points. So you can > set a link that says "before this node, send #halt to Halt". > But they are much more powerful: > -> selector > -> metaObject > -> what to pass as parameters > -> a condition > -> is it #before, #after, #around? > > can be set as wanted. > > So after some thinking one realizes that this subsumes > -> BreakPoints > -> MethodWrappers > -> CLOS style MOP where the class is the meta object > -> AOP style crosscutting. (Aspects is just a pattern on top) > -> â¦. > > e.g. Code Coverage: > ------------------------------ > > - add a #markExecuted to RBProgramNode. > - install this link an all the nodes that you are interested in: > > link := GPLink new metaObject: #node; selector: #markExecuted. > (markExecuted can even deinstall the link) > > CLOS style MOP > ---------------------- > (for sends:) > > link := GPLink new > metaObject: #class; > selector: #send:to:with:; > arguments: #(selector receiver arguments) > control: #instead. > > Add this link to all send nodes in your class after the compiler compiles something, and > your class hierarchy has a CLOS style where every send is indirected through a method > in the class side. > > Javassist (or Bytesurgeon) style "execute this code before this operation" > ------------------------ > > link := GPLink new > metaObject: [:object | object color = Color red ifTrue: [Beeper beep]]; > selector: #value:; > ï¿¼ï¿¼ï¿¼ arguments: #(object). > > The nice thing is that these links are highly dynamic: they can be installed quickly, remove > themselves, propagate themselves over the AST at runtime even. > > Marcus

May 20, 2013

ZnServer>>#useGzipCompressionAndChunking

by Sven Van Caekenberghe

Hi, ZnServer now supports gzip Content-Encoding and chunked Transfer-Encoding (something ZnClient already did). Here is an example from the unit tests: ZnServerTests>>#self withServerDo: [ :server | | client | server useGzipCompressionAndChunking: true. (client := ZnClient new) url: server localUrl; addPathSegment: 'dw-bench'; setAcceptEncodingGzip; get. self assert: client isSuccess. self assert: client response hasContentEncoding. self assert: (client response headers at: 'Content-Encoding') equals: 'gzip'. self assert: client response hasTransferEncoding. self assert: (client response headers at: 'Transfer-Encoding') equals: 'chunked' ] For the /dw-bench page, the actual uncompressed size is 7.6 Kb, while the compressed, transferred size is only 1.6 Kb (Google Chrome make it easy to see this difference). By combining a GzipWriteStream and a ZnChunkedWriteStream, streaming is naturally done with 4Kb buffers. Although the compression/decompression takes time, the profit in reduced transfer size is more important in almost all cases, especially for mobile networks. The counter examples are very small responses or responses that are already compressed (like most images). For now, the #useGzipCompressionAndChunking feature is disabled by default. When enabled, only textual content will be compressed/chunked automatically. Any Zn server handler can enable compression/chunking manually for any response. ConfigurationOfZincHTTPComponents project bleedingEdge load. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Marcus Denker

On May 20, 2013, at 4:44 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > I just started following this Dev mailing list, and I saw that 'AST > Everywhere' and 'Reflectivity' were mentioned as very promising (I > already know about Slots). > Can someone in a nutshell please describe these developments? Thanks, Right now, the compiler uses it's own AST, Syntax highlighting uses a very minimal token stream (and it's own parser), the refactoring engine has one, too. And then there is Bytecode which is used by the Debugger, for example. As a first step we plan to use the Refactoring AST for everything (Compiler, Refactoring, Syntax highlighting ) There is a AST Interpreter useful for experimenting, maybe in the future the debugger can use this instead of relying on byte code. (but this is for far later). Now with the AST already there, all the tools can rely on it (Gisela Decuzzi is working on this:) Navigation. When selecting code or navigating expressions, the editor can do better then just using word boundaries: http://www.youtube.com/watch?feature=player_embedded&v=pFLyzEI0jmE Suggestions. When we want to do an actions on a selection, why not just show those that make sense? Why do I need to carefully highlight a selector to browser implementors? The AST model can do much better! http://www.youtube.com/watch?feature=player_embedded&v=WmNKbewOXkE Reflectivity ========= Behavioral Reflection is quite interesting.. but there is not that much in Smalltalk by default to deeply hook into how code is executed. There are MethodWrappers (to be loaded as an additional tool). There is an in-image Bytecode Interpreter (hidden in ContextPart). People started to want more. "In this class, all Ivar accesses should be treated differently". Things like that. So people tried to improve Smalltalk in the past. E.g. adding a CLOS Style MOP (Noury did that with MetaClassTalk). But it is difficult to do it in a way that it does not get very slow (not introduce an overhead for every operation). And in the end, the MetaClass style MOP is quite limiting: All change of semantic is done *per Class*. Already quite nice, but limiting... So in 2003 Eric Tanter finished his PhD and he invented this: Eric Tanter , Jacques Noye , Denis Caromel , Pierre Cointe: Partial Behavioral Reflection: Spatial and Temporal Selection of Reification http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.8141 And as fate wanted, he was visiting in Bern the week before Christmas 2004, which gave me enough time to implement a Bytecode Transformation thing in the style of Javassist that this stuff was using. But it was cumbersomeâ¦ so at some point I thought "Bytecode Sucks", and took the Reflex model but transported it on the AST Level. http://scg.unibe.ch/archive/phd/denker-phd.pdf Soâ¦ what this means is that the AST can be annotated with so-called "meta links". When you set a link, the system behind the scene makes sure that new code is generated on the next call. One way to think about this is that these links are just extremely generalized break-points. So you can set a link that says "before this node, send #halt to Halt". But they are much more powerful: -> selector -> metaObject -> what to pass as parameters -> a condition -> is it #before, #after, #around? can be set as wanted. So after some thinking one realizes that this subsumes -> BreakPoints -> MethodWrappers -> CLOS style MOP where the class is the meta object -> AOP style crosscutting. (Aspects is just a pattern on top) -> â¦. e.g. Code Coverage: ------------------------------ - add a #markExecuted to RBProgramNode. - install this link an all the nodes that you are interested in: link := GPLink new metaObject: #node; selector: #markExecuted. (markExecuted can even deinstall the link) CLOS style MOP ---------------------- (for sends:) link := GPLink new metaObject: #class; selector: #send:to:with:; arguments: #(selector receiver arguments) control: #instead. Add this link to all send nodes in your class after the compiler compiles something, and your class hierarchy has a CLOS style where every send is indirected through a method in the class side. Javassist (or Bytesurgeon) style "execute this code before this operation" ------------------------ link := GPLink new metaObject: [:object | object color = Color red ifTrue: [Beeper beep]]; selector: #value:; ï¿¼ï¿¼ï¿¼ arguments: #(object). The nice thing is that these links are highly dynamic: they can be installed quickly, remove themselves, propagate themselves over the AST at runtime even. Marcus

May 20, 2013

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31

by Sven Van Caekenberghe

On 20 May 2013, at 07:00, seaside(a)rmod.lille.inria.fr wrote: > ### Here's what I've been up to since the last WhatsUp: - implemented Zn server side gzip compression & chunking - tried to improve Zn IO efficiency - various small Zn/Zdc improvements and new tests - debugged cmsbox's decision to block all Zn request - added REPL Zn handler - picked up an old, not yet pubished, project bringing it up to date > ### What's next, until 2013-05-31 (*): - prepare another Zn/Zdc version for inclusion in 3.0 (and 2.0) - prepare slides for Pharo Web conference (ahead of time ;-) Sven

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by stephane ducasse

On May 20, 2013, at 4:43 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > I just started following this Dev mailing list, and I saw that 'AST > Everywhere' and 'Reflectivity' were mentioned as very promising (I > already know about Slots). First the idea is that when you browse and navigate code we now use AST to support the text analysis so we can really know where we are. For example for senders and implementors perform: #foo: with: when the caret in on perform: then we are on the node and get the selector: perform:with: We do not parse the string to try to guess and get confused with foo:. Reflectivity is the work of marcus on a reflection model. We want to rethink the absence of design of the Smalltalk MOP. Stef > Can someone in a nutshell please describe these developments? Thanks, > -Paul >

May 20, 2013

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

On May 19, 2013, at 10:01 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > New TxText version 0.8 is ready: > > - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests > - edit decorators implemented: > TxNoneEditDecorator- basic editing TxNullEditDecorator ? > TxMaskedEditDecorator- input masked values like phone numbers > TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. > TxSmartCharsEditDecorator- input smart characters like ()[]{} > TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'. > According methods were added to TxTextMorph: > #editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) > #inputContents - returns "native" value (undecorated). > #displayedContents - returns raw text model asString > See new examples on TxTextMorph class side. > > Best regards, > Denis

May 20, 2013

AST Everywhere, Reflectivity

by Paul Davidowitz

I just started following this Dev mailing list, and I saw that 'AST Everywhere' and 'Reflectivity' were mentioned as very promising (I already know about Slots). Can someone in a nutshell please describe these developments? Thanks, -Paul

May 20, 2013

[update 3.0] #30148

by Marcus Denker

30148 ----- 10676 Failing Regressiontests: CompilerExceptionsTest https://pharo.fogbugz.com/f/cases/10676 10688 SpecInterpreterTest.testDynamicBuild is failing https://pharo.fogbugz.com/f/cases/10688/ Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.180… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.125.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/CompilerTests-MarcusDenker.16…

May 20, 2013