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

New chapter for new book

by Stephane Ducasse

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

March 31, 2017

Re: [Pharo-users] Pharo with Google Realtime database

by Esteban A. Maringolo

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

March 31, 2017

Pharo with Google Realtime database

by Asbath Sama biyalou

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

March 31, 2017

PetitParser question parsing HTML meta tags

by Hartmut Krasemann

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

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by Igor Stasenko

In other words: don't ask - tell. Instead of writing something like: object isSomething ifTrue: [ object doSomething ] ifFalse: [ object doSomethingElse ] just write it: object doSomething that gives you much less code bloat, and much clear view of your intent(s) and even in case of exception , you can always interpret DNU as "object are missing feature, you asked for", which is again, reveals your intent. Also things like: object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ self doSomethingElseWith: object ] in general considered as anti-pattern, because you basically implementing polymorphic behavior in wrong place i.e. in code that using object, instead of code that belongs to the object itself. On 31 March 2017 at 03:05, Ben Coman <btc(a)openinworld.com> wrote: > > > On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > > 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. > > Many people also technically frown on isXYZ is a similar way to isKindOf:, > but it is a lesser evil and pragmatically is used reasonably often. > > > > > Instead of adding a test method, there are also empty implementations > > Like this, what you can do is refactor that guarded code into a method > #myAction > and add Object>>myAction which throws the exception. > Thus you condense multiple condition statements into > one location and your application code becomes much cleaner. > > Object may end up loaded with a lot of methods not of interest to every > object, > but the trade-off of cleaner application code is generally worth it. > > btw, Here you start to see how using Pharo/Smalltalk "changes the way you > think about programming". > > Further, the exception thrown by Object>>myAction > should signal the error on a custom error object, similar to ZeroDivide > for example. > > > > or ones that return self or an appropriate null-value. > > Within your framework where you control all the objects > the Null-object pattern is probably the cleanest OO approach, > but it can't control what the user passes across the public API. > https://en.wikipedia.org/wiki/Null_Object_pattern > > btw, you can search null-object pattern in Spotter using " Null #c " > > > cheers -ben > > -- Best regards, Igor Stasenko.

March 31, 2017

Re: [Pharo-users] diff'ing with metacello

by Thierry Goubier

