Hi all,
I have the AspectMaps website in a more or less presentable state. Maybe it would be worthwhile linking to it from the tools page on moosetechnology.org The URL is http://pleiad.cl/aspectmaps
The screencast is very basic right now, I hope to find some time soon to make it more fancy, showing more features and adding voice to explain what is going on.
In any case, comments are always welcome!
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Dear Alex,
I published a new version including two new line shapes.
Best regards,
Veronica
---------------------------------------------------------------
Name: Mondrian-VeronicaUquillas.422
Author: VeronicaUquillas
Time: 14 April 2010, 10:33:04 am
UUID: 853081bf-6830-48f3-80d2-54aef392b7f6
Ancestors: Mondrian-Alexandre_Bergel.421
Added:
- dashed line shape
- arrowed dashed line shape
Hi!
Where are we with the release? I checked the remaining issues and
closed the one that were fixed or that I cannot reproduce.
I am not expert in Glamour or the lazy group definition, but I would
like to see Moose 4.0 out. How can I help? We can do some remote pair
programming.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Gabi,
Ahh, now I understand. Any entity answers to mooseModel, so you can do:
FAMIXClass>>someMethod
self mooseModel ...
Great that you are using the Pharo version. Just for convenience, you
can find the latest development image here:
http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
Please let us know if you have further problems.
Cheers,
Doru
On 12 Apr 2010, at 18:18, Gabriela Arevalo wrote:
> Hi Doru,
>
> Thanxs for answering so quick.
>
> I am attaching an jpg to illustrate my problem :)
>
> If I evaluate MooseModel root, I get an instance of MooseModel that
> contains all the existing models. In the image you see that there
> are two models: Collections and SequenceableCollection, and
> SequeanceableCollection is selected to be the current one of the
> analysis.
>
> How can I access to that model if I am coding any property in a
> class? I checked the entities to know if each entity knows the model
> which belongs to, but it seems not.
>
> In the long past we could do ModelManager uniqueInstance
> currentModel, but now, how do I know that information?
>
> I am using Pharo version. I used the VW version during the weekend,
> but it seems that there are some code broken and I could not manage
> to make it work.
>
> Cheers,
>
> Gabi
>
> 2010/4/12 Tudor Girba <tudor.girba(a)gmail.com>
> Hi Gabi,
>
> Nice to hear from you :).
>
> ModelManager was replaced by just another Model that holds Models.
> To get to it, you do "MooseModel root" and if you want to see
> allModels from there, you do "MooseModel root allModels".
>
> Yes, properties are defined using pragmas.
>
> Which Moose are you using? Pharo or VW?
>
> Cheers,
> Doru
>
>
> On 12 Apr 2010, at 02:11, Gabriela Arevalo wrote:
>
> Hi guys,
>
> I have two basic questions regarding the implementation of Moose
> 1) How do we manage now the currentModel (the selected Model in the
> Moose UI)?
> A long time ago :) :), we have had the ModelManager class and we
> could do ModelManager uniqueInstance currentModel
>
> 2) Properties: I have seen that we are using pragmas from the
> instance side. Is it right? Or are there any other way of specifying
> them?
>
> Cheers,
>
> Gabi
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Beauty is where we see it."
>
>
>
>
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Hi guys,
I have two basic questions regarding the implementation of Moose
1) How do we manage now the currentModel (the selected Model in the Moose
UI)?
A long time ago :) :), we have had the ModelManager class and we could do
ModelManager uniqueInstance currentModel
2) Properties: I have seen that we are using pragmas from the instance side.
Is it right? Or are there any other way of specifying them?
Cheers,
Gabi
Hi Steph,
This mail from Joachim Geidel might help with tweaking the memory in VW.
Cheers,
Ricky
Begin forwarded message:
> From: Joachim Geidel <joachim.geidel(a)onlinehome.de>
> Date: September 26, 2009 5:10:40 PM GMT+02:00
> To: Jim Guo <jimg1968(a)gmail.com>, vwnc <vwnc(a)cs.uiuc.edu>
> Subject: Re: [vwnc] any way to automaticly set memory policy?
>
> Am 26.09.09 14:40 schrieb Jim Guo:
>> Memory size nowadays are larger and each time I have to manually set
>> Memory Policy when build a new image. And we don't know the exact
>> memory size computer which will run a program in the future in advance
>> so it seems better decide automaticly.
>> Is there a way? Thanks.
>
> Yes, and no. :-)
>
> You can save the configuration of the Runtime Packager, including settings
> for MemoryPolicy parameters, for later use, such that you don't have to
> enter the values every time you build an image (see page 21-21 in the
> Application Developers Guide). But that addresses only part of the problem.
>
> MemoryPolicy does not implement the ability to adapt its parameters to its
> environment. But you can write a subclass of MemoryPolicy such that
> - it computes memoryUpperBound dynamically instead of using a constant value
> - it computes growthRegimeUpperBound as e.g. 90% of memoryUpperBound or
> whatever seems reasonable
> - sets defaults for other parameters to values more appropriate to larger
> memory sizes and the needs of your application (e.g., if your application
> needs large amounts of memory, it is a good idea to set
> preferredGrowthIncrement to a larger value than the default of 1 MB - I tend
> to set it to 10 MB without thinking much about it).
>
> The MemoryPolicy has several places where it can be adapted. For example,
> you can tweak the permitMemoryGrowth: method, the memoryMeasurementBlock or
> the way memoryUpperBound is determined to achieve what you want.
>
> It is relatively easy to detect how much physical memory your computer has
> using the appropriate operating system calls, and it's a good idea to set
> memoryUpperBound lower than that. VisualWorks applications can be extremely
> slow when parts of their memory are swapped to disk, especially when running
> global garbage collections.
>
> You could also implement a SubSystem which reads parameters for the
> MemoryPolicy from a configuration file and installs or configures the
> currentMemoryPolicy accordingly in its startUp method.
>
> You should also set the ObjectMemory's sizesAtStartup to larger values,
> especially the sizes of eden and survivor space. My rule of thumb is to set
> eden and survivor space to 10 times the default size, and then run the
> TimeProfiler on parts of the application which are likely to produce lots of
> temporary objects. If it shows that there are too many scavenges (garbage
> collection runs in NewSpace), I increase them further until scavenges don't
> decrease any more or time to execute the code starts increasing. You can
> increase the other size parameters too, in particular stack space and
> compiled code cache. I usually double them. If you don't use fixed space,
> leave its size at the default value. Increase OldSpace headroom such that it
> is large enough to hold the objects created after starting and initializing
> your application, and a bit more. That way, your application will start a
> bit faster, and it doesn't have to allocate more OldSpace segments during
> initialization.
>
> HTH,
> Joachim Geidel
>
>
> _______________________________________________
> vwnc mailing list
> vwnc(a)cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Hi all
I'm doing some experiences with fingerprint and I want to load Squeak38 mse in Moose on VW7.6
However I get some problems (memory not sufficient).
Does one of you know how I can change the initial memory of VW?
Stef
Hi,
Jannik (and Simon?) is doing a great job in removing cycles in Moose.
This means that methods get moved around between packages. Thus, if
you update packages one by one in the wrong order, you might get to
miss some methods. Best is to take a fresh image.
Cheers,
Doru
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Hi Fabrizio,
I noticed that some classes related to XML parsing that should belong
to MooseJEE were in Opax. I now moved them to MooseJEE.
Cheers,
Doru
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
