- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [Metacello] Re: problem with metacello in 1.2
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: October 23, 2010 9:31:33 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: [Metacello] Re: [Pharo-project] problem with metacello in 1.2 > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: October 23, 2010 9:31:23 PM GMT+02:00 > To: metacello(a)googlegroups.com > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Metacello] Re: [Pharo-project] problem with metacello in 1.2 > > > yes we spent some time trying to find what would be the problem > but we could not identify one version (image, vm) on which we got constantly the problem accross variation. > > Stef > On Oct 23, 2010, at 8:09 PM, Tudor Girba wrote: > >> Several people had the same problem today: Fabrizio and Jorge in Bern, and Jannik in Lille. And they had it with different versions of Pharo 1.2. >> >> Cheers, >> Doru >> >> >> On 23 Oct 2010, at 19:05, Mariano Martinez Peck wrote: >> >>> >>> >>> On Sat, Oct 23, 2010 at 7:05 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Wierd...now I have the same problem :( >>> >>> >>> On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> I think you were having a problem with the internet connection. Here it is fine. >>> Try again ;) >>> >>> 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> >>> Hi all, >>> i was trying to make Moose loadable into a 1.2 i did try to run the configuration of Moose and i got an error at the very beginning caused by the configuration of metacello. Am i missing something or it actually should work? I did expect to have problem but not with the configuration of metacello. >>> >>> I'm using a >>> >>> Pharo image 12203 on a Squeak4.2.5beta1U VM >>> >>> To reproduce the error just open the image and execute in a workspace: >>> >>> Gofer new >>> squeaksource: 'Moose'; >>> package: 'ConfigurationOfMoose'; >>> load. >>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >>> >>> Attached the log. >>> >>> Thanks, >>> Fabrizio >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> > > > >

1 0

[Pharo-project] Object>>at:modify:???
by stephane ducasse Oct. 23, 2010

Oct. 23, 2010

I would like to deprecate the following method since nobody use it. What do you think? Stef

3 3

[Pharo-project] problem with metacello in 1.2
by Fabrizio Perin Oct. 23, 2010

Oct. 23, 2010

Hi all, i was trying to make Moose loadable into a 1.2 i did try to run the configuration of Moose and i got an error at the very beginning caused by the configuration of metacello. Am i missing something or it actually should work? I did expect to have problem but not with the configuration of metacello. I'm using a Pharo image 12203 on a Squeak4.2.5beta1U VM To reproduce the error just open the image and execute in a workspace: Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault Attached the log. Thanks, Fabrizio

3 4

Re: [Pharo-project] Pavel can you check :)
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

When I clicked on a package, it got downloaded to the package cache using the writeDefinitions: method writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initializers := Dictionary new. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. (Class superclassOrder: (initializers keys collect: [:each | Smalltalk classOrTraitNamed: each])) do: [:class | stream nextPutAll: (initializers at: class name) contents ]. Now it is bugging because initializers keys could contain a class that is not in the image and then put nil in the set The previous version of the method was: writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initStream := String new writeStream. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. stream nextPutAll: initStream contents. - The previous version did not save initializers or may be different - Now the changes does not take into account classes that are not in the image. And this one should still be saved On Oct 23, 2010, at 12:22 PM, StÃ©phane Ducasse wrote: > Apparently when we browse > Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) > > we get a problem because there is a nil in the set. > > Can you have a look? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] "suggest" for the sprint
by Mariano Martinez Peck Oct. 23, 2010

Oct. 23, 2010

I also agree with Marcus idea: 'lets integrate much make us be more productive and progress faster'. I would love to have the Benjamin work. - Remove "Messages Names" and "Method FInder" and put his new tool. - Put his new changes browser. I would be really really nice to have this, even if it is not perfect yet. People may start to use it, report issues and give feedback. Thanks Mariano

1 0

[Pharo-project] Loading FFI into Pharo?
by Friedrich Dominicus Oct. 23, 2010

Oct. 23, 2010

In the end I'm trying to get ODBC running Pharo 1.1. I checked the docs and this should work: ScriptLoader loadFFI. for loading the FFI stuff. If I try that I get the message that this selector is unkwown. What am I supposed to do to get it known? Regards Friedrich

5 11

[Pharo-project] fix for smallDebugIcon
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

http://code.google.com/p/pharo/issues/detail?id=3146

1 0

Oct. 23, 2010

smallDebugIcon "Answer a small debug icon." ^self smallDebugIcon Should be turned into ^ self smallErrorIcon Stef

1 0

Oct. 23, 2010

This is in 1.2 :) Stef On Oct 23, 2010, at 4:55 PM, jaayer wrote: > > > > > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- > >> Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. >> >> >> So I looked that the documentation of each of these classes: >> >> >> Association: I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. >> >> >> Magnitude: I'm the abstract class Magnitude that provides common protocol for objects that have >> the ability to be compared along a linear dimension, such as dates or times. >> Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >> Character and LookupKey. >> >> >> >> Based on this, I think this relation is conceptually WRONG. >> If the idea is to reuse code then composition should be used instead of inheritance. >> >> >> >> >> What do you think? >> >> Saludos! >> Nico. >> blog: nicopaez.wordpress.com > > There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] [update 1.2] #12209
by Marcus Denker Oct. 23, 2010

Oct. 23, 2010

12209 ----- Issue 3049: ClassBuilderTest Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing Issue 1981: Raising DuplicateError Exception in class builder Issue 2525: SystemWindow out of focus color wrong Issue 3143: To mark a test as an expected failure, one has to overwrite expectedFailures -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2