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.
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.
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.
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.
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
> -~----------~----~----~----~------~----~------~--~---
>
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.euhttp://rmod.lille.inria.fr
---
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.
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.euhttp://rmod.lille.inria.fr
---
