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

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort

by Lukas Renggli

That would be great and would avoid that we have to conditionally load methods depending on what version of Pharo is used. As far as I see this is really just OrderedCollection>>#sort and OrderedCollection>>#sort: and they have no external dependencies. Lukas On 17 February 2010 15:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 17, 2010, at 2:13 PM, Lukas Renggli wrote: > >>> #sort you mean? Not yet... we either need to add it in Pharo, fix it >>> in the one click, or add it to the Grease package. >> >> OrderedCollection>>#sort and OrderedCollection>>#sort: is already part >> of Pharo 1.1. The Seaside tests pass in Pharo 1.1. >> >> I understand and I agree with Pharo not to implement #sort and #sort: >> in SequenceableCollection, because it does not make sense for most >> subclasses. SortedCollection, Heap and Interval are already sorted; >> and for LinkedList sorting does not really make sense. >> >> So I don't really know what to do to fix the Seaside test. We could >> ask the Pharo guys to integrate OrderedCollection>>#sort and >> OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too >> late? >> > > I think we can add that 1.0 > > For 1.1, there are some changes for generalizing and cleaning sort on the bugtracker that I plan to look > at (at some point). > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 17, 2010

Re: [Pharo-project] databases

by laurent laffont

Really great informations : Scenarioâs In different situations, there are different storage needs 1. You are writing a small demonstration program to show your customers, and want to populate the system with some representative data. Add a class instance variable to store the instances, and simply save the image. 2. You have a small system with a few hundred/thousand objects, and are not dependent on external systems. A prevayler-like system like SandstoneDB might be a perfect fit. Each object save means a disk access, so scaling ends with disk speed. A few old versions of the data are kept around, so backing up or reverting is easy. If you want a readable representation, SIXX might help. 3. You have a legacy (relational) database, with extensive reporting written for it. Use an ORM. 4. You have a complex and large object model that has to support changing the object model while developing. The solution is an OODB. Gemstone is the large and proven commercial offering. It has a free version for smaller databases (4GB data, 1 core, 1G ram), and has proven scalability to 500 machines. Magma is an open source OODB, seeing active development and growing more and more advanced functionality. Laurent Laffont On Wed, Feb 17, 2010 at 3:07 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > No :) Thanks for the link ! > > Laurent Laffont > > > > On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan(a)stack.nl>wrote: > >> Hello Laurent, >> >> I assume you are aware of: >> >> http://www.seaside.st/documentation/persistence >> >> Stephan >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Feb. 17, 2010

Re: [Pharo-project] databases

by laurent laffont

No :) Thanks for the link ! Laurent Laffont On Wed, Feb 17, 2010 at 2:23 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hello Laurent, > > I assume you are aware of: > > http://www.seaside.st/documentation/persistence > > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 17, 2010

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort

by Marcus Denker

On Feb 17, 2010, at 2:13 PM, Lukas Renggli wrote: >> #sort you mean? Not yet... we either need to add it in Pharo, fix it >> in the one click, or add it to the Grease package. > > OrderedCollection>>#sort and OrderedCollection>>#sort: is already part > of Pharo 1.1. The Seaside tests pass in Pharo 1.1. > > I understand and I agree with Pharo not to implement #sort and #sort: > in SequenceableCollection, because it does not make sense for most > subclasses. SortedCollection, Heap and Interval are already sorted; > and for LinkedList sorting does not really make sense. > > So I don't really know what to do to fix the Seaside test. We could > ask the Pharo guys to integrate OrderedCollection>>#sort and > OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too > late? > I think we can add that 1.0 For 1.1, there are some changes for generalizing and cleaning sort on the bugtracker that I plan to look at (at some point). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 17, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore

by Schwab,Wilhelm K

I agree that there is a contradiction between being self-sufficient and enjoying the benefits of central repositories. I have already encountered show-stoppers for Windows installation of Rio (Linux to the rescue) and was forced to create a local-only mode in my current loader. It is one thing to be hobbled by a temporary outage of a free service, but it is quite another to be vulnerable to deletions such as described below. One option would be for the files to go in but not come out w/o some effort, or perhaps for files to be uploaded in (hopefully) consistent groups that the owner can delete as an all-or-nothing set?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Yanni Chiu Sent: Wednesday, February 17, 2010 12:00 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore Dale Henrichs wrote: > ----- "Yanni Chiu" <yanni(a)rogers.com> wrote: > > | BTW, since all FFI-Examples packages were removed from the FFI > | repository, even Metacello "versions" would fail because the package > | is no longer there. > > This underscores Lukas' argument that you need to create your own repository of packages that you use. I don't understand how this jives with Metacello. If I depend on a Metacello configuration then I inherit the repository dependencies of that configuration -- unless I maintain my own copy of the configuration and the packages it references. > As far as I am concerned, it is a cardinal sin to remove packages from a public repository ... I agree. I assume the reason for removing the package was to eliminate confusion caused when the latest version of the package is loaded, but doesn't work, because none of the code should be there. Another approach might have been to delete all the classes/methods from the package, and submit it as the latest version. Though I'm not sure Monticello would accept an "empty" package. > We'll have to mark the earlier versions of FFI as broken in the Metacello config unless we can recover the older files... I probably can find an old version in a package-cache, but the repository for FFI is on http://source.squeakfoundation.org, which seems to be the active code base for Squeak (correct me if I'm wrong). -- Yanni _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 17, 2010

Re: [Pharo-project] databases

by Stephan Eggermont

Hello Laurent, I assume you are aware of: http://www.seaside.st/documentation/persistence Stephan

Feb. 17, 2010

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort

by Lukas Renggli

> #sort you mean? Not yet... we either need to add it in Pharo, fix it > in the one click, or add it to the Grease package. OrderedCollection>>#sort and OrderedCollection>>#sort: is already part of Pharo 1.1. The Seaside tests pass in Pharo 1.1. I understand and I agree with Pharo not to implement #sort and #sort: in SequenceableCollection, because it does not make sense for most subclasses. SortedCollection, Heap and Interval are already sorted; and for LinkedList sorting does not really make sense. So I don't really know what to do to fix the Seaside test. We could ask the Pharo guys to integrate OrderedCollection>>#sort and OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too late? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 17, 2010

Re: [Pharo-project] databases

by Dave Woodward

On 2/17/10 6:46 AM, GermÃ¡n Arduino wrote: > > > 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com>> > > Hi, > > I would like to learn on Pharo + databases. I've seen there's > several solutions in both object and relational databases. > - Which (open source) object database should I start with (most > used) ? > > > > Magma is the option I select, but not tried yet on Pharo. Magma 1.0v43 works on Pharo, I'm moving a production system to it (still in development but I haven't had any problems out of the normal kind caused by me mucking around). From what I've seen Magma is the only open source object database in Squeak that is still maintained and actively used. There is also GOODS, but I don't think that's being maintained (so you're on your own getting it to work). As for an object database that can be accessed from BOTH Squeak and Ruby... ? I think you might consider Gemstone/S, because their new Ruby product Maglev also runs on top of their Smalltalk runtime, but I have no idea how objects created using Smalltalk (like from GLASS) would show up in Maglev. Might be an interesting experiment! > > Cheers. > GermÃ¡n. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Dave Woodward ................................................... www.promedmedical.net 317.332.6438 davewoodward(a)promedmedical.net

Feb. 17, 2010

[Pharo-project] databases

by Torsten Bergmann

Hi Laurent, I think this topic or persistence in general would require more than one screencast to show people several options (like using the native drivers/database) up to higher level stuff mit OR mapping (Glorp) or Gemstone. Also well known (Oracle, MySQL, ...) vs. alternative databases (Magma, CouchDB, ...) or persistence in XML, ReferenceStreams, ... Maybe SQLite could be used for a simple database example using Pharo and SQL. There is a metacello config for it: http://n4.nabble.com/ANN-SQLite3-wrapper-updated-with-tests-td1294969.html Have a look at the test cases to see some code. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 17, 2010

Re: [Pharo-project] databases

by GermÃ¡n Arduino

2010/2/17 laurent laffont <laurent.laffont(a)gmail.com> > Hi, > > I would like to learn on Pharo + databases. I've seen there's several > solutions in both object and relational databases. > - Which (open source) object database should I start with (most used) ? > Magma is the option I select, but not tried yet on Pharo. Cheers. GermÃ¡n.

Feb. 17, 2010