May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Smalltalkhub needs your quick in the ass :)

by laurent laffont

To migrate a whole repository from SqueakSource to SmalltalkHub, here's how I've done (maybe there's a better way): Gofer it squeaksource: 'ProfStef'; package: 'ProfStef-Core'; package: 'ProfStef-Help'; package: 'ProfStef-Tests'; fetch. Gofer it url: 'http://smalltalkhub.com/mc/LaurentLaffont/ProfStef/main' username: 'LaurentLaffont' password: 'mysecretpassword'; package: 'ProfStef-Core'; package: 'ProfStef-Help'; package: 'ProfStef-Tests'; push. Laurent On Tue, May 15, 2012 at 11:23 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > Nicolas released internally a new version of smalltalkhub and everyday he > finds a good reason not to announce it. > So please do us a favorâ¦ create some projects and push your code there so > that nicolas gets the feel > of a alive and kicking smalltalkhub :) > > Stef >

May 15, 2012

Re: [Pharo-project] Pharo Kernel 2.0 Reload by Fuel activated

by StÃ©phane Ducasse

truly excellent Next week we should also sit with guillermo, ben and you so that we see how we can merge for the bootstrap because Guillermo has a 1.3 mb image now. Stef On May 15, 2012, at 9:21 AM, Pavel Krivanek wrote: > Hi, > > we were able to activate the job Pharo Kernel 2.0 Reload by Fuel [1] > and related tests [2]. In short, this job takes latest Pharo Kernel > image and with the only single script [3] it creates working Pharo > Core image. It uses code and some data previously exported by a > supporting job [4] [5]. > > The resultant image is not production-ready because Fuel Package > Loader currently doesn't work with changes file. > > The next step that should be quite simple is to do the same with an > image without Compiler :-) > > [1] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… > [2] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… > [3] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… > [4] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… > [5] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… > > Cheers, > -- Pavel >

May 15, 2012

Re: [Pharo-project] Problem with RPackage and MCPackage integration

by StÃ©phane Ducasse

On May 15, 2012, at 11:27 AM, Mariano Martinez Peck wrote: > Hi guys. I am experimenting with exporting Monticello packages with Fuel. What I am doing so far is I download somehting with metacello, then I query all the needed packages and its order and then I serialize that. To do that, I am using (PackageInfo named: 'XXX') and then I ask #classes or #extensionMethods. > The problem is that #extensionMethods is incredible slow: > > extensionMethods > ^ (Smalltalk allClassesAndTraits, (Smalltalk allClasses collect: [:c | c class])) gather: [:classOrTrait | self extensionMethodsForClass: classOrTrait] > > .... I THINK that RPackage store extension methods and tehrefor I guess it could be much faster. > > The problem I have now with RPackage is this. I have a MCPackage called 'Fuel'. And then I have different categories inside that package such as 'Fuel-Core', 'Fuel-Clusters'. 'Fuel-Stream', etc. > > (MCPackage named: 'Fuel') correspondingRPackage classes -> () > (RPackageOrganizer default packageNamed: 'Fuel') classes -> () I do not see why the system does not have an RPackage with Fuel if you have a working copy for it. Now I cannot debug that farâ¦ >From time to time you should come to visit us. Stef > > so i am getting an empty collection instead of the classes. If I enter to a category, it is fine, for example: > (RPackageOrganizer default packageNamed: 'Fuel-Clusters') classes -> a Set(FLGlobalSendCluster FLGlobalClassCluster FLObjectCluster FLCluster FLVariablesMapping FLWordObjectCluster FLIteratingCluster FLGlobalValueCluster FLVariableObjectCluster FLBitsObjectCluster FLGlobalCompiledMethodCluster FLPrimitiveCluster FLGlobalAssociationCluster FLPositiveSmallIntegerCluster FLGlobalCluster FLPointerObjectCluster FLWellKnownObjectsCluster FLMethodContextCluster FLSmallIntegerCluster FLUInt16Cluster FLGlobalClassSideCluster FLByteObjectCluster FLSubstitutionCluster FLNegativeSmallIntegerCluster FLHookPrimitiveCluster FLFixedObjectCluster FLWeakVariableObjectCluster) > > > so...how can I get a RPackage for my MCPackage/PackageInfo called 'Fuel' ? > > thanks > > > -- > Mariano > http://marianopeck.wordpress.com >

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

> > It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;) This is not unstable, this is bleeding edge. When I see how the other applications are crashing. I think that Pharo in alpha is quite stable. Gary did it with pinesoft and he is not toying so this is possible. Moose people decide when the version is getting less changing and it works. Stef

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

