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

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Norbert Hartl

Wow, thanks for the detailed explanation. That is really interesting! Norbert Am 20.05.2013 um 17:57 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > 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 21, 2013

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

by Sven Van Caekenberghe

Max, On 21 May 2013, at 09:43, Max Leske <maxleske(a)gmail.com> wrote: > Not sure if this is related, but my FileSystem-Git build for 2.0 broke this morning with a Zn stack trace (bad gateway): https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=20,VERSION=… Assuming you are loading Zn's #bleedingEdge, could you send me the URL you try to access and that fails ? I mean a standalone version of what is happening here ZnClient>>get GitDumbHTTPProtocol class>>initialRequestTo: GitDumbHTTPProtocol class>>connectTo: GitAbstractProtocol class>>url: GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>newProtocol GitSmartHTTPProtocolTest(GitAbstractProtocolTest)>>testTags GitSmartHTTPProtocolTest(TestCase)>>performTest If that is possible without giving out credentials. Sven > Max > > On 21.05.2013, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 21 May 2013, at 09:30, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) >> >> Hi Damien, please elaborate, maybe I can help. >> >> Sven >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

May 21, 2013

(Identity)Dictionary benchmarks

by Max Leske

My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). 4. Arrays are cool :) Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. Cheers, Max > > > > > > > > > -------------------------------------------------------------- > > ( comments are variations) > > sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). > "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." > "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." > batches := sizes collect: [ :size | size -> 10000 ]. > alphabet := Character alphabet. > > batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. > batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. > "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " > { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } > "{ Array }" > do: [ :class | > Smalltalk garbageCollect. > Transcript show: class name. > batches > do: [ :a | > | struct strings iterations | > "strings := (1 to: a key) collect: [ :i | i asString ]." > strings := (1 to: a key) collect: [ :i | > String streamContents: [ :s | > 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. > struct := class new. > "struct := (class = FLLargeIdentityDictionary > ifTrue: [ class new ] > ifFalse: [ class new: a key ])." > Transcript tab; show: ([ > a value timesRepeat: [ > 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). > strings := nil ] > displayingProgress: class name asString. > Transcript cr. ] > displayingProgress: 'Processing ...' >

May 21, 2013

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

by Max Leske

Not sure if this is related, but my FileSystem-Git build for 2.0 broke this morning with a Zn stack trace (bad gateway): https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=20,VERSION=… Max On 21.05.2013, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 21 May 2013, at 09:30, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) > > Hi Damien, please elaborate, maybe I can help. > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

May 21, 2013

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

by Sven Van Caekenberghe

On 21 May 2013, at 09:30, Damien Cassou <damien.cassou(a)gmail.com> wrote: > - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) Hi Damien, please elaborate, maybe I can help. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 21, 2013

Re: [Pharo-dev] [sbe] Pharo por Ejemplo vs Pharo en exemplos

by Rafael Luque

I contributed to this translation with the Syntax and Seaside chapters. IMO "Pharo en Ejemplos" sounds more natural than "Pharo por Ejemplo" that is the literal word-by-word translation. Rafa 2013/5/21 stephane ducasse <stephane.ducasse(a)free.fr> > > On May 21, 2013, at 8:47 AM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > > > > Be careful, there are many different forms of Spanish. The title should > be consistent with the main text. We are not qualified to judge. Ask > someone who knows the different dialects. > > > Yes I know :) > > > > > Oscar > > > > --- > > Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch > > Software Composition Group -- http://scg.unibe.ch/oscar > > University of Bern -- Tel/Fax +41 31 631.4618/3355 > > > > > > On 2013-05-21, at 8:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > >> Hi guys > >> > >> one guy mentions that Pharo en exemplos is a better translation than > Pharo por Ejemplo so what is your point of view on that? > >> > >> Stef > >> _______________________________________________ > >> sbe mailing list > >> sbe(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/sbe > > > > _______________________________________________ > > sbe mailing list > > sbe(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/sbe > > >

May 21, 2013

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

by Damien Cassou

### Here's what I've been up to since the last WhatsUp: SmalltalkHub - continue working on the configuration (it looks like Zinc has a bug with its handling of PUT requests) - fix a bug - add a button so that users can delete a mcz from SmalltalkHub Pharo packaging - send many patches upstream - delete the same patches from Ubuntu packaging scripts - update VM with latest upstream release Lectures - prepare Pharo lecture with StÃ©phane Books - work on some Jenkins jobs to build books ### What's next, until 2013-05-31 (*): -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by phil＠highoctane.be

Why not TxBaseEditDecorator ? On Tue, May 21, 2013 at 9:23 AM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > > I named it "none" edit decorator because It actually not performs any > decoration around basic editing operations. TxNoneEditDecorator just > performs it. > > > Yes this is what TxNullEditDecorator would convey. I do not see why > TxNoneEditDecorator would mean that and not the TxNullEditDecorator. > > Concrete edit decorator can execute specific action on text to perform > requested edit operation. There are three edit operations: > #insertCharacters:at:, #removeNextCharacterAt:, > #removePreviousCharacterAt:. They take aTextSelection as "at" argument. > For example TxInsertModeEditDecorator extends text selection before > characters insertion: > > TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection > aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString > size] > aTextSelection replaceWith: aString > > > Yes my point is still valid. > the NullDecorator does not decorate. > > > >> > TxMaskedEditDecorator- input masked values like phone numbers >> > TxInsertModeEditDecorator - input with "insert mode" where any new >> character >> > replace next one. >> insert mode is actually opposite - inserts when you type. >> replace mode is replaces when you type. >> > > I choose this name because on Windows you have "insert key" to activate > such mode in many text editors. > > > I think that igor suggestion is better. because replace is replace :) and > insert is insert. > > > > > > >> >> > 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'. >> > >> btw, can you wrap decorators on top of each other i.e. >> >> Masked-SimgleLine >> so i could have a single-line editor for entering only a phone number? >> > > Now with mask decorator you have single line text field. Multilined mask > is not supported (I dont try it actually). When you insert miltiline text > to masked field only first line will be used. I make such restriction to > simplify implementation. Actually I never see multilined masked field. > > Decorators can not be wrapped in general way. Maybe some of it. But there > is no cases in current decorators. > Main reason: most of decorators change cursor position with very specific > way. And wrapping decorators will lead to unpredictable and useless results. > > Your example Masked-SingleLine (if mask can be multilined) is not about > wrapping decorators. It is about input "filtering" . It is my next task. I > want put at text morph specification of correct input. So you can forbid > "cr" characters, can allow only numbers and etc. > And at same time decorators can restrict input by its implementation > requirements which happens with masked decorator. But edit decorators and > "filters" are different concepts (I not choose name for "filters" yet). > > TxSingleLineEditDecorator implements general way to edit single line text > with simple decoration format. Maybe it should be renamed. > TxSingleLineEditDecorator transforms full text by decoration format after > any edit operation. And it saves logical cursor position after > transformation. Look at methods of TxSmartNumbersDecorationFormat as > example. > > I will be happy if you introduce more clever names. Good names is > difficult task for single brain. Especially if you are not native english > speaker. > But many of you already suggest different names. How we can agree on any > one? > > Best regards, > Denis > > >> also, going ahead.. how easy/hard would be to implement a password input >> field, >> when model contains what user types, but display all *** chars? >> >> > 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 >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > >

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

> > I named it "none" edit decorator because It actually not performs any decoration around basic editing operations. TxNoneEditDecorator just performs it. Yes this is what TxNullEditDecorator would convey. I do not see why TxNoneEditDecorator would mean that and not the TxNullEditDecorator. > Concrete edit decorator can execute specific action on text to perform requested edit operation. There are three edit operations: #insertCharacters:at:, #removeNextCharacterAt:, #removePreviousCharacterAt:. They take aTextSelection as "at" argument. > For example TxInsertModeEditDecorator extends text selection before characters insertion: > > TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection > aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString size] > aTextSelection replaceWith: aString Yes my point is still valid. the NullDecorator does not decorate. > > > > TxMaskedEditDecorator- input masked values like phone numbers > > TxInsertModeEditDecorator - input with "insert mode" where any new character > > replace next one. > insert mode is actually opposite - inserts when you type. > replace mode is replaces when you type. > > I choose this name because on Windows you have "insert key" to activate such mode in many text editors. I think that igor suggestion is better. because replace is replace :) and insert is insert. > > > > 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'. > > > btw, can you wrap decorators on top of each other i.e. > > Masked-SimgleLine > so i could have a single-line editor for entering only a phone number? > > Now with mask decorator you have single line text field. Multilined mask is not supported (I dont try it actually). When you insert miltiline text to masked field only first line will be used. I make such restriction to simplify implementation. Actually I never see multilined masked field. > > Decorators can not be wrapped in general way. Maybe some of it. But there is no cases in current decorators. > Main reason: most of decorators change cursor position with very specific way. And wrapping decorators will lead to unpredictable and useless results. > > Your example Masked-SingleLine (if mask can be multilined) is not about wrapping decorators. It is about input "filtering" . It is my next task. I want put at text morph specification of correct input. So you can forbid "cr" characters, can allow only numbers and etc. > And at same time decorators can restrict input by its implementation requirements which happens with masked decorator. But edit decorators and "filters" are different concepts (I not choose name for "filters" yet). > > TxSingleLineEditDecorator implements general way to edit single line text with simple decoration format. Maybe it should be renamed. TxSingleLineEditDecorator transforms full text by decoration format after any edit operation. And it saves logical cursor position after transformation. Look at methods of TxSmartNumbersDecorationFormat as example. > > I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. > But many of you already suggest different names. How we can agree on any one? > > Best regards, > Denis > > > also, going ahead.. how easy/hard would be to implement a password input field, > when model contains what user types, but display all *** chars? > > > 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 > > > > -- > Best regards, > Igor Stasenko. > >

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/20 stephane ducasse <stephane.ducasse(a)free.fr> > >> 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 > > I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. > Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 Stef

May 21, 2013