Just to announce that external class extensions are now correctly
imported in the last version of Moose.
To explain: if you import a package A which made class extensions to
classes of a package external to the import (say Kernel), such
extensions were not taken into account.
Only class extensions made to classes of package A were taken into
account before.
Also got the count of failing tests down to 2 and of error test down
to 1.
--
Simon
hi all
I would like to know the stability of PhMondrian.
Apparently Jannik got problem and had to disable caches.
What is your experience with it.
In particular I would also like to know whether PackageBlueprint works
on
sqMoose. Would be nice to rescue this nice visualization.
In addition is distribution map (the real version) working on PhMoose
or PhMondrian?
Stef
Dear List,
FAMIXNamedEntity has a variables named receivingInvocations.
FAMIXBehaviouralEntity, a subclass of FAMIXNamedEntity, has a variable
incomingInvocations
What is the difference between the two? Leftover of Famix2 ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.
Begin forwarded message:
> From: Fabrice Bellingard <fbellingard(a)qualixo.com>
> Date: June 8, 2009 10:57:24 AM CEDT
> To: Projet de recherche Squale <recherche(a)squale.org>
> Subject: [Recherche] [WP 1.2] JS lib de visualisation
> Reply-To: Projet de recherche Squale <recherche(a)squale.org>
>
> Pour info, je suis tombé sur cette bibliothèque Javascript proposant
> différentes visualisations : http://thejit.org
>
>
> ----
> Best regards / Cordialement,
>
> - Fabrice BELLINGARD
> _______________________________________________
> Recherche mailing list
> Recherche(a)squale.org
> http://squale.org/cgi-bin/mailman/listinfo/recherche
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
> -~----------~----~----~----~------~----~------~--~---
>
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
---
Ok, it makes sense. I just loaded the last version of ConAn, but some
error popped up. What is the status ? Where you happy about the
implementation?
I can port SCG-Algorithm to Pharo, this shouldn't be a problem since I
am experienced in this kind of porting.
I suggest to use the Moose mailing list for FCA related discussion.
Cheers,
Alexandre
On 19 May 2009, at 05:13, Gabriela Arevalo wrote:
> Hi Alex,
>
> In fact, this is because when I finished my phd, my prototype was
> almost broken due to the continuous changes in moose.
> So I decided that the next version of ConAn would be Moose
> independent to avoid to suffer with Moose evolution and also to be
> able to work with any domain (not necessary related to Moose). The
> implementation you have seen is something I started last year
> recovering my code from my prototype in Store in Bern.
> I know the advantages of FAMIXEntity, but it was a nightmare to
> repair ConAn in the times that Moose changes a lot.
>
> Anyway, and considering that moose seems to be stable, I think that
> we can make it a subclass of that class. I should think about it.
>
> cheers,
>
> gabi
>
> PS: When are you moving to Chile?
>> Hi Gabriela,
>>
>> I was wondering why your implementation of FCA isn't implemented as
>> an extension of FAMIX. Even if FCA has little to do with Structural
>> entities in OO languages, FAMIXEntity could be inherited. For
>> example, why FormalConcept is not a subclass of it?
>>
>> Cheers,
>> Alexandre
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
When I want to open a MooseBrowser, a warning appears:
'Old implementation removed since it was not license clean.'
This is because in MSEPragmaProcessor>>processClass:, there is "aClass
methodDictionary do: [ ---something---]"
methodDictionary is a MethodDictionary. And in this class the method
do: is deprecated in the last version of pharo.
How can I replace it ?
The old method is:
---
do: aBlock
tally = 0 ifTrue: [^ self].
1 to: self basicSize do:
[:i | (self basicAt: i) == nil ifFalse:
[aBlock value: (array at: i)]]
---
Thanks
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.euhttp://rmod.lille.inria.fr
---
Dear list
With the latest Moose update, it is now possible to load Pharo into
Moose in less than a minute.
However, after loading Moose, you need to run PackageOrganizerCache
buildSystemCache (it takes less than 2 minutes to run).
Not sure if I really want to store this cache in MC for the moment
--
Simon
Hi,
I am reviewing the FAMIX implementation in Pharo. It looks pretty
nice, but here are a couple of issues:
- FAMIX-Extensions harbors right now mostly implementation details
(like accept:). I would move them to FAMIX-Implementation
- FAMIXSourceAnchor should be extended to deal with various source
anchor implementations.
- We need extensions to support Exceptions and Annotations
If it is Ok with everyone I will go on and tackle these issues.
Cheers,
Doru
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
Hi all,
I have loaded the last version of MondrianLoader in an image 279 and
another 304.
In both, when mondrian is loaded, I can not use my keyboard in the
workspace.
Has anyone the same problem ?
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.euhttp://rmod.lille.inria.fr
---
