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

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

by Richard Durr

I recommend ids because without them, objects that are *equal* but not * identicall* do not really fit into the db. ^^ On Thu, Apr 7, 2011 at 3:43 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > That sounds like a one-to-many relationship. In those cases, I create two > tables, one for the singleton side and one for the many side. The many side > includes the key field(s) from the one side, and setting it/them establishes > the relationship. A unique ID field for the singleton side is helpful, > especially if things get edited. For many to many, I create a third table > that does nothing but associate keys between the two tables - I'm not even > sure if there is another way to do it?? > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [ > bstjean(a)yahoo.com] > Sent: Thursday, April 07, 2011 8:57 AM > To: Alexandre Bergel > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] relational database and id field > > 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<mailto: > alexandre.bergel(a)me.com>> > > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr<mailto: > 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 8, 2011

Re: [Pharo-project] An idea about Pluggable widgets

by Richard Durr

Why not do it like in Cocoa? http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Coco… On Thu, Apr 7, 2011 at 9:26 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/4/7 Alain Plantec <alain.plantec(a)yahoo.com>: > > Le 07/04/2011 19:23, Igor Stasenko a Ã©crit : > >> > >> button1 model: (self for: #performAction adapt: #turnRed) > >> button2 model: (self for: #performAction adapt: #turnGreen) > > > > yes, cool! > > It seems to be a good way to clean morphic > > cheers > > Alain > > > > > > Yes, it's delegating the job to specialized objects. > Specialized objects shall know how to. > That should prevent Morphs to be omniscient. > > My favourite name for the opposite pattern is "god programming": we > all encountered the thousand lines functions with tons of imbricated > if/switch logic in C or C// world, didn't we ? > > Somehow, Igor proposal reminds me the VW UI architecture were they > pushed the wrapper pattern very far. > Personnally, I found myself comfortable with it, but it had its detractors > too. > It would be interesting to analyze their arguments. > > cheers. > > Nicolas > >

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Alexandre Bergel

A good source of ideas: http://www.sdml.info/projects/srcml/ Alexandre On 8 Apr 2011, at 12:57, Javier PimÃ¡s wrote: > > > On Fri, Apr 8, 2011 at 1:08 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > What is tricky with analyzing C are macros and preprocessors directive. > srcML does a satisfactory job. But indeed, having a solution based on PetitParser is indeed promising. > > Yes, and I don't know what to do, and would like to know if you or someone else have any idea of how to solve it. I will think some approach, but if you have some idea to share it would be better so I go directly to a good solution. I'm thinking that to feed the parser I'll have to preprocess the string with another parser, and make a string to string conversion by having a set of defines and paths so that #includes and #ifdefs work. But probably I'll need a cache because the generated string will be huge. > > What do you think? > > Regards, > Javier. > > Cheers, > Alexandre > > > On 7 Apr 2011, at 23:53, Javier PimÃ¡s wrote: > > > by the way, the grammar is based on > > > > http://www.quut.com/c/ANSI-C-grammar-l-1998.html > > > > and > > > > http://www.quut.com/c/ANSI-C-grammar-y.html > > > > I'd be very grateful if you contribute to cover the full extent of it! > > > > > > On Fri, Apr 8, 2011 at 12:37 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > Hi, > > I took some time to start developing a C parser with PetitParser. I used the slides of the smalltalk school, they were pretty useful, and after some hours I have a very basic tokens scanner. The idea of this work is to be able to feed the parser with C headers and automagically get the C bindings done in smalltalk. > > > > Now I have to actually start doing something with the scanned code. How should I do that, all in the same class? What if I want to generate bindings for different kinds of FFIs? Other question, how should I handle preprocessing? (now there isn't any kind of preprocessing) > > > > You can see the code, download it and commit improvements to the repo at www.squeaksource.com/Bindings > > > > Anybody who is interested is welcomed to help in the development! > > > > Regards, > > Javier. > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > > > > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Nicolas Cellier

2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Well, whatever the underneath representation, one can expect roundedTo: > 2 to return a float with two decimals. > > I am only interested in roundedTo: to display in the DrGeo canvas > numbers. It was still funny to see sometimes number with 10 digits. > > Thanks for the info. > > > Hilaire > Previous versions were lying too by not printing a number that would be reinterpreted into itself. But if it is what you want, then you should use the old print message, #absPrintOn:base: Maybe it could be wrapped into a printApproximatelyOn: to be polymorphic with other numbers ? Nicolas > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > >

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Hilaire Fernandes

Well, whatever the underneath representation, one can expect roundedTo: 2 to return a float with two decimals. I am only interested in roundedTo: to display in the DrGeo canvas numbers. It was still funny to see sometimes number with 10 digits. Thanks for the info. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Nicolas Cellier

2011/4/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Once more, Floats are inexact. > Â Â 0.01 ~= 0.01s2 > The name #absPrintExactlyOn:base: is lying, it does not print exactly, > but it prints the shortest decimal representation than will be rounded > to the same Float when read back. > > To print it exactly, you need to use #printShowingDecimalPlaces: indeed. > As every finite Float is a represented internally as a Fraction with a > denominator being a power of 2, every finite Float has a decimal > representation with a finite number of decimals digits (just multiply > numerator and denominator with adequate power of 5, and you'll get the > digits). > > So try: > 0.01 printShowingDecimalPlaces: 59 > -> 0.01000000000000000020816681711721685132943093776702880859375 > Oh one thing I forgot, you wanna know how many digits you need after decimal point to print exactly ? Easy, (0.01 asTrueFraction denominator highBit - 1). Nicolas

April 8, 2011

Re: [Pharo-project] Issue 3971 in pharo: OBSystemBrowserAdaptor does not correctly find classes

by pharo＠googlecode.com

Comment #4 on issue 3971 by DougEdmu...(a)gmail.com: OBSystemBrowserAdaptor does not correctly find classes http://code.google.com/p/pharo/issues/detail?id=3971 I did find Ducasse in the classes. :) Attachments: find_class.png 16.0 KB

April 8, 2011

Re: [Pharo-project] Issue 3971 in pharo: OBSystemBrowserAdaptor does not correctly find classes

by pharo＠googlecode.com

Comment #3 on issue 3971 by renggli: OBSystemBrowserAdaptor does not correctly find classes http://code.google.com/p/pharo/issues/detail?id=3971 Ok, it is a subsequence (http://en.wikipedia.org/wiki/Subsequence) I am terribly sorry for using the wrong term.

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Nicolas Cellier

Pour enfoncer le clou, let's play a bit more with inexact representations: { ((2.8 asTrueFraction roundTo: 0.01 asTrueFraction) - (2.8 predecessor)) abs -> -1. ((2.8 asTrueFraction roundTo: 0.01 asTrueFraction) - (2.8)) abs -> 0. ((2.8 asTrueFraction roundTo: 0.01 asTrueFraction) - (2.8 successor)) abs -> 1. } detectMin: [:e | e key ] you get 0.0->1, which mean that: (2.8 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat = (2.8 successor) But remember: (2.8 asTrueFraction roundTo: 0.01 asTrueFraction) ~= (2.8 successor) It must be interpreted as: the nearest Float to (2.8 asTrueFraction roundTo: 0.01 asTrueFraction) is (2.8 successor). If you want to know how far it is, then get an idea with: ((2.8 asTrueFraction roundTo: 0.01 asTrueFraction) - (2.8 successor) asTrueFraction) asFloat -2.0816681711721685e-16 Nicolas 2011/4/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > +1. Â This seems like an extension of "never test equality on floats." > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Friday, April 08, 2011 1:14 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unexpected behavior of roundTo: > > Once more, Floats are inexact. > Â Â 0.01 ~= 0.01s2 > The name #absPrintExactlyOn:base: is lying, it does not print exactly, > but it prints the shortest decimal representation than will be rounded > to the same Float when read back. > > To print it exactly, you need to use #printShowingDecimalPlaces: indeed. > As every finite Float is a represented internally as a Fraction with a > denominator being a power of 2, every finite Float has a decimal > representation with a finite number of decimals digits (just multiply > numerator and denominator with adequate power of 5, and you'll get the > digits). > > So try: > 0.01 printShowingDecimalPlaces: 59 > -> 0.01000000000000000020816681711721685132943093776702880859375 > > You see that even if you try to execute the operation without rounding > error, then convert it back to Float, you get the error: > Â (2.8011416510246336 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat > -> Â 2.8000000000000003 > > When you perform the #roundTo: operations in Float inexact arithmetic, > you may accumulate more rounding errors, so the result may vary. > > If you want to round to an exact hundredth, then use exact arithmetic and try: > Â 2.8011416510246336 roundTo: 0.01s2 > > Hope it helps to consider Float for what they are, inexact but fast. > Don't put too much expectations on them. > > Nicolas > > 2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: >> It looks like a known issue: >> >> printShowingDecimalPlaces: placesDesired >> Â Â Â Â "This implementation avoids any rounding error caused by rounded or >> roundTo: " >> Â Â Â Â ^ self asTrueFraction printShowingDecimalPlaces: placesDesired >> >> >> >> Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : >>> 2.8011416510246336 roundTo: 0.01 >>> >>> returns >>> >>> Â 2.8000000000000003 >>> >>> >>> Tested with 1.2 >>> >>> >>> Should I fill a ticket, I don't see anythings similar? >>> >>> Hilaire >>> >> >> >> -- >> Education 0.2 -- http://blog.ofset.org/hilaire >> >> >> > > >

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Nicolas Cellier

Yes nice example to exhibit in school This again happens even if performed exactly (then rounded to nearest Float) (2.8 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat As soon as you write 0.01 instead of (1/100) or (0.01s2), the worm is in the fruit. Nicolas 2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Even better: > > 2.8 truncateTo: 0.01 > -> 2.8000000000000003 > > > Le 08/04/2011 18:52, Hilaire Fernandes a Ã©crit : >> It looks like a known issue: >> >> printShowingDecimalPlaces: placesDesired >> Â Â Â "This implementation avoids any rounding error caused by rounded or >> roundTo: " >> Â Â Â ^ self asTrueFraction printShowingDecimalPlaces: placesDesired >> >> >> >> Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : >>> 2.8011416510246336 roundTo: 0.01 >>> >>> returns >>> >>> Â 2.8000000000000003 >>> >>> >>> Tested with 1.2 >>> >>> >>> Should I fill a ticket, I don't see anythings similar? >>> >>> Hilaire >>> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > >

April 8, 2011