Hi,
I went over some of the loading scripts and I noticed that there were
a number of duplicated scripts which led to inconsistencies. So, I now
changed them as follows.
Every loader has a load method that should load all the prerequisites.
For example, we have:
- MooseLoader>>load
- GlamourLoader>>load
- MondrianLoader>>load
When loading a prerequisite project that is within the realm of Moose
(e.g., Glamour, Mondrian), instead of hardcoding the script we
delegate to the appropriate loader. For example:
MooseLoader>>loadMondrian
Installer ss
project: 'Mondrian';
install: 'MondrianLoader'.
(Smalltalk at: #MondrianLoader) load.
Like this all loading scripts are in exactly one place.
The next step would be to go towards something like the Seasiders have
with their Package map in which we declaratively build a Moose
landscape with all dependent packages. That would be nice both for
loading and for creating a dependency visualization.
Cheers,
Doru
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
Hi,
We have both a MooseCook and a Moose-Cook. Moose-Cook is the real one,
but MooseCook seems to be very light and basically just have helper
methods. Is it Ok to move the existing functionality in other packages
and remove this one, or are there other use cases?
Cheers,
Doru
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Hi guys,
Today I imported a smalltalk project in Moose/Softwarenaut.
I have more than 3500 invocations with multiple candidates in the
candidates list. I decided that I will ignore those dependencies. I
would rather see fewer dependencies but be sure that the ones I see
are for real (some kind of the lower-bounds of inter-package
dependencies).
The problem is that after removing the ambiguous invocations, I still
have spurious invocations. Two examples:
- In the project, there is a class which defines the #includes:
method. In the resulting model, I have 64 invocations to this class's
#include. However, if you look at the code, you see that the
overwhelming majority of them are actually invocking List>>includes:.
In fact, the model sais that several classes from the VisualWorks Base
are depending on my code because they call includes:.
- The same situation with the #with. I have it defined in one class,
and all the invocations are attributed to the class although almost
all are actually invoking the WATagBrush>>with: from Seaside.
I am thinking that I should ignore the dependencies that have as
target methods that I will define in a blacklist. I would put in there
methods which are frequently used like: for: with: contains: etc... I
guess I can remove a lot of noise this way. Then i could probably
allow the user to further filter methods from the UI of S*naut.
However, the user would have to know the system in order to be able to
filter out these invocations. And the point of S*naut was that the
user did not know the system... :)
Does anybody have a better approach to making sure that the
dependencies in the model are for real?
Cheers,
Mircea.
Hi Alex,
In the lastest Mondrian, we have the error of the missing announcement
for resize in system window. Is there a possibility to get the patch
loaded from Monticello?
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hi all
I revert the stupid change I did to do not display Smalltalk for class.
I think that the renaming
moosePrintOn: to mooseNameOn: is really important because it conveys
that the moosePrintOn: is not about printing but naming the entity.
Stef
Begin forwarded message:
> From: François Tanguy <francois.tanguy(a)gmail.com>
> Date: May 10, 2009 10:46:36 AM CEDT
> To: pharo-project-request <Pharo-project(a)lists.gforge.inria.fr>
> Subject: [Pharo-project] The Fame code generator does not generate
> "container" annotation.
> Reply-To: Pharo-project(a)lists.gforge.inria.fr
>
> Hello all,
>
> The Fame code generator does not generate "container" annotation.
>
> ex : if in a MSE file
> (FM3.Property
> (id: 10051)
> (name ''superEquipment'')
> (type (ref: 5))
> (container true)
> (opposite (ref: 10061))
> )
>
> the code generated looks like this :
> superEquipment
> <MSEProperty: #superEquipment type: #SCAbstractEquipment
> opposite: #subEquipments>
> ^superEquipment
>
> should not it be like the following ?
> superEquipment
> <MSEProperty: #superEquipment type: #SCAbstractEquipment
> opposite: #subEquipments> <container>
> ^superEquipment
>
> It is pretty important because it allows the traversal of a model
> based on the containment of objects.
>
> François
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Hi.
My questions:
1. If I only want to use EyeSee graphing tool for a project, what is the
minimal set of parcels I need to load and is there any specific setup?
2. I installed Moose off the repository by loading the MooseSetup
parcel; but when I try to run some of the EyeSee samples eg:
Examples>>lineDiagram (evaluate self new lineDiagram)
>>lineBarCompositeDiagramWithSameAxis
I get the error Message not understood: #width on a SmallInteger (each
width; where each is integer 3346) called from
setlabelDistanceFromAxisCalculation: aDiagram on ValueLabelDecorator
I get the same error from the image I also downloaded from the web site
(moose-suite-2008-11-25.zip).
Should I load a different version of parcels; or is there something
missing?
Thanks
Liliana
Hi guys
do we have a displayString in moose?
Because I'm fedup to see Smalltalk::Morph..... all the times
we have moosePrintOn: so I was in the mood to skip 'Smalltalk' when
the parent namespace is smalltalk.
Stef