September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FluidDB API for Pharo

by Jordi Delgado

oops! just fixed. Now you should be able to get it. Sorry. Bests, Jordi > > On 25 Sep 2010, at 10:22, Jordi Delgado wrote: > > > Hi > > > > I write just to let you know that we (the smalltalk.cat group) did an > > API to interact with a nice no-SQL database called FluidDB. It has been > > mainly the work of Sergio Garcia, but there is a little of some of us in the > > tests and the code: > > http://www.squeaksource.com/FluidDB.html > > To see what this FluidDB is: > > http://fluidinfo.com/ > > > > Bests, > > > > Jordi > > Sounds interesting, however the SqueakSource project has a 'Global: no access', so we can't see anything. > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2010

Re: [Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

by Mariano Martinez Peck

On Sat, Sep 25, 2010 at 8:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi. Can someone with experience in "No-SQL" databases explain me the > > differences/advantages over a RDBMS and doing something like: > > > > create table database (key varchar() , value varchar() ) > > > > You can find many topics about it in the net. > Yes, but the net is full of idiots too. I mean...if I read the net then I should be programing in Java... I want to hear if someone of you, someone I know, had real experience with both alternatives. And why you would choose one over the other one. In addition, if someone has experience with a real app using Seaside or something like that. > This topic is really overheated :) > > yes, I know :) > > thanks > > > > mariano > > > > On Sat, Sep 25, 2010 at 10:30 AM, Sven Van Caekenberghe <sven(a)beta9.be> > > wrote: > >> > >> On 25 Sep 2010, at 10:22, Jordi Delgado wrote: > >> > >> > Hi > >> > > >> > I write just to let you know that we (the smalltalk.cat group) did an > >> > API to interact with a nice no-SQL database called FluidDB. It has > been > >> > mainly the work of Sergio Garcia, but there is a little of some of us > in > >> > the > >> > tests and the code: > >> > http://www.squeaksource.com/FluidDB.html > >> > To see what this FluidDB is: > >> > http://fluidinfo.com/ > >> > > >> > Bests, > >> > > >> > Jordi > >> > >> Sounds interesting, however the SqueakSource project has a 'Global: no > >> access', so we can't see anything. > >> > >> Sven > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

by Igor Stasenko

2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. Can someone with experience in "No-SQL" databases explain me the > differences/advantages over a RDBMS and doing something like: > > create table database (key varchar() , value varchar() ) > You can find many topics about it in the net. This topic is really overheated :) > thanks > > mariano > > On Sat, Sep 25, 2010 at 10:30 AM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: >> >> On 25 Sep 2010, at 10:22, Jordi Delgado wrote: >> >> > Hi >> > >> > I write just to let you know that we (the smalltalk.cat group) did an >> > API to interact with a nice no-SQL database called FluidDB. It has been >> > mainly the work of Sergio Garcia, but there is a little of some of us in >> > the >> > tests and the code: >> > http://www.squeaksource.com/FluidDB.html >> > To see what this FluidDB is: >> > http://fluidinfo.com/ >> > >> > Bests, >> > >> > Jordi >> >> Sounds interesting, however the SqueakSource project has a 'Global: no >> access', so we can't see anything. >> >> Sven >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by Mariano Martinez Peck

On Sat, Sep 25, 2010 at 7:09 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Mariano, > > This is a good and needed step. > > Now, just a problem: 1.1.1dev image does not work with the regular VM. This > is probably because you saved it again after you opened it with the Cog VM. > It would be great if the released dev image would work with both. > Excellent suggestion :) Thanks doru. > > Cheers, > Doru > > > > On 25 Sep 2010, at 17:56, Mariano Martinez Peck wrote: > > > Hi. This is not an official release. I didn't do all the formal procedure > for releasing a Pharo image. My idea is try to push CogVM and try to get as > much as testers as possible. Try to report issues and help Eliot. For that > purpose, I think having a one click image is worth it. > > > > So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some > fixes over 1.1 and the CogVM necessary changes). I build the image with > exactly the same versions of the external packages than Pharo 1.1. > > > > If you want to download that this Pharo1.1.1 dev image that works with > Cog here is the link: > > > > > https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip > > > > In addition, and thanks to Lukas, we could generate OneClicks with CogVM. > Here you can have a OneClick using the above image: > > > > > https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip > > > > Notice that this is not an official release and that there are > failing/errors tests. I've already sent emails for them and hopefully > someone may fix them. The only thing is not supported is the TestCoverage > (since it uses objects as methods, with is not yet supported in CogVM). > > > > Cheers > > > > Mariano > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

