Hi
I would like to give a try to do something else than latex.
Is there a list of bugs that I can work on?
Adrian you mentioned __state__ to finish and I know that Task was
left not totally finished.
Could you put your todo with the probability that you will work on them?
Stef
Dear Moose mailing list,
I am not sure whether the late hours is making me miss something
obvious, but how can I create an instance of a model, and populate it
with instances of Famix class ?
Cheers,
Alexanre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding
Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when
using the Moose GUI façade.
I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part
of. But I do not know how to set it.
the error comes from the method:
FAMIXAbstractStruture >>incomingAccesses
^self entityGroups at: #incomingAccesses ifAbsentPut: [self
mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the
SCGStore.
I attached a short java file to try this. Once the package loaded,
click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Was wondering how comes that the class Importer inherits from
collection? Is an importer really a collection?
Again, sorry in case of a naive question
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Was wondering how comes that the class Importer inherits from
collection? Is an importer really a collection?
Again, sorry in case of a naive question
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Sorry if my question illustrates my ignore in Moose :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi guys
I would like to know how we will migrate to FAMIX20 to 30
because I would like also to extract references (if I remember we
will have access and references).
And I'm right now chasing a bug in references extraction.
Stef
Hi,
I totally agree that the "base programmer" needs to be supported, but
on the other hand we should offer the tools to extend Moose. It is
just that I do not understand exactly what the advantages/
disadvantages are, and I propose to start a discussion on that.
I do not understand exactly the solution, but here is what I
understood as the reasons for wide classes:
1. extend the state of a class from another package
2. save memory by only allocating a instance variable slot when it is
used
3. (speed?)
1. In VW we can extend the methods and that allowed us to have a nice
extensible architecture. In the same way, we should be able to extend
the state as well, for example for caching results performed by a
method extension.
That is why currently, we have __state__ in each entity that has
dictionaries for storing such results, and we wrap the calls to
__state__ in setters and getters. For example, in DynaMoose we have:
FAMIXClass>>instances
^self __state__ attributeGet: #instances initializer:
[ OrderedCollection new ]
FAMIXClass>>instances: aCollection
^self __state__ attributeSet: #instances value: aCollection
The symbol is only used here. All tools work nicely with that
(actually, in VW looking for senders of a method will also get you
the usages of the symbol). This mechanism is crucial for extending
the meta-model.
The wide classes solution would pose the same overhead on the
programmer.
2. The second reason for the wide classes is to reduce the memory
footprint, because you will only get a slot if you use it.
The current solution will create a dictionary for all instance
variables extensions and an entry for each of them. I would be
curious to see what the difference is.
3. Speed. I am definitely not sure about this point, but wide classes
should be faster than looking into a dictionary. But, I do not
believe this has a real impact over the overall performance, in
particular given that the dictionary are rather small.
Of course, you can just bash anything I wrote here :)
Doru
--
www.tudorgirba.comwww.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
Hmm, I was about to write that the goal of collective behavior is to
model the behavior of the groups (like you demoed at ESUG), and I
wanted to ask how do you store this behavior in Store.
Now I see that I misunderstood completely. From the arguments below,
I believe it is not really worth the trouble.
Doru
>> B1) the reasons for collective behavior
>>
>
> To save memory.
>
> Each moose element has a back pointer to its model. This is 4 byte
> per element, ie 4 MB per 1 Mio elements. Which are realistic maybe
> even low numbers when analysing histories or traces. With collective
> behavior the memory footprint is (4 + F) * M * T, where F is the size
> of an anonymous class, M is the number of models and T is the number
> of element types used per model. Given that F is about 80 byte
> (including object headers and metaclasses etc pp) and T maybe about
> 25, that is 2 KB = 0.002 MB per Model.
>
>
>> B2) the solutions for collective behavior
>>
>> I propose to talk about each of these two points individually,
>> because they are not the same to me.
>
--
www.tudorgirba.comwww.tudorgirba.com/blog
"Some battles are better lost than fought."
Hi,
A new webpage based on Pier is up and running at: http://
moose.unibe.ch .
Feedback is welcome :).
Here is an overview:
-- the front page is supposed to offer all sorts of entry points into
the contents.
-- publications are read from a bib file that contains the entries
from scg.bib that are marked as moose-pub. For each publication a
page is created whose title is the title of the paper, the url is the
key of the entry and the tags of the page are the keywords of the
entry. This is useful for the publications cloud that you can see on
the front page.
I spent quite some time to add missing moose-pub keywords and to add
several other keywords. Now that the keywords are actually used,
perhaps we will have an incentive to add some more for our
publications :)
-- on the front page there is a place for a highlight that is
randomly shown. At the moment there are just 2 movies with Mondrian.
It would be cool to have more such videos with your nice tools :). To
add your highlight, you have to add a page below randomhighlight
similar to:
http://moose.unibe.ch/randomhighlight/videomondrianbasics
-- on the tools page, each tool has a page allocated. You can add
tags in each tool page, and these keywords are taken into account in
the tools cloud. For example, you can specify whether the tool is in-
visualworks or in-java.
-- there is a news feed. At the moment it is broken due to some
Apache settings or something :), but it should be available at:
http://moose.unibe.ch/news?view=PBEntriesRssView
-- the site contains the content from the Smallwiki page. I also took
the liberty to copy some content from personal sites (like codecity
or softwarenaut). I hope that is Ok.
-- you can follow the changes via RSS:
http://moose.unibe.ch/?view=PRChangesRssView
-- the webpage is persisted in the image, and the image is scheduled
to be saved under a different name 1 hour after a change.
You need a user to change the page, please ask me for one. There are
two types of users: admin and editor. The admin can do everything,
while the editor can just edit :). You will probably get an editor user.
Further details about how to edit the site can be found at:
http://moose.unibe.ch/varia/howtoedit
This is just version 1. There are several things that are still in plan:
- make publications updated periodically from external urls.
Currently it is updated manually.
- make the tool page a special component that has explicit links to
publications and developers. The tool should also have an explicit
license field.
- port the Store queries from VW to Squeak to create activity reports.
- add last update information on each page.
- work on the css to make it use a better alignment
Cheers,
Doru
p.s. I would like to thank Lukas Renggli and Adrian Lienhard for
their help and patience :).
--
www.tudorgirba.comwww.tudorgirba.com/blog
"We cannot reach the flow of things unless we let go."
> From: Tudor Girba <girba(a)iam.unibe.ch>
> Date: November 22, 2007 11:51:01 AM GMT+01:00
> To: Toon Verwaest <toon.verwaest(a)gmail.com>
> Cc: Moose-dev Moose Dev <moose-dev(a)iam.unibe.ch>
> Subject: Re: moose.unibe.ch
>
> Indeed, this is the main rule of web design.
>
> But, in this case, the problem is in Pier. I will fix it soon.
>
> Doru
>
>
>
>
> On Nov 22, 2007, at 11:21 AM, Toon Verwaest wrote:
>
>> This is how your moosepage looks on firefox. Since 44.68% of your
>> visitors come from firefox (+3% mozilla). I would strongly advice
>> you to have a look at designing the site so its compatible with
>> non-safari browsers. On internet explorer it already looks fairly
>> ok but not great either. And actually, safari represents only 15%
>> of the users, so only 15% of the users see the page correctly.
>> Isn't this one of the major web design rules?
>>
>> cheers
>> Toon
>
>
>
> --
> www.tudorgirba.com
> www.tudorgirba.com/blog
>
> "Obvious things are difficult to teach."
>
>
--
www.tudorgirba.comwww.tudorgirba.com/blog
"One cannot do more than one can do."
Toon and me created a moose-dev channel on freenode to hang around,
please feel free to join us
irc://chat.freenode.net:8000/moose-dev
Is this a correct IRC link? ... we'll see :)
cheers,
AA
When i try to load moose config 1.23 in a fresh image i get the
following error:
Warning: Package "HapaxNamespace" cannot be loaded.
The following classes cannot be loaded because their environment is not
in the image nor in the package being loaded:
LICENSE (environment path: Root.Smalltalk.Hapax)
When i hit ok anyway, i get a lot of unloadable class definitions
Warning: Package "Clustering" cannot be loaded.
The following classes cannot be loaded because their environment is not
in the image nor in the package being loaded:
CorrelationSquare (environment path: Root.Smalltalk.Hapax)
ClusterTest (environment path: Root.Smalltalk.Hapax)
CorrelationVector (environment path: Root.Smalltalk.Hapax)
DendrogramLeaf (environment path: Root.Smalltalk.Hapax)
ClusteringData (environment path: Root.Smalltalk.Hapax)
TimeWarpingEngine (environment path: Root.Smalltalk.Hapax)
ValueItem (environment path: Root.Smalltalk.Hapax)
CollectionItem (environment path: Root.Smalltalk.Hapax)
DistanceSquare (environment path: Root.Smalltalk.Hapax)
ClusterEngine (environment path: Root.Smalltalk.Hapax)
SeriationEngine (environment path: Root.Smalltalk.Hapax)
Dendrogram (environment path: Root.Smalltalk.Hapax)
DendrogramTest (environment path: Root.Smalltalk.Hapax)
ClusteringVector (environment path: Root.Smalltalk.Hapax)
DendrogramNode (environment path: Root.Smalltalk.Hapax)
VectorItem (environment path: Root.Smalltalk.Hapax)
FeatureCollection (environment path: Root.Smalltalk.Hapax)
etc...
Cheers,
Matt
Hi,
I am trying to load my prerequisites (MooseDevelopment) and first I
get this:
"Warning: Package "Meta-FM3-Model" cannot be loaded.
The following classes cannot be loaded because their environment is
not in the image nor in the package being loaded:
MultivalueLink (environment path: Root.Smalltalk.Meta)"
Followed by a bunch of unloadable definitions in Meta.
After loading everything I could, I try to initialize the meta
descriptions and I get:
"Unhandled exception: Message not understood: #on:opposite:
UndefinedObject(Object)>>doesNotUnderstand:
EMOF.Class>>initialize
..."
Could you guys fix it?
Thanks,
Ricky
Hi Moose-Dev-Team,
i´m currently trying to install Moose with the Moose Suite Loader in
Visual Works 7.5. When i try to download the suite, the first dialog
tells me "currently disconnected, do you want to reconnect?" so sure i
want, so clicking yes leads me to the next problem that tells me "A
problem was detected. Please try again".
The status window in VisualWorks tells me:
"
visualnc.im created at April 17, 2007 10:52:24 amERROR: current
transaction is aborted, commands ignored until end of transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
...
"
I hope you can help me to install the Moose Suite because i want to use
it in my diplom-thesis about software-metrics. I wanted to use the
MooseSuite in a chapter about visualizing metrics in the software
development process.
Thanks in advice!
Greetings
Timo Gienger
Hey Doru,
I did not manage to achieve this, can you take care?
We want to have
- sendToBack
- bringToFront
- sendBackword
- bringForward
in the context menu of Mondrian figure.
(as in Excel par example)
cheers,
AA
Hi guys
we have been discussing with alex here about our visibility since
other groups at inria are using Gforge and are counting their
donwloads. I think that we cannot do too much because I do not see
how it would make sense to use svn for developing Moose.
Now I see several paths to help moose while helping us (stef at
inria) internally:
I think tat this is really important to refer to the moose articles
in the paper and PhD thesis.
Oscar Nierstrasz, Stéphane Ducasse and Tudor Gîrba, The Story of
Moose: an Agile Reengineering Environment, In Proceedings of the
European Software Engineering Conference (ESEC/FSE 2005), New York
NY, ACM Press, pp. 1-10, 2005, Invited paper, PDF , DOI
Stéphane Ducasse, Tudor Gîrba, Michele Lanza and Serge Demeyer,
Moose: a Collaborative and Extensible Reengineering Environment, In
Tools for Software Maintenance and Reengineering, Milano, Franco
Angeli, pp. 55-71, 2005, PDF
Stef