>> It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do >> seriuous development you won't beusing Pharo 2.0, will you? ;) > > I talked about that few days ago with GermÃ¡n. The problem is not in > using of unstable version. The problem is that it is very easy to stop > to be in touch with Pharo now and within one year when the current > unstable version will become stable the developers will face to very > different system. That is one of the reason why GermÃ¡n choose Cuis for > his current projects. Developers want simple predictable system. Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. And and and again again again and again who is concerned by RPackage vs PackageInfo, systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. I find that a totally false argument. > I do not think that the way out from this is to slow down. On the > contrary. We simply have to do this era of a lot of big changes as > short as possible ;-)

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

>> I think we have to improve the foreknowledge about what will happen, > why it will happen, what it will mean, what are the related issues > etc. > I in most cases I have no clue about changes in package structure of > the image that are being performed and that require changes in Pharo > Kernel processing, initialization etc. As an example I can mention > recent CodeImporter integration. > > I like the improvements rate but as the side effect it makes Pharo > less attractive platform for serious development. Why? People should not develop in the bleeding edge of the system or at least they should know what they do. I use pharo bleeding edge daily and fix as soon as something goes wrong. Today we even improve Monticello browser feedback and version browsing. Stef

May 15, 2012

[Pharo-project] Smalltalkhub needs your quick in the ass :)

by StÃ©phane Ducasse

Hi guys Nicolas released internally a new version of smalltalkhub and everyday he finds a good reason not to announce it. So please do us a favorâ¦ create some projects and push your code there so that nicolas gets the feel of a alive and kicking smalltalkhub :) Stef

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by StÃ©phane Ducasse

Thanks Busy stef (but escaping boring meetings for a while). > On Sun, May 13, 2012 at 5:31 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > It depends of the usage of copy... > If the purpose is to modify a class, then the copy will replace the > original in a short future, and you should better keep the > associations untouched and only change them in a final Namespace at: > className put: theClassCopy... > If the purpose is to create a new class, then yes, there's some > additional operation required. > But where will you bind the new association? Another namespace? > > I agree. If copy is supposed to create a fully-fledged copy then the Class>>copy method is broken in several ways: > - As Mariano noted, it doesn't copy CompiledMethods nor update their methodClass associations. > - It doesn't add the copy to the superclass's subclass > - the class has the same name as the original but isn't reachable from Smalltalk > > But if the use case is some temporary transformation, as Nicholas notes, then the method is ok. Except that "copy" is a really unhelpful name. This is a specialised copy for certain circumstances and the selevtor should reflect that. Anyone know what the use case this copy was written for is? > > It's clearly for the ClassBuilder. See SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder. SO the comment could be more helpful, e.g. > > copy > "Answer a copy of the receiver without a list of subclasses. > This copy is used by the ClassBuilder when mutating classes on redefinition. > (SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder)" > > find attached. > > > > > Nicolas > > 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: > > yes, this looks like a bug. > > But i would recompile all methods of copied class, so all these > > nuances is handled. > > > > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> > >> > >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> > >>> > >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: > >>> > >>> > Hi guys. The last literal of a instance-side compiled method always > >>> > points to the SAME (#==) association of the class in Smalltalk global. > >>> > The literals of a compiled method that refer to class variables refer to > >>> > the same association (#==) of the classPool of its class: > >>> > > >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == > >>> > (GRPlatform classPool associationAt: #Current). -> true > >>> > > >>> > However, if I do a copy of the class: > >>> > > >>> > | copy | > >>> > copy := GRPlatform copy. > >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool > >>> > associationAt: #Current). > >>> > > >>> > this is not true anymore. Of course, you can see this because of the > >>> > Class >> #copy implementation: > >>> > > >>> > So my question is....is #copy breaking the contract (and therefore it > >>> > has to be fixed) or this is not mandatory for the system (as it is with the > >>> > last literal pointing to classes)? > >>> > >>> since namespace binding are shared between method literal and namespace, I > >>> think that this is a bug. > >>> > >> > >> I did this workaround > >> > >> Class >> rebindClassVariablesInMethods > >> > >> self class methodDict valuesDo: [ :aCompiledMethod | > >> 1 to: aCompiledMethod numLiterals-2 do: [ :index | > >> | literal | > >> literal := aCompiledMethod literalAt: index. > >> literal isVariableBinding ifTrue: [ > >> (self innerBindingOf: literal key) ifNotNil: [:aBinding | > >> aCompiledMethod literalAt: index put: aBinding > >> ] > >> ] > >> ] > >> ] > >> > >>> > >>> Stef > >>> > > >>> > Thanks, > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > -- > best, > Eliot > > > > > -- > best, > Eliot > > > > > -- > best, > Eliot > > <Class-copy.st>

May 15, 2012

Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes

by StÃ©phane Ducasse

Thanks Esteban for your cool slides: https://gforge.inria.fr/frs/download.php/30774/lawsuit3slides.pdf https://gforge.inria.fr/frs/download.php/30773/ibizlog3slides.pdf We want more! Stef

May 15, 2012

[Pharo-project] Pharo 1.3 - Build # 35 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

May 15, 2012