December 2018 - Pharo-users

how to use indexes to copy a substring out of a string

by Roelof Wobben

Dec. 29, 2018

Magritte seaside save

by Vitor Medina Cruz

Hello, So: > > MyObject new asComponent addValidatedForm > How do I define save callBack? I tried: MyObject new asComponent addValidatedForm : {#save -> 'save'. #cancel -> > 'cancel'}. > and defined save in both instance or class side of MyObject, but that didn't work. Regards, Vitor. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Dec. 29, 2018

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

Hi Doru, This one is still pending: https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html Of course we have slow days at end of year and I don't expect immediate answer, but now that discussion was active is good to point some pending conversation, even to be taken after holidays. Cheers, Offray On 29/12/18 6:38, Tudor Girba wrote: > Hi Offray, > > I believe I replied to all your emails. If I missed one, please point me to it. > > Cheers, > Doru > > >> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> >> On 28/12/18 8:03, Tudor Girba wrote: >>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>>> >>>> WOW >>> :) >>> >>> What part of it do you like? >>> >>> Cheers, >>> Doru >> And which parts you don't? >> >> I wrote a long mail regarding good and no so good parts of the new GT >> experience, including features possible forks, that I hope will be >> answered also in detail, to keep the big picture. >> >> Cheers, >> >> Offray >> >> >> > -- > www.feenk.com > > "You can inspect and adapt only what is explicit." > >

Dec. 29, 2018

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, I believe I replied to all your emails. If I missed one, please point me to it. Cheers, Doru > On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > > On 28/12/18 8:03, Tudor Girba wrote: >>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>> >>> WOW >> :) >> >> What part of it do you like? >> >> Cheers, >> Doru > > And which parts you don't? > > I wrote a long mail regarding good and no so good parts of the new GT > experience, including features possible forks, that I hope will be > answered also in detail, to keep the big picture. > > Cheers, > > Offray > > > -- www.feenk.com "You can inspect and adapt only what is explicit."

Dec. 29, 2018

Re: [Pharo-users] Subscribing to streaming input with ZnClient

by Jimmie Houchin