2017-03-31 8:16 GMT+02:00 Siemen Baader <siemenbaader(a)gmail.com>: > Ok. So it is a missing feature. I will do individual diff'ing on versions > of the package that contains the method under concern instead. This is > after all not different from a git repo that uses eg a package.json file to > include external projects. > One of the thing that can be done is to temporarily copy all the versions concerned into a Git-based repository with Iceberg or GitFileTree, and then sees if git can provides a better diff, or even a git blame ability. I've done that multiple times... copy multiple versions in a repo, study the diff, and then just throw it away. Thierry > > Thanks for enlightening me! > > Siemen > > On Thu, Mar 30, 2017 at 4:57 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2017-03-30 16:42 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >>> On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <siemenbaader(a)gmail.com> >>> wrote: >>> > Below is a fileout of 'ConfigurationOfPharoJS'. I download new >>> releases of >>> > PharoJS as they become available. Recently I found a regression - a >>> method >>> > 'PjApplication class >> playgroundWithoutLaunch' did not work any >>> more. What >>> > I wanted to do was to revert the whole project to an earlier version >>> until >>> > the method worked again - then look for the code that has been changed >>> > between releases and find the bug. >>> > >>> > In practice, even the earliest version (version 1.0 - method >>> #version10) did >>> > have the bug and I could not roll back the project to earlier release >>> states >>> > because there is no metadate for them. But I'd still like to learn how >>> to do >>> > it, so let's just say I want to compare version 1.2 and 1.3: >>> > >>> > version12: spec >>> > <version: '1.2' imports: #('0.1-baseline' )> >>> > >>> > version13: spec >>> > <version: '1.3' imports: #('0.2-baseline' )> >>> > >>> > >>> > I hope this makes sense. Thanks for helping me understand! >>> >>> You can only directly diff the Configurations themselves. >>> I fairly sure you can't auto-diff the packages loaded by each >>> configuration. >>> This is a missing feature. It would be nice to have something like >>> the merge-diff, >>> but there are probably other priorities. Maybe the new git workflow >>> will open some possibilities?? >>> >> >> If you have a project-oriented way of committing to git (you commit both >> the configuration and all the packages in one commit), then diffing via git >> would work. >> >> Current status on that feature is: >> >> - BaselineOf and all related packages save in one commit can be done with >> GitFileTree. I added an API for that and made a few experiments by >> organising and saving projects via the Metacello registry (with GUI >> support). I rolled back that extension in AltBrowser and I will reimplement >> it soon in a different, better way. >> >> - Iceberg ? >> >> - ConfigurationOf ? The approach of storing a configurationOf inside a >> meta repository makes implementing that harder. >> >> Now, I think the tools would probably be able to get that to work over >> Monticello with few changes, but they are a tad complex to implement, as in >> loading two different configurationsOf and resolving related packages >> (without loading them), and then changing the diff viewer to project all >> differences between all classes of the two groups of packages. One thing to >> remember is that complete packages, in multiple versions, can be loaded >> simultaneously as Monticello models without disrupting the code currently >> loaded and active in the image, as when you "browse" a Monticello package >> on disk. >> >> Thierry >> >> >>> >>> cheers -ben >>> >>> >> >

March 31, 2017

Re: [Pharo-users] diff'ing with metacello

by Siemen Baader

Ok. So it is a missing feature. I will do individual diff'ing on versions of the package that contains the method under concern instead. This is after all not different from a git repo that uses eg a package.json file to include external projects. Thanks for enlightening me! Siemen On Thu, Mar 30, 2017 at 4:57 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2017-03-30 16:42 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <siemenbaader(a)gmail.com> >> wrote: >> > Below is a fileout of 'ConfigurationOfPharoJS'. I download new releases >> of >> > PharoJS as they become available. Recently I found a regression - a >> method >> > 'PjApplication class >> playgroundWithoutLaunch' did not work any more. >> What >> > I wanted to do was to revert the whole project to an earlier version >> until >> > the method worked again - then look for the code that has been changed >> > between releases and find the bug. >> > >> > In practice, even the earliest version (version 1.0 - method >> #version10) did >> > have the bug and I could not roll back the project to earlier release >> states >> > because there is no metadate for them. But I'd still like to learn how >> to do >> > it, so let's just say I want to compare version 1.2 and 1.3: >> > >> > version12: spec >> > <version: '1.2' imports: #('0.1-baseline' )> >> > >> > version13: spec >> > <version: '1.3' imports: #('0.2-baseline' )> >> > >> > >> > I hope this makes sense. Thanks for helping me understand! >> >> You can only directly diff the Configurations themselves. >> I fairly sure you can't auto-diff the packages loaded by each >> configuration. >> This is a missing feature. It would be nice to have something like >> the merge-diff, >> but there are probably other priorities. Maybe the new git workflow >> will open some possibilities?? >> > > If you have a project-oriented way of committing to git (you commit both > the configuration and all the packages in one commit), then diffing via git > would work. > > Current status on that feature is: > > - BaselineOf and all related packages save in one commit can be done with > GitFileTree. I added an API for that and made a few experiments by > organising and saving projects via the Metacello registry (with GUI > support). I rolled back that extension in AltBrowser and I will reimplement > it soon in a different, better way. > > - Iceberg ? > > - ConfigurationOf ? The approach of storing a configurationOf inside a > meta repository makes implementing that harder. > > Now, I think the tools would probably be able to get that to work over > Monticello with few changes, but they are a tad complex to implement, as in > loading two different configurationsOf and resolving related packages > (without loading them), and then changing the diff viewer to project all > differences between all classes of the two groups of packages. One thing to > remember is that complete packages, in multiple versions, can be loaded > simultaneously as Monticello models without disrupting the code currently > loaded and active in the image, as when you "browse" a Monticello package > on disk. > > Thierry > > >> >> cheers -ben >> >> >

March 31, 2017

Re: [Pharo-users] Morphic component to display images/pictures

by Stephane Ducasse

have a look at the solution of the challenge 2 or 3 in the mooc :) On Thu, Mar 30, 2017 at 3:37 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 30/03/17 13:24, Peter Uhnak wrote: > >> do we have a Morphic/Brick/whatever component for displaying >> pictures/images in Pharo? >> > > You can combine something with ImageMorph, ImagePreviewMorph, Form and > TransformMorph. I don't know about mousewheel support, I vaguely remember > something about mousewheel events being tranformed, and > forgot if that was vm- or image-side. > > > 1) zooming with mousewheel (now it scrolls vertically) >> 2) dragging the image around to scroll both vertically and horizontally >> (now I have to use manually the scrollbars) >> 3) ideally also buttons like "show 1:1 size", "show fit to window" >> > > > >

March 31, 2017

Re: [Pharo-users] PetitParser question parsing HTML meta tags

by Martin McClure

On 03/30/2017 10:58 AM, PAUL DEBRUICKER wrote: > 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. This looks like a job for the ordered choice operator. Perhaps something very roughly like this... descTag := nameDescTag / httpDescTag. nameDescTag := 'name=' , descAnyCase. httpDescTag := 'http-equiv=' , descAnyCase. descAnyCase := 'description' asParser / 'Description' asParser. And so on. HTH. Regards, -Martin

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by Ben Coman

On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > 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. Many people also technically frown on isXYZ is a similar way to isKindOf:, but it is a lesser evil and pragmatically is used reasonably often. > > Instead of adding a test method, there are also empty implementations Like this, what you can do is refactor that guarded code into a method #myAction and add Object>>myAction which throws the exception. Thus you condense multiple condition statements into one location and your application code becomes much cleaner. Object may end up loaded with a lot of methods not of interest to every object, but the trade-off of cleaner application code is generally worth it. btw, Here you start to see how using Pharo/Smalltalk "changes the way you think about programming". Further, the exception thrown by Object>>myAction should signal the error on a custom error object, similar to ZeroDivide for example. > or ones that return self or an appropriate null-value. Within your framework where you control all the objects the Null-object pattern is probably the cleanest OO approach, but it can't control what the user passes across the public API. https://en.wikipedia.org/wiki/Null_Object_pattern btw, you can search null-object pattern in Spotter using " Null #c " cheers -ben

March 31, 2017