February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 4 & NeoCSV

by Andreas Wacknitz

Am 07.02.15 um 14:19 schrieb Sven Van Caekenberghe: > Hi Andreas, > > I added it. Thanks a lot. Andreas > > Sven > >> On 07 Feb 2015, at 13:59, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >> >> I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is there any reason for the lack of it? >> NeoJSON is available, thoughâ¦ >> >> Regards >> Andreas >

Feb. 7, 2015

Re: [Pharo-dev] Pharo 4 & NeoCSV

by Sven Van Caekenberghe

Hi Andreas, I added it. Sven > On 07 Feb 2015, at 13:59, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is there any reason for the lack of it? > NeoJSON is available, thoughâ¦ > > Regards > Andreas

Feb. 7, 2015

Pharo 4 & NeoCSV

by Andreas Wacknitz

I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is there any reason for the lack of it? NeoJSON is available, thoughâ¦ Regards Andreas

Feb. 7, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Nicolai Hess

2015-02-06 22:02 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > I have changed two methods of the configuration: > > -=-=- > stable: spec > <symbolicVersion: #stable> > > spec for: #'pharo2.x' version: '2.1'. > "after some modification in NB made it incompatible with 3.0" > spec for: #'pharo3.x' version: '2.3'. > *spec for: #'pharo4.x' version: '2.7â. â<<== added, maybe instead of > pharo4.x could be common"* > -=-=- > development: spec > <symbolicVersion: #'development'> > > spec for: #'common' version: '*2.3-baseline*â. â<<== it is likely not > necessary" > -=-=- > > I have changed it, because I think there should be two lines in Versioner: > one with development label, second with stable label. > Then everything works. > Let me know if it helps. > Juraj > Thank you Juraj, that works .... better, but now, commiting the new configuration shows a bunch of "Critical Issues" Critical Warning missing recommend field... Critcal Warning The name of package x does not match file name x.7 Critical Warning No Version specified. .... Not that easy. Maybe, the ConfigurationOfAthens was only written and updated by hand, does not work with Versionner? > > > 6. 2. 2015 v 17:28, Nicolai Hess <nicolaihess(a)web.de>: > > 2015-02-06 1:40 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > >> Well, then I cannot see packages that are not included in the version >> 2.7. Can you mention some? I will try to make a new version. >> > > I want to include the latest versions of > Athens-Cairo: Athens-Cairo-NicolaiHess.82 > and > Athens-Text: Athens-Text-NicolaiHess.16 > > The other packages hasn't change since version 2.7 > > > nicolai > > > >> >> Juraj >> >> 5. 2. 2015 v 20:07, Nicolai Hess <nicolaihess(a)web.de>: >> >> >> 2015-02-05 23:06 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >> >>> I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano >>> did the job. There is a new 2.7 version. >>> >> >> No, the version 2.7 is not new, I have some changes that came after that >> version. >> >> >>> >>> Cheers, >>> Juraj >>> >>> 5. 2. 2015 v 18:28, Nicolai Hess <nicolaihess(a)web.de>: >>> >>> 2015-02-05 21:56 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >>> >>>> I am just guessing: try to click on âdevelopmentâ item on the left side. >>>> >>> >>> >>> -> "Information: Nothing to save" >>> >>> Already tried :) >>> >>> >>>> >>>> Cheers, >>>> Juraj >>>> >>>> > 5. 2. 2015 v 17:13, Nicolai Hess <nicolaihess(a)web.de>: >>>> > >>>> > Hello, >>>> > >>>> > I fixed some issues for Athens and upload the changes to the >>>> > repository. Now, I want to use Versionner to create a new >>>> configuration. >>>> > What I tried: >>>> > >>>> > Open a fresh image >>>> > Open the Athens repository and load the new changesets >>>> > -> There are some merge conflicts. Why? There shouldn't be >>>> > any conflicts. How do you do this? >>>> > >>>> > After merging the changes I open Versionner. >>>> > I thought I have to make a new Release but the button "Release >>>> Version" is >>>> > disabled. >>>> > What did I miss? >>>> > >>>> > >>>> > >>>> > nicolai >>>> >>>> >>> >>> >> >> > >

