June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Mac Squeak binary virtual machine for Squeak 3.10.2

by Serge Stinckwich

If I remember correctly, it was easy to port Moose from VW to Pharo, because there was a lot of tests. I'm currently working on porting another software from VW to Pharo without any tests and I'm suffering ;-) On Wed, Jun 10, 2015 at 8:36 PM, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > Stef, > Why be sorry? It's great that you have a stable kernel in Pharo. Where do I > find the definition of the Pharo public API? > > In which way is the Pharo technology that underlies Moose more complex than > BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because it extends > the Squeak Parser and debugger and that this is unknown territory to me. > There remains, of course, minorproblems and bugs caused by changes in the > various services offered by the Squeak kernel. > > It's clear that one port went without a hitch for you. That does not mean > that porting BabyIDE to Pharo will be equally simple. And may be the people > who did your port do not share my extensive ignorance of the Pharo innards > and the nature of the changes in the release? I am not a Pharo creator. I > was considering to become a Pharo user but reconsidered when I read what you > say below. This was partly because I believe you underestimate the work > needed to port BabyIDE to Pharo and partly because you do not appear to > appreciate the need that programmers (your customers) have for a stable > programming language. > Trygve > > On 09.06.2015 19:59, stepharo wrote: > > I'm sorry to say that Pharo public API does not change that much. > We could port all Moose in one afternoon and Moose is certainly more complex > :). > > Stef -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 10, 2015

Re: [Pharo-users] Using GTSpotter how do I find an implementor of #accept ?

by Nicolai Hess

2015-06-10 16:24 GMT+02:00 Paul DeBruicker <pdebruic(a)gmail.com>: > So by default the search tool is only guaranteed to return an exact term > match if there are only less than 5 non-exact match results? > > Yes > > > > > > Nicolai Hess wrote > > 2015-06-10 7:39 GMT+02:00 Paul DeBruicker < > > > pdebruic@ > > > >: > > > >> when I hit shift+enter and type 'accept' I get things that are not > >> #accept, e.g. #accept: and AbstractAcceptor. > >> > >> If I add a space after accept it doesn't help. > >> > >> > >> What do I not understand? > >> > > > > the result list is not sorted and the result list is built by all methods > > having the query string as part > > of its selector name. > > > > Yes this can be improved and it is not difficult, for example you can add > > this method to > > > > GTFilterImplementor>>applyFilterWithQuery > > super applyFilterWithQuery. > > items sort: [ :a :b | (self itemFilterNameFor: a) size < (self > > itemFilterNameFor: b) size ] > > > > this will sort the result list by the size of the selector name. So, if > > there is a perfect match, > > it will be listed first. > > (BUT only in the implementors category if you "dive-in", not in the > > 5-elements-result-preview-list). > > > > Maybe there is a better way without sorting. (We can modify > > applyFilterWithQuery for the implementors > > filter, to put perfect matches at the begining of the list). > > > > But all this is not easy to discover. Spotter classes make some heavy use > > of delegation, many operations > > are split and delgated to subclasses (GOOD!) > > many classes aren't documented (BAD!) and this makes it really difficult > > to > > catch how all this is supposed to work together. > > > > > > nicolai > > > > > > > > > >> > >> > >> Thanks > >> > >> > >> Paul > >> > > > > > > -- > View this message in context: > http://forum.world.st/Using-GTSpotter-how-do-I-find-an-implementor-of-accep… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 10, 2015

Re: [Pharo-users] Mac Squeak binary virtual machine for Squeak 3.10.2

by Trygve Reenskaug

Stef, Why be sorry? It's great that you have a stable kernel in Pharo. Where do I find the definition of the Pharo public API? In which way is the Pharo technology that underlies Moose more complex than BabyIDE? Porting BabyIDE from Squeak 3.10 to 4.5 was hard because it extends the Squeak Parser and debugger and that this is unknown territory to me. There remains, of course, minorproblems and bugs caused by changes in the various services offered by the Squeak kernel. It's clear that one port went without a hitch for you. That does not mean that porting BabyIDE to Pharo will be equally simple. And may be the people who did your port do not share my extensive ignorance of the Pharo innards and the nature of the changes in the release? I am not a Pharo creator. I was considering to become a Pharo user but reconsidered when I read what you say below. This was partly because I believe you underestimate the work needed to port BabyIDE to Pharo and partly because you do not appear to appreciate the need that programmers (your customers) have for a stable programming language. Trygve On 09.06.2015 19:59, stepharo wrote: > I'm sorry to say that Pharo public API does not change that much. > We could port all Moose in one afternoon and Moose is certainly more > complex :). > > Stef

