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

Re: [Pharo-dev] http://forum.world.st down?

by Dale Henrichs

still down:( On 9/11/15 12:15 PM, Dale Henrichs wrote: > http://downforeveryoneorjustme.com/forum.world.st > >

Sept. 12, 2015

Re: [Pharo-dev] Annotating instance variables

by Ben Coman

On Sat, Sep 12, 2015 at 2:26 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 11 Sep 2015, at 20:05, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >> >> I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings. >> >> Is such thing "easily" possible now? There is API support from Reflectivity maybe? >> > > The infrastructure is thereâ¦ we can annotate instance variables. > > (Point slotNamed: #x) propertyAt: #note put: 'useless'. > (Point slotNamed: #x) propertyAt: #note > > One could build a user interface around that. > > Properties are not saved with monticello, though. They are like method properties. So one would > need to build something on top... > > Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but > it is actually part of the slot definition: > > Object subclass: #Point > slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. > #y } > classVariables: { } > category: 'Kernel-BasicObjects' > > As the note is part of the slot definition, it would be saved in Monticello. > > > (unrelated: I still am tempted to just use the term âinstance variableâ and get rid of the term Slot.. for the paper is was nice, but now? Especially > as we have slot like first class ClassVars and Globals that nevertheless are not slotsâ¦) Could you expand on how ClassVars and Globals are slot-like but not slots. One *tiny* consideration in favour of "slot" is that its more concise that "instance variable". Actually in post I often abbreviate to "iv" or "ivar". Also, would it be fair to say that for most programming languages variables are "dead", and it might be good to distinguish the "liveness" of slots. Further, there may be a particular class of early adopters who upon hearing the term "slot" that they don't know, will be compelled to investigate btw, can temporary variables be Slots? cheers -ben

Sept. 12, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by Tudor Girba

When in doubt, just do small steps :). Moose dissolved this central navigation class in about 4 years. I certainly do not think that we should wait for anything. I just think that we should pick it as a target and guide the incremental improvements towards distributing the queries throughout the object model. Cheers, Doru On Sat, Sep 12, 2015 at 8:43 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 11/9/15 14:15, Ben Coman a Ã©crit : > >> On Fri, Sep 11, 2015 at 5:01 AM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> I think SystemNavigation should essentially dissolve in the near future. >>> >> What timeline do you consider *near* ? ;) >> Should we go with my last proposal in the meantime? >> > > yes > never never stops to incrementally improve the system because something > better will happen > especially when doing this small steps is the first one in building the > better one :) > > This makes me realizes that I lost my great Calvin and Hobbes quote :) > > >> Moose used to have one of these some 10 years ago, and now all queries are >>> implemented as fluent APIs distributed throughout the model classes. >>> >> Could you clue me in on the "model" classes? >> cheers -ben >> >> On Thu, Sep 10, 2015 at 8:29 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> Pragma should not depend on SystemNavigation. The inverse >>>> >>>> >>>> Le 10/9/15 19:44, Ben Coman a Ã©crit : >>>> >>>> On Fri, Sep 11, 2015 at 12:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>>> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: >>>>>>> >>>>>>> The bootstrap-dependency graph and report [1] mark dependency >>>>>>> System-Announcements --> PragmaCollector for pruning. This is due >>>>>>> to... >>>>>>> >>>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>>> | collector | >>>>>>> self reset. >>>>>>> collector := PragmaCollector filter: [ :pragma | >>>>>>> pragma keyword = #systemEventRegistration ]. >>>>>>> collector reset. >>>>>>> collector do: [ :pragma | >>>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>>> selector ] >>>>>>> >>>>>>> Browsing around I came to understand that PragmaCollector is useful >>>>>>> as >>>>>>> a pragma cache, but here the collector is thrown away, so that >>>>>>> facility is not needed. A key part is "collector reset" which does... >>>>>>> self class allSystemPragmas >>>>>>> do: [:pragma | self addPragma: pragma] >>>>>>> >>>>>>> where the #addPragma: evaluates the initialize'd #filter: block. Now >>>>>>> it seems that #allSystemPragmas might fit nicely on Pragma rather >>>>>>> than >>>>>>> PragmaCollector >>>>>>> such that the following should be equivalent... >>>>>>> >>>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>>> | systemPragmas | >>>>>>> self reset. >>>>>>> systemPragmas := Pragma allSystemPragmas collect: [ :pragma >>>>>>> | >>>>>>> pragma keyword = #systemEventRegistration ]. >>>>>>> systemPragmas do: [ :pragma | >>>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>>> selector >>>>>>> >>>>>>> Cool. I like that better. >>>>>> >>>>>> However #allSystemPragmas depends on SystemNavigation, so is it be >>>>>>> okay for Pragma to depend on SystemNavigation? >>>>>>> >>>>>> Spontaneously Iâd say that SystemNavigation should depend on Pragma or >>>>>> PragmaCollector for looking up pragmas, not the other way around. >>>>>> >>>>> So you mean something like... >>>>> >>>>> SystemAnnouncer>>restoreAllNotifications >>>>> self reset. >>>>> SystemNavigation allPragmasNamed: #systemEventRegistration >>>>> do: >>>>> [ :pragma | >>>>> pragma methodClass theNonMetaClass perform: pragma >>>>> selector ]. >>>>> >>>>> where... >>>>> >>>>> SystemNavigation>>allPragmasNamed: symbol do: aBlock >>>>> | systemPragmas | >>>>> systemPragmas := >>>>> self allSystemPragmas collect: [ :pragma | pragma >>>>> keyword >>>>> = symbol ]. >>>>> systemPragmas do: [ :pragma | >>>>> pragma methodClass theNonMetaClass perform: pragma >>>>> selector >>>>> >>>>> SystemNavigation>>allSystemPragmas >>>>> ^ (Array >>>>> streamContents: [:stream | >>>>> self allBehaviorsDo: [:behavior | >>>>> Pragma >>>>> withPragmasIn: behavior >>>>> do: [:pragma | stream nextPut: pragma]]]) >>>>> >>>>> cheers -ben >>>>> >>>>> >>>>> Actually, class side of Pragma has several #named:in: like methods, so >>>>>>> something like the following would be neat... >>>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>>> self reset. >>>>>>> Pragma allNamed: #systemEventRegistration do: [ :pragma | >>>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>>> selector ]. >>>>>>> >>>>>> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 12, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by stepharo

Le 11/9/15 14:15, Ben Coman a Ã©crit : > On Fri, Sep 11, 2015 at 5:01 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> I think SystemNavigation should essentially dissolve in the near future. > What timeline do you consider *near* ? ;) > Should we go with my last proposal in the meantime? yes never never stops to incrementally improve the system because something better will happen especially when doing this small steps is the first one in building the better one :) This makes me realizes that I lost my great Calvin and Hobbes quote :) > >> Moose used to have one of these some 10 years ago, and now all queries are >> implemented as fluent APIs distributed throughout the model classes. > Could you clue me in on the "model" classes? > cheers -ben > >> On Thu, Sep 10, 2015 at 8:29 PM, stepharo <stepharo(a)free.fr> wrote: >>> Pragma should not depend on SystemNavigation. The inverse >>> >>> >>> Le 10/9/15 19:44, Ben Coman a Ã©crit : >>> >>>> On Fri, Sep 11, 2015 at 12:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: >>>>>> >>>>>> The bootstrap-dependency graph and report [1] mark dependency >>>>>> System-Announcements --> PragmaCollector for pruning. This is due to... >>>>>> >>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>> | collector | >>>>>> self reset. >>>>>> collector := PragmaCollector filter: [ :pragma | >>>>>> pragma keyword = #systemEventRegistration ]. >>>>>> collector reset. >>>>>> collector do: [ :pragma | >>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>> selector ] >>>>>> >>>>>> Browsing around I came to understand that PragmaCollector is useful as >>>>>> a pragma cache, but here the collector is thrown away, so that >>>>>> facility is not needed. A key part is "collector reset" which does... >>>>>> self class allSystemPragmas >>>>>> do: [:pragma | self addPragma: pragma] >>>>>> >>>>>> where the #addPragma: evaluates the initialize'd #filter: block. Now >>>>>> it seems that #allSystemPragmas might fit nicely on Pragma rather than >>>>>> PragmaCollector >>>>>> such that the following should be equivalent... >>>>>> >>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>> | systemPragmas | >>>>>> self reset. >>>>>> systemPragmas := Pragma allSystemPragmas collect: [ :pragma | >>>>>> pragma keyword = #systemEventRegistration ]. >>>>>> systemPragmas do: [ :pragma | >>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>> selector >>>>>> >>>>> Cool. I like that better. >>>>> >>>>>> However #allSystemPragmas depends on SystemNavigation, so is it be >>>>>> okay for Pragma to depend on SystemNavigation? >>>>> Spontaneously Iâd say that SystemNavigation should depend on Pragma or >>>>> PragmaCollector for looking up pragmas, not the other way around. >>>> So you mean something like... >>>> >>>> SystemAnnouncer>>restoreAllNotifications >>>> self reset. >>>> SystemNavigation allPragmasNamed: #systemEventRegistration do: >>>> [ :pragma | >>>> pragma methodClass theNonMetaClass perform: pragma >>>> selector ]. >>>> >>>> where... >>>> >>>> SystemNavigation>>allPragmasNamed: symbol do: aBlock >>>> | systemPragmas | >>>> systemPragmas := >>>> self allSystemPragmas collect: [ :pragma | pragma keyword >>>> = symbol ]. >>>> systemPragmas do: [ :pragma | >>>> pragma methodClass theNonMetaClass perform: pragma >>>> selector >>>> >>>> SystemNavigation>>allSystemPragmas >>>> ^ (Array >>>> streamContents: [:stream | >>>> self allBehaviorsDo: [:behavior | >>>> Pragma >>>> withPragmasIn: behavior >>>> do: [:pragma | stream nextPut: pragma]]]) >>>> >>>> cheers -ben >>>> >>>> >>>>>> Actually, class side of Pragma has several #named:in: like methods, so >>>>>> something like the following would be neat... >>>>>> SystemAnnouncer>>restoreAllNotifications >>>>>> self reset. >>>>>> Pragma allNamed: #systemEventRegistration do: [ :pragma | >>>>>> pragma methodClass theNonMetaClass perform: pragma >>>>>> selector ]. >

Sept. 12, 2015

Re: [Pharo-dev] Annotating instance variables

by Marcus Denker

> > Properties are not saved with monticello, though. They are like method properties. So one would > need to build something on top... > > > I don't know about MC model, but maybe extending MC to support properies/annotations could be a path? > Yes, that would be a possibility. Adding things to the monticello .zip is easy (and easy to ignore later/by others). > > Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but > it is actually part of the slot definition: > > Object subclass: #Point > slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. > #y } > classVariables: { } > category: 'Kernel-BasicObjects' > > As the note is part of the slot definition, it would be saved in Monticello. > > > It could be silly question but most of the time I wish to annotate while debugging, using that option would affect my debugged objec state? No, the current class builder would migrate the objects (I think). As this does not change the shape of the instances, even that can be avoided. Marcus

Sept. 12, 2015

Re: [Pharo-dev] http://forum.world.st down?

by Dale Henrichs

Thx! On 09/11/2015 01:16 PM, Peter UhnÃ¡k wrote: > I also see it down. Btw this also happened couple of weeks ago (so I > guess it will fix itself.)) > > On Fri, Sep 11, 2015 at 9:15 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > http://downforeveryoneorjustme.com/forum.world.st > > > >

