November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] learning rewrite rules

by StÃ©phane Ducasse

in the pharo by example git hub repository now I check that there is only an emtpy doc and your paper :). I hope that I did not throw away what I wrote :( Stef On Nov 4, 2010, at 9:56 AM, Lukas Renggli wrote: > Yeah, where do I find that chapter? > > There is a section on the AST matching/search in my PhD as Helvetia > builds on top of it. Not on the AST rewriting though, Helvetia uses a > different mechanism there. Still it might be a good start. > > Lukas > > On 4 November 2010 09:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> lukas >> >> I would love to have a chapter on Rules. I have a starter that I wrote long time ago for the squeak french book >> but it would be cool if you could add to it. >> >> Stef >> >> On Nov 4, 2010, at 12:55 AM, Lukas Renggli wrote: >> >>>> If I try to match it like: >>>> '`@browser showOn: `@target; from: `@origin; using: [ `@browser ``@.statements]' >>> >>> The match expression >>> >>> `@browser ``@.statements >>> >>> doesn't make sense. Statements (.) cannot be a message selector that >>> would be expected after a receiver. Also, you cannot have a selector >>> list (@) if you don't give also an argument list to match. So the >>> closest valid thing is >>> >>> `@browser `message >>> >>> which looks for unary message sends (recursive is not necessary here >>> either, because there is nothing to recurse into), or >>> >>> `@browser `@message: ``@message >>> >>> which looks for arbitrary message sends and recursively into all arguments. >>> >>>> It seems to only get those appearances which contain a single appearance of browser inside the block. >>> >>> As I wrote in the previous mail you need to do it with nested >>> rewrites. Inside the block you match for any sequence of statements: >>> >>> `@.statements >>> >>> And as replacement you use the `{ :context | ... } trick to perform a >>> new rewrite somehow along the following untested lines: >>> >>> `{ :context | >>> RBParseTreeRewriter new >>> " replace whatever matched to `@browser with the variable a " >>> replaceTree: (context at: '`@browser') with: (RBParser >>> parseExpression: 'a'); >>> " execute on the list of statements " >>> executeTree: (context at: '`@.statements'); >>> " return the rewritten tree " >>> tree } >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Nov. 4, 2010

Re: [Pharo-project] learning rewrite rules

by Lukas Renggli

Yeah, where do I find that chapter? There is a section on the AST matching/search in my PhD as Helvetia builds on top of it. Not on the AST rewriting though, Helvetia uses a different mechanism there. Still it might be a good start. Lukas On 4 November 2010 09:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > lukas > > I would love to have a chapter on Rules. I have a starter that I wrote long time ago for the squeak french book > but it would be cool if you could add to it. > > Stef > > On Nov 4, 2010, at 12:55 AM, Lukas Renggli wrote: > >>> If I try to match it like: >>> Â '`@browser showOn: `@target; from: `@origin; using: [ `@browser ``@.statements]' >> >> The match expression >> >> Â Â `@browser ``@.statements >> >> doesn't make sense. Statements (.) cannot be a message selector that >> would be expected after a receiver. Also, you cannot have a selector >> list (@) if you don't give also an argument list to match. So the >> closest valid thing is >> >> Â Â `@browser `message >> >> which looks for unary message sends (recursive is not necessary here >> either, because there is nothing to recurse into), or >> >> Â Â `@browser `@message: ``@message >> >> which looks for arbitrary message sends and recursively into all arguments. >> >>> It seems to only get those appearances which contain a single appearance of browser inside the block. >> >> As I wrote in the previous mail you need to do it with nested >> rewrites. Inside the block you match for any sequence of statements: >> >> Â Â `@.statements >> >> And as replacement you use the `{ :context | ... } trick to perform a >> new rewrite somehow along the following untested lines: >> >> Â Â `{ :context | >> Â Â Â Â RBParseTreeRewriter new >> Â Â Â Â Â Â " replace whatever matched to `@browser with the variable a " >> Â Â Â Â Â Â replaceTree: (context at: '`@browser') with: (RBParser >> parseExpression: 'a'); >> Â Â Â Â Â Â " execute on the list of statements " >> Â Â Â Â Â Â executeTree: (context at: '`@.statements'); >> Â Â Â Â Â Â " return the rewritten tree " >> Â Â Â Â Â Â tree } >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 4, 2010

Re: [Pharo-project] learning rewrite rules

by StÃ©phane Ducasse

lukas I would love to have a chapter on Rules. I have a starter that I wrote long time ago for the squeak french book but it would be cool if you could add to it. Stef On Nov 4, 2010, at 12:55 AM, Lukas Renggli wrote: >> If I try to match it like: >> '`@browser showOn: `@target; from: `@origin; using: [ `@browser ``@.statements]' > > The match expression > > `@browser ``@.statements > > doesn't make sense. Statements (.) cannot be a message selector that > would be expected after a receiver. Also, you cannot have a selector > list (@) if you don't give also an argument list to match. So the > closest valid thing is > > `@browser `message > > which looks for unary message sends (recursive is not necessary here > either, because there is nothing to recurse into), or > > `@browser `@message: ``@message > > which looks for arbitrary message sends and recursively into all arguments. > >> It seems to only get those appearances which contain a single appearance of browser inside the block. > > As I wrote in the previous mail you need to do it with nested > rewrites. Inside the block you match for any sequence of statements: > > `@.statements > > And as replacement you use the `{ :context | ... } trick to perform a > new rewrite somehow along the following untested lines: > > `{ :context | > RBParseTreeRewriter new > " replace whatever matched to `@browser with the variable a " > replaceTree: (context at: '`@browser') with: (RBParser > parseExpression: 'a'); > " execute on the list of statements " > executeTree: (context at: '`@.statements'); > " return the rewritten tree " > tree } > > Cheers, > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Nov. 4, 2010

Re: [Pharo-project] a question about reef naming conventions

by StÃ©phane Ducasse

how it is right now :)? On Nov 3, 2010, at 11:52 PM, Esteban Lorenzano wrote: > Hi, > I'm having some doubts about how to call some methods for Reef. To be precise, I'm not sure about the naming og the method extensions I'm adding. > For instance, I have an extension for Object, the method #asView, and some others in BlockClosure, #asCallback, asCallbackOn:, etc. > > So... I want to ask which naming convention is better. > > 1) Just let the methods like now? > 2) adding a prefix, like reView, reCallback, etc.? > 3) adding a full name prefix, asReefView, asReefCallback, etc.? > for me asReefView is not the same as reefView so between reView and reefView I prefer reefView > What do you think? > > Cheers, > Esteban > > >

