- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strategies with Nautilus announcements

by Nicolai Hess

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > as NautilusMethodSelected contains also an information about protocol, > class, package; > NautilusProtocolSelected contains an information about class and package; > . > . > . > > Iâve inherited NautilusClassSelected from NautilusPackageSelected and > NautilusProtocolSelected from NautilusClassSelectedâ¦ to remove duplication. > But as announcement subscription also includes itâs subclasses, if you > subscribe to NautilusPackageSelected, you end up receiving also > NautilusClassSelected, NautilusProtocolSelected and NautilusMethodSelected. > > What is a good way to resolve this (I can simply separate all the classes, > but maybe there is something important from conceptual point of view)? > I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of subannouncements (WindowClosed/WindowOpened ...) What we could do (maybe this is a bit overkill): - make an announcements hierarchy (NautilusPackageAnnouncement -> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts - create sub classes for every "kind" NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement And only subscribe to this subclasses. That way we are using the hierarchy of Announcement classes for removing of duplicated code, but only register and announce the "leaf"-nodes (NautilusClassChangedAnnouncement / NautilusPackageChangedAnnouncement...) what do you think? > > Uko >

Sept. 12, 2015

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

by Peter UhnÃ¡k

Btw since forum.world.st is just an aggregation of mailing lists, you could access the mailing list directly http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ or use google with site: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ ... but the indexing seems to be quite random and there's also http://blog.gmane.org/gmane.comp.lang.smalltalk.pharo.devel but the search is also not so good... :( 2015-09-12 16:25 GMT+02:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > still down:( > > On 9/11/15 12:15 PM, Dale Henrichs wrote: > >> http://downforeveryoneorjustme.com/forum.world.st >> >> >> > >

Sept. 12, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Nicolai Hess

2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > I'm a bit concerned that this is creating drift with the "official" > Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long > filename support for win32 was recently added by Marcel Taumel in May of > this year. Are you tracking that? How can we keep the sources harmonized? > Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs). github branch: https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin I'll create a push request. nicolai > > On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> For those who had problems with pharo on windows and github based >> repositories, >> I built a windows vm with support for long paths: >> >> >> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >> >> >> For browsing directories with large paths (FileList or Inspect), >> you may need one additional change in the image (But I am not really sure >> about that) : >> >> DiskStore>>initialize >> super initialize. >> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. >> >> >> please test and give feedback. >> >> This wasn't as easy as I thought, and I had to make some more changes >> for the file permissions (the stat-functions don't work for files with >> long paths). >> Please test other file/folder operations. >> >> >> nicolai >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > >

Sept. 12, 2015

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