October 2011 - Pharo-users - lists.pharo.org

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by StÃ©phane Ducasse

On Oct 13, 2011, at 10:21 PM, Sven Van Caekenberghe wrote: > Sean, FranÃ§ois, > > On 13 Oct 2011, at 18:18, Sean P. DeNigris wrote: > >> fstephany wrote: >>> >>> If your needs are simple you can maybe directly use Zinc ? >>> >> >> Yes, I haven't played with Zinc yet, so this is a good opportunity. I read >> the "getting started" page and didn't see anything about REST. Where can I >> find Zinc REST examples or it is roll-your-own at this point? >> >> Thanks. >> Sean > > There is a Zinc-REST package in http://www.squeaksource.com/ZincHTTPComponents which depends on Zn only. I use this myself in a production project and it is my second version of this idea, but unfortunately it is not documented at all ;-) well we should document Zn first :) Sven the first thing would be to produce some slides like that other people can read them and we could write a chapter for Pharo for the enterprise. > The idea is that you plug a handler in a Zn server, an instance of ZnRestServerDelegate. This instance has a URI space. The URI space is another object that #match: -es a request to a call object, then the HTTP method of the call object is executed, with URI variables resolved by the matching process. > > A concrete subclass of ZnRestUriSpace is ZnCallHierarchyRestUriSpace: here, a class hierarchy below some root represents the URI space. By subclassing the root from ZnAutoMatchedRestCall you can use a #pattern class method like #( 'users' '*") to match URIs like /users/12 (with 12 being the first variable). In very special cases, #match: itself can be overwritten. > > So the hierarchy would be > > ZnAutoMatchedRestCall > MyRestCalls > MyUsersRestCall > > MyUsersRestCall class>>#pattern > ^ #( 'users' '*") > > MyUsersRestCall >>#get > | user | > user := MyUser userWithId: self variables first. > ^ ZnResponse ok: (ZnEntity with: user asJson type: ZnMimeType applicationJson) > > This is non-refactored code without error handling, but the idea should be clear. > I quite like it when each resouce has its own class, but some might like pragma's better. > > Sven > > >

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by Sven Van Caekenberghe

Sean, FranÃ§ois, On 13 Oct 2011, at 18:18, Sean P. DeNigris wrote: > fstephany wrote: >> >> If your needs are simple you can maybe directly use Zinc ? >> > > Yes, I haven't played with Zinc yet, so this is a good opportunity. I read > the "getting started" page and didn't see anything about REST. Where can I > find Zinc REST examples or it is roll-your-own at this point? > > Thanks. > Sean There is a Zinc-REST package in http://www.squeaksource.com/ZincHTTPComponents which depends on Zn only. I use this myself in a production project and it is my second version of this idea, but unfortunately it is not documented at all ;-) The idea is that you plug a handler in a Zn server, an instance of ZnRestServerDelegate. This instance has a URI space. The URI space is another object that #match: -es a request to a call object, then the HTTP method of the call object is executed, with URI variables resolved by the matching process. A concrete subclass of ZnRestUriSpace is ZnCallHierarchyRestUriSpace: here, a class hierarchy below some root represents the URI space. By subclassing the root from ZnAutoMatchedRestCall you can use a #pattern class method like #( 'users' '*") to match URIs like /users/12 (with 12 being the first variable). In very special cases, #match: itself can be overwritten. So the hierarchy would be ZnAutoMatchedRestCall MyRestCalls MyUsersRestCall MyUsersRestCall class>>#pattern ^ #( 'users' '*") MyUsersRestCall >>#get | user | user := MyUser userWithId: self variables first. ^ ZnResponse ok: (ZnEntity with: user asJson type: ZnMimeType applicationJson) This is non-refactored code without error handling, but the idea should be clear. I quite like it when each resouce has its own class, but some might like pragma's better. Sven

Oct. 13, 2011

Planning a nice pharo conference :)

by StÃ©phane Ducasse

Hi guys the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, frameworks, tips and trick on server set up, community building, drinking beers and more. So we could host such conference in beginning of may for example. What do you think? Would you be interested to join a two-three days conference focusing on dev and business? Stef

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by StÃ©phane Ducasse

And norbert I would like you to present that to the next pharo conf. :) On Oct 13, 2011, at 7:27 PM, Norbert Hartl wrote: > > Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris: > >> >> Pat Maddox-3 wrote: >>> >>> http://code.google.com/p/seaside/wiki/SeasideRest >>> >> >> Thanks Pat. I was hoping not to have to load Seaside... >> > The name Seaside-REST is a bit misleading because you need only little from seaside to get going. And there are no sessions and such created. I use it in production and I can say it is really easy to work with. Combined with the zinc lib you can have REST-like services _with_ proper mime handling data. Well, I put magritte and Magritte-XMLBinding on top and voila I have a full REST services with mime multipart handling and XML object serialization/deserialization without having to care too much about any of the involved components. > Soon I will add Magritte-JSON to it and will use the Accept header filtering provided by Seaside-REST and then all my wishes are fullfilled probably even before christmas this year. > > Norbert > > > >

