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

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

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

On Wed, Sep 9, 2015 at 4:31 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Whoever created http://smalltalkhub.com/#!/~PharoExtras/Compatibility/ > > I would rename it to SmalltalkCompatibility to ANSICompatibility because > "Compatibility" is a too general term and could mean backward compatibility > of Pharo versions or compatibility to other languages as well. That was me :) I was thinking more broadly that over time the "repository" might hold different packages Compatibility-ANSI, Compatibility-VW, Compatibility-Dolphin. But maybe that is overreaching and its better to be more focussed. Let me know what you think on this and restate what you think the repository name should be. > Also see http://wiki.squeak.org/squeak/2384 and http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec > which could be a start. I saw those, but they interact with existing classes, so I thought it easier to kickstart by loading in the tests first, which are all new classes. I only created the repository since the tests were *hard* to find eventually at http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibility/ So I thought it would be good make them more accessible as a Monticello Package. cheers -ben P.S. I don't quite follow "to SmalltalkCompatibility to ANSICompatibility" do you mean "to SmalltalkCompatibility or ANSICompatibility" ? > >> Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> Von: stepharo <stepharo(a)free.fr> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] ANSICompatibility package >> >> We should have a SmalltalkCompatibility (not Ansi per se) package >> were we can add some methods to help migration. >> >> Stef >> >> >> Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >> Hi, >> >> >> >> is there actually such a thing like ANSICompatibility package? >> >> (it has been mentioned here lately, but I cannot find it) >> >> >> >> Thanks, Jan >> >> >> > I made it up for the purpose of discussion to see what interest it generated. >> > Should we start one ? >> > cheers -ben >> > >> > >> >> >> >

Sept. 9, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

The interactive graph is cool. Some suggestions: * Mark nodes of dependencies you want to prune in red. * Allow nodes to be pinned * http://bl.ocks.org/GerHobbelt/3637711 * http://stackoverflow.com/questions/11584757/interactively-fixing-a-node-in-… * http://stackoverflow.com/questions/12496851/d3-force-graph-sticky-nodes * http://bl.ocks.org/mbostock/3750558 * Node size to reflect size of package. A small number of dependencies to a fat node might be best to tackle first. * Highlighting & Fisheye * http://www.coppelia.io/2014/07/an-a-to-z-of-extra-features-for-the-d3-force… * Mark in bootstrap-dependency-report-graph-data.csv <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> which dependencies you want to eliminate, so that others might have a play with visualisation. More exotic... * Serve the bootstrap-dependency-report-graph.html <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> and bootstrap-dependency-report-graph-data.csv <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> out from Zinc, so I can point my browser at my local Pharo Image, and when a dependency is deleted, the graph updates automagically * When I double-click a node in the graph, it selects that item in the dependency analyzer in Image. * I guess the same might be done with two local Images - Moose as the observer and Pharo as the subject. cheers -ben On Wed, Sep 9, 2015 at 5:33 PM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi, > > We now have a best overview of bootstrap dependencies. > You can check the latest report at > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > . > With Max, we reused Dijkstra algo in Moose to help finding dependencies > leading to Morphic and co. > It is now possible to have a visualization that is usable (there is also a > button to open it in the report): > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > Next steps are to cut dependencies in red in the report table. > > Christophe. > > ps: by the way the dependency analyzer (with fixes asked) will be > introduced soon in the image. > > > Le 4 sept. 2015 Ã 15:13, Christophe Demarey a Ã©crit : > > Hi, > > I created a job to automatically generate a report of the Pharo image > dependencies as well as current bootstrap dependencies. > You can find them here: > > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > > There are a lot (too many) dependencies but you can focus on some of them > with the search field. > Dependencies inside orange boxes are dependencies that are there but that > we ignore (for example, an example method adds an extra-dependency). It > should be fixed later but is not a problem for now. Ignored dependencies > are declared in the package manifest in #ignoredDependencies. > Dependencies inside red boxes are dependencies we want to remove for the > bootstrap. For now, they are listed in the bootstrap dependency report. > > People that are willing to help to have a more modular Pharo could first > take a look at the bootstrap dependency report and check dependencies that > we should cut. > Once we know, we can open issues on fogbugz in the 'bootstrap category' > and update manifests accordingly. > To investigate more deeply dependencies, you can use the > DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies > (inheritance, reference, extension, traits, message send). > > Regards, > Christophe. > > >

Sept. 9, 2015

Strategies with Nautilus announcements

by Yuriy Tymchuk

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)? Uko

Sept. 9, 2015