October 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11009

by StÃ©phane Ducasse

11009 ----- Issue 1267: mantis 0006732: Undo polygon painting cause drawing not functioning anymore Jorge

Oct. 20, 2009

Re: [Pharo-project] #1339 - ODBC crashes vm

by Mariano Martinez Peck

On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > This one is caused by an initialization bug of some sort, the > byteSizes of ODBC-structs are incorrect. > > In short, the solution is to do: > ExternalStructure allSubclassesDo: [:each | each compileFields] > after you load a package which defines ExternalStructure subclasses > (like ODBC does). > > Hi Henrik! Nice to see you arround ;) In SqueakDBX I use FFI, I have subclasses of ExternalStructure and I don't remember having to do that. The only thing I do in those subclasses is to implement a class side method initialize like this: initialize super initialize. self defineFields And then, if you see defineFields you will se that at the end, it does a compileField... You can see defineFields in FFI documentation: http://wiki.squeak.org/squeak/2426 So, in my opinion a better solution may be this. What do you think ? Cheers Mariano > For some reason, in an image after loading: > > ExternalStrucure >> byteSize > "Return the size in bytes of this structure." > ^self compiledSpec first bitAnd: FFIStructSizeMask > > SQLHENV compiledSpec first: 65536 > FFIStructSizeMask: 65535... > > So basically, when you allocate the struct a handle of a ByteArray of > size byteSize, you'll sooner or later you access unallocated memory > and crash. > Recomputing all the compiledSpecs with the doit above leads to the > correct sizes (4 in the case of SQLHENV) being stored in the > compiledSpecs. > > Either way, not raising an error when the size for a struct when > and'ed with the mask, but instead causing a silent crash later on > just seems bad bad bad to me. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 20, 2009

[Pharo-project] [update 1.1] #11008

by StÃ©phane Ducasse

11008 ----- Issue 1280: mantis 7258: Dictionary asSet does not behave like a Set Jorge

Oct. 20, 2009

[Pharo-project] [update 1.1] #11007

by StÃ©phane Ducasse

11007 ----- Issue 1279: mantis 6482: Interval storeOn: incorrect for some ScaledDecimal Jorge (sent from Stef mac)

Oct. 20, 2009

Re: [Pharo-project] scriptloader>>loadComanche

by StÃ©phane Ducasse

Yeap this is what I mean with Universes. Stef On Oct 20, 2009, at 1:40 PM, Damien Cassou wrote: > On Tue, Oct 20, 2009 at 9:15 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Damien I would really like to see Universes coming back. Do we have >> any chance getting it back? > > No, not in the sense of what was the previous Universes system. What > we really want: > > - a repository on SqueakSource > - a package in that repository with a single class > - this class defines one method per package we support > - each method as a small script to load the package (best thing for > the method would be to load the loader of the particular package and > launch it) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 20, 2009

Re: [Pharo-project] '' asNumber -> 'Reading a number failed'

by csrabak＠bol.com.br

Em 20/10/2009 10:04, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> escreveu: > 2009/10/20 : >> I don't see where are we willing to arrive at. >> >> '' asNumber gives zero in several other Smalltalks (Dolphin and VW, >> for example) and used to work as Mariano mentions in earlier versions >> of Pharo (which makes me surmise is the way Squeak worked as well). >> >> So attempting addressing Nicolas point: the context where '' can be >> expected is when reading text from some other source (mainly text from >> a file) into you Pharo application. >> >> A library API has to have a reasonable balance between an excruciating >> "conceptual right" set of calls and the "principle of minimum >> surprise" for the corner cases in general. >> >> From this discussion, are we saying that for now on in order to have >> strings converted into numbers if we want to have the behaviour '' >> returning zero we shall change from '' asNumber to '' asNumberOrZero >> and this method will call a more general method like this? >> >> Number>>asNumberOrZero >> ^self asNumberOr: 0 >> >> And >> >> Number>>asNumberOr: aNumber >> ^Number readFrom: self ifFail: [^aNumber] >> >> Just my .0199999.... >> >> > > If this is an identified inter-dialect feature, then some applications > will rely on it, and then yes we SHOULD maintain the feature. Yes I think the crux is identifying if it is a feature that has become a 'de facto standard' or not. . . > > But we can in no way keep all the silly other cases. > However, did you try these in other dialects FWIW: > ' ' asNumber. Returns 0 in VW and an exception in Dolphin (note that if you put '' instead of ' ' in Dolphin it returns zero instead) > 'a' asNumber. Returns 0 in VW and an exception in Dolphin. > 'b2' asNumber. Returns 0 in VW and an exception in Dolphin. > etc... ST/X generates exceptions for all the cases above. > > I guess VW & Dolphin should fail in all these cases... > Squeak did not and would answer 0 in most cases, and that's what I > don't want to see anymore... > > Another question is should we authorize non blank trailing characters > ? I think no. > '2r' asNumber. > '2 + 3' asNumber. > etc.. > We had a discussion about this in another thread but we did not arrived at a final position if memory serves me. [snipped] HTH -- Cesar Rabak

Oct. 20, 2009

[Pharo-project] Fwd: System-Settings

by StÃ©phane Ducasse

Begin forwarded message: > From: Alain Plantec <beranger22(a)gmail.com> > Date: October 20, 2009 1:39:07 PM GMT+02:00 > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: System-Settings > Reply-To: alain.plantec(a)univ-brest.fr > > In InBox > > Name: System-Settings-AlainPlantec.96 > Author: AlainPlantec > Time: 20 October 2009, 1:37:48 pm > UUID: efcd89d0-129a-402e-83cd-bfc0ab84e270 > Ancestors: System-Settings-alain_plantec.95 > > empty log message >

Oct. 20, 2009

[Pharo-project] Fwd: issue 1331

by StÃ©phane Ducasse

Begin forwarded message: > From: Johan Brichau <Johan.Brichau(a)uclouvain.be> > Date: October 20, 2009 2:03:59 PM GMT+02:00 > To: Stephane Ducasse <stephane.ducasse(a)inria.fr> > Subject: issue 1331 > > I created and tagged this one as for 1.1 but you might want to > include it in 1.0 because it's a basic bug fix > > http://code.google.com/p/pharo/issues/detail?id=1331 > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > >

Oct. 20, 2009

Re: [Pharo-project] [ANN] Pharo Core 1.1 alpha

by Marcus Denker

On 19.10.2009, at 21:05, Laval Jannik wrote: > Hi, > > It would be cool to have the new source file in this package and/or > available on the website. > I added it to the gforge. It's linked on pharo-project, too. http://gforge.inria.fr/frs/download.php/24391/PharoV10.sources.zip

Oct. 20, 2009

[Pharo-project] [update 1.1] #11006

by StÃ©phane Ducasse

11006 ----- Issue 1276: mantis 6972: [clean-up] TextAlignment does not use TextConstants Jorge (using the mac of stef)

Oct. 20, 2009