Oct. 13, 2011

Re: [Pharo-users] red-black and other trees

by Paul DeBruicker

I created the CenteredIntervalTree repo on Squeaksource. The CenteredIntervalTree is about 2x slower to create than a DateTree but 50-500x faster to query in Pharo 1.3 on Linux. The speed difference remains relatively constant as the tree size grows. I only tested up to 1,000,000 timespans. It works with instances of class Interval and Timespan. Converting the Timespans to Intervals using #asSeconds makes the creation process faster than the DateTree creation process. I used the code below to approximate the speed differences. You need to have the BTree package loaded from SqueakSource to try the example below. Paul |timespanDatabase dateTree centeredIntervalTree timespansOfInterest timingResults results size iterations interval tmpResults citResults dtResults| size:=10. iterations:=10. interval:=1 to: size. results:=Dictionary new. timingResults := Dictionary new. timespanDatabase:= OrderedCollection new. interval do:[:eachMonth | interval do: [:eachDay| interval do:[:eachHour| timespanDatabase add:(Timespan starting: (DateAndTime now + (eachMonth*30) days + eachDay days + eachHour hours) duration: 2 hours)]]]. timespansOfInterest :=OrderedCollection new. timespansOfInterest add: (timespanDatabase at: 20). interval do:[:each | timespansOfInterest add: timespanDatabase atRandom]. results at: 'timespanDatabase-size' put:timespanDatabase size. "results at: 'timespanDatabase' put: timespanDatabase ." timingResults at:'dateTree-creation' put:([iterations timesRepeat:[dateTree:=DateTree new. timespanDatabase do:[:eachTimespan| dateTree at: eachTimespan put: eachTimespan]]] timeToRun). timingResults at:'dateTree-query' put:([iterations timesRepeat:[tmpResults:=Dictionary new. timespansOfInterest do: [:each | tmpResults at: each put: (dateTree during: each)]]] timeToRun). results at:'dateTree-results' put: tmpResults. timingResults at:'centeredIntervalTree-creation' put:([iterations timesRepeat:[centeredIntervalTree :=CenteredIntervalTree from: timespanDatabase ]] timeToRun). timingResults at:'centeredIntervalTree-query' put:([iterations timesRepeat:[tmpResults:=Dictionary new. timespansOfInterest do:[:each | tmpResults at: each put: (centeredIntervalTree intervalsThatInclude: each) asSet]]] timeToRun). results at:'centeredIntervalTree-results' put: tmpResults. citResults:=OrderedCollection new. (results at: 'centeredIntervalTree-results') keysAndValuesDo: [:timespan :col| citResults addAll:col]. dtResults:=OrderedCollection new. (results at: 'dateTree-results') keysAndValuesDo: [:timespan :col| dtResults addAll:col]. dtResults size = citResults size ifFalse:[self halt.]. (dtResults includesAllOf: citResults) ifFalse:[self halt]. (citResults includesAllOf: dtResults) ifFalse:[self halt]. timingResults On 10/13/2011 03:03 AM, pharo-users-request(a)lists.gforge.inria.fr wrote: > Date: Wed, 12 Oct 2011 22:27:26 +0200 > From: Lukas Renggli<renggli(a)gmail.com> > Subject: Re: [Pharo-users] red-black and other trees > To: A friendly place where any question about pharo is welcome > <pharo-users(a)lists.gforge.inria.fr> > Message-ID: > <CANoDCG-osEdoF85ikhn2xShe6T=gpu9hKe4r9w-zVGUJxrp5hw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > The BTree package contains a class called DateTree for exactly that > purpose. Works very well with huge collections of date intervals. > > Lukas > > On 12 October 2011 22:13, Paul DeBruicker<pdebruic(a)gmail.com> wrote: >> > Hi - >> > >> > I am considering implementing a Centered Interval Tree >> > (http://en.wikipedia.org/wiki/Interval_tree) because I have to get the set >> > of Timespans a particular Timespan overlaps from an arbitrary set of >> > Timespans. >> > >> > >> > In looking around I can only find the BTree implementation on SqueakSource, >> > and the Left-Leaning-Red-Black-Tree linked to in the following list posting: >> > http://forum.world.st/Interesting-survey-about-smalltalk-tp2261561p2263370.… >> > >> > >> > Does Pharo either not need/benefit from the various kinds of trees? >> > >> > Or is it trivial to implement/adapt the BTree to behave as a Red-Black Tree >> > (or, in my case, the Centered Interval Tree) and as such I just need to >> > learn how to do that? >> > >> > Thanks >> > >> > Paul >> > >> >

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by Norbert Hartl

