- Pharo-dev - lists.pharo.org

[Pharo-project] WebClient with SSL
by Steven Baker Nov. 4, 2010

Nov. 4, 2010

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

2 1

Re: [Pharo-project] learning rewrite rules
by StÃ©phane Ducasse Nov. 4, 2010

Nov. 4, 2010

I'm adding some other files (in french) :( but I'm stuck with git.... > 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 >

2 1

Re: [Pharo-project] learning rewrite rules
by StÃ©phane Ducasse Nov. 4, 2010

Nov. 4, 2010

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 >

1 0

Re: [Pharo-project] learning rewrite rules
by StÃ©phane Ducasse Nov. 4, 2010

Nov. 4, 2010

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 >

2 1

Re: [Pharo-project] a question about reef naming conventions
by StÃ©phane Ducasse Nov. 4, 2010

Nov. 4, 2010

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 > > >

1 0

Re: [Pharo-project] WebClient with SSL
by StÃ©phane Ducasse Nov. 4, 2010

Nov. 4, 2010

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 >

1 0

[Pharo-project] a question about reef naming conventions
by Esteban Lorenzano Nov. 4, 2010

Nov. 4, 2010

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

3 2

[Pharo-project] learning rewrite rules
by Tudor Girba Nov. 3, 2010

Nov. 3, 2010

Hi, I am trying to write a rewrite rule to replace something like: browser showOn: #xxx; from: #yyy; using: [ browser list ... browser tree ... ] to something like: browser transmit to: #xxx; from: #yyy; andShow: [:a | a list ... a tree ... ] I managed to do the following: RBParseTreeRewriter new replace: '`@browser showOn: `@target; from: `@origin; using: [ ``@.statements ]' with: '`@browser transmit to: `@target; from: `@origin; andShow: [:a | ``@.statements]'; yourself 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? Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

2 3

Nov. 3, 2010

> I did create my own wizard mechanism. The main reason for that is for best > integration with UIBuilder, classes and widgets from CLFramework. I donÂ´t > want depends of third parts if I can avoid :) But you would have look at Merlin and mentioned that may be we could have added a factory and you would have got a good wizard builder and it would have improved. Stef

2 1

Nov. 3, 2010

Patching XMLNode>>printOn: like that seems to work. XMLNode>>printOn: aStream | writer | writer := XMLWriter on: aStream. >> writer enablePrettyPrinting. self printXMLOn: writer. writer flushMarkup. Now this is clearly not a good solution. I will change my code not to be based on the printOn behavior and use a writer instead. Now I do not understand why we create a writer for each printOn: message Stef On Oct 31, 2010, at 12:03 PM, StÃ©phane Ducasse wrote: > > In my really old code I wrote > > save > "self new save" > > | doc | > doc := self buildXML. > doc printOn: self stream > > > buildXML > > ^ self base asXML > > > Base>>asXML > "BDBase uniqueInstance asXML" > > | doc elem | > doc := XMLDocument new. > doc version: '1.0'. > elem := XMLElement > name: #Base > attributes: > (Dictionary new > at: 'date' put: Date today asString; > at: 'entriesNumber' put: self elements size asString; > at: 'note' put: self note asString; > yourself). > doc addElement: elem. > self elements do: [:each | elem addElement: each asXML]. > ^ doc > > Elements>>asXML > ^ XMLElement name: self class xmlName attributes: self attributes > > > So how can I control that each elements ends with a linebreak/cr whatever? > > Stef > > > > >

2 1