Nov. 4, 2010

Re: [Pharo-project] WebClient with SSL

by StÃ©phane Ducasse

normally yes. I do not see why it should not. May be we missed some network cleaning of squeak but what do you mean by failing to build. Stef On Nov 4, 2010, at 6:47 AM, Steven Baker wrote: > Heya folks, > > I need SSL support for WebClient. SqueakSSL fails to build in my Pharo > image. Is SqueakSSL supposed to work? (Before I spend more time > troubleshooting it.) Is there another method? > > Thanks, > > -Steve >

Nov. 4, 2010

Re: [Pharo-project] a question about reef naming conventions

by Peter van Rooijen

On Thu, 04 Nov 2010 00:01:24 +0100, Diogenes Moreira <diogenes.moreira(a)gmail.com> wrote: > I think the third option is clearer than the others. I agree, but I'd use a "real" prefix, exactly the same characters at the beginning, every time. So that would become: reefAsView, reefAsCallback. In my own code, I prefix selectors sometimes and always as real prefixes. But I would use an abbreviation for the project/"namespace" prefix instead of something that could be a word, so that the prefix stands out more. So that might become: rfAsView, rfAsCallback. Cheers, Peter > Best Regards > On Wed, Nov 3, 2010 at 7:52 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> Hi, >> I'm having some doubts about how to call some methods for Reef. To be >> precise, I'm not sure about the naming og the method extensions I'm >> adding. >> For instance, I have an extension for Object, the method #asView, and >> some others in BlockClosure, #asCallback, asCallbackOn:, etc. >> So... I want to ask which naming convention is better. >> 1) Just let the methods like now? >> 2) adding a prefix, like reView, reCallback, etc.? >> 3) adding a full name prefix, asReefView, asReefCallback, etc.? >> What do you think? >> Cheers, >> Esteban -- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048