Am 13.10.2011 um 17:30 schrieb Sean P. DeNigris: > > Pat Maddox-3 wrote: >> >> http://code.google.com/p/seaside/wiki/SeasideRest >> > > Thanks Pat. I was hoping not to have to load Seaside... > The name Seaside-REST is a bit misleading because you need only little from seaside to get going. And there are no sessions and such created. I use it in production and I can say it is really easy to work with. Combined with the zinc lib you can have REST-like services _with_ proper mime handling data. Well, I put magritte and Magritte-XMLBinding on top and voila I have a full REST services with mime multipart handling and XML object serialization/deserialization without having to care too much about any of the involved components. Soon I will add Magritte-JSON to it and will use the Accept header filtering provided by Seaside-REST and then all my wishes are fullfilled probably even before christmas this year. Norbert

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by Sean P. DeNigris

fstephany wrote: > > If your needs are simple you can maybe directly use Zinc ? > Yes, I haven't played with Zinc yet, so this is a good opportunity. I read the "getting started" page and didn't see anything about REST. Where can I find Zinc REST examples or it is roll-your-own at this point? Thanks. Sean -- View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3902074.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by Francois Stephany

> Thanks Pat. I was hoping not to have to load Seaside... If your needs are simple you can maybe directly use Zinc ?

Oct. 13, 2011

Re: [Pharo-users] RESTful Pharo app (not Seaside)

by Pat Maddox

On Oct 13, 2011, at 8:30 AM, Sean P. DeNigris wrote: > > Pat Maddox-3 wrote: >> >> http://code.google.com/p/seaside/wiki/SeasideRest >> > > Thanks Pat. I was hoping not to have to load Seaside... Ah well then there's always Stout....super immature framework that James Ladd & I worked on in Vegas. I can upload what I have to Squeaksource a bit later if you want. You'll have to do some more work on it but it's a good starting point. When I showed it at a lightning talk someone asked me if I had heard of Zinc, and said that it did something similar. Although when I looked I didn't see it... http://zn.stfx.eu/zn/index.html Pat

Oct. 13, 2011

Re: [Pharo-users] [ANN] Pharo Glorp port release

by Mariano Martinez Peck

On Thu, Oct 13, 2011 at 1:56 PM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Hi, > > DBXTalk is good work! > I really love to see that stuff going forward! > > Thanks. > Before I spend a lot of time playing around: has anybody tried using > Pharo/GLORP/ODBC (Access or SQLSrv) on Windows? > Yes, but I have to admit that it's almost the most complicated scenario to configure. At least I know someone tried Pharo/Glorp/ODBC/SQL Server. I think you can just give it a try. Get the dll of OpenDBX (they are in our website), get a Pharo VM that has a working FFI, and give it a try. > Or Pharo/GLORP/SQLite on Windows? > Yes, this works almost out of the box. In fact, I can provide you a zip that contains Pharo VM + image + opendbx dll + sqlite dll. > Is there some place on the web where I can find info on how to set this up? > > http://dbxtalk.smallworks.com.ar/Compiling%20and%20installing%20OpenDBX http://dbxtalk.smallworks.com.ar/Compiling%20for%20different%20backends > In an open source context, this is probably a heretic question, and if I > could choose freely, Linux and PostgresQL would be my favorite. > Sure, that's pretty easy. OpenDBX and PostgreSQL are easy to make it work in Linux. > OTOH: The fact that each windows installation comes with an Access engine > and respective ODBC driver makes the combination very attractive for > starting something on a windows machine really fast. No installation of > anything but Pharo, no need for admin rights or anything. Just set up the > odbc driver and off you go! Great chance to show the strength of Smalltalk > and Glorp to other team members and friends... > well more or less. In the case of DBX you will need the OpenDBX library anyway, even if being ODBC. OpenDBX sees ODBC just as another backend. And of course, that's only if you like accessing by ODBC (which I don't like BTW). Of course, you can create a database driver for Glorp that uses the ODBC driver of squeak in which case you wouldn't need the OpenDBX driver. > SQLite is a similar story: copy the dlls onto the machine and the journey > can start. > > yes, that's even easier. As I say, it can be provided in a "DBXOneClick" :) Cheers -- Mariano http://marianopeck.wordpress.com

Oct. 13, 2011