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
There is a prelimary one I did some years ago to extract limited
information out of MC loaded code.
MSEExporter on SqueakSource.
Stef
On May 6, 2009, at 8:23 PM, Alexandre Bergel wrote:
> Dear All,
>
> Is there a Smalltalk -> MSE translator? Probably not since there is an
> importer. I am just wondering.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Hi,
I marked the MooseDevelopment 3.2.149.soulintegration as broken
because it has unloadable definitions.
With this occasion I looked at the code and I could not really
understand the changes. Especially adding a "version" instance
variable in FAMIXModelRoot does not sound right.
If this is something needed by SOUL, then you want to use the built-in
attribute dictionary:
self __state__ attributeGet: #YOUR_VAR default: VALUE
self __state__ attributeSet: #YOUR_VAR value: VALUE
Also, the code added in the constructor of EntityVersion makes
reference to an inexistent method (perhaps a SOUL method?):
aVersionEntity shouldStoreVersion ifTrue:[ aVersionEntity version:
version ].
Cheers,
Doru
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
Dear,
I tried to use SmallDude duplication code and it appeared that belongsTo
(on FAMIXMethod) did not return the correct class if the method is a
class method.
Since I do not know where belongsTo is set, I can't check why it do not
work.
The workaround I did is on FAMIXMethod>>sourceText:
sourceText
self mooseModel isJava ifTrue: [^''].
self mooseModel isSmalltalk ifTrue: [^(
((self hasClassScope)
ifTrue: [(MSEUtilities smalltalkClassFromFamixClassName: self
belongsTo mooseName) class]
ifFalse: [(MSEUtilities smalltalkClassFromFamixClassName: self
belongsTo mooseName)]
)
sourceCodeAt: self name) asString].
self mooseModel isPython ifTrue:[
^self pythonASTNode sourceText
].
^''
It looks ugly but seems to work. I'm not sure it is correct and if
SmallDude will return correct results.
Antoine C.
--
Antoine Cailliau
www.ac-graphic.net
Hi
on the squeak version could we move the creation of default sample
models from the MooseModel newWithDefault and root
to a menu item in a browser?
Stef
Hi
I fixed the importer so that it does not bark when a class is not
defined in a package.
Now I will check that we can load the complete pharo inside moose.
Stef
I loaded the latest version of moose.
MooseLoader load
Then I wanted to try to create a model
MooseLoader createModelForNetwork
Yesterday it worked perfectly I could open a MooseBrowser on it.
and now I cannot
it seems that the MSEPragmaProcessor is not in the image
Does anybody see the same?
Stef
Dear all,
I'm trying to use Moose but I didn't found documentation about the
scription in Easel. I try to get a map of all classes of my project
with the call links. If a method of a class call to an other method of
an other class I would like to have an edge between the two classes.
Can someone help me ? Here is the code I currently have:
view nodes: classGroup using: (RectangleShape withBorder height:
#numberOfMethods; width: #numberOfAttributes; linearFillColor:
#numberOfLinesOfCode within: classGroup).
view edges: classGroup from: #yourself toAll: #directSubclasses.
view treeLayout.
Thanks in advance,
Antoine C.
Hi
I loaded the latest version of Moose and now when I open a normal
package browser (the one of david) I have in addition
Src C. | Sys. Complex | UML diagram raises an error too.
UML diagram raises an error.
how to get rid of the SrcC. Sys.Complexity extra buttons in the
packageBrowser?
I would like to avoid to have the browser polluted with extra stuff. I
would already love to not have the default button bar since I never use
variables senders...
Stef
BTW these buttons appear in the MooseBrowser but they generate also
DNU there. ;(
Hi
I wanted to import pharo into moose and I did MooseBrowser open
import pharo packages....
and then I realized that I must click one by one on each packages.
Is it correct?
Stef