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

Re: [Pharo-dev] Commit right to Pharo30Inbox

by Sven Van Caekenberghe

Done. On 27 Apr 2014, at 13:17, Carlo <snoobabk(a)gmail.com> wrote: > Hi > > I would like to submit a SLICE to the pharo inbox, can you please grant me commit rights? > > username: CarloTeixeira > > Thanks > Carlo

April 27, 2014

Re: [Pharo-dev] Differences when loading metacello stable configurations

by Tudor Girba

What Guille is saying is that loadVersion: #stable does not imply loading the #stable blessing. In the Metacello lingo, it implies loading the #stable symbolic version. I think the blessing should be deprecated because it is not maintained reliably (plus it adds yet another level of complexity in Metacello without a direct significant benefit). Doru On Sun, Apr 27, 2014 at 3:04 PM, Max Leske <maxleske(a)gmail.com> wrote: > To recap (to see if I understood you): > - Gofer loads the blessing, ignoring the platform > - Metacello loads the blessing only if it is defined for the current > platform > > If the above is correct, then I actually think that the Gofer version is > the right way to do it. You *explicitly* ask for the stable blessing and > you should get what you ask for. > Both should undoubtedly behave the same way though, so maybe you should > open a bug report. > > Max > > On 27.04.2014, at 14:54, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > If I do a normal load it happens the same. The thing is that GoferMetacelloLoad > fetches first some version using the blessing and then using the version > number/symbol. > > > On Sun, Apr 27, 2014 at 2:05 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 27.04.2014, at 13:55, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> > Hi guys! >> > >> > I'm having different behaviors when loading metacello configurations >> using the configuration directly and using gofer: >> > >> > "This loads well" >> > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >> > package: 'ConfigurationOfOpenDBXDriver'; >> > load. >> > >> > (ConfigurationOfOpenDBXDriver project version: #stable) >> > load: âdefault' >> >> Youâre not specifying âdefaultâ below. Could that make a difference? >> >> > >> > "This tries to load the version 1.2 of the configuration which is not >> stable and doesn't work on pharo3..." >> > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >> > configurationOf: 'OpenDBXDriver'; >> > loadVersion: #stable. >> > >> > Apparently that's because... >> > >> > In GoferMetacelloLoad>>metacelloVersion >> > >> > It tries to fetch the first the latest version for a blessing and just >> afterwards it tries to get the explicit version... >> > >> > And yes! >> > >> > ConfigurationOfOpenDBXDriver project latestVersion: #stable => 1.2 >> > >> > But that is using the blessing... So yes, blessing of version 1.2 is >> stable. >> > >> > Shouldn't the #loadVersion: from Gofer behave the same as Metacello? >> > >> > Anyways, I can change the blessing of my old version I think, that can >> solve my problem quickly :) >> > >> > Guille >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

April 27, 2014

Re: [Pharo-dev] Differences when loading metacello stable configurations

by Max Leske

To recap (to see if I understood you): - Gofer loads the blessing, ignoring the platform - Metacello loads the blessing only if it is defined for the current platform If the above is correct, then I actually think that the Gofer version is the right way to do it. You *explicitly* ask for the stable blessing and you should get what you ask for. Both should undoubtedly behave the same way though, so maybe you should open a bug report. Max On 27.04.2014, at 14:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > If I do a normal load it happens the same. The thing is that GoferMetacelloLoad fetches first some version using the blessing and then using the version number/symbol. > > > On Sun, Apr 27, 2014 at 2:05 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 27.04.2014, at 13:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > Hi guys! > > > > I'm having different behaviors when loading metacello configurations using the configuration directly and using gofer: > > > > "This loads well" > > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > > package: 'ConfigurationOfOpenDBXDriver'; > > load. > > > > (ConfigurationOfOpenDBXDriver project version: #stable) > > load: âdefault' > > Youâre not specifying âdefaultâ below. Could that make a difference? > > > > > "This tries to load the version 1.2 of the configuration which is not stable and doesn't work on pharo3..." > > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > > configurationOf: 'OpenDBXDriver'; > > loadVersion: #stable. > > > > Apparently that's because... > > > > In GoferMetacelloLoad>>metacelloVersion > > > > It tries to fetch the first the latest version for a blessing and just afterwards it tries to get the explicit version... > > > > And yes! > > > > ConfigurationOfOpenDBXDriver project latestVersion: #stable => 1.2 > > > > But that is using the blessing... So yes, blessing of version 1.2 is stable. > > > > Shouldn't the #loadVersion: from Gofer behave the same as Metacello? > > > > Anyways, I can change the blessing of my old version I think, that can solve my problem quickly :) > > > > Guille > > >

April 27, 2014

Re: [Pharo-dev] Differences when loading metacello stable configurations

by Guillermo Polito

