- Pharo-users - lists.pharo.org

Re: [Pharo-users] preparing data for diagramms

by StÃ©phane Ducasse

Normally this is plan :) But I guess that andre did not started on it. Stef On Oct 15, 2011, at 1:53 PM, Norbert Hartl wrote: > > Am 15.10.2011 um 09:05 schrieb StÃ©phane Ducasse: > >> There is EyeSee that andre Hora ported and enhanced. >> >> And we should improve it. >> > I think I wasn't clear enough. I'm targetting the web as visualization frontend. EyeSee seems to be mostly the diagram drawing part in pharo. I'm more interested in the data mageling part. Can EyeSee help if you like to draw your diagrams with javascript on a web page? > > Norbert > >> >> >> On Oct 14, 2011, at 11:16 PM, Norbert Hartl wrote: >> >>> Hi, >>> >>> is there a toolkit that helps to prepare data for diagramms and such. I mean accumulating in time series like day, week, ..., calculating average, sums,.. and scaling data. Something that just eases to typical stuff one needs to go from log data to visual representation. >>> >>> thanks in advance, >>> >>> Norbert >>> >> >> > >

Oct. 15, 2011

Re: [Pharo-users] preparing data for diagramms

by Norbert Hartl

Am 15.10.2011 um 09:05 schrieb StÃ©phane Ducasse: > There is EyeSee that andre Hora ported and enhanced. > > And we should improve it. > I think I wasn't clear enough. I'm targetting the web as visualization frontend. EyeSee seems to be mostly the diagram drawing part in pharo. I'm more interested in the data mageling part. Can EyeSee help if you like to draw your diagrams with javascript on a web page? Norbert > > > On Oct 14, 2011, at 11:16 PM, Norbert Hartl wrote: > >> Hi, >> >> is there a toolkit that helps to prepare data for diagramms and such. I mean accumulating in time series like day, week, ..., calculating average, sums,.. and scaling data. Something that just eases to typical stuff one needs to go from log data to visual representation. >> >> thanks in advance, >> >> Norbert >> > >

Oct. 15, 2011

Re: [Pharo-users] preparing data for diagramms

by StÃ©phane Ducasse

There is EyeSee that andre Hora ported and enhanced. And we should improve it. Stef On Oct 14, 2011, at 11:16 PM, Norbert Hartl wrote: > Hi, > > is there a toolkit that helps to prepare data for diagramms and such. I mean accumulating in time series like day, week, ..., calculating average, sums,.. and scaling data. Something that just eases to typical stuff one needs to go from log data to visual representation. > > thanks in advance, > > Norbert >

Oct. 15, 2011

preparing data for diagramms

by Norbert Hartl

Hi, is there a toolkit that helps to prepare data for diagramms and such. I mean accumulating in time series like day, week, ..., calculating average, sums,.. and scaling data. Something that just eases to typical stuff one needs to go from log data to visual representation. thanks in advance, Norbert

Oct. 14, 2011

Re: [Pharo-users] [Pharo-project] Planning a nice pharo conference :)

by Luc Fabresse

2011/10/13 Norbert Hartl <norbert(a)hartl.name>: > > Am 13.10.2011 um 22:12 schrieb 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? >> > Of course. And as it is only a 3,5 hour trip by train there is no "no go". > > Norbert > I am in too! Luc > >

Oct. 14, 2011

Re: [Pharo-users] Planning a nice pharo conference :)

by Norbert Hartl

Am 13.10.2011 um 22:12 schrieb 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? > Of course. And as it is only a 3,5 hour trip by train there is no "no go". Norbert

Oct. 13, 2011

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

by Norbert Hartl

Am 13.10.2011 um 22:21 schrieb 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. > Did you have a look at Seaside-REST. I think Phillipe did a great job in implementing the routing for http handlers. As far as I know the whole routing code is not seaside dependent at all. It is just the way to enable it. Would probably useful to have a look there and try to phase out the seaside stuff and enable it to adapt to different things like zinc. What do you mean? Norbert

Oct. 13, 2011

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

by Norbert Hartl

Am 13.10.2011 um 22:07 schrieb StÃ©phane Ducasse: > And norbert I would like you to present that to the next pharo conf. :) > deal! Norbert > > 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] RESTful Pharo app (not Seaside)

by Sean P. DeNigris

Thanks for all the responses. I'm reminded how great our community is. Also, REST is working out beautifully as a simple cross-language communication channel since every language and even the command line can send/receive via http. Straight XMLRPC felt like it was in my way by comparison. Sean -- View this message in context: http://forum.world.st/RESTful-Pharo-app-not-Seaside-tp3900373p3902821.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 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