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

Re: [Pharo-users] [ANN] Language of Languages Demo at SPLASH '11

by StÃ©phane Ducasse

Thanks Nick for letting us know. Good luck. I suggest that you propose a ready to use image on your web site. BTW did you see Helvetia and PetitParser? Because they can help you. Stef On Oct 17, 2011, at 3:42 AM, Nick Chen wrote: > Dear Smalltalkers > > Jamie Douglass, Ralph Johnson and I are working on an experimental language > workbench called Language of Languages (LoLs) that focuses on unifying > concepts > (meta-models) across different notations. This affords the user greater > flexibility for editing the model in a variety of different notations while > maintaining consistency. We are building this language workbench on top of > Pharo > Smalltalk[1] and we are using the Glamour engine[2] to build some of the > language browsers. > > If anyone is attending SPLASH[3] this year, we'd like to invite you to one > of > our demo sessions. You can find a schedule of our demos at > http://languageoflanguages.org/news. You can find more information about > LoLs > from our website at http://www.languageoflanguages.org. > > Hope to see you at SPLASH '11! > > -- > Nick > University of Illinois at Urbana-Champaign > > [1] http://www.pharo-project.org/home > [2] http://www.moosetechnology.org/tools/glamour > [3] http://splashcon.org/2011/ > > -- > View this message in context: http://forum.world.st/ANN-Language-of-Languages-Demo-at-SPLASH-11-tp3910817… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Oct. 17, 2011

Re: [Pharo-users] [ANN] Language of Languages Demo at SPLASH '11

by Lukas Renggli

Hi Nick, Looks interesting. I followed your download instructions, but unfortunately the Monticello project on SqueakSource is marked as private, so it cannot be installed. Lukas On 17 October 2011 03:42, Nick Chen <nchen.dev(a)mac.com> wrote: > Dear Smalltalkers > > Jamie Douglass, Ralph Johnson and I are working on an experimental language > workbench called Language of Languages (LoLs) that focuses on unifying > concepts > (meta-models) across different notations. This affords the user greater > flexibility for editing the model in a variety of different notations while > maintaining consistency. We are building this language workbench on top of > Pharo > Smalltalk[1] and we are using the Glamour engine[2] to build some of the > language browsers. > > If anyone is attending SPLASH[3] this year, we'd like to invite you to one > of > our demo sessions. You can find a schedule of our demos at > http://languageoflanguages.org/news. You can find more information about > LoLs > from our website at http://www.languageoflanguages.org. > > Hope to see you at SPLASH '11! > > -- > Nick > University of Illinois at Urbana-Champaign > > [1] http://www.pharo-project.org/home > [2] http://www.moosetechnology.org/tools/glamour > [3] http://splashcon.org/2011/ > > -- > View this message in context: http://forum.world.st/ANN-Language-of-Languages-Demo-at-SPLASH-11-tp3910817… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 17, 2011

[ANN] Language of Languages Demo at SPLASH '11

by Nick Chen

Dear Smalltalkers Jamie Douglass, Ralph Johnson and I are working on an experimental language workbench called Language of Languages (LoLs) that focuses on unifying concepts (meta-models) across different notations. This affords the user greater flexibility for editing the model in a variety of different notations while maintaining consistency. We are building this language workbench on top of Pharo Smalltalk[1] and we are using the Glamour engine[2] to build some of the language browsers. If anyone is attending SPLASH[3] this year, we'd like to invite you to one of our demo sessions. You can find a schedule of our demos at http://languageoflanguages.org/news. You can find more information about LoLs from our website at http://www.languageoflanguages.org. Hope to see you at SPLASH '11! -- Nick University of Illinois at Urbana-Champaign [1] http://www.pharo-project.org/home [2] http://www.moosetechnology.org/tools/glamour [3] http://splashcon.org/2011/ -- View this message in context: http://forum.world.st/ANN-Language-of-Languages-Demo-at-SPLASH-11-tp3910817… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 17, 2011

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

by Marcus Denker

On Oct 16, 2011, at 8:00 PM, eMko wrote: > I think I am not the only one who is also interested in the conference, but > can not go there in person. Is it possible to have videos from the > conference? > Yes, we will do again videos. At least the same kind as the ones from "Deep into Smalltalk" http://www.youtube.com/user/esugboard#g/c/843D1D545F9F52B6 Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 16, 2011

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

by eMko

I think I am not the only one who is also interested in the conference, but can not go there in person. Is it possible to have videos from the conference? Martin MadÄra -- View this message in context: http://forum.world.st/Planning-a-nice-pharo-conference-tp3902751p3910012.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 16, 2011

Re: [Pharo-users] preparing data for diagramms

by Tudor Girba

Hi, EyeSee is a model for charts. The rendering logic is meant to be orthogonal. Cheers, Doru On 15 Oct 2011, at 20:07, StÃ©phane Ducasse wrote: > 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 >>>> >>> >>> >> >> > > -- www.tudorgirba.com "Don't give to get. Just give."

Oct. 15, 2011

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

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