If I do a normal load it happens the same. The thing is that GoferMetacelloLoad fetches first some version using the blessing and then using the version number/symbol. On Sun, Apr 27, 2014 at 2:05 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 27.04.2014, at 13:55, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > Hi guys! > > > > I'm having different behaviors when loading metacello configurations > using the configuration directly and using gofer: > > > > "This loads well" > > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > > package: 'ConfigurationOfOpenDBXDriver'; > > load. > > > > (ConfigurationOfOpenDBXDriver project version: #stable) > > load: âdefault' > > Youâre not specifying âdefaultâ below. Could that make a difference? > > > > > "This tries to load the version 1.2 of the configuration which is not > stable and doesn't work on pharo3..." > > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > > configurationOf: 'OpenDBXDriver'; > > loadVersion: #stable. > > > > Apparently that's because... > > > > In GoferMetacelloLoad>>metacelloVersion > > > > It tries to fetch the first the latest version for a blessing and just > afterwards it tries to get the explicit version... > > > > And yes! > > > > ConfigurationOfOpenDBXDriver project latestVersion: #stable => 1.2 > > > > But that is using the blessing... So yes, blessing of version 1.2 is > stable. > > > > Shouldn't the #loadVersion: from Gofer behave the same as Metacello? > > > > Anyways, I can change the blessing of my old version I think, that can > solve my problem quickly :) > > > > Guille > > >

April 27, 2014

Re: [Pharo-dev] Fast way to load package form github

by GOUBIER Thierry

Hi Johan, thanks for the answer, this is perfect :) When reading the Metacello source, I didn't understand that you could, instead of the branch, use a tag or a commit ID as the version identifier. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Johan Brichau [johan(a)inceptive.be] EnvoyÃ© : dimanche 27 avril 2014 11:22 Ã : Pharo Development List Objet : Re: [Pharo-dev] Fast way to load package form github On 26 Apr 2014, at 16:46, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > That said, if you found a way to refer a specific commit via github://, I'd really like to know how :) In metacello, you can do it [1,2]: github:// <github user> / <github project> [ : <version identifier> ] [ / <repository path> ] Did I misunderstand your question? cheers Johan [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr…

April 27, 2014

Re: [Pharo-dev] Differences when loading metacello stable configurations

by Max Leske

On 27.04.2014, at 13:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi guys! > > I'm having different behaviors when loading metacello configurations using the configuration directly and using gofer: > > "This loads well" > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > package: 'ConfigurationOfOpenDBXDriver'; > load. > > (ConfigurationOfOpenDBXDriver project version: #stable) > load: âdefault' Youâre not specifying âdefaultâ below. Could that make a difference? > > "This tries to load the version 1.2 of the configuration which is not stable and doesn't work on pharo3..." > Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; > configurationOf: 'OpenDBXDriver'; > loadVersion: #stable. > > Apparently that's because... > > In GoferMetacelloLoad>>metacelloVersion > > It tries to fetch the first the latest version for a blessing and just afterwards it tries to get the explicit version... > > And yes! > > ConfigurationOfOpenDBXDriver project latestVersion: #stable => 1.2 > > But that is using the blessing... So yes, blessing of version 1.2 is stable. > > Shouldn't the #loadVersion: from Gofer behave the same as Metacello? > > Anyways, I can change the blessing of my old version I think, that can solve my problem quickly :) > > Guille

April 27, 2014

Differences when loading metacello stable configurations

by Guillermo Polito

Hi guys! I'm having different behaviors when loading metacello configurations using the configuration directly and using gofer: "This loads well" Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; package: 'ConfigurationOfOpenDBXDriver'; load. (ConfigurationOfOpenDBXDriver project version: #stable) load: 'default' "This tries to load the version 1.2 of the configuration which is not stable and doesn't work on pharo3..." Gofer it smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; configurationOf: 'OpenDBXDriver'; loadVersion: #stable. Apparently that's because... In GoferMetacelloLoad>>metacelloVersion It tries to fetch the first the latest version for a blessing and just afterwards it tries to get the explicit version... And yes! ConfigurationOfOpenDBXDriver project latestVersion: #stable => 1.2 But that is using the blessing... So yes, blessing of version 1.2 is stable. Shouldn't the #loadVersion: from Gofer behave the same as Metacello? Anyways, I can change the blessing of my old version I think, that can solve my problem quickly :) Guille

April 27, 2014

Commit right to Pharo30Inbox

by Carlo

Hi I would like to submit a SLICE to the pharo inbox, can you please grant me commit rights? username: CarloTeixeira Thanks Carlo

April 27, 2014

Re: [Pharo-dev] Fast way to load package form github

by Yuriy Tymchuk

On 27 Apr 2014, at 11:22, Johan Brichau <johan(a)inceptive.be> wrote: > > On 26 Apr 2014, at 16:46, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > >> That said, if you found a way to refer a specific commit via github://, I'd really like to know how :) > > In metacello, you can do it [1,2]: > > github:// <github user> / <github project> [ : <version identifier> ] [ / <repository path> ] > > Did I misunderstand your question? Thank you, Iâve found this already. Here is a little quid I wrote: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… Cheers! Uko > > cheers > Johan > > [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… > [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr…