Feb. 7, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40480 Home: https://github.com/pharo-project/pharo-core

Feb. 7, 2015

[pharo-project/pharo-core] c8ce6d: 40480

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c8ce6dadac22e0dc8c0280e697c63c70c8161749 https://github.com/pharo-project/pharo-core/commit/c8ce6dadac22e0dc8c0280e6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-07 (Sat, 07 Feb 2015) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script480.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40480.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/Slot.class/instance/class building/installingIn_.st A Slot.package/Slot.class/instance/class building/removingFrom_.st R Slot.package/Slot.class/instance/meta-object-protocol/installingIn_.st R Slot.package/Slot.class/instance/meta-object-protocol/removingFrom_.st A Slot.package/Slot.class/instance/meta-object-protocol/wantsInitalization.st A Slot.package/Slot.class/instance/private/addSlotInitToInitialize_.st A Slot.package/Slot.class/instance/private/ensureInitalizeMethodExists_.st A Slot.package/Slot.class/instance/private/ensureSlotIniatializationFor_.st A Traits.package/TBehavior.class/instance/initialization/initializeSlots_.st Log Message: ----------- 40480 14882 Slots: add mechanism for initializing slots https://pharo.fogbugz.com/f/cases/14882 http://files.pharo.org/image/40/40480.zip

Feb. 7, 2015

Re: [Pharo-dev] [Slots] Slots that initialize

by Marcus Denker

> On 07 Feb 2015, at 10:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 06 Feb 2015, at 18:15, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 06 Feb 2015, at 11:50, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>>> >>>> Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot >>>> can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it >>>> reflectively). >>> >>> This is now done: >>> >>> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-ca… <https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-ca…> >>> >> > > So, with this mechanism in place we can actually solve a nice problem: Slot initialisation. > > on #initialize, we want to hand the new object to each slot to give it a change to initialize it. > Now adding > self allSlots do: [ :slot | slot initialize: anObject ] > > to #initialize and doing that for all object is not good as this would slot down all #initialize calls. > We might want to pay that later when if we happen to use it a lot, but now now. > > https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializin… <https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializin…> > This is now in update #470 Marcus

Feb. 7, 2015

Re: [Pharo-dev] [Slots] Slots that initialize

by Marcus Denker

> On 06 Feb 2015, at 18:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 06 Feb 2015, at 11:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot >>> can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it >>> reflectively). >> >> This is now done: >> >> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-ca… >> > So, with this mechanism in place we can actually solve a nice problem: Slot initialisation. on #initialize, we want to hand the new object to each slot to give it a change to initialize it. Now adding self allSlots do: [ :slot | slot initialize: anObject ] to #initialize and doing that for all object is not good as this would slot down all #initialize calls. We might want to pay that later when if we happen to use it a lot, but now now. https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializin… <https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializin…> now implements it this way: 1) Slots that want #initialize: the be called on allocation need to implement #wantsInitalization 2) Then magically we add #initialize if needed and, if needed, add self class initializeSlots: self. to it. (this for now just uses text manipulationâ¦ later this will be a nice example for a concept that we need to reify as part of the MOP: âI want to hook into object initializationâ). Playing with it âââââââ (I need to add a testsâ¦) InstanceVariableSlot subclass: #InitSlot slots: { } classVariables: { } category: âPlayGround' initialize: anObject self write: 5 to: anObject. wantsInitalization ^ true Now create a class: Object subclass: #MyCClass slots: { #ttt => InitSlot } classVariables: { } category: âPlayGround' MyCClass new ==> ttt is initialised with 5. For what is this useful? âââââââââââ 1) e.g. the virtual slot that hold the dictionary for all PropertySlots needs to be initialised with an empty Dict 2) We can start to experiment with Slots that specify a value in the definition 3) â¦. Marcus