On 12/27/18 9:00 AM, Sven Van Caekenberghe wrote: > Hi Jimmie, > >> On 27 Dec 2018, at 15:15, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >> Hello, >> >> I am wanting to subscribe to a perpetual stream of JSON data in my app. I have failed to find an example which helps me understand how to do so. It may be there but I have not discovered it. >> >> How do I do something like that? A curl example from the website. >> >> curl \ >> -H "Authorization: abcdefg?????" \ >> >> "https://stream-mystreamingsite.com/stream?query=whatIwant" >> Response Headers >> HTTP/1.1 200 OK >> Access-Control-Allow-Headers: Authorization, Content-Type, Accept-Datetime-Format >> Access-Control-Allow-Methods: PUT, PATCH, POST, GET, OPTIONS, DELETE >> Access-Control-Allow-Origin: * >> Content-Type: application/octet-stream >> >> >> After subscribing to the stream I will need to get and access the JSON data so that my app can process it. >> >> Any help and wisdom greatly appreciated. >> >> Thanks. >> >> Jimmie > The client and server part of the WebSockets extension to Zinc HTTP Components already supports similar functionality, so this is certainly doable. > > Unless you can give me a public end point to test, I can only write some untested pseudo code. > > | client reader | > client := ZnClient new. > client url: 'https://stream-mystreamingsite.com/stream?query=whatIwant'. > client streaming: true. > client headerAt: 'Authorization' put: 'xxx'. > client get. > reader := NeoJSONReader on: (ZnCharacterReadStream on: client contents). > [ reader atEnd] whileFalse: [ reader next ]. > reader close. > client close. > > Be sure to tell us how you got it working. > > HTH, > > Sven Hello Sven, Thanks for your help. The server I am connecting to requires an account to access. But you provided sufficient information to get me going. Thanks. This is for a Trading Application. I am a ways off before ready for releasing. I will open source when it is usable and cleaned up enough from personal code. Currently I have named it SmallTrader, hence the ST prefix for classes. I have an STClient class which subclasses ZnClient and sets it up with the necessary account authorization. Below is the STPriceStream#mainLoop method. Basically it is populating some OrderedCollections in the STPriceStream which are available to the app's mainLoop. It is working perfectly. I currently have it printing out data to stdout so that I can watch the data it collects to visually understand what is happening. The connection below is the instance of the class which connects to this specific broker. Since connections are specific to a broker I am putting all of the parsing into ST objects such as STPrice and STCandle in the broker specific class as it understands what the broker returns. This will allow my app to be able to use different brokers simply by changing which connection class we call. Currently I am writing for one specific one where my account is located. But I want to be able to add brokers in time. Thanks again for your help. mainLoop Â Â Â | delay pricesStream reader | Â Â Â delay := (Duration milliSeconds: 100) asDelay. Â Â Â minuteDateTime := STCandle datetimeMinute: (DateAndTime now asUTC). Â Â Â pricesStream := connection newPriceStreamConnectionForInstruments: instruments. Â Â Â pricesStream get. Â Â Â reader := STONReader on: (ZnCharacterReadStream on: pricesStream contents). Â Â Â [ reader atEnd] whileFalse: [ Â Â Â Â Â Â stop Â Â Â Â Â Â Â Â Â ifFalse: [ | price | Â Â Â Â Â Â Â Â Â Â Â Â price := connection pricesStreamNextPrice: (reader next). Â Â Â Â Â Â Â Â Â Â Â Â price ifNotNil: [ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â prices add: price. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â price datetimeMinute = minuteDateTime Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ minutePrices add: price ] Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ self processMinutePrices: price ]]] Â Â Â Â Â Â Â Â Â ifTrue: [ Â Â Â Â Â Â Â Â Â Â Â Â reader close Â Â Â Â Â Â Â Â Â Â Â Â ^ self ]. Â Â Â Â Â Â delay wait ]. Jimmie

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Serge Stinckwich

On Thu, Dec 27, 2018 at 5:43 PM Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > Hi everyone, > > I am confronted with an implementation choice that I expect to be not so > rare, and I wonder what "the Pharo way" is for dealing with it. I will > use a toy example for illustration, my real case is more complex but not > fundamentally different. > > Suppose I want to represent arithmetic expressions that support various > operations (evaluation, simplification, compilation to whatever > language, ...). In the textbook discussion, I'd have a class hierarchy > such as > > Expression (abstract) > IntegerExpression > VariableNameExpression > SumExpression > ProductExpression > ... > > What I really want is not some IntegerExpression, but plain Pharo > integers, and for variable names I want to use plain Pharo symbols. > > From my current understanding of Pharo, my options are > > 1. Use wrapper objects for integers and symbols, i.e. have a class > IntegerExpression that stores an integer in an instance variable. > > 2. Add the methods of my abstract Expression class to all the classes > representing integers and symbols. > > 3. Implement my own dispatch that does not rely on method lookup. > > None of these really looks attractive. 1) adds a lot of overhead, both > in the code ("IntegerExpression withValue: 5" rather than just "5") and > at runtime. 3) also adds a lot of overhead because I have to implement > my own dispatch. 2) would probably be the least effort, but looks like a > kludge. > > For comparison, in the Lisp world (CLOS, Racket, ...) that I know much > better, I would use generic functions and provide implementations for > integers and symbols as well as for my own Expression types. > > So... how would you approach this problem? > > Hi Konrad, in your case I would write a parser for your specific concrete syntax with PetitParser and then generate an instance of the abstract syntax you have defined. Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Steffen MÃ¤rcker

Did you already try to measure the impaired overhead of a wrapper solution? It might very well be negligible in an otherwise purely symbolic computation. A hybrid solution might be - instead of wrapping each value - to add a single method to the value classes that wraps a value on the fly if needed, e.g. Integer>>asExpression ^ExpressionWrapper wrap: self. If the expression protocol is invoked only rarely on the pure values, this solution reduces the overhead while keeping the value classes clean of foreign methods. Another option might be to build a trait that adds the behavior to the value classes. Best, Steffen Am .12.2018, 09:29 Uhr, schrieb Konrad Hinsen <konrad.hinsen(a)fastmail.net>: > Richard Sargent <richard.sargent(a)gemtalksystems.com> writes: > >> I understand your desire to utilize the existing Smalltalk mechanisms. >> But, >> I think the most important thing is modelling consistency. >> >> What are the behaviours you expect from Expression, SumExpression, and >> ProductExpression? Do they know their parent expression? Their children? >> Other things? > > I certainly agree that this should be the main consideration, but in my > case that's done. Each Expression subclass stored its own specific > information, which for leaf nodes such as integer expressions is really > just a value. All I need is integers with added behavior. > >> I think that, in general, you will benefit from fully and consistently >> modelling the parse tree. > > I should have mentioned that my Expressions are not parse trees. They > are used as values in symbolic computation. They are constructed and > deconstructed all the time, which is one reason I want to eliminate > overhead, the other reason being clarity of code. > > Konrad. >

Dec. 28, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

On 28/12/18 8:03, Tudor Girba wrote: >> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >> >> WOW > :) > > What part of it do you like? > > Cheers, > Doru And which parts you don't? I wrote a long mail regarding good and no so good parts of the new GT experience, including features possible forks, that I hope will be answered also in detail, to keep the big picture. Cheers, Offray

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Tim Mackinnon

I was going to chip in that every class inherits what compiler it uses and so you can easily override that to do something special (like wrapping classes). However, is this possibly an area where the meta-links kicks in so you donât have to do this and get a more generic solution? (I havenât played with this, but there are a few threads where people are using it, and itâs progressed quite a lot in Pharo 7). Tim Sent from my iPhone > On 28 Dec 2018, at 16:37, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Fri, 28 Dec 2018 at 16:30, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >> Richard Sargent <richard.sargent(a)gemtalksystems.com> writes: >> >> > I understand your desire to utilize the existing Smalltalk mechanisms. But, >> > I think the most important thing is modelling consistency. >> > >> > What are the behaviours you expect from Expression, SumExpression, and >> > ProductExpression? Do they know their parent expression? Their children? >> > Other things? >> >> I certainly agree that this should be the main consideration, but in my >> case that's done. Each Expression subclass stored its own specific >> information, which for leaf nodes such as integer expressions is really >> just a value. All I need is integers with added behavior. >> >> > I think that, in general, you will benefit from fully and consistently >> > modelling the parse tree. >> >> I should have mentioned that my Expressions are not parse trees. They >> are used as values in symbolic computation. They are constructed and >> deconstructed all the time, which is one reason I want to eliminate >> overhead, the other reason being clarity of code. > > This may not be what you are looking for, but maybe help flesh out ideas. > Try debugging... > OpalCompiler new evaluate: '1 + 2' > > cheers -ben

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Ben Coman

On Fri, 28 Dec 2018 at 16:30, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > Richard Sargent <richard.sargent(a)gemtalksystems.com> writes: > > > I understand your desire to utilize the existing Smalltalk mechanisms. > But, > > I think the most important thing is modelling consistency. > > > > What are the behaviours you expect from Expression, SumExpression, and > > ProductExpression? Do they know their parent expression? Their children? > > Other things? > > I certainly agree that this should be the main consideration, but in my > case that's done. Each Expression subclass stored its own specific > information, which for leaf nodes such as integer expressions is really > just a value. All I need is integers with added behavior. > > > I think that, in general, you will benefit from fully and consistently > > modelling the parse tree. > > I should have mentioned that my Expressions are not parse trees. They > are used as values in symbolic computation. They are constructed and > deconstructed all the time, which is one reason I want to eliminate > overhead, the other reason being clarity of code. > This may not be what you are looking for, but maybe help flesh out ideas. Try debugging... OpalCompiler new evaluate: '1 + 2' cheers -ben

Dec. 28, 2018