March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] New chapter for new book
by Dimitris Chloupis March 31, 2017

March 31, 2017

Awesome to see Pharo doing so great on documentation front, when I joined back in 2011 there was not even basic documentation now there so many new useful books that is fun to read like this one. Great work !!!! :) On Fri, Mar 31, 2017 at 5:06 PM Marc Hanisch via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Wow, thats amazing! > > Thank you Stephane! > > 2017-03-31 15:51 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > I attached a new chapter for my forthcoming book. > > Stef > > >

2 2

Re: [Pharo-users] type checking in Smalltalk
by jtuchel＠objektfabrik.de March 31, 2017

March 31, 2017

Marc, you should definitely go and understand method lookup and handling of unknown messages. This is the fun part of Smalltalk ;-) Just don't overuse it, because you can do things that are so cool you won't be able to understand your own code any more ;-) Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

1 0

New chapter for new book
by Stephane Ducasse March 31, 2017

March 31, 2017

Hi I attached a new chapter for my forthcoming book. Stef

2 1

Re: [Pharo-users] type checking in Smalltalk
by Stephan Eggermont March 31, 2017

March 31, 2017

On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: > Reading this, I realized, that I never saw such type-checking in > Pharo production code. So the question is, what are recommended > design principles for that problem in Smalltalk? Do you use what is > called duck typing? Normally I'm not interested in what an object is, but what it can do. So a test on #respondsTo: can tell me if the object knows how to do something. In smalltalk, I can add methods to existing classes, so there are a lot of extension methods on Object isXYZ, returning false. Morph returns true to isMorph, so all subclasses of Morph can be recognized that way. Instead of adding a test method, there are also empty implementations or ones that return self or an appropriate null-value. Stephan

4 3

Re: [Pharo-users] Pharo with Google Realtime database
by Esteban A. Maringolo March 31, 2017

March 31, 2017

There isn't any Firebase database driver for it. I used Firebase database and auth briefly for a JS/HTML only app, and I pulled the data using plain ZnClient to access the REST API. Regards, Esteban A. Maringolo 2017-03-31 8:13 GMT-03:00 Asbath Sama biyalou via Pharo-users <pharo-users(a)lists.pharo.org>: > > > ---------- Mensaje reenviado ---------- > From: Asbath Sama biyalou <asamabiyalou(a)yahoo.com> > To: Pharo users users <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Fri, 31 Mar 2017 12:13:06 +0100 > Subject: Pharo with Google Realtime database > Hello everybody, > > I developed an Android app. And the server of the application is written > in Pharo. > > Google Realtime database is a NoSQL database which is very good for > synchronization with android apps. I want to add data to this database > from my Pharo app. And to do this I have to use a Rest Api. The rest api > is existing for other languages like Php (Firebase-php), Python, Java, > Go, etc. > > I want to know if this api is existing for Pharo? > > > Thanks, > > > Asbath > > >

1 0

Pharo with Google Realtime database
by Asbath Sama biyalou March 31, 2017

March 31, 2017

Hello everybody, I developed an Android app. And the server of the application is written in Pharo. Google Realtime database is a NoSQL database which is very good for synchronization with android apps. I want to add data to this database from my Pharo app. And to do this I have to use a Rest Api. The rest api is existing for other languages like Php (Firebase-php), Python, Java, Go, etc. I want to know if this api is existing for Pharo? Thanks, Asbath

1 0

PetitParser question parsing HTML meta tags
by Hartmut Krasemann March 31, 2017

March 31, 2017

