Moose-dev May 2009

moose-dev@list.inf.unibe.ch

15 participants
43 discussions

Re: Class Extensions
by Mircea Lungu 09 Jun '09

09 Jun '09

Hi Guys, I looked a bit in more detail at the class extensions problem. Here I bring a bit more to the discussion table. I attach a Snaut screenshot of an analysis session of Hapax + Code Foo. (seems attachment is too big for the mailinglist so here's a link: http://www.inf.unisi.ch/phd/lungu/files/ClassExtensionsInMoose.png) The panel on the right is the detail of the 91 invocations abstracted in the high-level dependency between Hapax Development and Visual Works. To the right of every method which is extended in a different package thabn Base VisualWorks you can see that package. What you will see is that althoug most of those dependencies are defined in othe packages than VisualWorks Base they still are abstracted in the relationship between Hapax and VisualWorks base. You will see that there is a dependency between hapax and Number>>pythag: which methoid is defined in Hapax itself. The reason is the following. A method, even when it is an extension (isExtension is True) belongsTo a class. And the class, logically, belongs to the namespace where it was initially defined and is, logically, packaged in the package it was initially defined in. When I compute the high-level depedencies in softwarenaut i aggregate them from methods to classes and from there up along the namespace of package hierarchy. Since the extended methods are placed in their original classes, I end up with dependencies between the wrong packages. The high-level dependencies in softwarenaut are wrong because the model can not express the existence of class extensions. I can see two solutions: - we introduce a FAMIXClassExtension as an explicit entity which is a class which has a reference to the extended class. maybe we can even introduce a new relationship which is Class Extension. - we piggyback the class extensions on top of the classes in a similar way the metaclasses are implemented. In our example, for Collection we would define a Collection class in CodeFoo, SqueakExtensions, EyeSee and ech one of these would only contain the methods that it defines. I am interested if anybody else is interested in this. And I want to hear your opinions. Cheers, Mircea.

5 14

Re: Test report
by Alexandre Bergel 28 May '09

28 May '09

A minor explanation: Mondrian has still some broken tests. These are essentially related to resizing nodes. This is a feature currently missing in the Pharo version of Mondrian. I will work on it soon, but for now, I do not want to remove failed tests, else the probability that it slips to the forgotten world will get higher. Cheers, Alexandre On 28 May 2009, at 11:12, Simon Denier wrote: > Mondrian: 127 run, 110 passes, 0 expected failures, 3 failures, 14 > errors, 0 unexpected passes - 28 May 2009 5:04:39 pm > > Glamour: 55 run, 55 passes, 0 expected failures, 0 failures, 0 > errors, 0 unexpected passes - 28 May 2009 5:05:13 pm > > Fame: 168 run, 168 passes, 0 expected failures, 0 failures, 0 > errors, 0 unexpected passes - 28 May 2009 5:05:40 pm > > Moose: 319 run, 311 passes, 0 expected failures, 5 failures, 3 > errors, 0 unexpected passes - 28 May 2009 5:08:39 pm > > Moose_CookTest: 268 run, 224 passes, 0 expected failures, 4 > failures, 40 errors, 0 unexpected passes - 28 May 2009 5:11:10 pm > > Moose_Famix2: 188 run, 143 passes, 0 expected failures, 43 failures, > 2 errors, 0 unexpected passes - 28 May 2009 5:12:08 pm > > ******************************************************************************** > SqueakSource project: Mondrian > Packages loaded: Mondrian. > 127 run, 110 passes, 0 expected failures, 3 failures, 14 errors, 0 > unexpected passes > > Beginning of test: 28 May 2009 5:04:39 p > m > End of test: 28 May 2009 5:04:48 pm > > ------------------- > Failed Tests: > ------------------- > MOFormsBuilderTest>>#testRecomputePreferredBounds > MOFormsBuilderTest>>#testPxSize > MOLayoutTest>>#testContextTransfer > ------------------- > > > ------------------- > Error Tests: > ------------------- > MOFormsBuilderTest>>#testColumnCenterResize > MOFormsBuilderTest>>#testColumnFillResize > MOFormsBuilderTest>>#testColumnLeftResize > MOFormsBuilderTest>>#testColumnRightResize > MOFormsBuilderTest>>#testOoApi > MOFormsBuilderTest>>#testPxReSize > MOFormsBuilderTest>>#testRowBottomResize > MOFormsBuilderTest>>#testRowCenterResize > MOFormsBuilderTest>>#testRowFillResize > MOFormsBuilderTest>>#testRowTopResize > MOLayoutTest>>#testDominanceTreeLayout > MOLayoutTest>>#testScatterplot > MOLayoutTest>>#testScatterplotLayout > MOLayoutTest>>#testTransparentEdges > ------------------- > > > > Content generated by TestServer-simon_denier.36 > ******************************************************************************** > SqueakSourc > e project: Glamour > Packages loaded: Glamour-All. Glamour-Morphic. > 55 run, 55 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes > > Beginning of test: 28 May 2009 5:05:13 pm > End of test: 28 May 2009 5:05:13 pm > > ------------------- > Failed Tests: > ------------------- > ------------------- > > > ------------------- > Error Tests: > ------------------- > ------------------- > > > > Content generated by TestServer-simon_denier.36 > ******************************************************************************** > SqueakSource project: Fame > Packages loaded: Fame. > 168 run, 168 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes > > Beginning of test: 28 May 2009 5:05:40 pm > End of test: 28 May 2009 5:05:41 pm > > ------------------- > Failed Tests: > ------------------- > ------------------- > > > ------------------- > Error Tests: > ------------------- > ------------------- > > > > Content generated by TestServer-simon_denier.36 > ******************************************************************************** > SqueakSource project: Moose > Packages loaded > : Moose-All. > 319 run, 311 passes, 0 expected failures, 5 failures, 3 errors, 0 > unexpected passes > > Beginning of test: 28 May 2009 5:08:39 pm > End of test: 28 May 2009 5:10:33 pm > > ------------------- > Failed Tests: > ------------------- > HismoTest>>#testAttributeHistoriesCreation > ModelTest>>#testAddingAndRemoving > UtilitiesTest>>#testSmalltalkClassNameFromFamixClassName > FamixReferenceModelImporterTest>>#testExtensionPackage > FamixPropertiesTest>>#testClassComments > ------------------- > > > ------------------- > Error Tests: > ------------------- > FamixReferenceModelImporterTest>>#testExternalExtension > HismoTest>>#testSelectByExpression > HismoTest>>#testYesterdaysWeather > ------------------- > > > > Content generated by TestServer-simon_denier.36 > ******************************************************************************** > SqueakSource project: Moose > Packages loaded: CookTest. > 268 run, 224 passes, 0 expected failures, 4 failures, 40 errors, 0 > unexpected passes > > Beginning of test: 28 May 200 > 9 5:11:10 pm > End of test: 28 May 2009 5:11:18 pm > > ------------------- > Failed Tests: > ------------------- > FAMIXMethodNavigationTest > >>#testSureReferencedDefinedIntoAndPackagedInto > FAMIXMethodNavigationTest>>#testSureReferencedMethodsDefinedInto > FAMIXMethodNavigationTest>>#testSureReferencedMethods > FAMIXMethodNavigationTest>>#testSureReferencedPackages > ------------------- > > > ------------------- > Error Tests: > ------------------- > FAMIXClassNavigationTest > >>#testEachOutgoingReferenceImpliesAnIncomingReference > FAMIXClassNavigationTest > > > >#testEachPotentialOutgoingReferenceImpliesAPotentialIncomingReference > FAMIXPackageNavigationTest>>#testClientClasses > FAMIXPackageNavigationTest>>#testClientClassesInto > FAMIXPackageNavigationTest>>#testClientPackages > FAMIXPackageNavigationTest > >>#testEachOutgoingReferenceImpliesAnIncomingReference > FAMIXPackageNavigationTest > > > >#testEachPotentialOutgoingReferenceImpliesAPotentialIncomingReference > FAMIXPackageNavigationTest>>#testEachStaticOutgoingReference > ImpliesAStaticIncomingReference > FAMIXPackageNavigationTest > >>#testEachSureOutgoingReferenceImpliesASureIncomingReference > FAMIXPackageNavigationTest > >>#testIncomingDependenciesAreEitherReferencesOrInheritances > FAMIXPackageNavigationTest > >>#testIncomingReferencesAreEitherPotentialOrSureOrStatic > FAMIXPackageNavigationTest > >>#testOutgoingDependenciesAreEitherReferencesOrInheritances > FAMIXPackageNavigationTest > >>#testOutgoingReferencesAreEitherPotentialOrSureOrStatic > FAMIXPackageNavigationTest>>#testPotentialReferencedClasses > FAMIXPackageNavigationTest>>#testPotentialReferencedClassesInto > FAMIXPackageNavigationTest>>#testPotentialReferencedPackages > FAMIXPackageNavigationTest>>#testPotentialReferencingClasses > FAMIXPackageNavigationTest>>#testPotentialReferencingClassesInto > FAMIXPackageNavigationTest>>#testPotentialReferencingPackages > FAMIXPackageNavigationTest>>#testProviderClasses > FAMIXPackageNavigationTest>>#testProviderClassesInto > FAMIXPackageNavigationTest>>#testProviderPackages > FA > MIXPackageNavigationTest>>#testReferencedClasses > FAMIXPackageNavigationTest>>#testReferencedClassesInto > FAMIXPackageNavigationTest>>#testReferencedPackages > FAMIXPackageNavigationTest>>#testReferencingClasses > FAMIXPackageNavigationTest>>#testReferencingClassesInto > FAMIXPackageNavigationTest>>#testReferencingPackages > FAMIXPackageNavigationTest>>#testStaticClientClassesInto > FAMIXPackageNavigationTest>>#testStaticProviderClasses > FAMIXPackageNavigationTest>>#testStaticProviderClassesInto > FAMIXPackageNavigationTest>>#testStaticProviderPackages > FAMIXPackageNavigationTest>>#testStaticReferencedClasses > FAMIXPackageNavigationTest>>#testStaticReferencedClassesInto > FAMIXPackageNavigationTest>>#testStaticReferencedPackages > FAMIXPackageNavigationTest>>#testStaticReferencingClassesInto > FAMIXPackageNavigationTest>>#testSureReferencedClasses > FAMIXPackageNavigationTest > >>#testSureReferencedClassesIncludeAllStaticReferencedClasses > FAMIXPackageNavigationTest>>#testSureReferencedClassesInto > FAMIX > PackageNavigationTest>>#testSureReferencedPackages > ------------------- > > > > Content generated by TestServer-simon_denier.36 > ******************************************************************************** > SqueakSource project: Moose > Packages loaded: FAMIX2-All. > 188 run, 143 passes, 0 expected failures, 43 failures, 2 errors, 0 > unexpected passes > > Beginning of test: 28 May 2009 5:12:08 pm > End of test: 28 May 2009 5:12:21 pm > > ------------------- > Failed Tests: > ------------------- > FAMIX2ReferenceModelImporterTest > >>#testAccessingImportedClassWithinReturnVariable > FAMIX2ReferenceModelImporterTest > >>#testAccessingStubClassWithinReturnVariable > FAMIX2ReferenceModelImporterTest>>#testSingleSelfSend > FAMIX2ReferenceModelImporterTest>>#testAccessReadOnly > FAMIX2ReferenceModelImporterTest>>#testSingleSelfSendOnClassSide > FAMIX2PropertiesTest>>#testClassInvocations > FAMIX2PropertiesTest>>#testMethodsSimpleProperties > FAMIX2ReferenceModelImporterTest > >>#testaccessSharedVariableOfSuperclassInstan > ceSide > FAMIX2PropertiesTest>>#testMethodHierarchyNesting > FAMIX2PropertiesTest>>#testMethodName > FAMIX2ReferenceModelImporterTest>>#testInstVariableAccessInSuperClass > FAMIX2PropertiesTest>>#testClassWeightedMethodCount > FAMIX2ReferenceModelImporterTest > >>#testaccessSharedVariableOfSuperclassClassSide2 > FAMIX2PropertiesTest>>#testMethodSmalltalkStatements > FAMIX2ReferenceModelImporterTest>>#testAccessWriteOnly > FAMIX2PropertiesTest>>#testMethodSmalltalkMessageSends > FAMIX2PropertiesTest>>#testClassHierarchy > FAMIX2PropertiesTest>>#testAttributeMetrics > FAMIX2ReferenceModelImporterTest>>#testSelfAccessInDefiningClass > FAMIX2ReferenceModelImporterTest>>#testAccessingFormalParameter > FAMIX2ReferenceModelImporterTest>>#testAccessingLocalVariable > FAMIX2ReferenceModelImporterTest > >>#testSelfAccessInDefiningClassOnClassSide > FAMIX2LANImporterTest>>#testIncomingInvocationReification > FAMIX2ReferenceModelImporterTest > >>#testAccessingGlobalVariableFromInstanceSide > FAMIX2ReferenceModelImporterTest>>#te > stClassSelfSend > FAMIX2PropertiesTest>>#testMethodSmalltalkParameters > FAMIX2ReferenceModelImporterTest > >>#testInstVariableAccessTwiceTheSameVariable > FAMIX2ReferenceModelImporterTest > >>#testaccessSharedVariableFromTheInstanceSide > FAMIX2PropertiesTest>>#testMethodSmalltalkCyclomaticComplexity > FAMIX2ReferenceModelImporterTest > >>#testInstVariableAccessInDefiningClass > FAMIX2PropertiesTest>>#testMethodSmalltalkConditionals > FAMIX2ReferenceModelImporterTest>>#testAccessingNamespace > FAMIX2PropertiesTest>>#testMethodInvocations > FAMIX2ReferenceModelImporterTest>>#testReadAndWrite > FAMIX2PropertiesTest>>#testClassCategories > FAMIX2ReferenceModelImporterTest>>#testSingleSelfSendWithReturn > FAMIX2PropertiesTest>>#testClassAttributes > FAMIX2ReferenceModelImporterTest>>#testUnknownVariableAccess > FAMIX2PropertiesTest>>#testClassMethods > FAMIX2ReferenceModelImporterTest > >>#testInstVariableAccessInDefiningMetaclass > FAMIX2ReferenceModelImporterTest > >>#testaccessSharedVariableOfSuperclassClassSide > FAMIX2Re > ferenceModelImporterTest>>#testStubSharedVariableAccessShortName > FAMIX2ReferenceModelImporterTest > >>#testaccessSharedVariableFromTheClassSide > ------------------- > > > ------------------- > Error Tests: > ------------------- > FAMIX2ModelExtractionTest>>#testAllLocalVariables > FAMIX2PropertiesTest>>#testClassAllProperties > ------------------- > > > > Content generated by TestServer-simon_denier.36 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Unicode comment breaks the mse exporter
by Mircea Lungu 26 May '09

26 May '09

Hi guys, I am not trying to spam the list. It is just that I keep running into a bunch of issues these days. I am export an mse model of CodeFoo (actually the same exception is raised for a few other models). The exporter crashes when it tries to write out a comment which contains some unicode characters. The comment is in Character>>initCyrillicSmallCapital The raised exception is "This character is not supported by this class of string". I think the solution would be to open the mse file stream as utf-8 encoded. I wonder if the importer would still work then. The other option is to simply not print the unicode comments. Cheers, Mircea.

3 3

Class Extensions
by Mircea Lungu 25 May '09

25 May '09

Hey guys, If I import bundle X in Moose, MooseModel>>allModelClasses returns also the classes which are extended in bundle X. However, the class itself does not know that it is an extension. On top of that, the class is imported with all the methods that are defined in all the image, not only the overriden ones. This class (with all the imported methods) is however not part of my model. My first question is: how do I know if a class is an extension? I've seen that a method answers to the #isExtension message. I could also define an isExtension in the class which considers a class an extension if it contains at least an extended method. Any reason why this would not work? Second, if we know that a class is an extension, should we change the implementation of allModelClasses so it does not return the extensions? Thanks, A nice evening, Mircea.

2 1

Smalltalk Parser Fails
by Mircea Lungu 23 May '09

23 May '09

Hi guys, I am using the last MooseConfig 1.28 from the bern Store on Visual Works. I am trying to import moose and a few other systems in moose. The parser fails when parsing some test methods in the (DynaMooseTests, MooseUIExtensions, MetaTests). What all these methods have in common is definitions of arrays like in the following example method: ------------- modelSpec ^ #(Moose.Model (entity (FAMIX.Package (id: 1) (name P1)) (FAMIX.Package (id: 2) (name P2) (packagedIn (idref: 1))) (FAMIX.Class (id: 5) (name C5) (packagedIn (idref: 2))) (FAMIX.Class (id: 6) (name C6) (packagedIn (idref: 2))) (FAMIX.Class (id: 7) (name C7) (packagedIn (idref: 2))) (FAMIX.Package (id: 3) (name P3) (packagedIn (idref: 1))) (FAMIX.Class (id: 8) (name C8) (packagedIn (idref: 3))) (FAMIX.Class (id: 9) (name C9) (packagedIn (idref: 3))) (FAMIX.Class (id: 4) (name C4) (packagedIn (idref: 1))) )) ------------- Did anybody encounter anything like this? If so, is there a patch for it? Thanks, Mircea.

5 10

Fwd: [MC] Re: Metacello - versionMap: contional elements
by stephane ducasse 22 May '09

22 May '09

I do not have the time but this would be useful experience to do. stef Begin forwarded message: > From: Dale Henrichs <dale.henrichs(a)gemstone.com> > Date: May 22, 2009 6:43:50 PM CEDT > To: monticello-dev(a)googlegroups.com > Subject: [MC] Re: Metacello - versionMap: contional elements > Reply-To: monticello-dev(a)googlegroups.com > > > > ----- "stephane ducasse" <stephane.ducasse(a)gmail.com> wrote: > > | On May 22, 2009, at 12:28 AM, Dale Henrichs wrote: > | > | > > | > In Metacello, the versionMap is _the_ package management artifact. > | > Developers in a software project use the versionMap to communicate > | > to other developers (consumers of their software project): > | > > | > - which packages belong to a particular version of the software > | > project > | > - the load order of the packages on a version by version basis > | > - the operations to be performed pre/post load/unload. > | > - which other versionMaps (software projects) are required for a > | > particular > | > version to function correctly. > | > - which groups of packages are intended to work together as > loadable > | > units. > | > | sounds good to me. > | Dale I think that when you have something stable we could give a try > | to manage moose with it. > > Stef, > > The current version is stable (Metacello-dkh.147). I'm holding off > development until I feel comfortable with the requirements for the > next wholesale rewrite. > > I think it would be useful for you to take a cut at using Metacello > to configure Moose and identify the things that are difficult to > express or just plain wacky:) There should be enough functionality > there for you to do a proof-of-concept for Moose. > > WAVersionMap is a functional prototype and is based on Metacello-dkh. > 147, so I'd recommend that you use WAVersionMap as a guide as to > what you can and can't do and then asking me questions if things > aren't obvious. With that said, be prepared to toss everything > you've done for Moose against Metacello-dkh.147, because the API > will be changing with the next rewrite. > > Dale > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Monticello Development" group. > To post to this group, send email to monticello-dev(a)googlegroups.com > To unsubscribe from this group, send email to monticello-dev+unsubscribe(a)googlegroups.com > For more options, visit this group at http://groups.google.com/group/monticello-dev?hl=en > -~----------~----~----~----~------~----~------~--~--- >

1 0

modifying a moosemodel
by Alexandre Bergel 21 May '09

21 May '09

Hi! Something I thought about. Since some people (including Hany and Jannik) are getting an interest in modifying moose models, an event mechanism will probably be needed, pretty much as it is needed in Pharo. We could then imagine a hierarchy: MooseAnnouncement MooseAddedClass MooseRemovedMethod ... Easy to do though Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Glamour Mondrian
by Laval Jannik 20 May '09

20 May '09

Hi Doru, when I make a Glamour browser with a mondrian view, the size of the mondrian panel is fixed. In a previous version, it is not. Is it possible to change this behaviour in my code ? My code is: --------- littleOrionBrowser | browser | browser := GLMTableLayoutBrowser new. browser column: #models; column: #changedElements. browser showOn: #models; using: [ browser list format:[:system | system name]; display: [:system | system orionModels]]. browser showOn: #changedElements; from: #models; using: [ browser list display: [:model | model orionSystem currentModel: model. model entities select: [:element | element mooseModel = model] ]]. browser sendToOutside: #model from:#models. ^ browser ---------- withVisual | browser | browser := GLMTableLayoutBrowser new. browser row: #textual; row: #visual. browser showOn: #textual; using:[ browser custom: self littleOrionBrowser.]. browser showOn: #visual; from:#textual->#model; using:[ browser mondrian title: 'DSM'; painting: [ :view :model | (model allPackages viewDSMOn: view)]]. browser sendToOutside: #model from:#textual->#model. ^ browser ---------- I use the method withVisual. Thanks for your help. Cheers --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

2 2

MooseLoader load -> does not work
by Stéphane Ducasse 20 May '09

20 May '09

This package depends on the following classes: OBPluggableTextMorphWithShout OBTextMorphWithShout You must resolve these dependencies before you will be able to load these definitions: MOEaselTextEditor MOEaselTextEditor>>bindingOf: MOEaselTextEditor>>hasBindingOf: MOEaselTextEditor>>hasBindingThatBeginsWith: MOEaselTextEditor>>textMorphClass MOTextMorphWithShout MOTextMorphWithShout>>doIt Select Proceed to continue, or close this window to cancel the operation.

3 4

make a package Moose-Release
by Laval Jannik 20 May '09

20 May '09

Hi all, A lot of things have been broken in the last days. So, Moose, Mondrian, Glamour and DSM works fine in Sattose... now bugs appear everywhere. It could be cool to have a package Moose-Release, where we put stable packages, or make a MooseRelease-Loader. --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2009