Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Johan Fabry

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

15 years

Mondrian: dashed lines

by Veronica Isabel Uquillas Gomez

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

15 years, 1 month

Moose 4.0?

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 1 month

Re: Current model and properties

by Tudor Girba

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."

15 years, 1 month

Current model and properties

by Gabriela Arevalo

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

15 years, 1 month

Re: changing memory in VW for loading a large case studies

by Richard Wettel

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

15 years, 1 month

changing memory in VW for loading a large case studies

by Stéphane Ducasse

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

15 years, 1 month

cycles

by Tudor Girba

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."

15 years, 1 month

Moose-Algos-Graph tutorial

by Simon Denier

By popular request ;) I wrote a first tutorial about using and extending the graph library of Moose Algos http://www.moosetechnology.org/tools/moosealgos/graph -- Simon

15 years, 1 month

moose jee and opax

by Tudor Girba

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."

15 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev