April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Actions done in 1.3

by Noury Bouraqadi

On 7 avr. 2011, at 09:53, Marcus Denker wrote: > > I want a 1.3 that is in "we could release today if we wanted" 90% of the time. > > Yes! What about integrating only things that do not break tests? I mean : -have a DEV version with all what we want -having a "STABLE" version where all tests are green. Fixes/extensions are migrated from the to STABLE each time the DEV tests go green. The lifecycle would be a sequence of iterations. Each iteration would be similar to something like what Laurent suggested: -Additions to DEV (fixes/enhancements/whatever) -Fixing DEV -Committing to STABLE Noury http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

April 7, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #11 on issue 2559 by marcus.d...(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 The interesting thing is that it it just takes 200Kb more space. I can live with that! (I took a version with, one without. Recompiled, did a #releaseclean in both and the difference is 14802344 vs. 15007540 for saved images of the same window size. One problem that I see is that we need to change the metric of Cog when not to JIT. Right now it does not JIT when the method is too large, and that "too large" is defined as having more than X literals (60, I think).

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by merlyn＠stonehenge.com

>>>>> "Geert" == Geert Claes <geert.wl.claes(a)gmail.com> writes: Geert> That's where the ConfigurationOf...'s and Metacello come in to ensure Geert> dependencies, versions and Smalltalk implementations. I guess I'm thinking more of development. The question we were facing about Squeaksource (and don't yet know if this applies to SmalltalkHub) is how I as a developer keep my Squeak contributions separate from the same package being developed for Pharo for the packages that overlap but require different versions. Is there some way of tagging a Monticello package in SmalltalkHub as to which releases the development line is intended for? Note that I've just barely woken up, so if this sounds as confusing as it is to me right now, it probably is confused. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

April 7, 2011

Re: [Pharo-project] Metacello chapter

by Noury Bouraqadi

I don't know how other authors work. Not having write access to the repo, I have to fork, make my changes and then ask the admin of the repo (you + who else) to pull (=> merge) changes I made. Noury On 7 avr. 2011, at 09:18, StÃ©phane Ducasse wrote: > and so what? I still do not understand it. > may be noury should be added to the project. > > > On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote: > >> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3 >> >> On Thu, Apr 7, 2011 at 3:10 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>>> Cool. BTW, I have a pending pull request on the Socket chapter. >>> >>> what is it? >>> what do you mean? >>> what do you need? >>> >>> Stef >>> >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ > > Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

April 7, 2011

Re: [Pharo-project] relational database and id field

by Benoit St-Jean

One more remark, Since you're storing objects into a RDBMS, I guess what you're trying to express into "the relational world" is a notion of pointer (such as an object contains a collection of something in one of its instance variable, or a child has a mother kinda relationship, link). In that case, to save you headaches and lots of "weird object-oriented modeling", an oid (object id) is what is used normally. Any sequence (the shorter the better, don't use GUID for instance!) would do... ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Alexandre Bergel <alexandre.bergel(a)me.com> To: Benoit St-Jean <bstjean(a)yahoo.com> Cc: Pharo-project(a)lists.gforge.inria.fr Sent: Thu, April 7, 2011 9:49:11 AM Subject: Re: [Pharo-project] relational database and id field > Normally, you should always have a primary key to uniquely identify a record in >a database table. If you have an attribute (or a set of attributes) that can >uniquely identify your ComicBook, you don't need an id field. BUT, if you tell >me you're going to store lots and lots and lots of those ComicBook instances, >having an id (integer) as the primary key has potential non-negligeable >advantages over, say, something like a name. Mainly because an id (let's >suppose it's an INT) takes way less storage than say a name (VARCHAR(30) for >instance) and thus more index records can fit into the key buffer in memory. Ok, I understand. > 1) yes, always provide a primary key > 2) if you have already A primary key (even a composite one) > 2a) if you need performance and are gonna store LOTS of those objects, the >smaller the key the better so you could create a surrogate key (the id key) >instead of using the "real" primary key > 2b) if performance is not an issue, you can use what is already available >that uniquely identifies your object (row) in the database table Thanks! > P.S. Are you using a particular OO-RDBMS framework? No, I am correcting a student thesis :-) I would probably not use SQL if I had to :-) Cheers, Alexandre > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > From: Alexandre Bergel <alexandre.bergel(a)me.com> > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thu, April 7, 2011 9:19:03 AM > Subject: [Pharo-project] relational database and id field > > Hi! > > Since there are some experts in databases here, I ask a general question about >it. > Assume that I have to use a relational database to store, let's stay instances >of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] relational database and id field

by laurent laffont

On Thu, Apr 7, 2011 at 2:39 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Thu, Apr 7, 2011 at 3:19 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > >> Hi! >> >> Since there are some experts in databases here, I ask a general question >> about it. >> Assume that I have to use a relational database to store, let's stay >> instances of Stef's ComicBook class. >> Should the class ComicBook have a field id to uniquely identify a book? >> > > I always put an id field. All cases without id I've encountered were always > a pain. > > I don't have any argument against unique id. > > And if you are thinking about ISBN: - ISBN "should" be unique. In reality they're not. Because we communicate with software that have bugs. People who enter ISBN have bugs too. And when you mashup datas you always get soon or later 2 different documents with same ISBN. - documents edited before 1972 and not reedited after don't have ISBN. Laurent. > Laurent. > > > >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >

April 7, 2011

Re: [Pharo-project] relational database and id field

by Henrik Sperre Johansen

On 07.04.2011 15:19, Alexandre Bergel wrote: > Hi! > > Since there are some experts in databases here, I ask a general question about it. > Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre IANAE, but my definitive answer would be... Maybe. :) Depends on what other tables are in the database, their relationship with the ComicBook table,which you intend to query often, what you intend to query them for, etc. Cheers, Henry

April 7, 2011

Re: [Pharo-project] relational database and id field

by Benoit St-Jean

Hi Alexandre, Normally, you should always have a primary key to uniquely identify a record in a database table. If you have an attribute (or a set of attributes) that can uniquely identify your ComicBook, you don't need an id field. BUT, if you tell me you're going to store lots and lots and lots of those ComicBook instances, having an id (integer) as the primary key has potential non-negligeable advantages over, say, something like a name. Mainly because an id (let's suppose it's an INT) takes way less storage than say a name (VARCHAR(30) for instance) and thus more index records can fit into the key buffer in memory. To be brief 1) yes, always provide a primary key 2) if you have already A primary key (even a composite one) 2a) if you need performance and are gonna store LOTS of those objects, the smaller the key the better so you could create a surrogate key (the id key) instead of using the "real" primary key 2b) if performance is not an issue, you can use what is already available that uniquely identifies your object (row) in the database table P.S. Are you using a particular OO-RDBMS framework? ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Alexandre Bergel <alexandre.bergel(a)me.com> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> Sent: Thu, April 7, 2011 9:19:03 AM Subject: [Pharo-project] relational database and id field Hi! Since there are some experts in databases here, I ask a general question about it. Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. Should the class ComicBook have a field id to uniquely identify a book? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] relational database and id field

by laurent laffont

On Thu, Apr 7, 2011 at 3:19 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > Since there are some experts in databases here, I ask a general question > about it. > Assume that I have to use a relational database to store, let's stay > instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > I always put an id field. All cases without id I've encountered were always a pain. I don't have any argument against unique id. Laurent. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

April 7, 2011

[Pharo-project] Issue 3970 in pharo: Finder broken with last updates related to MorphTreeMorph

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3970 by marcus.d...(a)gmail.com: Finder broken with last updates related to MorphTreeMorph http://code.google.com/p/pharo/issues/detail?id=3970 Finder broken with last updates related to MorphTreeMorph

April 7, 2011