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

Re: [Pharo-dev] Pharo Inbox now Public Writable

by stepharo

Yes this is normal. > IIRC you still need to be logged in... > > <http://forum.world.st/file/n4756131/Pharo_Inbox.png> > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-Inbox-now-Public-Writable-tp4756131.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 28, 2014

Re: [Pharo-dev] Hijri calendar

by stepharo

Hi maximillo would you be interested to have a chapter on our next book on Chalten? I hope so. We could take your documentation at input. Stef On 23/4/14 22:44, Maximiliano Taborda wrote: > Hi, > You could try Chalten, it also has support for the Islamic Calendar. > Take a look here: https://github.com/mtaborda/chalten. > > Regards. > Maxi > > > 2014-04-23 17:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com > <mailto:pdebruic@gmail.com>>: > > Torsten Bergmann wrote > > Paul DeBruicker wrote > >> Chronos has: > >> ... > >> Is that what you want? > > > > The www.chronos-st.org <http://www.chronos-st.org> seems to be > gone. But there is > > http://smalltalkhub.com/#!/~Chronos/Chronos/ > <http://smalltalkhub.com/#%21/%7EChronos/Chronos/> > > > > Thanks - I will have a look. Is it known to work in Pharo 3.0? > > > > Thx > > T. > > Eh it will probably die because the base config loads code that uses > FileDirectory. I did port it to Pharo 2. I think if you edit the > ConfigurationOfChronos to load into Pharo 3 what it loads into > Pharo 2 it > should work OK. But I haven't tried it. > > > > > > > > > -- > View this message in context: > http://forum.world.st/Hijri-calendar-tp4756080p4756106.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 27, 2014

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

by Dale Henrichs

Blessing is an attribute of a particular version ... multiple versions can have the same blessing, so there is limited utility to blessings ... personally I find the distinction between #release and #development useful for blessings with #release declaring that the version will not be changed anymore and #development declaring that the version may change in significant ways in the future ... deprecate blessings? I don't think so ... yet ... deprecate #stable blessing? I guess I never really understood what they were for ... I would think that #stable symbolic version is preferred mechanism... Dale On Sun, Apr 27, 2014 at 9:45 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Tudor Girba-2 wrote > > 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). > > Yes, I don't see what value the blessing provides in light of symbolic > versions... I'd like to hear Dale's opinion though... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Differences-when-loading-metacello-stable-configurati… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 27, 2014

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

by Sean P. DeNigris

Tudor Girba-2 wrote > 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). Yes, I don't see what value the blessing provides in light of symbolic versions... I'd like to hear Dale's opinion though... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Differences-when-loading-metacello-stable-configurati… 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

Max Leske wrote > Iâm not a big fan of rebasingâ¦ :) Agreed. Seems advisable to avoid in general. But it also seems to be useful on one's own private repository or in pull requests (the context in which I learned about it). ----- 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 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