okaaay, wrong reply-to, retweet....
Begin forwarded message:
> From: Simon Denier <Simon.Denier(a)inria.fr>
> Date: 28 janvier 2010 23:45:50 HNEC
> To: Simon Denier <Simon.Denier(a)inria.fr>
> Subject: Re: [Moose-dev] Building package cache
>
>
> On 26 janv. 2010, at 22:03, Simon Denier wrote:
>
>>
>> On 26 janv. 2010, at 21:07, Alexandre Bergel wrote:
>>
>>> I do not have a solution, but this is really annoying. In addition to the time taken by loading Moose, it makes 10 minutes just to check what are are dependencies Mondrian has.
>>>
>>
>> Well, temporary solutions sometimes become less than temporary... I fear this is the case.
>>
>> Maybe we can do something with an incremental, on-demand cache: whenever a class or method is imported, we check whether the cache has been built for it - if not, we built it.
>
>
>
> After playing a bit with the idea tonight, now I remember why I choose the global cache solution. So I explain how it works in the current system:
>
> To build the system cache, I go over all classes and all class extensions of PackageInfos and register their most specific package.
> Since I go over the whole system, I assume I know all class extensions in all classes.
> Now when I ask the package for a method, there are two cases:
> - either I can find it in the cache of class extensions and I return its package
> - either I can't find it, so I assume it is a normal method and retrieve the package of its class (from the cache).
>
> Now in an incremental cache system, I can cache a class when I import it, I can even cache a package so that its class extensions are imported, as above. The big problem is then that I can't assume that I know all class extensions within the class, because other packages (which I don't necessarily import) may do some. To do that, I should ask all methods within each imported class for its most specific package. This was more or less the situation we had before the cache, which brought the system to its knees on large projects. Perhaps I will try tomorrow but I don't have high hope. We need something better than that.
>
>
> --
> Simon
>
>
>
--
Simon
Hi,
yesterday I tried to delete a moose model from my image using the function Utilities>>Delete on the moose panel. The model disappear from the list but saving the image it has the same size. Executing "MooseModel allInstances" I saw that the model was still there. I tried to close all windows and then i execute "Smalltalk garbageCollect" and again the saved image has the same size because the model has not been removed.
I'm working on the pharo dev image 10508, Moose-Core 215 but i detect the same error in an older image: pharo dev image 10502, Moose-Core 208.
Cheers,
Fabrizio
Hi Jannik,
Sometimes the DSMMatrixTest>>testSorterLayer test is failing. Do you
happen to have an idea why? Is it a problem of the code or is it
actually a problem of the test?
I am asking because it is the only test that crashes from time to time
in the hudson builds :).
Cheers,
Doru
--
www.tudorgirba.com
"Being happy is a matter of choice."
Hi there
Issue 28 is now closed. It was the last pending issue for 4.0 in Moose itself. Tests are green in Moose and we add another test for the case. So you should not notive any problem when running the importer.
--
Simon & Stef
In xml files generated with srcml, we can find the balise '<decl_stmt>..
</decl_stmt>'. Does anyOne know what it represent? Because I have the
impression that it represent sometimes a function declaration, But this is
not assimilate to a function declaration in CAnalyzer.
Hi,
When opening a mooseModel in a mooseFinder, several groups of entities
appear ('all famixaaccess' 'all famixattribute'). How can I access to this
groups from the mooseModel.
I have tryed to send 'entityGroups' to a moose model (generated with
CAnalyzer) , but it only answer me a part of all the groups visible.
Hi Alex,
Thanks for implementing the zOrder! It works great.
What's even nicer is that in the process, it looks like issue the edge
clipping problem was also solved:
http://code.google.com/p/moose-technology/issues/detail?id=229
Cheers,
Doru
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
It should now be okay. Please update to
Mondrian-Alexandre_Bergel.355
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