June 10, 2015

Pratt Parsers for PetitParser

by Camille

Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. A Pratt parser (a.k.a top-down operator precedence parser) handles left-recursion and operator precedence. It handles grouping, prefix, postfix, infix (right- or left-associative) and "multifixâ operators (e.g. "if ... then ... else ...", "... ? ... : ...", Smalltalk keyword messages). Normally Pratt Parsing needs a tokenization phase but here tokenization is done on the fly with other PP parsers. Apart from tokenization, no backtracking is needed so parsing is quite fast (approximatively 2 times faster than PPExpressionParser). Here is an exemple of a calculator: parser := PPPrattParser new. "Numbers" parser terminal: #digit asParser plus do: [ :token | token inputValue asNumber ]. parser skip: #space asParser plus. "Parentheses" parser groupLeft: $( asParser right: $) asParser. "Addition, substraction, multiplication, division: all left infix, * and / have higher precedence than + and -" parser leftInfix: $+ asParser precedence: 1 do: [ :left :op :right | left + right ]. parser leftInfix: $- asParser precedence: 1 do: [ :left :op :right | left - right ]. parser leftInfix: $* asParser precedence: 2 do: [ :left :op :right | left * right ]. parser leftInfix: $/ asParser precedence: 2 do: [ :left :op :right | left / right ]. "Power: right infix with higher precedence than multiplication and division" parser rightInfix: $^ asParser precedence: 3 do: [ :left :op :right | left raisedTo: right ]. "Unary minus: prefix with highest precedence" parser prefix: $- asParser precedence: 4 do: [ :op :right | right negated ]. parser parse: '2*3 + 4^(1/2)*3' ----> 12 To try it: Gofer it smalltalkhubUser: 'CamilleTeruel' project: 'PetitPratt'; package: 'PetitPratt'; load Note that it is in beta stage so it might still change drastically. @PP Devs: I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). But I guess it was introduced because it gives good results in other cases. So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? Cheers, Camille

June 10, 2015

Re: [Pharo-users] ZnClient and percent characters

by Sven Van Caekenberghe

> On 10 Jun 2015, at 17:24, David <stormbyte(a)gmail.com> wrote: > > El Wed, 10 Jun 2015 10:14:37 -0500 > Jimmie Houchin <jlhouchin(a)gmail.com> > escribiÃ³: >> Hello, >> >> I am attempting to use ZnClient to request data. The request requires >> a %2C (comma) delimited string as part of the query. Below is a >> snippet. >> >> znClient >> addPath: '/v1/instruments'; >> queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; >> get ; >> contents) >> >> The string 'displayName%2Cinstrument%2Cpip' >> is being converted to 'displayName%252Cinstrument%252Cpip' >> which causes the request to fail. >> >> The query needs to be >> fields=displayName%2Cinstrument%2Cpip >> >> I have not found how to do this correctly. >> Any help greatly appreciated. >> >> Thanks. >> >> Jimmie >> >> > > Maybe a silly thing, but since %2C = , ... Did you tried already to > make itself encode that? Like > znClient > addPath: '/v1/instruments'; > queryAt: 'fields' putAll: 'displayName,instrument,pip'; > get ; > contents) > > I suspect it is using encoding internally, that is why % is also > encoded if you try to put it. > > I hope that works Not silly and no need to suspect, but absolutely correct ! Sven

June 10, 2015

Re: [Pharo-users] Getting a user input string using Morphs

by stepharo

Yes hilaire ActiveHand as a global is a "bad concept" In blog there is not globals anymore :) Le 10/6/15 10:54, Hilaire a Ã©crit : > The needed change for this low level access to morph is probably a small > one, related to ActiveHand, but I have not yet move to 4.0. > In the other hand, you may want to use higher level approaches suggested > by Pharo fellows. > > Hilaire > > Le 10/06/2015 09:20, Jigyasa Grover a Ã©crit : >> Yes >> I am currently developing it in Pharo 4.0 >> >> Thanks :) >> >> >