April 27, 2014

Re: [Pharo-dev] Error adding a Class instVar

by Camille Teruel

Hello Esteban, Sorry for the delay. All the layout of all these classes is wrong, due to some ancient bug. The bug fix has been integrated but all the classes that have been modified in-between may have this problem. To fix that you have to force the rebuild of these classes (by adding then removing a dummy inst var for ex). Here is a script that do that: ivName := 'anIVNameImPrettySureNobodyUses'. all := Smalltalk allClasses flatCollect: [ :e | { e . e class } ]. candidates := all reject: [ :e | e superclass isNil or: [e layout slotScope isKindOf: LayoutEmptyScope ] ]. toRebuild := candidates reject: [ :e | e superclass layout slotScope == e layout slotScope parentScope ]. toRebuild do: [ :e | e addInstVarNamed: ivName ]. toRebuild do: [ :e | (e isClassSide ifTrue: [ (Smalltalk at: e instanceSide name) classSide ] ifFalse: [ Smalltalk at: e name ]) removeInstVarNamed: ivName ] On 25 avr. 2014, at 16:53, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Camille, all the classes in my hiearchy are in the toRebuild collection. > > But these others are also included: > > AdabasLikePlatform class > AsyncFileReadStream class > CannotAutomaticallyDetermineJoin class > CannotFindSession class > DialogWindowModel class > DolphinDatabaseAccessor class > DuplicatePrimaryKeyException class > ExternalOSProcess class > GlorpDatabaseReadError class > GlorpDatabaseWriteError class > GlorpIllegalCommand class > GlorpInvalidExpressionError class > GlorpInvalidTypeError class > GlorpLinkTableAnywhereDescriptorSystem class > GlorpTransactionFailure class > GlorpWriteFailure class > JQueryClass class > JQueryInstance class > MAMemoryFileModel class > MBAbstractInfoList class > MBLabelInfo class > MBSpecInfo class > MCClassDefinition > MCClassDefinition class > MCClassTraitDefinition > MCClassTraitDefinition class > MCFileTreeFileSystemUtils class > MCMethodDefinition > MCMethodDefinition class > MCMockDefinition > MCMockDefinition class > MCOrganizationDefinition > MCOrganizationDefinition class > MCScriptDefinition > MCScriptDefinition class > MacOSProcessAccessor class > MacProcess class > MySQLPlatform class > OS2OSProcessAccessor class > OS2Process class > ObjectStudioDatabaseAccessor class > OcelotPlatform class > OraclePlatform class > PGAbstractStringResponse class > PGAsciiRow class > PGAuthentication class > PGBackendKeyData class > PGCancelRequest class > PGColumnDescription class > PGCopyInResponse class > PGCopyOutResponse class > PGFunctionCall class > PGFunctionResultResponse class > PGNotificationResponse class > PGPasswordPacket class > PGQuery class > PGReadyForQuery class > PGRowDescription class > PGStartupPacket class > PGTerminate class > PostgreSQLPlatform class > ProfStef class > RBSLDAPAuthenticationProvider class > RBSPostgresAuthenticationProvider class > RBSSuperUserSession class > RBSVoyageAuthenticationProvider class > RiscOSProcess class > RiscOSProcessAccessor class > SQLServerPlatform class > SQLite3Platform class > SpecDebugActionButton class > SqueakDatabaseAccessor class > TextInputFieldModel class > UIThemeVistary class > UIThemeWatery class > UnixProcess class > VADatabaseAccessor class > VWDatabaseAccessor class > ValidationError class > WAAncestryAttributeEditor class > WABufferedResponse class > WACacheAttributeEditor class > WAComboResponse class > WAConfigAttributeEditor class > WAFileAttributeEditor class > WAFileLibrary class > WAFileMetadataLibrary class > WAFilterAttributeEditor class > WAStreamedResponse class > WindowsOSProcessAccessor class > WindowsProcess class > WorldModel class > > Regards! > > > Esteban A. Maringolo > > > 2014-04-25 4:42 GMT-03:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> On 25 avr. 2014, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 25 Apr 2014, at 04:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>>> I was adding a Class instance variable when I got this, admittedly, funny error. >>>> >>>> Any clues of why? >>>> >>>> The class has a Trait (which I plan to remove). Maybe that is causing this? >>> >>> This is this problem: >>> >>> https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… >> >> No I don't think so, 13028 is the subclass cache problem whereas Esteban's problem seems to be related to wrong slot scope problem. >> Esteban, is it the latest image? >> Can run this script in your image and tell us the content of toRebuild? >> >> all := Smalltalk allClasses flatCollect: [ :e | { e . e class } ]. >> candidates := all reject: [ :e | e superclass isNil or: [e layout slotScope isKindOf: LayoutEmptyScope ] ]. >> toRebuild := candidates reject: [ :e | e superclass layout slotScope == e layout slotScope parentScope ]. >> >> Does toRebuild contains your class or one class of its hierarchy? >> >>> >>> >> >> >

April 27, 2014