Feb. 7, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Ben Coman

On Sat, Feb 7, 2015 at 5:13 AM, stepharo <stepharo(a)free.fr> wrote: > I want relationships for certain modeling purposes > What I like is that we should arrive to get a collection of useful slots > with optimal implementation instead all of us reinventing the wheel. > > Stef > In the Flexible Object Layouts paper, it was first class relationships that really caught my eye. Thats what I am hoping for to start having a dive into Slots. And since the paper says "no mainstream OOPL provides first-class relationships as a programming construct" it might be a nice feature to advertise with Pharo 4 release. "First-class relationships" is quite a catchy term ? cheers -ben > > Le 6/2/15 18:15, Marcus Denker a Ã©crit : > > On 06 Feb 2015, at 11:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Next: When building classes with Slots, the class builder need to call >>>> back on the slot and hand the class to each. Then the slot >>>> can reflectively change the class, e.g. the PropertySlot will check if >>>> there is already a hidden property base slot and if not, add it >>>> reflectively). >>>> >>> This is now done: >>> >>> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in- >>> ClassBuilder-to-call-slots-when-building-a-class >>> >>> For playing with this, in 479: >> >> InstanceVariableSlot subclass: #AccessorSlot >> slots: { } >> classVariables: { } >> category: âPackage' >> >> two methods, #installingIn and #removingFrom:, which are called by the >> class builder: >> >> >> installingIn: aClass >> | reader writer | >> >> reader := String streamContents: [ :str | >> str >> nextPutAll: self name; >> cr;tab; >> nextPutAll: ' ^'; >> nextPutAll: self name. >> ]. >> writer := String streamContents: [ :str | >> str >> nextPutAll: self name; >> nextPutAll: ': anObject'; >> cr;tab; >> nextPutAll: self name; >> nextPutAll: ':= anObject.'. >> ]. >> aClass compile: reader classified: 'accessing'. >> aClass compile: writer classified: 'accessingâ. >> >> >> removingFrom: aClass >> >> aClass removeSelector: self name. >> aClass removeSelector: self name asMutator. >> >> >> Now we can make a class and see how the accessors are automatically added >> (and removed when the slot is removed): >> >> Object subclass: #TT >> slots: { #tttt => AccessorSlot } >> classVariables: { } >> category: âPackage' >> >> >> NOTE: this is an example of what can be done with Slots. It is *not* an >> example of what *should* be done with Slots. >> (this we only will know after using them for a while). >> >> Marcus >> >> >> >> >> > >

Feb. 7, 2015

Re: [Pharo-dev] ||

by kilon alios

Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . About python decorators I disagree that are similar to pragmas. Pragmas are focused on being descriptive , python decorators are descriptive as by product. The main focus of python decorators is to shorten code by introducing syntactic sugar. I agree though this is a very interesting discussion and I dont understand most of the things stated here so I leave an open door and mind for pragmas. Maybe one day I will "get it". On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Really interesting discussion. I like pragmas but this is interesting to >> see them challenged. >> > > Thanks. It's a pleasure to discuss that way :) > > >> Yes, but there end up being lots of naming conventions and they are >>> non-obvious. Whereas pragmas, because they are in-your-face in the methods >>> in question, don't need conventions. They just need documenting ;-). >>> >> Thierry I'm skeptical that multiple protocol will save the problem >> because you will rely on coding conventions. >> > > Pragma as well: just explain the conventions behind the gtInspector > pragmas, for example. > > But give me multiple protocols and I'll show you the same conventions > rewritten in less lines (and a slightly more efficient code). > > >> And pragma is a clever tagging. >> > > Then maybe we should remove protocols and replace them with pragmas :) > > Thierry > > >> >> Stef >> >> >> >

Feb. 7, 2015