I just discovered that all models are kept in the image, even if you
remove it. SmallBrother records all events which keeps references.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear All,
Each famix function and method has a set of outgoing variable
accesses. Can this set contain an element more than once? In other
words, how a method that accesses twice the same variable be
represented?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
> -~----------~----~----~----~------~----~------~--~---
>