Alex
two remarks:
- what is the level of reification because we reify a lot and it can be discarded.
- did you check the orion model
because with orion you only represent the delta and this is a big difference.
Stef
On Nov 24, 2011, at 2:05 PM, Alexandre Bergel wrote:
> Having a reification in Moose of 100 versions of Mondrian for example :-)
>
> Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
>
> Alexandre
>
>
> On 24 Nov 2011, at 03:27, Francois Stephany wrote:
>
>> I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is.
>> Alex, what is your use case (in practice!) for more than 500MB?
>>
>> On 23/11/11 18:25, Igor Stasenko wrote:
>>> It is problematic, and requires different memory management than we
>>> currently have.
>>> I think if you need really big data sets, then use gemstone, which is
>>> developed to deal with that specifically.
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
Hi,
I have some problem to import a moose model that i have previously exported.
The error that appear is the following:
'Element ''Famix'' not found.'
The MSE exported from the MooseModel is attached.
The elements of the model contain a method "annotation" that look like this:
annotation
<MSEClass: #Column super: #FAMIXRelationalEntity>
<package: #FAMIX>
Once i have the moose model i export it with "exportToMSE" than i try to import the model again with "importFromMSE".
Any idea why i have that problem? Do you need more info to understand the problem?
Cheers,
Fabrizio
FAMIXBehaviouralEntity is an abstract superclass for any kind of behavior.
For example, functions and methods. It has a name because it is a named
entity but it also has a signature in the format: methodName(paramType1,
paramType2). The signature property is necessary for a behavioral entity.
An external parser should provide a few metrics that cannot be derived from
the model such as cyclomatic complexity, numberOfStatements and
numberOfConditionals. Other metrics can be computed from the model if
enough information is provided such as numberOfLinesOfCode (from source
anchor) and numberOfComments (from FAMIXComment).
It provides properties to manage:
(i) parameters
(ii) local variables
(iii) accesses to variables, and
(iv) invocations to and from other behavioural entities.
Optionally, it can also specify a declaredType (e.g. return types for
functions). This is useful for modeling behaviours from statically typed
languages.
Strange, the Fuel tests are green on my image and I have the last version of all packages.
Alexandre
On 23 Nov 2011, at 18:27, admin(a)moosetechnology.org wrote:
> See <http://hudson.moosetechnology.org/job/moose-latest-dev/710/>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I am building a small browser in Glamour to monitor events. I have a list such as:
constructor list
title: 'events';
display: [ :event | event allEvents ]
Is there a way to refresh the list once the Glamour GUI has showed up?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
We produced a test that shows a bug related to the classScope.
In Moose-Tests-SmalltalkImporter-LAN-AlexandreBergel.10 we added testClassVariable. This test fails. We need to make the appropriate change to make it pass. This bug prevents us from using MooseChef
In our local image we check the belongsTo in the method classScope. This makes mooseChef happy.
Anyone can have a look at it please?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
---------- Forwarded message ----------
From: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
Date: Thu, Nov 24, 2011 at 1:14 PM
Subject: [Esug-list] 18 months Postdoc position in Reengineering available
To: ESUG Members <esug-list(a)lists.esug.org>
> From: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> Subject: 18 months Postdoc position in Reengineering available
> Date: November 23, 2011 9:52:01 AM GMT+01:00
> To: ERCIM WG Software Evolution ERCIM WG Software Evolution Mailing List <evol(a)lists.inf.unisi.ch>
>
> http://rmod.lille.inria.fr/web/pier/blog/2011-05-22
>
> Postdoc position in software engineering at University of Chile in cooperation with INRIA
>
> A post-doctoral research position is available with the Pleiad Lab (Universityof Chile) and the RMoD Group (INRIA Lille Nord Europe). The position is scheduled to start in January 2012, but earlier dates are possible. The phd should be defended no prior than 2010.
>
> The position is targeted for research on software maintenance and software visualization. Validation of research hypotheses will be carried out using the Pharo programming language. Experience with it, or any other Smalltalk dialect, is a plus (but not necessary).
>
> The postdoctoral researcher will be expected to develop independent research initiatives within the scope of the position, design and contribute to the research experiments conducted by Pleiad and RMoD. There is no teaching duty associated with this position.
>
> Both Pleiad and RMoD offer a creative, productive and multicultural staff and students, with many collaboration opportunities. Pleiad and RMoD have an extensive expertise and an advanced infrastructure related to software analysis, data mining, testing, meta-modeling and language semantics.
>
> The position is funded by INRIA for a period of 18 months. In order to foster the collaboration between France and Chili, the candidate will have to share his time between Lille, France and Santiago, Chile.
>
> The candidate must hold a PhD in computer science.
>
> Contact Persons:
>
> • Alexandre Bergel and Stéphane Ducasse
> • http://pleiad.dcc.uchile.cl
> • http://rmod.lille.inria.fr
> • http://www.pharo-project.org
> • http://www.moosetechnology.org
_______________________________________________
Esug-list mailing list
Esug-list(a)lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
--
www.tudorgirba.com
"Every thing has its own flow"
FamixInheritance>>name seems superflous because it overrides a superclass
method with the same behavior.
We tried to remove the entity but then a (seemingly unrelated) test is
failing in FamixModelExtractionTest>>testReferenceModel.
We didn't commit this change in the repository fearing that something might
fail.
Hi,
It looks like the commit activity is going up. Great!
The side effect is that we now run into concurrent changes and thus,
we need to deal with merges. As a discipline, please try to follow the
following routine:
- before commit, look at the changes
- commit (do not forget the descriptive comment :))
- after the commit, browse the remote repository to see if there is no
concurrent change
- if a concurrent change appeared, merge
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
