Hi
I'm working in 7.6 and I have problems to execute the moose tests.
How do you get the buttons?
I have RBSUnitExtension loaded.... but no effect
Stef
I'm wondering why a Method does not have a static/instance attribute.
In Famix2.1 we had
hasClassScope: aBoolean
self privateState attributeSet: #hasClassScope value: aBoolean
Now I do not like to see that as Smalltalk specific since the
distinction instance class is quite general enough
if we map hasClassScope to isStatic?
Stef
I'm contemplating morbidly Meta and I was wondering why do we need to
have EMOF
for what we do at the meta-metamodel. It seems to me that we lost our
soul in the process
and especially now that nobody maintain the metapart. I have large
doubts.
I run the test of meta dn 59 are breaking ;(
I'm considering porting FAMIX2.1 to Squeak. I will call the class
FAMIX2Class.
Stef
debugging with slot is not really cool since we get FMSlot everywhere
instead of the reference to the exact object.
Then I was wondering what is the exact gain: we do not duplicate the
management of what exactly?
Because we are trading coding the management of the relation by space
(the slot objects) and speed
we send value all the times everywhere now.
May be for FAME it is better to generate Slot instead of methods in
the class. But so far I do not know exactly what is the gain.
because I still have to define add/remove.... in the interface of the
class that has a slot.
It seems to me that this is meta programming for the poor. Ideally
Smalltalk would have a nice meta
object protocol and we would define a Slot metaobject and say it in
the class and we would get
the management at runtime or may be at compile time.
Now it looks to me like an overhead without any real gain.
Stef
doru
I wonder why there is a
FAMIXMethod>>initialize
initialize super initialize.
parentClass := FMOneSlot new
owner: self;
oppInstVar: #methods;
yourself.
and why there is the following definition in FamixType
initialize
super initialize.
subInheritances := FMManySlot new
owner: self;
oppInstVar: #superclass;
yourself.
methods := FMManySlot new
owner: self;
oppInstVar: #parentClass;
yourself.
container := FMOneSlot new
owner: self;
oppInstVar: #types;
yourself.
superInheritances := FMManySlot new
owner: self;
oppInstVar: #subclass;
yourself.
attributes := FMManySlot new
owner: self;
oppInstVar: #parentClass;
yourself.
do we have to do it because we do not specify in the Slot the type of
the target oppInstVar class?
Stef
Did you try to close the system browser and open it again?
I only loaded these packages and when I create a new class which inherits
from SUnit.TestCase, I have the buttons in the bottom bar.
Romain
-----Message d'origine-----
De : Stéphane Ducasse [mailto:stephane.ducasse@univ-savoie.fr]
Envoyé : vendredi 13 juin 2008 15:23
À : peirsro(a)ensieta.fr; Related to the development of Moose and other
related tools
Objet : Re: [Moose-dev] Re: How to get the Sunit buttons
On Jun 13, 2008, at 3:13 PM, Romain PEIRS wrote:
> Hi,
>
> I loaded: RBSUnitExtensions (7.5, BaseSystem) and SUnitToo(ls)
> (RB4xx-29,
> triggs). That works fine.
> The buttons design changed but they appears after the package bar in
> the
> bottom right corner.
also in VW 7.6
For me right now I cannot run any VW moose tests.
Stef
Hi,
I loaded: RBSUnitExtensions (7.5, BaseSystem) and SUnitToo(ls)(RB4xx-29,
triggs). That works fine.
The buttons design changed but they appears after the package bar in the
bottom right corner.
Romain
-----Message d'origine-----
De : moose-dev-bounces(a)iam.unibe.ch
[mailto:moose-dev-bounces@iam.unibe.ch] De la part de Stéphane Ducasse
Envoyé : vendredi 13 juin 2008 14:56
À : Related to the development of Moose and other related tools
Objet : [Moose-dev] How to get the Sunit buttons
Hi
I'm working in 7.6 and I have problems to execute the moose tests.
How do you get the buttons?
I have RBSUnitExtension loaded.... but no effect
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
Which VW version are you using?
Because I have no problem with VW 7.5.
Romain
-----Message d'origine-----
De : moose-dev-bounces(a)iam.unibe.ch
[mailto:moose-dev-bounces@iam.unibe.ch] De la part de stephane ducasse
Envoyé : vendredi 13 juin 2008 11:02
À : Related to the development of Moose and other related tools
Objet : [Moose-dev] about SUnitToo and other non working stuff
Hi guys
I loaded
SUnitToo suggests SUnitToo(ls)
Successfully loaded: SUnitToo (38b.kuhn.2)
Successfully loaded: SUnitToo(ls) (RB4xx - 27)
Successfully loaded: ExtraRBForSUnitToo (33.tgriggs)
I cannot find a way to run the tests. Wonderful piece of software....
Now I cannot run my tests.
Do I need SunitToo to run well the tests in moose?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi guys
I loaded
SUnitToo suggests SUnitToo(ls)
Successfully loaded: SUnitToo (38b.kuhn.2)
Successfully loaded: SUnitToo(ls) (RB4xx - 27)
Successfully loaded: ExtraRBForSUnitToo (33.tgriggs)
I cannot find a way to run the tests. Wonderful piece of software....
Now I cannot run my tests.
Do I need SunitToo to run well the tests in moose?
Stef
add: anElement
| descriptionName group |
self flag: 'broken'.
descriptionName := anElement mooseDescription mmQualifiedName.
group := byGroup
at: descriptionName
ifAbsentPut: [OrderedCollection new].
group add: anElement.
elements add: anElement.
^anElement
I'm really sorry but I have the impression that we will not make it
that way.
The wrong person doing the wrong things.
stef
Hi guys
I would like to code FAMIX 3.0 in Moose in VW using Meta.
I think that we are doing a mistake to do everything at once.
Really. I think that implementing from FAMIX 3.0 should take a good
afternoon.
and we would get an implementation that we can have a look at to support
the port to Squeak. We are doing far too much stuff at the same time.
This looks to me like suicide.
Stef
FamixAbstractObject in VW = FAmixEntity?
I guess so but there is no simple way for me to be sure.
And siuch class should not inherit from Object but from
MooseAbstractEntity in VW = MooseEntity in Sq
argh.
I would like to get the SqueakModelExtractor working but for that I
need FAMIX 3.0
How can I make progress?
I really want to get moose on pharos because I want to build stuff on
moose to analyze pharo.
Stef
Doru
when I try to run the test in Moose-All in Squeak I get a DNU model
allMethods....
I want to check in VW but I do not succeed to run the tests. I should
be sooooo fucking stupid.
What a huge improvement this UI terribly excellent. I lost 20 min and
now I'm pissed off.
allMethods does not seem to be implemented on mooseModel or I'm blind.
But again I may be totally stupid.... I start to love really squeak.
I put a halt in the setUp method of the CandidateListOperator which is
inoved in the ressources setup
Now I
setUp
self halt.
groups := (model allMethods reject: #isAbstract) groupedBy: #signature
Hi all
I loaded the
- latest version of FAME
- mse-lr
- OB
- moose-all
Now when I load moose-all I get a
"FMBookMock You must resolve these dependencies before you will be
able to load these definitions: FMBookMock>>mooseButtons
FMBookMock>>viewer"
:(
Stef
Hi,
I just explored moose utilities on moose website and I found that
Package DNA had been modified?!!
I found he last version of Package blueprints (I modified this version
from more than 2 months), and I did not find Package fingerprint?
Is it the same problem that happened with Java4Moose?
thanks,
hani
hi!
Last time I checked the moose.unibe.ch website, I was surprised to see
that the Java4Moose section has disappeared from the Tools section.
This has the a smell of old backup restoration. Someone may give an
update on this?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi
I really enjoyed the dojo.
Now how can we proceed? I would really like to have a Moose up and
running in Pharo.
Doru do you have an idea when you will have time to work on FAMIX 30?
From my side I will work on the extractor and populate FAMIX-
Implementation and Famix-Smalltalk.
Stef
Hi.
I'm interested in the Squeak port ... Is it currently usable?
My goal ... define my meta-models, generate Squeak code classes + accessors
including bi-directional ones, do some meta-driven Seaside (and eventually
some Mondrian visualizations of models, if Mondrian will run in Squeak).
I've browsed the VW version of the code a few weeks ago, but do not (yet)
have a clear idea of where to start. Anything by way of a few paragraph
"getting started" guide for beginers?
Thanks,
Desmond
> -----Original Message-----
> From: moose-dev-bounces(a)iam.unibe.ch
> [mailto:moose-dev-bounces@iam.unibe.ch] On Behalf Of Toon Verwaest
> Sent: Tuesday, June 03, 2008 6:56 AM
> To: Related to the development of Moose and other related tools
> Subject: [Moose-dev] Re: Dojo follow up
>
> Please regerate the FAMIX3.0 code with the code generator before doing
> other stuff. I changed the slot implementation in Fame yesterday so
> that it uses a nice <varname>Slot accessor to get to the actual slots
> instead of hacky instVarAt stuff.
>
> Just generte and only accept the methods ending in Slot ;)
>
> On (03/06/08 09:17), Tudor Girba wrote:
> > From: Tudor Girba <girba(a)iam.unibe.ch>
> > To: Related to the development of Moose and other related tools
> > <moose-dev(a)iam.unibe.ch>
> > Subject: [Moose-dev] Re: Dojo follow up
> > Date: Tue, 3 Jun 2008 09:17:12 +0200
> >
> > Hi Stef,
> >
> > FAMIX 3.0 should be correct now, except that it does not have the
> > traversal methods yet.
> >
> > I will work again on generating pictures and potentially a
> > documentation on Thursday and Friday.
> >
> > Cheers,
> > Doru
> >
> >
> >
> > On Jun 3, 2008, at 6:10 AM, Stéphane Ducasse wrote:
> >
> > > Now I cannot work on the SqueakExtractor because Famix30 is not
> > > complete.
> > > I would really a document explaining Famix 30 and a
> working version.
> > > I can hack around but it may not be the correct one at the end.
> > >
> > > Stef
> > >
> > > On May 27, 2008, at 1:22 PM, stephane ducasse wrote:
> > >
> > >> Hi
> > >>
> > >> I really enjoyed the dojo.
> > >> Now how can we proceed? I would really like to have a
> Moose up and
> > >> running in Pharo.
> > >> Doru do you have an idea when you will have time to work
> on FAMIX 30?
> > >>
> > >> From my side I will work on the extractor and populate FAMIX-
> > >> Implementation and Famix-Smalltalk.
> > >>
> > >> Stef
> > >> _______________________________________________
> > >> Moose-dev mailing list
> > >> Moose-dev(a)iam.unibe.ch
> > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
> > > _______________________________________________
> > > Moose-dev mailing list
> > > Moose-dev(a)iam.unibe.ch
> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > www.tudorgirba.com
> > www.tudorgirba.com/blog
> >
> > "Not knowing how to do something is not an argument for how
> it cannot
> > be done."
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
Hi Stef,
Unfortunately, at this moment, there is no one directly willing in
port it.
Cheers,
Doru
On Jun 3, 2008, at 10:44 AM, Stéphane Ducasse wrote:
> Hi guys
>
> I want to know whether you plan to migrate eyesee to squeak.
>
> Stef
> _______________________________________________
> Moose mailing list
> Moose(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose
--
www.tudorgirba.comwww.tudorgirba.com/blog
"Problem solving should be concentrated on describing
the problem in a way that is relevant for the solution."
Dear list,
today I installed Moose, and, on top of that, ClusterFinder, which
would simply refuse to work - sometimes it will choke on a "Subscript
out of bounds" immediately, sometimes it will show a growing progress
bar and then complain about the message #writeStream not being
understood (while, at the same time, "errorr!a CodeFoo.Deprecation"
messages appear).
I installed the most recent versions of Moose and ClusterFinder. What
do I have to do to make this work?
Best,
Michael
Hi Azadeh,
First, you have to create nodes to be able to draw edges.
Second, in your case, I guess the simplest thing is to use the numbers
as the models for the edges and just specify "from:" from the first
collection and "to:" from the second collection.
Perhaps something like this would work:
viewFrom: col1 to: col2
| view |
view := Mondrian.ViewRenderer new.
view node: col1 forIt: [
view nodes: col1.
view verticalLineLayout.].
view node: col2 forIt: [
view nodes: col2.
view verticalLineLayout.].
"we just created 2 nodes for the two collections and inside we added a
node for each element"
"we also laid out the nodes vertically inside each root node"
view edges: (1 to: col1 size) from: [:index | col1 at: index] to:
[:index | col2 at: index].
view open
Cheers,
Doru
On Jun 3, 2008, at 7:09 PM, azadeh wrote:
> Hi,
> I have a question about Mondrian .
> I want to visualize an exttraction result by ViewRenderer .
> As the result I have two OrderedCollections that have a semantic
> relation between their entities.
> Now i need to make edges from col1 index:1 to col2 index:1; col1
> index:2 to col2 index:2; in this way.
> I tried this way:
> viewfrom : col1 to:col2
> view := Smalltalk.Mondrian.ViewRenderer new.
> i := 1 .[i < (col1 size)] whileTrue:[ view1 edges: col1 from:
> [ col1 at: i] to:[col2 at:i]. i := i + 1.] .
> view open.
> or this way:
> view1 edges: col1 fromAll: [:model| col1] toAll:[:model| col2].
> ps1: the edges are from col1 to col2.
>
> What should i do please?
>
> Best,
> Azadeh
--
www.tudorgirba.comwww.tudorgirba.com/blog
"Every successful trip needs a suitable vehicle."
Hi Dominique,
I saw that you added an extension to Collection. I like the change,
but I need to say two things:
- please use just camel case in the names of the methods (no _)
- actually, I would say that the fix would be better in the groupedBy:
method. What do you say?
Cheers,
Doru
--
www.tudorgirba.comwww.tudorgirba.com/blog
"When people care, great things can happen."
