- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Esteban A. Maringolo

2015-09-09 6:21 GMT-03:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Note that when:send:to: already existed in VW before announcements (it did > work with a symbol like when: #someAspectChanged send: #someAction to: > self, and this was tiggered thru dependents mechanism - self changed: > #someAspectChanged...). > > IMO, it is very expressive, whatever the underlying mechanism (dependents > or Announcement). > > +1 Dolphin Smalltalk also uses #when:send:to:, and also #when:sendTo: and #when:perform: Regards! Esteban A. Maringolo

Sept. 9, 2015

Re: [Pharo-dev] FTDataSource API

by Yuriy Tymchuk

Done https://pharo.fogbugz.com/f/cases/16537/FTDataSource-elementAt-should-not-b… > On 09 Sep 2015, at 17:48, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > mmmâ¦ thatâs an error :) > Iâm using (wrongly) #elementAt: to pick up drag&drop passengers in FTTableMorph>>#startDrag:, and that is a mistake (it should call some #passegerAt: method). > > can you fill a bug report, please? > > Esteban > > > >> On 09 Sep 2015, at 17:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi, >> >> Iâm a bit confused because FTDataSource has two methods #cellColumn:row: and #elementAt: with subclassResponsibility. I understand when FTSimpleDataSource implements #elementAt: and uses it in #cellColumn:row:. But as #cellColumn:row: is more general, why is there #elementAt: defined in FTDataSource? >> >> Uko > >

Sept. 9, 2015

Re: [Pharo-dev] AbstractNautilusUI class >> #on: versus onModel:

by Franck Warlouzet

It is not the only place where on: is used to set the model, I guess it is a common way to do this kind of things. Franck > From: btc(a)openinworld.com > Date: Wed, 9 Sep 2015 23:47:52 +0800 > To: pharo-dev(a)lists.pharo.org > Subject: [Pharo-dev] AbstractNautilusUI class >> #on: versus onModel: > > This is a small point, but maybe one tiny incremental improvement. > Just thought I'd get some feedback before opening a ticket. While > debug tracing through... > Smalltalk tools openClassBrowser > > in Nautilus>>open I see... > (self uiClass on: self) > > which calls PackageTreeNautilusUI class(AbstractNautilusUI class)>>on: > ^ self new model: aNautilus > > where PackageTreeNautilusUI(AbstractNautilusUI)>>model: > model := aNautilusModel. > ... > > and my passing thought was a nicer API would be > PackageTreeNautilusUI class(AbstractNautilusUI class)>>onModel: > > such that Nautilus>>open would be... > (self uiClass onModel: self) > > > Thoughts? > cheers -ben >

Sept. 9, 2015

Magritte-XMLBinding causes DNU when using Seaside editor example

by Skip

Hello, Magritte-XMLBinding (loaded by MagritteAddons) appears to go bad when you use descriptions of descriptions. Try to add a description using the MADescriptionEditor example in Seaside. I get the following: âMessageNotUnderstoord: MXXmlNamedElementTarget>>attributeNameâ. Is it just me?

Sept. 9, 2015

Re: [Pharo-dev] FTDataSource API

by Esteban Lorenzano

mmmâ¦ thatâs an error :) Iâm using (wrongly) #elementAt: to pick up drag&drop passengers in FTTableMorph>>#startDrag:, and that is a mistake (it should call some #passegerAt: method). can you fill a bug report, please? Esteban > On 09 Sep 2015, at 17:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, > > Iâm a bit confused because FTDataSource has two methods #cellColumn:row: and #elementAt: with subclassResponsibility. I understand when FTSimpleDataSource implements #elementAt: and uses it in #cellColumn:row:. But as #cellColumn:row: is more general, why is there #elementAt: defined in FTDataSource? > > Uko

Sept. 9, 2015

AbstractNautilusUI class >> #on: versus onModel:

by Ben Coman

This is a small point, but maybe one tiny incremental improvement. Just thought I'd get some feedback before opening a ticket. While debug tracing through... Smalltalk tools openClassBrowser in Nautilus>>open I see... (self uiClass on: self) which calls PackageTreeNautilusUI class(AbstractNautilusUI class)>>on: ^ self new model: aNautilus where PackageTreeNautilusUI(AbstractNautilusUI)>>model: model := aNautilusModel. ... and my passing thought was a nicer API would be PackageTreeNautilusUI class(AbstractNautilusUI class)>>onModel: such that Nautilus>>open would be... (self uiClass onModel: self) Thoughts? cheers -ben

Sept. 9, 2015

Re: [Pharo-dev] merging in a filetree repository

by Damien Cassou

Esteban Lorenzano <estebanlm(a)gmail.com> writes: > Most of our problems here is because we insist on being interchangeable between git and mcz. > While treating git as âjust another repositoryâ can feel appealable in certain cases (for example, in the super-uncommon way of handle vm building we have, when we use git and Eliot uses squeak source, then we are kind of a mirror), this is not the most common usage: if you start a project on git, you are expected other contributors use git tooâ¦ same as in any other SVC tool (there is not compatibility between SVN, HG, GIT, etc.) > > Of course, it looked like a good idea at the beginning, but now I think is counterproductive (is the kind of ideas that are great at the beginning because it provides security/confortability to users, but with time demonstrate obsolete). > > What we actually need is tools that can load configurations from different sources (for example, I have a project in git who uses seaside and I want a configuration who loads bothâ¦). > Butâ¦ guess what? WE ALREADY HAVE IT!!!! Metacello is perfectly capable of doing that. Gofer is capable of doing that. Heck, even monticello is capable of doing that as long as we do not pretend their are interchangeable! > > So, againâ¦ what we actually need is to accept reality: we do not need all that metadata in 99% of cases! do you propose to stop using Monticello completely? Just have a snippet to load code from a directory and store packages to a directory? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 9, 2015

Re: [Pharo-dev] merging in a filetree repository

by Damien Cassou

Alexandre Bergel <alexandre.bergel(a)me.com> writes: > Also, if I understand correctly, at each new repository I need to create a file .gitattributes : > > *.package/monticello.meta/version merge=mcVersion > *.package/*.class/methodProperties.json merge=mcMethodProperties > *.package/*.class/properties.json merge=mcProperties > *.package/*.extension/methodProperties.json merge=mcMethodProperties > *.package/*.extension/properties.json merge=mcProperties there are many potential places for these attributes: - the git project level (you can even commit it so all contributors benefit from it) - a top-level directory where git projects are cloned - ~/.config/git/attributes if you want it for all your git projects (that's what I'm trying) - /etc/gitattributes if you want it for all users of your environment - anywhere provided the place is referenced in your global git configuration Read http://git-scm.com/docs/gitattributes for more information -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 9, 2015

Re: [Pharo-dev] [ANN] MessageFlowBrowser

by Torsten Bergmann

Nicolai wrote: >You need to set the class this method belongs to: > >a smalltalkCode > smalltalkClass: [:each | each <class/behavior> ]; > display: [:each | each sourceCode ]]. Yes - I know that. At least from the code I found in the image. But how do I do that in the context of Glamour where the tree is transmitted to the code pane... See #openOn: in MessageFlowBrowser. Thanks T.

Sept. 9, 2015

FTDataSource API

by Yuriy Tymchuk

Hi, Iâm a bit confused because FTDataSource has two methods #cellColumn:row: and #elementAt: with subclassResponsibility. I understand when FTSimpleDataSource implements #elementAt: and uses it in #cellColumn:row:. But as #cellColumn:row: is more general, why is there #elementAt: defined in FTDataSource? Uko

Sept. 9, 2015