- Pharo-dev - lists.pharo.org

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

by Max Leske

On 27.04.2014, at 17:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Goubier Thierry wrote >> I didn't understand that you could, instead of the branch, use a tag or a >> commit ID as the version identifier > > Something interesting I read recently that helped me understand git better > is that a "branch" is just a pointer to a commit, just like a release tag. correct. > The history of the branch is available, not because there is a "branch > object" that stores/calculates it, but because commits are linked back to > their ancestors. exactly. > If you arbitrarily change the #myBranch pointer to point to > a different commit, you'd automatically get that commit's history. yes. > So I'm > seeing that there is a tree of commits, with references to various leaves, > called "tag" or "branch" or "id" depending on the use context. IIRC even > when you do a rebase it doesn't change that commit (call it x), but creates > a new commit x' and changes the pointer to point to it. Thatâs essentially right. The problem with rebase however, is that the branch (e.g. âdevâ) will point to a different commit *with different history* after the rebase. So as soon as you have shared any of the commits that are part of the rebase, the people that have pulled from you will (usually) be forced to reclone your repository since Git canât know that a rebase happened (one could manually reset the branch to a common parent and then apply the pull, but you donât really want to do that). Some open source repository owners advocate a strict âno mergeâ policy, which implies that contributing developers canât merge their work into the public branch. Instead they are required to perform a rebase. That works (as said above) as long as none of those commits were shared. Iâm not a big fan of rebasingâ¦ :) > > I am a git beginner, so feel free to correct or augment the aboveâ¦ > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Fast-way-to-load-package-form-github-tp4756579p475668… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 27, 2014

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

by Sean P. DeNigris

Goubier Thierry wrote > I didn't understand that you could, instead of the branch, use a tag or a > commit ID as the version identifier Something interesting I read recently that helped me understand git better is that a "branch" is just a pointer to a commit, just like a release tag. The history of the branch is available, not because there is a "branch object" that stores/calculates it, but because commits are linked back to their ancestors. If you arbitrarily change the #myBranch pointer to point to a different commit, you'd automatically get that commit's history. So I'm seeing that there is a tree of commits, with references to various leaves, called "tag" or "branch" or "id" depending on the use context. IIRC even when you do a rebase it doesn't change that commit (call it x), but creates a new commit x' and changes the pointer to point to it. I am a git beginner, so feel free to correct or augment the above... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Fast-way-to-load-package-form-github-tp4756579p475668… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2014

Re: [Pharo-dev] Commit right to Pharo30Inbox

by Sean P. DeNigris

Nicolas Petton wrote > The Pharo inbox should have public write access. "should" -> "does" http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main "Monticello registration (public write access" You just have to be logged in. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Commit-right-to-Pharo30Inbox-tp4756663p4756684.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2014

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

by Esteban A. Maringolo

Thank you Camille. I added a gist for future reference: https://gist.github.com/eMaringolo/11346194 Best regards! Esteban A. Maringolo 2014-04-27 7:44 GMT-03:00 Camille Teruel <camille.teruel(a)gmail.com>: > 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

Re: [Pharo-dev] Commit right to Pharo30Inbox

by Nicolas Petton

Hi! The Pharo inbox should have public write access. Cheers, Nico Sven Van Caekenberghe writes: > 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 -- Nicolas Petton http://nicolas-petton.fr

April 27, 2014

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