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

Re: [Pharo-project] support for flattening-out traits for export?

by Mariano Martinez Peck

Thanks Adrian. BTW, there is no way to fileout a whole Monticello package? it seems I have to manually do a fileout of each category, not package :( Eliot: we were discussing today with Martin and maybe we will get rid of Traits. The truth is that in our case we use them mostly for tests and we think that with a good refactor we can avoid using them without duplicating too much code. In fact, we suffer several problems with traits and the integration with tools like Monticello. And even more it makes porting more complicated. We cannot code that much now because we are preparing a paper for ESUG but we will give it a try. Taking into account all your knowledge and experience in general and with Parcels, we will LOVE to listen your feedback for Fuel. Cheers Mariano On Tue, Jun 7, 2011 at 12:29 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > IIRC this can be achieved with two small changes: > > - Comment out the line "method isLocalSelector" from PackageInfo>>methods. > This will flatten the traits into the classes, i.e., make all methods of a > class being stored even if they come from a trait. > > - In addition you probably need to change PackageInfo>>classes to filter > out all traits (like ... reject: #isTrait). > > HTH, > Adrian > > On Jun 7, 2011, at 08:11 , Mariano Martinez Peck wrote: > > > On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda(a)gmail.com > >wrote: > > > >> Hi All, > >> > >> if I want to export a package (Fuel!!) to a dialect without traits is > >> there anything to help me remove the trait info and just file-out the > >> composed code? > >> > >> > > Hi Eliot. Traits are only used in Fuel for testing. And really used for > > testing methods for classes and traits (not the basic methods). So, of > > course, you can directly fileout the Fuel package only without traits. > > > > One of the things I always wanted is what you are really asking, a way to > > fileout forgetting traits, just letting those methods directly in the > > classes. But I have no idea if that's possible. > > > > Finally, I was never really convinced about the Traits usage in Fuel. > Mostly > > because some tools seem not to be happy with them...We should check how > much > > difficult and what we loose removing them now.... > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Adrian Lienhard

IIRC this can be achieved with two small changes: - Comment out the line "method isLocalSelector" from PackageInfo>>methods. This will flatten the traits into the classes, i.e., make all methods of a class being stored even if they come from a trait. - In addition you probably need to change PackageInfo>>classes to filter out all traits (like ... reject: #isTrait). HTH, Adrian On Jun 7, 2011, at 08:11 , Mariano Martinez Peck wrote: > On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi All, >> >> if I want to export a package (Fuel!!) to a dialect without traits is >> there anything to help me remove the trait info and just file-out the >> composed code? >> >> > Hi Eliot. Traits are only used in Fuel for testing. And really used for > testing methods for classes and traits (not the basic methods). So, of > course, you can directly fileout the Fuel package only without traits. > > One of the things I always wanted is what you are really asking, a way to > fileout forgetting traits, just letting those methods directly in the > classes. But I have no idea if that's possible. > > Finally, I was never really convinced about the Traits usage in Fuel. Mostly > because some tools seem not to be happy with them...We should check how much > difficult and what we loose removing them now.... > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com

June 7, 2011

Re: [Pharo-project] supporting bootstrap

by Igor Stasenko

On 6 June 2011 22:54, Carlo <snoobabk(a)yahoo.ie> wrote: > Sorry ignore...didn't read your comment... > > On 06 Jun 2011, at 9:51 PM, Carlo wrote: > > How about: > > (((value class isObsolete not) and: [value isTrait not]) and: [ key == value name ]) > > not sure if it covers all the same scenarios but in my image it gave the same answers as before the change: > Smalltalk globals flushClassNameCache. > Smalltalk globals classNames size. 1940 > Smalltalk globals nonClassNames size. 96 > > Cheers > Carlo > > On 06 Jun 2011, at 9:28 PM, StÃ©phane Ducasse wrote: > > fillCaches > Â Â Â Â "Fill cachedClassNames and cachedNonClassNames. Return an array with the calculated values." > > Â Â Â Â | classNames nonClassNames | > Â Â Â Â classNames := OrderedCollection new: self size. > Â Â Â Â nonClassNames := OrderedCollection new. > Â Â Â Â self keysAndValuesDo: [ :key :value | > Â Â Â Â Â Â Â Â "The key == value name test below addresses two separate issues: > Â Â Â Â Â Â Â Â Â Â Â Â 1) Obsolete classes, where key = #Foo and value name = 'AnObsoleteFoo' > Â Â Â Â Â Â Â Â Â Â Â Â 2) Aliases, i.e., Smalltalk at: #OtherName put: aClass" > Â Â Â Â Â Â Â Â ((value isKindOf: (self class environment at: #Class)) and: [ key == value name ]) > Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ classNames add: key ] > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ nonClassNames add: key ] ]. > Â Â Â Â Â Â Â Â "The expression (self class environment at: #Class) deserves some explanation. > Â Â Â Â Â Â Â Â For bootstrapping we need to have a different Class when executing value isKindOf: Class : > Â Â Â Â Â Â Â Â In such expression Class represents a kind of fixed point: the class of the class of the system. > Â Â Â Â Â Â Â Â When bootstrapping we want the class Class of the current kernel defined in the current namespace. > Â Â Â Â Â Â Â Â Since the current namespace should contains the class that describes itself as well as a new Class class. > Â Â Â Â Â Â Â Â we are done :). - StephaneDucasse" > > Â Â Â Â classNames sort. > Â Â Â Â cachedNonClassNames := nonClassNames sort. > Â Â Â Â cachedClassNames := classNames. > Â Â Â Â ^{ classNames. nonClassNames } > why not just use #isBehavior? > Stef > > France - ukraine still 0-0 :) > > > > > > > > -- Best regards, Igor Stasenko AKA sig.

June 7, 2011

Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days

by Norbert Hartl

Am 07.06.2011 um 10:37 schrieb Norbert Hartl: > I cannot reach the server so I cannot check. But I checked at the weekend and wrote a mail to the pharo list. The build failed because it couldn't load a file from Lukas' server. I could load it via my browser. So triggering a new build will hopefully fix it. > Ok, now I see. It has been restarted but there is another error. Norbert > Norbert > > Am 07.06.2011 um 09:47 schrieb Marcus Denker: > >> Hello, >> >> The 1.2 full build is broken since 5 days >> >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ >> >> Someone needs to fix it. >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > >

June 7, 2011

Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days

by Norbert Hartl

I cannot reach the server so I cannot check. But I checked at the weekend and wrote a mail to the pharo list. The build failed because it couldn't load a file from Lukas' server. I could load it via my browser. So triggering a new build will hopefully fix it. Norbert Am 07.06.2011 um 09:47 schrieb Marcus Denker: > Hello, > > The 1.2 full build is broken since 5 days > > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > > Someone needs to fix it. > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

June 7, 2011

[Pharo-project] [TODO] 1.2 full build broken since 5 days

by Marcus Denker

Hello, The 1.2 full build is broken since 5 days https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ Someone needs to fix it. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 7, 2011

Re: [Pharo-project] Spaktacualr Class Forest of Pharo

by StÃ©phane Ducasse

would be nice to have packages (= field with cows) and classes inside. Stef On Jun 7, 2011, at 4:38 AM, HwaJong Oh wrote: > Hi, > > I've http://appdal.com/groups/36442/wiki/56611/Pharo__.html rendered all > the classes of Pharo into a forest of 3D space with > http://appdal.com/groups/36442/wiki/47cf4/Pharo____.html Sketchup Ruby > script which was generated by Pharo code. (it does not generate definition > of ruby methods. You need to type it :-( ) > You can get that code by using Gofer: > > Gofer new > squeaksource: 'DaliotsPlayground'; > package: 'ConfigurationOfSketchupRuby'; > load. > > (Smalltalk at: #ConfigurationOfSketchupRuby) project latestVersion load. > > > Best Regards > HwaJong Oh > > -- > View this message in context: http://forum.world.st/Spaktacualr-Class-Forest-of-Pharo-tp3578542p3578542.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 7, 2011

Re: [Pharo-project] [Pharo-users] [ANN] New Glorp Port

by StÃ©phane Ducasse

thanks guillermo! Stef On Jun 7, 2011, at 4:57 AM, Guillermo Polito wrote: > I'm glad to announce a first stable version of the new Glorp Port, from VW 7.7.1. > > The port has been integrated with the DBXTalk Driver (before known as SqueakDBX), and tested on the following platforms: > > MySql: 872 tests run, 18 errors, 6 failures > PostgreSQL: 872 tests, 18 errors, 6 failures > Oracle: 872 tests, 21 errors, 5 failures. > > Most of the errors are caused by stuff the DBXTalk Driver does not support yet, like LOBS. Also, there are some bugs yet I have to attack and learn how to get rid of, hehe. > > One think to be careful of yet is the licencing (or how it should be written). Glorp licence today is LGPL, but in the way to be MIT :). > > So, if you want to download and try it, evaluate in a workspace, in Pharo 1.2 and 1.3, > > Gofer it > squeaksource: 'DBXTalk'; > package: 'ConfigurationOfGlorpDBX'; > load. > > (ConfigurationOfGlorpDBX project version: #stable) load > > And start playing! > > I think I'll become the new port mantainer, so feedback, bug reports and everything else is appreciated. > > BTW, documentation and some new tools are on the way too. > > > Guille :)

June 7, 2011

Re: [Pharo-project] Spaktacualr Class Forest of Pharo

by Geert Claes

That looks pretty cool! -- View this message in context: http://forum.world.st/Spaktacualr-Class-Forest-of-Pharo-tp3578542p3578742.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Mariano Martinez Peck

On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > if I want to export a package (Fuel!!) to a dialect without traits is > there anything to help me remove the trait info and just file-out the > composed code? > > Hi Eliot. Traits are only used in Fuel for testing. And really used for testing methods for classes and traits (not the basic methods). So, of course, you can directly fileout the Fuel package only without traits. One of the things I always wanted is what you are really asking, a way to fileout forgetting traits, just letting those methods directly in the classes. But I have no idea if that's possible. Finally, I was never really convinced about the Traits usage in Fuel. Mostly because some tools seem not to be happy with them...We should check how much difficult and what we loose removing them now.... Cheers -- Mariano http://marianopeck.wordpress.com

June 7, 2011