[Pharo-project] squeaksource is down :(

by Mariano Martinez Peck

thanks mariano

Sept. 25, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by Tudor Girba

Hi Mariano, This is a good and needed step. Now, just a problem: 1.1.1dev image does not work with the regular VM. This is probably because you saved it again after you opened it with the Cog VM. It would be great if the released dev image would work with both. Cheers, Doru On 25 Sep 2010, at 17:56, Mariano Martinez Peck wrote: > Hi. This is not an official release. I didn't do all the formal procedure for releasing a Pharo image. My idea is try to push CogVM and try to get as much as testers as possible. Try to report issues and help Eliot. For that purpose, I think having a one click image is worth it. > > So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some fixes over 1.1 and the CogVM necessary changes). I build the image with exactly the same versions of the external packages than Pharo 1.1. > > If you want to download that this Pharo1.1.1 dev image that works with Cog here is the link: > > https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip > > In addition, and thanks to Lukas, we could generate OneClicks with CogVM. Here you can have a OneClick using the above image: > > https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip > > Notice that this is not an official release and that there are failing/errors tests. I've already sent emails for them and hopefully someone may fix them. The only thing is not supported is the TestCoverage (since it uses objects as methods, with is not yet supported in CogVM). > > Cheers > > Mariano > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Sept. 25, 2010

[Pharo-project] [ANN] Pharo 1.1.1 OneClickCogVm

by Mariano Martinez Peck

Hi. This is not an official release. I didn't do all the formal procedure for releasing a Pharo image. My idea is try to push CogVM and try to get as much as testers as possible. Try to report issues and help Eliot. For that purpose, I think having a one click image is worth it. So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some fixes over 1.1 and the CogVM necessary changes). I build the image with exactly the same versions of the external packages than Pharo 1.1. If you want to download that this Pharo1.1.1 dev image that works with Cog here is the link: https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip In addition, and thanks to Lukas, we could generate OneClicks with CogVM. Here you can have a OneClick using the above image: https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip Notice that this is not an official release and that there are failing/errors tests. I've already sent emails for them and hopefully someone may fix them. The only thing is not supported is the TestCoverage (since it uses objects as methods, with is not yet supported in CogVM). Cheers Mariano

Sept. 25, 2010

[Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo

by Mariano Martinez Peck

Hi. Can someone with experience in "No-SQL" databases explain me the differences/advantages over a RDBMS and doing something like: create table database (key varchar() , value varchar() ) thanks mariano On Sat, Sep 25, 2010 at 10:30 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 25 Sep 2010, at 10:22, Jordi Delgado wrote: > > > Hi > > > > I write just to let you know that we (the smalltalk.cat group) did an > > API to interact with a nice no-SQL database called FluidDB. It has been > > mainly the work of Sergio Garcia, but there is a little of some of us in > the > > tests and the code: > > http://www.squeaksource.com/FluidDB.html > > To see what this FluidDB is: > > http://fluidinfo.com/ > > > > Bests, > > > > Jordi > > Sounds interesting, however the SqueakSource project has a 'Global: no > access', so we can't see anything. > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Igor Stasenko

On 25 September 2010 10:41, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: > Thanks, Igor > > Two questions. > > 1) I have not been following closely the Pharo development. Does Pharo > rely mainly on Announcements (Event objects) for Morphic GUI code > these days? > No. Its just my observation, that some parts of it look almost exactly as in announcements. Yes, and Announcements was born later than Morphic. > MCHttpRepository location: > 'http://source.lukas-renggli.ch/announcements' user: '' password: '' > > 2) I found > How Morphic processes events > Â http://wiki.squeak.org/squeak/118 > written by Andreas Raab in 2003 > > Could somebody have a quick look at it and tell me if this still more > or less applies to the current Squeak and Pharo implementations? > > Where do I find a description how Pharo handles Morphic events these days? > They are almost the same. This problem with Morphic, for any entry-level developer, that its a huge code base, and it sparsely documented. So, it is really hard to make conclusions about what model it using and what might break, if you change/remove some code. > --Hannes > > > On 9/25/10, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> On 9/24/10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> >>>> >>>> Hannes Hirzel-2 wrote: >>>>> >>>>>> I tried (one of these felt very satisfying): >>>>>> * Morph>>on:send:to:, which sounded good, but never got called >>>>>> * intercepting Morph>>processEvent:using: (which I was told was not a >>>>>> good >>>>>> idea) >>>>>> * (after seeking help), locking the submorphs and overriding the dozen >>>>>> or >>>>>> so >>>>>> event-related methods in the chain from my morph to TextMorphForShout >>>>>> (the >>>>>> Morph that actually handles the text and input). >>>>>> * subclassing TextMorphForShout and then subclassing >>>>>> PluggableShoutMorph >>>>>> to >>>>>> use that subclass. >>>>> >>>>> Which method did you like best? >>>>> >>>> >>>> Ha ha, should have been *none of these felt...*, but: >>> >>>> 1. The on:send:to: was what I /wanted/ to do, with the downside being >>>> that >>>> it did nothing, lol. >>> >>>> 2. The intercept of Morph>>processEvent:using: was okay, but dangerous >>>> because it's easy to lock the image when messing with this. >>> >>>> 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very >>>> heavy >>>> weight for listening in on one event. Â IOW I may have gone that route >>>> eventually if the behavior got complex, but didn't like being chained to >>>> it >>>> for my simple case. >>>> >>>> >>>> Hannes Hirzel-2 wrote: >>>>> >>>>> There are some notes on this issue at >>>>> http://wiki.squeak.org/squeak/2477 >>>>> ( Eddie Cottongim writes: I know of three main ways to handle events >>>>> in Morphic.......) >>>>> >>>> Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler >>>> >>>> >>>> Hannes Hirzel-2 wrote: >>>>> >>>>> Conclusion: It might be worthwile to find out more how Juan has pruned >>>>> Morphic in Cuis and if it is still valuable for use, document that and >>>>> put it to use in Squeak and Pharo. >>>>> >>>> Cool, I've started this as well. Â Let's keep the list posted if we come >>>> up >>>> with anything. >>>> >>>> Sean >>> >>> >>> >>> >>>> p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start >>>> another >>>> thread. >>> >>> Juan has in Cuis 2.6 >>> >>> Morph >>> >>> on: eventName send: selector to: recipient >>> >> i saw such message pattern. Guess where? >> Announcements! :) >> >> announcer on: MyAnnouncement send: #foo to: bar >> >>> Â Â Â Â self flag: #jmv. >>> Â Â Â Â "Do NOT implement EventHandler in Morphic 3 or LightWidgets. >>> Â Â Â Â Even more. Try to avoid all the stuff in Morphic-OldEvents" >>> >>> Â Â Â Â self eventHandler ifNil: [self eventHandler: EventHandler new]. >>> Â Â Â Â self eventHandler on: eventName send: selector to: recipient >>> >>> >>> So the best thing as of now would be to remove this in Squeak and >>> Pharo so that the next people who analyze this do not loose time with >>> it and can advance more with the things which work..... >>> >> >> The dichotomy here is , that Morph from one side acts as an event recipient, >> but from another side, it acts as an events source for eventHandler. >> (as far as i can tell, this is an intent of introducing EventHandler). >> >> This could be managed in more gracious manner, by having a single >> entry point for all events, >> which coming to morph. Then you can write: >> >> singleEntryPointForAllEvents: anEvent >> Â Â self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent >> fromMorph: self ]. >> Â Â self handleEvent: anEvent >> >> and get rid of repetituous code from all places, like: >> >> keyStroke: anEvent >> Â Â Â "Handle a keystroke event. Â The default response is to let my >> eventHandler, if any, handle it." >> >> Â Â Â self eventHandler ifNotNil: >> Â Â Â Â Â Â Â [self eventHandler keyStroke: anEvent fromMorph: self]. >> >> >>> HJH >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2010

Re: [Pharo-project] Fame vs Magritte

by StÃ©phane Ducasse

here is my summary fame is a minimal meta meta model ( 4 or 5 classes): we use it describe other model (such as Famix) based on fame you can load and save model. Magritte is a meta data driven framework. you describe specific entity and the tools interpret it. On Sep 25, 2010, at 11:24 AM, FranÃ§ois Tanguy wrote: > Hi, > > being a end user, I am bit confused with these 2 frameworks: Fame and Magritte. > There are both meta-meta-models. So what make them different from a conceptual point of view ? > > For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte). > > Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description. > > Any info on this would be appreciated. > > Thanks. > > Francois > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 25, 2010