Nov. 4, 2010

[Pharo-project] WebClient with SSL

by Steven Baker

Heya folks, I need SSL support for WebClient. SqueakSSL fails to build in my Pharo image. Is SqueakSSL supposed to work? (Before I spend more time troubleshooting it.) Is there another method? Thanks, -Steve

Nov. 4, 2010

Re: [Pharo-project] MicroSqueak

by Craig Latta

Hi Stef-- > ...we did not read spoon because we could not find it Oh dear, it looks like the company that serves the Spoon files changed names. I've updated http://netjam.org/spoon/. Please do let me know whenever there's trouble getting stuff (apologies if you did and I didn't see it). I only recently started reading the Pharo list. thanks again, -C -- Craig Latta www.netjam.org + 31 020 894 6247 + 1 415 287 3547

Nov. 4, 2010

Re: [Pharo-project] learning rewrite rules

by Lukas Renggli

> If I try to match it like: > Â '`@browser showOn: `@target; from: `@origin; using: [ `@browser ``@.statements]' The match expression `@browser ``@.statements doesn't make sense. Statements (.) cannot be a message selector that would be expected after a receiver. Also, you cannot have a selector list (@) if you don't give also an argument list to match. So the closest valid thing is `@browser `message which looks for unary message sends (recursive is not necessary here either, because there is nothing to recurse into), or `@browser `@message: ``@message which looks for arbitrary message sends and recursively into all arguments. > It seems to only get those appearances which contain a single appearance of browser inside the block. As I wrote in the previous mail you need to do it with nested rewrites. Inside the block you match for any sequence of statements: `@.statements And as replacement you use the `{ :context | ... } trick to perform a new rewrite somehow along the following untested lines: `{ :context | RBParseTreeRewriter new " replace whatever matched to `@browser with the variable a " replaceTree: (context at: '`@browser') with: (RBParser parseExpression: 'a'); " execute on the list of statements " executeTree: (context at: '`@.statements'); " return the rewritten tree " tree } Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 3, 2010

Re: [Pharo-project] learning rewrite rules

by Tudor Girba

Thanks. I will look into this. In the meantime, I have another question: is there a way to specify that a certain pattern can appear multiple times and that I am interested in all occurrences? For example, I can have multiple appearances of "browser xyz" inside the following block: browser showOn: #xxx; from: #yyy; using: [ browser list ... browser tree ... browser text ] If I try to match it like: '`@browser showOn: `@target; from: `@origin; using: [ `@browser ``@.statements]' It seems to only get those appearances which contain a single appearance of browser inside the block. Cheers, Doru On 3 Nov 2010, at 16:55, Lukas Renggli wrote: >> However, the problem here is that I do not know how to replace all the "browser" appearances with "a" inside the andShow: block. I tried multiple variations like the one below, but I could not seem to get it to work as I want. >> >> replace: '`@browser showOn: `@target; from: `@origin; using: [ >> `@browser ``@.statements]' with: '`@browser transmit to: `@target; from: `@origin; andShow: [:a | a ``@.statements]'; >> >> >> Can anyone point me into the right direction? > > Yes, you can put in the replacement code some code snippets like > > `{ :context | ... } > > Replace the "..." with some Smalltalk code that returns a parse tree > node (or a collection of parse-tree nodes). The context-variable is a > dictionary containing the current bindings of the matched nodes. So > you can perform a sub-rewrite on ``@.statements to replace all > accesses to `@browser with the variable a; and you return the > transformed tree. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Nov. 3, 2010