Hi,
In the latest version 1.313, DynaMoose seems to have lost its tests.
Is this by mistake, or is it intended?
Cheers,
Doru
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"The coherence of a trip is given by the clearness of the goal."
There was discussion if it might be possible to omit the list of
invocation candidates and just give the "most common candidate" and
derive all others.
Please find below an example where this does not work for statically
types languages.
The client class invokes m() on an instance of B. m is implement in
A (B's superclass) and C and D (B's subclasses), but also in E (a
sibling of B). Lets assume we just store the "most common candidate"
A.m and derive candidates looking at subclasses, then we get the
false positive E.m!
Another case (which applies to dynamic languages too) is when m() is
invoked using a super send somewhere in D, and we just store A.m()
and we derive it now, again D.m and E.m and C.m are false positive.
So at least you need information about
receiver type
signature (not yet 1st class in FAMIX!)
kind of lookup (self, super, whatever...)
whereas the "most specific candidate" encodes implementing type and
signature as string.
So for now, maybe best is to just store all candidates in any case.
cheers,
Toon and AA
Dear Moosers,
I was pondering over Famix and found that it only uses 20% of EMOF's
features. As it seems, the E in EMOF is not really standing for
essential :)
What I came up with when porting MSE to Java, is a much simpler mmmodel.
I documented it on the wiki
http://smallwiki.unibe.ch/moose/mse/msemmmodel/
would be nice to make this the new mmmodel of moose and get rid of
all the EMOF bloat.
by the way, a Java implementation is in its first draft, if you are
interested contact me.
cheers,
AA
Hi everyone,
As some of you know, I am working on a FAMIX importer for Eclipse
java source files, written in Smalltalk (using our JavaConnect
system). At this moment, the importer creates a FAMIX model with
classes, methods, namespaces and inheritance relations.
Now, I experience some strange behaviour of the Mondrian 'Screen
filling system complexity' visualisation. If you take a look at the
screenshot below, you can see the 'Event' class hierarchy. Well, that
is: a list of 'Event' classes and a hierarchy. The strange thing is
that the nodes in the flat line represent exactly the same entities
as the nodes in the hierarchy.
Maybe it's supposed to be this way? But this only appeared after I
added 'implements' relations to the model using
FamixInheritanceLinks. I verified if the model does not contain
duplicate entities for those classes (which would be an obvious
explanation). Inspecting the entities in the flat line did also
reveal they do have outgoingInheritance links.
So, I'm confused and hope you can shed some light on this :-)
ps: Tudor, I hope you got the importer to work now in Mac Intel?
ps2: For those interested in trying this: http://www.info.ucl.ac.be/
~jbrichau/penumbra.html . We're having trouble making JavaConnect run
on Windows, so any help to make it work is appreciated. The problem
is mainly in finding the correct java libraries to load. Idem for
Linux. Or if you can wait long enough, we will be working on an
integration with JNIPort too ;-)
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
Hi Sergio,
Nice to hear from you.
We use MOF as a meta-meta-model. FAMIX is an instance of MOF and it
is used as a meta-model. So, when you analyze a program you will get
a model that conforms to FAMIX.
FAMIX is a language independent meta-model, meaning that it is
basically a common denominator of various languages. For example, you
will not get all details of the AST in it, but you will get
invocations (calls between methods) and accesses (from methods to
variables).
A UML-like diagram of the current FAMIX 2.2 can be found at:
http://smallwiki.unibe.ch/moose/famixcore2.2metamodel/
So, if you want to define transformations and generate code, you will
probably need a more detailed model than FAMIX. But, if you just want
to reason about the code without caring much about the AST, than
FAMIX is more suitable.
However, given that Moose works at the level of the meta-meta-model,
it can accommodate other meta-models as well. For example, we have a
meta-model for analyzing dynamic information (Dynamix), historical
information (Hismo) or CVS information (Chronia).
We are now working on FAMIX 3.0. With this occasion we will redefine
some terms. For example, what is now known as FAMIX will become FAMIX-
Core, and we will explicitly define extensions to this Core.
For further questions, we strongly advise to join our moose-dev
mailing list at:
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On Oct 22, 2007, at 10:57 AM, Sergio Castro wrote:
> Dear MOOSE team,
>
> I am interested in understanding if I can used MOOSE for my research,
> but I am currently a bit confused about a couple of things.
>
> My idea was to use a language independent model of an object oriented
> program, and querying this model for obtaining Intensional Views of
> the
> software. After, I would like to make transformations on this model
> if I
> detect that some constraints over these software views do not hold,
> and
> finally generate source code that reflect the transformations
> accomplished in the model.
>
> My question is if the program representation used by MOOSE is rich
> enough to define over it any kind of software views based on the
> structural relationships of the source code elements the model was
> built
> from. Or in other words, which information from the source code I lost
> when I build my model in MOOSE?
>
> Another issue that confuses me is about FAMIX, from the "The Story of
> Moose" paper written by Nierstrasz, Ducasse and G?rba, it seemed to me
> that the FAMIX model was replaced with a MOF like meta model, but I
> found in the Moose wiki (http://smallwiki.unibe.ch/moose) a comment
> about the development of Famix 3.0. Is then FAMIX still part of MOOSE?
> or I misunderstood and the new MOF like meta model is a reengineered
> version of FAMIX?
>
>
> thanks in advance for any comment or orientation,
>
> Sergio Castro
>
> _______________________________________________
> Moose mailing list
> Moose(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"Being happy is a matter of choice."
Please find attached bugs in FAMIX 2.2
- Chronia.CvsFileVersion.comment has type Smalltalk.Core.Text instead of
primitive String
- Chronia.CvsFileVersion.timestamp has type Smalltalk.Core.Timestamp instead
of some primitive
- Chronia.Author has both name and Name as property, which fucks up code
generation
- Smalltalk.CvsModelRoot should be in package Chronia
- Smalltalk.Hapax package should be top level, not nested
- Smalltalk.Dude package should be top level, not nested
- Opposites do not match: DynaMoose.Alias.variable
- Opposites do not match: FAMIX.Method.activation
- Container must be single-values: Moose.Model.entity
- Opposites do not match: Moose.Model.mooseModel
- Container must be single-values: FAMIX.Package.definedClass
- Missing type: Chronia.Commit.startTime
- Missing type: Chronia.Commit.endTime
- Opposites do not match: FAMIX.AbstractStructuralEntity.accessedByList
- Opposites do not match: DynaMoose.Activation.argument
- May not have more than one container: FAMIX.Namespace
- Container must be single-values: FAMIX.Namespace.class
- Container must be single-values: FAMIX.Namespace.namespace
- Opposites do not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
- May not have more than one container: FAMIX.Class
- Container must be single-values: FAMIX.Class.attribute
- Opposites do not match: FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.accessedByList
- Opposites do not match: FAMIX.Class.outgoingInheritance
- Container must be single-values: FAMIX.Class.method
cheers,
AA
Hi everybody,
I have a question, more of an idea: should closures (or Smalltalk blocks) be
included in the meta-model?
You could see closure as a anonymous function, but with some special
properties.
They are becoming a very used feature in programming languages: Smalltalk,
Lisp, Scheme, Python, Ruby, Javascript and others have closures and even the
next versions of both Java and C# it's announced to have closures.
Any opinions?
Adrian Dozsa
Hi Doru,
I wanted to use the design disharmonies detection implemented in Moose.
Since my trials on both Java and Smalltalk systems failed, I would
like to know what is the development status here.
I saw that most of the identity and collaborative disharmonies rules
are implemented, at least for Java.
However, almost none of them returned a valid result (the metrics
that they are based on seem to return nil instead of a value).
Could you give me some hints on how to use them?
Maybe I'm doing something wrong here, I just tried something like:
aMooseModel allClasses select: [:each | each isBrainClass]
Thanks,
Ricky
There is a nice method in Behavior that is invoked when ever the
annotations of a class's methods change, would be nice to use that to
make Meta more causally connected. Would be nice if someone has time
to do that, refer to
> instanceMethodsChanged
> "One of the receiver's instance methods which has meta
> annotations changed. The method may have been removed,
> or may be about to be added. Because this action may be
> invoked many times, and because the change it reflects
> may not be completed yet, the receiver's response should
> probably be fairly limited (such as flushing a cache) rather
> than something more proactive, such as actively repopulating
> a data structure that records the state of things."
>
> ^self
Maybe that is also useful for you, Andrea.
cheers,
AA
Oops, forgot reply all.
On 26 Sep 2007, at 23:53 , Adrian Kuhn wrote:
> On 26 Sep 2007, at 18:30 , Tudor Girba wrote:
>
>> As for Meta and Hapax, Adrian said that he reserves the right to
>> license them and that we should discuss about it after we get the
>> agreement with the Unibe. But, in a follow up mail he changed his
>> mind and said that "if we come to some nice agreement with Univ its
>> okay to license these two bundles under BSD". I must admit that I am
>> a bit confused, but perhaps this was just another misunderstanding :)
>
> It is the same I wrote in my mail back then
>
>> All these are issues I'd like to be addresses and taken into account
>> when officially (re)licensing Moose now. Personally I would prefer to
>> have a license that allows us to be more specific about what we
>> consider to be fair use. But I am not strictly against BSD as well,
>> it would be even okay for me to license Meta as such if we find to
>> some agreement that ensures fairness for all involved parties
>
> and that still applies.
>
> AA
>
>
>
On 26 Sep 2007, at 16:33 , Orla Greevy wrote:
>>> In my opinion we should aim to be as flexible as the Java world
>>> tools
>>> e.g. Checkstyle, tomcat, etc.
>>
>> I do not understand.
>>
> In the case of the above mentioned tools, they can be used by
> anyone in any context, i.e. commerical or non commerical.
Which are usually under GPL or compatible. GPL has the nice property
that any non-commercial contributer can be sure no one will ever
commercialize his contributions; but still any commercial user can
use it or sell services on top of it, and in case of LGPL even build
products on top of it. My concern as researcher is that BSD does
fully satisfy the interest of non-commercial contributers in the same
way. Maybe that got lost in all the rant with Doru.
AA
Hi Adrian,
I saw that you removed Collection>>separatedBy: from CodeFoo. I
thought this was a nice method, and I looked for other similar
methods to use, but I cannot seem to find the right one.
What am I missing?
Doru
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"Value is always contextual."
Hello,
I am a new mooser, I am working on a Smalltalk project with VisualWorks. I am trying to write a unit test but I have a problem: I have not possibility to run and to step my test because I don't have the tools for it. Nevertheless, I have loaded the package StefFoo, my test class inherites from SUnit.TestCase.
What did I forget to run my tests?
Romain
Hey Stef, dear Moosers,
there is a new implementation of lazy (or dynamic, as I call them
now) inst vars for Moose. The new implementation is not based an wide
classes, but on anonymous subclasses, and includes very strict sanity
checks to guarantee type safety and Smalltalk's language model.
You may only extend a base class with an inst var, iff
name isString.
name isSymbol not.
name allSatisfy: #isLetter.
(case allInstVarNames includes: name) not.
class canUnderstand: name asSymbol.
class canUnderstand: (name copyWith: $:) asSymbol.
and you must implement the accessors in the class as follows
class >> foo
^self dynamicInstVarNamed: 'foo'
class >> foo: value
self dynamicInstVarNamed: 'foo' put: value
with this setup, we can guarantee that no tool is broken, neither the
browser, nor inspector and debugger or senders- and implementors-of.
Except for the first write access, access time on an dynamic instance
variable is guaranteed to be the same as for "normal" instance
variables.
Please refer to DynamicInstVars and DynamicInstVarsTest on SCG Store,
for a first draft implementation.
cheers,
AA
You are right.
On 3 Sep 2007, at 10:24 , Oscar Nierstrasz wrote:
>
> Aren't these emails supposed to be going to the moose-dev list?
>
> They are all being sent to scg-staff now.
>
> Oscar
>
> On Sep 3, 2007, at 10:10, Bergel, Alexandre wrote:
>
>>> Why touch the compiler, when two simple methods in Object can do
>>> the same?
>>
>> If WideClass is just an optimisation, then I should write my code
>> as if this mechanism is not present. Moreover, using a kind of
>> annotation mechanism will make legacy code to benefit from WideClass.
>>
>>>
>>> Also, when lazy inst vars are part of the class def, again we run
>>> into the limitation that they can not be a package extension.
>>> This is one of the needs we do have in Moose.
>>
>> As far as I understand, an ideal implementation of WC will have to
>> be in the VM. And this, for the same reason that lazy evaluation
>> in Haskel is implemented in the VM.
>>
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
As ESUG was so inspiring, I could not resist some VW hacking on the
train home...
If you browse to WideClass and WideClassTest on SCG Store, there is a
simple implementation of wide classes. As we have tons of empty inst
vars in moose models, that might help us to save some megas on large
case studies.
How to use it?
Sending #wide:put: to any object will install an instance var and
accessors on the receiver instance.
o := Object new.
o wide: #foo put: 4.
o foo
and even better, if you implement #foo and #foo: as follows
foo ^nil
foo: arg self wide: #foo put: arg
upon first execution of #foo: the foo inst var is installed and both
methods get properly overriden with simple accessors. There is no DNU
hack anywhere!
Hope you have some fun playing around with it!
cheers,
AA
Hi guys
As I mentioned during the moose workshop we would like to get your
evaluation of our ideas.
I would really like if you could perform the experiment described at:
http://lseg.free.fr/PackageBlueprints/
Stef
Hi,
Today I tried to import from mse files and I get the following
exception during the import:
"Message not understood: #accessedByLists"
Then, I tried to import a model from Smalltalk and to export it in
mse. Loading this fresh file generated the same exception. Could you
please fix this?
(I peeked a bit in the Moose code and it seems that
FAMIXAbstractStructuralEntity has an accessedByList attribute and two
pairs of accessors: #accessedByList and #accessedByLists and the
setters, too. Maybe it has something to do with this).
Thanks and cheers!
Ricky
PS. And another issue is that when I tried to load the latest
MooseDevelopment bundle, I got some packages that could not be loaded...
Hi,
I chatted with Travis Griggs and he showed me a package called
LessProgress. This packages replaces the ugly progress bars that
always get on top of any window with a small progress bar in the
Launcher (see attached picture).
To use it, you have to:
- load LessProgress (either from Cincom or from Bern Store)
- go to the Window menu in the Launcher
- New Launcher
- done
I put this in my base image.
Cheers,
Doru
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"We cannot reach the flow of things unless we let go."