its easier this way (still in form of a script): parseHtmlPageForDescription: htmlString | parser endParser metaParser descriptionParser contentParser res1Parser res2Parser quoteParser nonQuoteParser | metaParser := '<meta name="' asParser. "the next line extends the parser to understand http-equiv" metaParser := metaParser | '<meta http-equiv="' asParser. quoteParser := $" asParser. nonQuoteParser := PPPredicateObjectParser anyExceptAnyOf: '"'. descriptionParser := nonQuoteParser star token. res1Parser := descriptionParser . res2Parser := descriptionParser . contentParser := '" content="' asParser trim. endParser := '">' asParser. parser := (metaParser, res1Parser, contentParser, res2Parser, endParser) end ==> [:nodes| Array with: (nodes at: 2) inputValue with: (nodes at: 4) inputValue ]. ^parser parse: htmlString. "self parseHtmlPageForDescription: self htmlString1 self parseHtmlPageForDescription: self htmlString2 self parseHtmlPageForDescription: self htmlString3 " with htmlString1 ^'<meta name=" Description" content="my description">' etc.. you may want to read http://www.lukas-renggli.ch/blog/petitparser-1 good luck Hartmut > This is kind of a "I'm tired of thinking about this and not making much progress for the amount of time I'm putting in question" but here it is: > > > > I'm trying to parse descriptions from HTML meta elements. I can't use Soup because there isn't a working GemStone port. > > I've got it to work with the structure: > > <meta name="description" content="my description"> > > and > > <meta name="Description" content="my description"> > > > but I'm running into instances of: > > <meta http-equiv="description" content="my description"> > > and > > <meta http-equiv="Description" content="my description"> > > > and am having trouble adapting my parsing code (such as it is). > > > The parsing code that addresses the first two cases is: > > > > parseHtmlPageForDescription: htmlString > | startParser endParser ppStream descParser result text lower str doubleQuoteIndex | > lower := 'escription' asParser. > startParser := '<meta name=' asParser , #'any' asParser , #'any' asParser. > endParser := '>' asParser. > ppStream := htmlString readStream asPetitStream. > descParser := ((#'any' asParser starLazy: startParser , lower) > , (#'any' asParser starLazy: endParser)) ==> #'second'. > result := descParser parse: ppStream. > text := (result > inject: (WriteStream on: String new) > into: [ :stream :char | > stream nextPut: char. > stream ]) > contents trimBoth. > str := text copyFrom: (text findString: 'content=') + 9 to: text size. > doubleQuoteIndex := 8 - ((str last: 7) indexOf: $"). > ^ str copyFrom: 1 to: str size - doubleQuoteIndex > > > I can't figure out how to change the startParser parser to accept the second idiom. And maybe there's a better approach altogether. Anyway. If anyone has any ideas on different approaches I'd appreciate learning them. > > > Thanks for giving it some thought > > Paul -- signatur Hartmut Krasemann KÃ¶nigsberger Str. 41 c D 22869 Schenefeld Tel. 040.8307097 Mobil 0171.6451283 Krasemann(a)acm.org

1 0

Re: [Pharo-users] type checking in Smalltalk
by Denis Kudriashov March 30, 2017

March 30, 2017

2017-03-30 16:03 GMT+02:00 Marc Hanisch via Pharo-users < pharo-users(a)lists.pharo.org>: > It is advised not to use the message isKindOf: in applications. > > I do understand that it is not a good idea to do different operations > depending on the kind of an object in one method. But in my (Javascript) > production code I do a lot of checking if an argument to a function is > "instanceof" someObject. When it is not the expected type of object, an > exception is thrown. I do this to ensure that someone (=another developer) > does not by accident passes a wrong type into my method. > > Reading this, I realized, that I never saw such type-checking in Pharo > production code. > In Pharo you will got DNU error automatically when object will receive message which it *d*oes *n*ot *u*nderstands. Then Pharo will show debugger to investigate and fix the problem. This is called dynamic typing and I guess JS will do something similar. So I wonder why you need custom error when program breaks types.

1 0

Re: [Pharo-users] type checking in Smalltalk
by Alexandre Bergel March 30, 2017

March 30, 2017

Hi Marc, > Reading this, I realized, that I never saw such type-checking in Pharo production code. So the question is, what are recommended design principles for that problem in Smalltalk? Do you use what is called duck typing? I have carefully studied the topic of type checking in the past. I came to the conclusion that type errors are too easy to fix to justify a support in the language. There are always exceptions, for example, if you wish to provide guaranties and proof on some aspect of the language, interesting to hardware driver developers and critical software developers. In that case, you may want to have type annotation, maybe. But all in all, static type checking is more a distraction than a real benefit for practitioners in my opinion. Cheers, Alexandre

1 0

type checking in Smalltalk
by Marc Hanisch March 30, 2017

March 30, 2017

Hello, I have a question which is more related to software engineering than to Pharo, but I hope that someone can give me an useful hint ;-) In Pharo By Example 5, Page 308, in the Chapter "Introspection", it is written: "Although these features (type inspection) are especially useful for imple- menting development tools, they are normally not appropriate for typical applications. Asking an object for its class, or querying it to discover which messages it understands, are typical signs of design problems, since they violate the principle of encapsulation." It is advised not to use the message isKindOf: in applications. I do understand that it is not a good idea to do different operations depending on the kind of an object in one method. But in my (Javascript) production code I do a lot of checking if an argument to a function is "instanceof" someObject. When it is not the expected type of object, an exception is thrown. I do this to ensure that someone (=another developer) does not by accident passes a wrong type into my method. Reading this, I realized, that I never saw such type-checking in Pharo production code. So the question is, what are recommended design principles for that problem in Smalltalk? Do you use what is called duck typing? Thanks for any advice :-) Marc

1 0