June 10, 2015

Re: [Pharo-users] ZnClient and percent characters

by David

El Wed, 10 Jun 2015 10:14:37 -0500 Jimmie Houchin <jlhouchin(a)gmail.com> escribiÃ³: > Hello, > > I am attempting to use ZnClient to request data. The request requires > a %2C (comma) delimited string as part of the query. Below is a > snippet. > > znClient > addPath: '/v1/instruments'; > queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; > get ; > contents) > > The string 'displayName%2Cinstrument%2Cpip' > is being converted to 'displayName%252Cinstrument%252Cpip' > which causes the request to fail. > > The query needs to be > fields=displayName%2Cinstrument%2Cpip > > I have not found how to do this correctly. > Any help greatly appreciated. > > Thanks. > > Jimmie > > Maybe a silly thing, but since %2C = , ... Did you tried already to make itself encode that? Like znClient addPath: '/v1/instruments'; queryAt: 'fields' putAll: 'displayName,instrument,pip'; get ; contents) I suspect it is using encoding internally, that is why % is also encoded if you try to put it. I hope that works

June 10, 2015

ZnClient and percent characters

by Jimmie Houchin

Hello, I am attempting to use ZnClient to request data. The request requires a %2C (comma) delimited string as part of the query. Below is a snippet. znClient addPath: '/v1/instruments'; queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; get ; contents) The string 'displayName%2Cinstrument%2Cpip' is being converted to 'displayName%252Cinstrument%252Cpip' which causes the request to fail. The query needs to be fields=displayName%2Cinstrument%2Cpip I have not found how to do this correctly. Any help greatly appreciated. Thanks. Jimmie

June 10, 2015

Re: [Pharo-users] Using GTSpotter how do I find an implementor of #accept ?

by Paul DeBruicker

So by default the search tool is only guaranteed to return an exact term match if there are only less than 5 non-exact match results? Nicolai Hess wrote > 2015-06-10 7:39 GMT+02:00 Paul DeBruicker < > pdebruic@ > >: > >> when I hit shift+enter and type 'accept' I get things that are not >> #accept, e.g. #accept: and AbstractAcceptor. >> >> If I add a space after accept it doesn't help. >> >> >> What do I not understand? >> > > the result list is not sorted and the result list is built by all methods > having the query string as part > of its selector name. > > Yes this can be improved and it is not difficult, for example you can add > this method to > > GTFilterImplementor>>applyFilterWithQuery > super applyFilterWithQuery. > items sort: [ :a :b | (self itemFilterNameFor: a) size < (self > itemFilterNameFor: b) size ] > > this will sort the result list by the size of the selector name. So, if > there is a perfect match, > it will be listed first. > (BUT only in the implementors category if you "dive-in", not in the > 5-elements-result-preview-list). > > Maybe there is a better way without sorting. (We can modify > applyFilterWithQuery for the implementors > filter, to put perfect matches at the begining of the list). > > But all this is not easy to discover. Spotter classes make some heavy use > of delegation, many operations > are split and delgated to subclasses (GOOD!) > many classes aren't documented (BAD!) and this makes it really difficult > to > catch how all this is supposed to work together. > > > nicolai > > > > >> >> >> Thanks >> >> >> Paul >> -- View this message in context: http://forum.world.st/Using-GTSpotter-how-do-I-find-an-implementor-of-accep… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 10, 2015

Re: [Pharo-users] Using PluggableTextFieldMorph

by stepharo

better use rubric because we will remove PluggableTextField... and friends. Le 10/6/15 11:40, Jigyasa Grover a Ã©crit : > Hi > > With reference to my earlier query 'Getting a user input string using > Morphs' > <http://forum.world.st/Getting-a-user-input-string-using-Morphs-td4831121.ht…> > I have come across 'PluggableTextFieldMorph' which seems to be the one I was > looking for. > Could anyone pls help so as to how could I use the 'getText' method to > retrieve the user input string. > > Thanks > Jigyasa > > > > -- > View this message in context: http://forum.world.st/Using-PluggableTextFieldMorph-tp4831375.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 10, 2015