Sept. 11, 2015

Re: [Pharo-dev] http://forum.world.st down?

by Peter UhnÃ¡k

I also see it down. Btw this also happened couple of weeks ago (so I guess it will fix itself.)) On Fri, Sep 11, 2015 at 9:15 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > http://downforeveryoneorjustme.com/forum.world.st > > > >

Sept. 11, 2015

Re: [Pharo-dev] Annotating instance variables

by Torsten Bergmann

Sept. 11, 2015

Re: [Pharo-dev] Annotating instance variables

by HernÃ¡n Morales Durand

Hi Marcus, Thanks for the answers. I am discovering Reflectivity, I just have a couple more questions if you don't mind: 2015-09-11 15:26 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 11 Sep 2015, at 20:05, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > > > I saw some interesting reflection progress in Pharo 5. I wonder if there > is a feature to rank instance variables. For example, from the browser I > want to assign a category "important" to an instance variable, or "possibly > useless", etc. for later refactorings. > > > > Is such thing "easily" possible now? There is API support from > Reflectivity maybe? > > > > The infrastructure is thereâ¦ we can annotate instance variables. > > (Point slotNamed: #x) propertyAt: #note put: 'useless'. > (Point slotNamed: #x) propertyAt: #note > > One could build a user interface around that. > > This is cool, I just hope the Nautilus plugin interface is stable by now then :) > Properties are not saved with monticello, though. They are like method > properties. So one would > need to build something on top... > > I don't know about MC model, but maybe extending MC to support properies/annotations could be a path? > Another idea would be to make a subclass of InstanceVariableSlot that > stores the note in a property but > it is actually part of the slot definition: > > Object subclass: #Point > slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. > #y } > classVariables: { } > category: 'Kernel-BasicObjects' > > As the note is part of the slot definition, it would be saved in > Monticello. > > It could be silly question but most of the time I wish to annotate while debugging, using that option would affect my debugged objec state? Cheers, HernÃ¡n > (unrelated: I still am tempted to just use the term âinstance variableâ > and get rid of the term Slot.. for the paper is was nice, but now? > Especially > as we have slot like first class ClassVars and Globals that nevertheless > are not slotsâ¦) > > Marcus > > > >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility

by David T. Lewis

Eliot, I agree. Indeed, even with an interpreter VM it has long been the case that a plugin compiled as 64 bit will not work on a VM compiled for 64 bit and vice versa. With the number of variations of 32/64, Spur/V3, and so forth, I don't think that this is a problem worth worrying about. Better to just be a aware that plugins are not readily interchangeable in those cases. Dave > Hi Chris, > > On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <brasspen(a)gmail.com> > wrote: > >> I had the idea that a plugin from one VM could be dragged into another >> VM's directory and that it could be used just by starting up the image. >> I've done a little experimenting and it seems more of an idea of a >> reality. >> The functionality is there, but VM developers over the years have not >> seen >> this as a priority. Typically plugins and their VMs are compiled >> together. >> Or a person adds one by recompiling a VM compilation rig they already >> have. >> > > The problems I see with this are > > a) a plugin compiled for Spur may not work with V3 or vice verse. The > issue is the header size of an object. Some plugins, but not all, use > this > define, and the header sizes between Spur and V3 are incompatible. > > b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't > work > with 32-bit VMs. Period. > > Now there are platform-level packaging technologies, such as fat binaries > on Mac OS X, that allow one to construct plugins that contain more than > one > binary. But this is a lot of work to build and maintain. > > So personally I wouldn't put much effort into this level of drag-and-drop > compatibility. Instead I'd put energy into good error messages so that > when plugins don't work the user can find out why, and that when the wrong > kind of plugin is used the VM doesn't just stumble along, maybe producing > incorrect results, but instead puts the plugin out with a comprehensible > complaint. > > Does this make sense? I know its a downer, but what you propose is, IMO, > not affordable given our resources. > > > And I must say, *this is a VM-DEV discussion, not a general purpose Squeak > discussion*, yes? > > As I had a rig for the Interpreter VM I decided to compile a plugin and > see >> if I could drag it around to other VM directories for use. Most times it >> didn't work. >> >> I compiled a TheUniversalAnswer plugin which returns 42. I moved it from >> a >> 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not >> use >> the squeak.sh start script. That is, I dragged so.vm-sound-null, >> so.TheUniversalAnswer and so.vm-display-X11 into the same directory as >> the >> VM binary. That worked. >> >> The only way to see the external plugins is with #listLoadedModules. >> But, >> irritatingly, modules are loaded as needed, so once you have proof of >> using >> the primitive from the plugin, yea, it will appear as a result of that >> Smalltalk listLoadedModules message. So, it's not that useful. >> >> I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 >> and >> 4.13.10-3268 without success. And the unload selectors #forgetModule: >> and >> unloadModule:, which both use primitive 571 don't appear to work on my >> Ubuntu 15.04. >> >> So, I don't know if a community of plugins passed around is in the >> offing. >> What I have learned is that many of the answers are in >> sqUnixExternalPrims.c. The issues are really where does the VM look for >> primitives and what does it do when it finds one. It appears to me, >> after >> reading both the non-Cog and Cog versions of that file, that this an >> interesting area poorly documented that VM developers alter in haste to >> get >> on to something else. >> >> It's pretty important stuff, though. Do you start the VM with the binary >> on the path? Do you use squeak.sh? Where is the VM looking for stuff. >> Where >> will FFI look for stuff. And so on. >> >> Chris >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Sept. 11, 2015