Moose out of memory

> Hi,
> There was a previous message in the list about an out of memory problem with
> Moose when running
> 3 times  MooseScripts createModelForConfigurationOfMoose
> I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading
> the moose book (nice).
>
> IMHO although something is perhaps not completly clear in the vm in memory
> allocation and/or ui process and/or low space watcher (I tryed to debug the
> vm but did not succeed), here the problem seems to be in the Moose model.
> I suspect that the problem is just that the cache  keeps a reference to the
> Moose model each time the script is run, see at the end of
> MooseScripts>>createModelForConfigurationOfMoose  the model is added to a
> cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut
> 130M of memory each time.
> clearing the Moose cache resolve the problem.
> MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except
> that there is an exception for the root model (I don't know Moose, it may
> not be the best command).
> Perhaps the moose model should not be added by type but overriden each time
> (beeing identified by a "name" ?).
>
> PS: Moose is cool :)
>
> Cheers
> Alain
>
>
>
>

> Hi,
> There was a previous message in the list about an out of memory problem with
> Moose when running
> 3 times  MooseScripts createModelForConfigurationOfMoose
> I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading
> the moose book (nice).
>
> IMHO although something is perhaps not completly clear in the vm in memory
> allocation and/or ui process and/or low space watcher (I tryed to debug the
> vm but did not succeed), here the problem seems to be in the Moose model.
> I suspect that the problem is just that the cache  keeps a reference to the
> Moose model each time the script is run, see at the end of
> MooseScripts>>createModelForConfigurationOfMoose  the model is added to a
> cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut
> 130M of memory each time.
> clearing the Moose cache resolve the problem.
> MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except
> that there is an exception for the root model (I don't know Moose, it may
> not be the best command).
> Perhaps the moose model should not be added by type but overriden each time
> (beeing identified by a "name" ?).
>
> PS: Moose is cool :)
>
> Cheers
> Alain
>
>
>
>

> Hi,
>
> I am happy you like Moose.
>
> We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
>
> In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
>
> Igor, do you happen to have an update on this issue?
>

> On 26 June 2011 22:05, Tudor Girba <[hidden email]> wrote:
>> Hi,
>>
>> I am happy you like Moose.
>>
>> We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
>>
>> In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
>>
>> Igor, do you happen to have an update on this issue?
>>
>
> I will include fix into my branch. The windows slave is now working,
> so there is a little to do.. push the changes and update configs.

> Hi,
> There was a previous message in the list about an out of memory problem
> with
> Moose when running
> 3 times  MooseScripts createModelForConfigurationOfMoose
> I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading
> the moose book (nice).
>
> IMHO although something is perhaps not completly clear in the vm in memory
> allocation and/or ui process and/or low space watcher (I tryed to debug
> the
> vm but did not succeed), here the problem seems to be in the Moose model.
> I suspect that the problem is just that the cache  keeps a reference to
> the
> Moose model each time the script is run, see at the end of
> MooseScripts>>createModelForConfigurationOfMoose  the model is added to a
> cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes
> abut
> 130M of memory each time.
> clearing the Moose cache resolve the problem.
> MooseModel allInstancesDo:[ :m | m remove ] seems to be working here,
> except
> that there is an exception for the root model (I don't know Moose, it may
> not be the best command).
> Perhaps the moose model should not be added by type but overriden each
> time
> (beeing identified by a "name" ?).
>
> PS: Moose is cool :)
>
> Cheers
> Alain
>
>
>
>

> On 26 June 2011 22:05, Tudor Girba <[hidden email]> wrote:
>> Hi,
>>
>> I am happy you like Moose.
>>
>> We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
>>
>> In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
>>
>> Igor, do you happen to have an update on this issue?
>>
>
> I will include fix into my branch. The windows slave is now working,

> so there is a little to do.. push the changes and update configs.
>
> As for, whether this fix will be integrated into main branch, you
> asking a wrong person.
>
>> Cheers,
>> Doru
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>
> On Jun 27, 2011, at 6:20 PM, Igor Stasenko wrote:
>
>> On 26 June 2011 22:05, Tudor Girba <[hidden email]> wrote:
>>> Hi,
>>>
>>> I am happy you like Moose.
>>>
>>> We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
>>>
>>> In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
>>>
>>> Igor, do you happen to have an update on this issue?
>>>
>>
>> I will include fix into my branch. The windows slave is now working,
>
> Really?
>
> Excellllllent! After all this fight.
>

>>
>
> Yes, after some voodoo spells, today i got a VM built.
>
> Good to know that process are really reproducable: built once using
> git+config on my machine locally ==> repeating the same without
> problems on hudson slave.
> Except that setup is a bit different (tools, installs, paths, Windows
> idiosyncrazy etc etc) and i had to fix it before everything could
> start running.