From girba at iam.unibe.ch Mon Sep 1 11:25:34 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 1 Sep 2008 11:25:34 +0200 Subject: [Moose-dev] famoosr 2008 Message-ID: Hi, The deadline for submitting to FAMOOSr 2008 is approaching fast: September 8. Why should you submit your work there? - Have a chance to get feedback - Participate in discussions and find collaborators - Let the others know what you can do with Moose More details can be found at: http://moose.unibe.ch/events/famoosr2008 Cheers, Doru -- www.tudorgirba.com www.tudorgirba.com/blog "One cannot do more than one can do." From girba at iam.unibe.ch Mon Sep 1 11:28:19 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 1 Sep 2008 11:28:19 +0200 Subject: [Moose-dev] Re: [Moose] Trouble setting up an Image In-Reply-To: References: Message-ID: Hi Steffen, Sorry for the late reply. Please try again, because the problem should have been fixed. Please send us more questions and I promise you will get a faster response :). I would also suggest to join our mailing list: https://www.iam.unibe.ch/mailman/listinfo/moose-dev Cheers, Doru On Aug 6, 2008, at 10:03 PM, Steffen M?rcker wrote: > Hi, > > I've followed the download instructions, but installing with via the > "MooseSuiteLoader parcel" and via Store as well failed. Some parcels, > namely Clustering couldn't be loaded. Platform: VW 7.6 NC on Windows > XP > > Thanks in advance, > Steffen M?rcker > _______________________________________________ > Moose mailing list > Moose at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose > -- www.tudorgirba.com www.tudorgirba.com/blog "Every thing should have the right to be different." From Alexandre.Bergel at inria.fr Tue Sep 2 17:06:31 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Tue, 2 Sep 2008 17:06:31 +0200 Subject: [Moose-dev] [squeak] broken release... Message-ID: Dear all, I wanted to load the last release of Moose, but I have some unresolved dependencies (MSE related stuff). Stef, I think you were the last one to commit. Would you mind to see how to resolve this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at univ-savoie.fr Tue Sep 2 21:14:58 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 2 Sep 2008 21:14:58 +0200 Subject: [Moose-dev] Re: [squeak] broken release... In-Reply-To: References: Message-ID: > What is an unresolved dependencies. What is an unresolved I loaded the latest moose-all 87 (before release it I tested and it worked at that time too) into pharo 64 + RB + OB + Fame and it works. So what is your problem. > I wanted to load the last release of Moose, but I have some unresolved > dependencies (MSE related stuff). Stef, I think you were the last one > to commit. Would you mind to see how to resolve this? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From bergel at iam.unibe.ch Wed Sep 3 12:01:36 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Wed, 3 Sep 2008 12:01:36 +0200 Subject: [Moose-dev] Re: [squeak] broken release... In-Reply-To: References: Message-ID: <2CBF7B22-B200-49EE-809C-481DA20A78CB@iam.unibe.ch> Not having loaded Fame was the problem. It loads well now. Alexandre On 2 Sep 2008, at 21:14, St?phane Ducasse wrote: >> What is an unresolved dependencies. > > What is an unresolved > I loaded the latest moose-all 87 (before release it I tested and it > worked at that time too) > into pharo 64 + RB + OB + Fame and it works. > So what is your problem. > > >> I wanted to load the last release of Moose, but I have some >> unresolved >> dependencies (MSE related stuff). Stef, I think you were the last one >> to commit. Would you mind to see how to resolve this? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Alexandre.Bergel at inria.fr Thu Sep 4 10:04:00 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Thu, 4 Sep 2008 10:04:00 +0200 Subject: [Moose-dev] FAMIXNamedEntity>>belongsT Message-ID: Hi! Is the following method the way it should be? -=-=-=-=-=-=-=-=-=-=-=-= FAMIXNamedEntity>>belongsTo "This stub-code was automatically generated. Please fill in." self notImplemented -=-=-=-=-=-=-=-=-=-=-=-= When I run the following code, I get a rollback on this notImplemented: -=-=-=-=-=-=-=-=-=-=-=-= | class | class := FAMIXClass new. class name: 'AClass'. class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). class addToMethods: (FAMIXMethod new name: 'anotherMethod'; yourself). (class mooseDescription allAttributes detect: [:p | p name == #belongsTo]) getFrom: class -=-=-=-=-=-=-=-=-=-=-=-= Any idea ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From akuhn at gmx.ch Thu Sep 4 10:09:28 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 4 Sep 2008 10:09:28 +0200 Subject: [Moose-dev] Re: FAME is changing under our feets.... In-Reply-To: References: Message-ID: <747E2DED-0A69-4A68-8D3D-5D8E38B82F1A@gmx.ch> Hi Stef, You are right, I will use #deprecated: from now on. Maybe it could help if I mark all published methods as such, so people can avoid using internal methods. What do you think? In any case, the published interface of Fame should now be stable. Yesterday I backported Fame from Squeak to VW even. cheers, AA On 4 Sep 2008, at 9:59 , st?phane ducasse wrote: > Hi guys > > Fame is changing so we have to fix Moose without knowing the > changes of Fame. > Adrian why don't use deprecated: because we are clients of FAME > and we cannot break each time you change something. > > So what do we do? > - solution 1: fork fame > - solution 2: code freeze > > Stef > > From Alexandre.Bergel at inria.fr Thu Sep 4 10:27:55 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Thu, 4 Sep 2008 10:27:55 +0200 Subject: [Moose-dev] Bug in FAMIX? Message-ID: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Hi, | class | class := FAMIXClass new. class name: 'AClass'. class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). class addToMethods: (FAMIXMethod new name: 'anotherMethod'; yourself). (class mooseDescription allAttributes detect: [:p | p name == #methods]) getFrom: class The following code returns: an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod #anotherMethod)) Shouldn't it be instead?: an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod #anotherMethod) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Alexandre.Bergel at inria.fr Thu Sep 4 10:31:27 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Thu, 4 Sep 2008 10:31:27 +0200 Subject: [Moose-dev] from FAMIXClass to FAMIX2Class Message-ID: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> Hi again, Doru, last week you wrote a small class definition for the MooseFinder. | class | class := FAMIXClass new. class name: 'AClass'. class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). class addToMethods: (FAMIXMethod new name: 'anotherMethod'; yourself). Remember? I guess this should be the FAMIX 2 version of these 5 lines of code: | class | class := FAMIX2Class new. class setName: 'AClass'. class addToMethods: (FAMIX2Method new setName: 'aMethod'; yourself). class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; yourself). However it lamentably open debugger that cannot be closed. The image is unusable. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From ducasse at iam.unibe.ch Thu Sep 4 09:59:27 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 4 Sep 2008 09:59:27 +0200 Subject: [Moose-dev] FAME is changing under our feets.... Message-ID: Hi guys Fame is changing so we have to fix Moose without knowing the changes of Fame. Adrian why don't use deprecated: because we are clients of FAME and we cannot break each time you change something. So what do we do? - solution 1: fork fame - solution 2: code freeze Stef From ducasse at iam.unibe.ch Thu Sep 4 10:45:22 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 4 Sep 2008 10:45:22 +0200 Subject: [Moose-dev] Re: FAME is changing under our feets.... In-Reply-To: <747E2DED-0A69-4A68-8D3D-5D8E38B82F1A@gmx.ch> References: <747E2DED-0A69-4A68-8D3D-5D8E38B82F1A@gmx.ch> Message-ID: <396BBDB0-80BD-453F-A656-24E86544B166@iam.unibe.ch> Ok at least mark them as deprecated: because we cannot get the infrastrcuture changing for us now. On Sep 4, 2008, at 10:09 AM, Adrian Kuhn wrote: > Hi Stef, > > You are right, I will use #deprecated: from now on. > > Maybe it could help if I mark all published methods as such, so > people can avoid using internal methods. What do you think? In any > case, the published interface of Fame should now be stable. > Yesterday I backported Fame from Squeak to VW even. > > > cheers, > AA > > > > On 4 Sep 2008, at 9:59 , st?phane ducasse wrote: > >> Hi guys >> >> Fame is changing so we have to fix Moose without knowing the >> changes of Fame. >> Adrian why don't use deprecated: because we are clients of FAME >> and we cannot break each time you change something. >> >> So what do we do? >> - solution 1: fork fame >> - solution 2: code freeze >> >> Stef >> >> > > From stephane.ducasse at univ-savoie.fr Thu Sep 4 10:48:45 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 10:48:45 +0200 Subject: [Moose-dev] FMPragmaGenerator generateFAMIX2annotations metamodel explore Message-ID: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> Does not work anymore in the latest version of FAME. Well... So I will rollback to an old version of Fame to perform the changes. Stef From bergel at iam.unibe.ch Thu Sep 4 10:52:11 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 10:52:11 +0200 Subject: [Moose-dev] Re: from FAMIXClass to FAMIX2Class In-Reply-To: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> References: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> Message-ID: <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> I should have written: | class | class := FAMIX2Class new. class setName: 'AClass'. class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). class addMethod: (FAMIX2Method new setName: 'anotherMethod'; yourself). (replaced addToMethods: by addMethod:) But it is still interesting why it blocks the image. It has to do with BlockContext. Cheers, Alexandre On 4 Sep 2008, at 10:31, Alexandre Bergel wrote: > Hi again, > > Doru, last week you wrote a small class definition for the > MooseFinder. > > | class | > class := FAMIXClass new. > class name: 'AClass'. > class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). > class addToMethods: (FAMIXMethod new name: 'anotherMethod'; > yourself). > > Remember? > I guess this should be the FAMIX 2 version of these 5 lines of code: > > | class | > class := FAMIX2Class new. > class setName: 'AClass'. > class addToMethods: (FAMIX2Method new setName: 'aMethod'; yourself). > class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; > yourself). > > However it lamentably open debugger that cannot be closed. The image > is unusable. > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at univ-savoie.fr Thu Sep 4 10:57:04 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 10:57:04 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> Message-ID: <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> I applied the FMPragmaGenerator and published a new version but I do not know how to access the description FAMIX2Class asMetaDescription does not work How do I get that stuff to work? I really think that we got too meta.... sadly. Stef > Does not work anymore in the latest version of FAME. > Well... > So I will rollback to an old version of Fame to perform the changes. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From girba at iam.unibe.ch Thu Sep 4 10:58:08 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 10:58:08 +0200 Subject: [Moose-dev] Re: FAMIXNamedEntity>>belongsT In-Reply-To: References: Message-ID: Hi Alex, This is not really a bug, it is just what the code generator from the information it has. The reason for why it is not implemented is the following. We wanted to keep belongsTo because it is like a trademark for FAMIX :), but on the other hand it would be nice if a method has a parentClass. So, in FAMIX 3.0 belongsTo, is derived from whatever implementation there is for the different classes. So, for FAMIXMethod, belongsTo should return parentClass. For FAMIXClass, belongsTo should return parentScope. Because we cannot encode this information in FM3, the decision was to just generate self shouldImplement. The rest should be done by hand. Cheers, Doru On Sep 4, 2008, at 10:04 AM, Alexandre Bergel wrote: > Hi! > > Is the following method the way it should be? > -=-=-=-=-=-=-=-=-=-=-=-= > FAMIXNamedEntity>>belongsTo > > "This stub-code was automatically generated. Please fill in." > self notImplemented > -=-=-=-=-=-=-=-=-=-=-=-= > > When I run the following code, I get a rollback on this > notImplemented: > -=-=-=-=-=-=-=-=-=-=-=-= > | class | > class := FAMIXClass new. > class name: 'AClass'. > class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). > class addToMethods: (FAMIXMethod new name: 'anotherMethod'; > yourself). > (class mooseDescription allAttributes detect: [:p | p name == > #belongsTo]) getFrom: class > -=-=-=-=-=-=-=-=-=-=-=-= > > Any idea ? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From girba at iam.unibe.ch Thu Sep 4 10:59:57 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 10:59:57 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Message-ID: Hmm, Something is funny here. I have to take a closer look. Cheers, Doru On Sep 4, 2008, at 10:27 AM, Alexandre Bergel wrote: > Hi, > > | class | > class := FAMIXClass new. > class name: 'AClass'. > class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). > class addToMethods: (FAMIXMethod new name: 'anotherMethod'; > yourself). > (class mooseDescription allAttributes detect: [:p | p name == > #methods]) getFrom: class > > The following code returns: > an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod > #anotherMethod)) > > Shouldn't it be instead?: > an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod > #anotherMethod) > > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "It's not what we do that matters most, it's how we do it." From girba at iam.unibe.ch Thu Sep 4 11:00:52 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 11:00:52 +0200 Subject: [Moose-dev] Re: from FAMIXClass to FAMIX2Class In-Reply-To: <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> References: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> Message-ID: <242A11A1-0F00-415C-AA26-7BCCC0E7E353@iam.unibe.ch> Actually, at the time I did work with FAMIXClass, not FAMIX2Class because FAMIX2 was not described in Fame yet. But it should work with FAMIX2 now as well. Does it still freeze with FAMIX code only? Cheers, Doru On Sep 4, 2008, at 10:52 AM, Bergel, Alexandre wrote: > I should have written: > > | class | > class := FAMIX2Class new. > class setName: 'AClass'. > class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). > class addMethod: (FAMIX2Method new setName: 'anotherMethod'; > yourself). > > (replaced addToMethods: by addMethod:) > But it is still interesting why it blocks the image. It has to do with > BlockContext. > > Cheers, > Alexandre > > On 4 Sep 2008, at 10:31, Alexandre Bergel wrote: > >> Hi again, >> >> Doru, last week you wrote a small class definition for the >> MooseFinder. >> >> | class | >> class := FAMIXClass new. >> class name: 'AClass'. >> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >> yourself). >> >> Remember? >> I guess this should be the FAMIX 2 version of these 5 lines of code: >> >> | class | >> class := FAMIX2Class new. >> class setName: 'AClass'. >> class addToMethods: (FAMIX2Method new setName: 'aMethod'; yourself). >> class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; >> yourself). >> >> However it lamentably open debugger that cannot be closed. The image >> is unusable. >> >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "When people care, great things can happen." From stephane.ducasse at univ-savoie.fr Thu Sep 4 11:06:04 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 11:06:04 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> Message-ID: How do I get FAMIX2 descriptions declared and used so that FAMIX2Class mooseDescription works MooseModel resetMetaDescriptions does not seem to On Sep 4, 2008, at 10:57 AM, St?phane Ducasse wrote: > I applied the FMPragmaGenerator and published a new version but I do > not know > how to access the description > > FAMIX2Class asMetaDescription does not work FAMIX2Class mooseDescription does not work > From bergel at iam.unibe.ch Thu Sep 4 11:08:43 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 11:08:43 +0200 Subject: [Moose-dev] Re: FAMIXNamedEntity>>belongsT In-Reply-To: References: Message-ID: <842B4C5D-9C97-4109-AE5F-7CD2AA11E58F@iam.unibe.ch> > I discovered this when pressing belongsTo in the MooseFinder: a debugger opens. > So, for FAMIXMethod, belongsTo should return parentClass. For > FAMIXClass, belongsTo should return parentScope. I do not know how to do this. I am waiting to get FAMIX2 meta described instead. > Because we cannot encode this information in FM3, the decision was to > just generate self shouldImplement. The rest should be done by hand. No idea how. Cheers, Alexandre > > > On Sep 4, 2008, at 10:04 AM, Alexandre Bergel wrote: > >> Hi! >> >> Is the following method the way it should be? >> -=-=-=-=-=-=-=-=-=-=-=-= >> FAMIXNamedEntity>>belongsTo >> >> "This stub-code was automatically generated. Please fill in." >> self notImplemented >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> When I run the following code, I get a rollback on this >> notImplemented: >> -=-=-=-=-=-=-=-=-=-=-=-= >> | class | >> class := FAMIXClass new. >> class name: 'AClass'. >> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >> yourself). >> (class mooseDescription allAttributes detect: [:p | p name == >> #belongsTo]) getFrom: class >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Any idea ? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Problem solving should be concentrated on describing > the problem in a way that is relevant for the solution." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at univ-savoie.fr Thu Sep 4 11:14:19 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 11:14:19 +0200 Subject: [Moose-dev] How to get FAME working with FAMIX2Metadescribed entities..... Message-ID: <7682DB52-C225-45B6-9DCC-CB16B6C7D519@univ-savoie.fr> MooseEntity initializeMeta does not seem to work From girba at iam.unibe.ch Thu Sep 4 11:15:03 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 11:15:03 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> Message-ID: Hi, FAMIX2Class mooseDescription works only if the repository is correctly setup :). If you look in the code, then "MooseModel>>meta" is the one that returns the meta-model. It is lazily created and in the current implementation is starts the lookup from FAMIXEntity which does not include FAMIX2. I would suggest to make it FAMIX2ModelRoot for the moment just to make it work with your code. Cheers, Doru On Sep 4, 2008, at 11:06 AM, St?phane Ducasse wrote: > How do I get FAMIX2 descriptions declared and used so that FAMIX2Class > mooseDescription works > > > > MooseModel resetMetaDescriptions > does not seem to > > On Sep 4, 2008, at 10:57 AM, St?phane Ducasse wrote: > >> I applied the FMPragmaGenerator and published a new version but I do >> not know >> how to access the description >> >> FAMIX2Class asMetaDescription does not work > > FAMIX2Class mooseDescription does not work > > >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com www.tudorgirba.com/blog "Obvious things are difficult to teach." From girba at iam.unibe.ch Thu Sep 4 11:16:32 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 11:16:32 +0200 Subject: [Moose-dev] Re: FAMIXNamedEntity>>belongsT In-Reply-To: <842B4C5D-9C97-4109-AE5F-7CD2AA11E58F@iam.unibe.ch> References: <842B4C5D-9C97-4109-AE5F-7CD2AA11E58F@iam.unibe.ch> Message-ID: <131FBCF2-7C0E-496F-A80D-8E65CB849E65@iam.unibe.ch> :) Again, belongsTo is just an alias. In Smalltalk, you implement this by delegating forward to other methods. FAMIXClass>>belongsTo ^self parentScope FAMIXMethod>>belongsTo ^self parentClass Cheers, Doru On Sep 4, 2008, at 11:08 AM, Bergel, Alexandre wrote: >> > > I discovered this when pressing belongsTo in the MooseFinder: a > debugger opens. > >> So, for FAMIXMethod, belongsTo should return parentClass. For >> FAMIXClass, belongsTo should return parentScope. > > I do not know how to do this. I am waiting to get FAMIX2 meta > described instead. > >> Because we cannot encode this information in FM3, the decision was to >> just generate self shouldImplement. The rest should be done by hand. > > No idea how. > > Cheers, > Alexandre > > >> >> >> On Sep 4, 2008, at 10:04 AM, Alexandre Bergel wrote: >> >>> Hi! >>> >>> Is the following method the way it should be? >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> FAMIXNamedEntity>>belongsTo >>> >>> "This stub-code was automatically generated. Please fill in." >>> self notImplemented >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> When I run the following code, I get a rollback on this >>> notImplemented: >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> | class | >>> class := FAMIXClass new. >>> class name: 'AClass'. >>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>> yourself). >>> (class mooseDescription allAttributes detect: [:p | p name == >>> #belongsTo]) getFrom: class >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Any idea ? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Problem solving should be concentrated on describing >> the problem in a way that is relevant for the solution." >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Next time you see your life passing by, say 'hi' and get to know her." From bergel at iam.unibe.ch Thu Sep 4 11:22:20 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 11:22:20 +0200 Subject: [Moose-dev] Re: from FAMIXClass to FAMIX2Class In-Reply-To: <242A11A1-0F00-415C-AA26-7BCCC0E7E353@iam.unibe.ch> References: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> <242A11A1-0F00-415C-AA26-7BCCC0E7E353@iam.unibe.ch> Message-ID: The image froze because moosePrintOn: called belongsTo, and it uses an assertion to check that belongsTo is notNil. moosePrintOn: is called by printOn:, which loops in a debugger. For now, FAMIX2Class cannot be browsed since asMooseDescription does not work. The following code leads to an error: | class | class := FAMIX2Class new. class setName: 'AClass'. class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). class addMethod: (FAMIX2Method new setName: 'anotherMethod'; yourself). class mooseDescription. The reason is that the instance of FMMetaRepository has an instance variable named classDict, which contains as keys the FAMIX3 classes, and not the ones of the version 2. This looks like to be very deep in the fame, famix3, meta blob. I do not know what should be done to fix this. Cheers, Alexandre On 4 Sep 2008, at 11:00, Tudor Girba wrote: > Actually, at the time I did work with FAMIXClass, not FAMIX2Class > because FAMIX2 was not described in Fame yet. > > But it should work with FAMIX2 now as well. Does it still freeze with > FAMIX code only? > > Cheers, > Doru > > On Sep 4, 2008, at 10:52 AM, Bergel, Alexandre wrote: > >> I should have written: >> >> | class | >> class := FAMIX2Class new. >> class setName: 'AClass'. >> class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). >> class addMethod: (FAMIX2Method new setName: 'anotherMethod'; >> yourself). >> >> (replaced addToMethods: by addMethod:) >> But it is still interesting why it blocks the image. It has to do >> with >> BlockContext. >> >> Cheers, >> Alexandre >> >> On 4 Sep 2008, at 10:31, Alexandre Bergel wrote: >> >>> Hi again, >>> >>> Doru, last week you wrote a small class definition for the >>> MooseFinder. >>> >>> | class | >>> class := FAMIXClass new. >>> class name: 'AClass'. >>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>> yourself). >>> >>> Remember? >>> I guess this should be the FAMIX 2 version of these 5 lines of code: >>> >>> | class | >>> class := FAMIX2Class new. >>> class setName: 'AClass'. >>> class addToMethods: (FAMIX2Method new setName: 'aMethod'; >>> yourself). >>> class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; >>> yourself). >>> >>> However it lamentably open debugger that cannot be closed. The image >>> is unusable. >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "When people care, great things can happen." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at univ-savoie.fr Thu Sep 4 11:26:44 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 11:26:44 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> Message-ID: <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: > Hi, > > FAMIX2Class mooseDescription works only if the repository is correctly > setup :). > > If you look in the code, then "MooseModel>>meta" is the one that > returns the meta-model. Ah I thought that we could plug any metamodel under fame Now I did MooseModel2 class>>metaTower "self resetMetaDescriptions. self metaTower" | pp | ^metaTower ifNil: [ pp := FMPragmaProcessor new. pp queue: MooseEntity withAllSubclasses. pp run. metaTower := pp asTower] and I got a wonderful error which is a bad smell to me. Stef > It is lazily created and in the current > implementation is starts the lookup from FAMIXEntity which does not > include FAMIX2. > > I would suggest to make it FAMIX2ModelRoot for the moment just to make > it work with your code. > > From bergel at iam.unibe.ch Thu Sep 4 11:31:17 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 11:31:17 +0200 Subject: [Moose-dev] Re: FAMIXNamedEntity>>belongsT In-Reply-To: <131FBCF2-7C0E-496F-A80D-8E65CB849E65@iam.unibe.ch> References: <842B4C5D-9C97-4109-AE5F-7CD2AA11E58F@iam.unibe.ch> <131FBCF2-7C0E-496F-A80D-8E65CB849E65@iam.unibe.ch> Message-ID: <2338F933-0539-4C9E-8D79-91AE297DF91E@iam.unibe.ch> > FAMIXClass>>belongsTo > ^self parentScope Should it be instead:? FAMIXClass>>belongsTo ^ self packagedIn parentScope is defined nowhere. But packageIn returns nil (I guess no package has been defined, woaa :-) > FAMIXMethod>>belongsTo > ^self parentClass This one was already there. Cheers, Alexandre > > > Cheers, > Doru > > On Sep 4, 2008, at 11:08 AM, Bergel, Alexandre wrote: > >>> >> >> I discovered this when pressing belongsTo in the MooseFinder: a >> debugger opens. >> >>> So, for FAMIXMethod, belongsTo should return parentClass. For >>> FAMIXClass, belongsTo should return parentScope. >> >> I do not know how to do this. I am waiting to get FAMIX2 meta >> described instead. >> >>> Because we cannot encode this information in FM3, the decision was >>> to >>> just generate self shouldImplement. The rest should be done by hand. >> >> No idea how. >> >> Cheers, >> Alexandre >> >> >>> >>> >>> On Sep 4, 2008, at 10:04 AM, Alexandre Bergel wrote: >>> >>>> Hi! >>>> >>>> Is the following method the way it should be? >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> FAMIXNamedEntity>>belongsTo >>>> >>>> "This stub-code was automatically generated. Please fill in." >>>> self notImplemented >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> When I run the following code, I get a rollback on this >>>> notImplemented: >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> | class | >>>> class := FAMIXClass new. >>>> class name: 'AClass'. >>>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>>> yourself). >>>> (class mooseDescription allAttributes detect: [:p | p name == >>>> #belongsTo]) getFrom: class >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Any idea ? >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "Problem solving should be concentrated on describing >>> the problem in a way that is relevant for the solution." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From akuhn at gmx.ch Thu Sep 4 11:30:05 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 4 Sep 2008 11:30:05 +0200 Subject: [Moose-dev] Public interface of Fame (for Smalltalk) In-Reply-To: <396BBDB0-80BD-453F-A656-24E86544B166@iam.unibe.ch> References: <747E2DED-0A69-4A68-8D3D-5D8E38B82F1A@gmx.ch> <396BBDB0-80BD-453F-A656-24E86544B166@iam.unibe.ch> Message-ID: <9FFFABA8-CC85-4FDC-B806-A34FBAA320A9@gmx.ch> Hi there, The public interface of Fame for Smalltalk is pretty stable new (and testable). To get the specification of the interface print FMPublicInterface new and to test it against the current implementation, run FMPublicInterface suite run All public method will remain as they are now. Methods not in the public interface are to be considered internal and subject to future changes. Please review your code and try to avoid internal methods. cheers, AA On 4 Sep 2008, at 10:45 , st?phane ducasse wrote: > Ok at least mark them as deprecated: because we cannot get the > infrastrcuture changing for us now. > On Sep 4, 2008, at 10:09 AM, Adrian Kuhn wrote: > >> Hi Stef, >> >> You are right, I will use #deprecated: from now on. >> >> Maybe it could help if I mark all published methods as such, so >> people can avoid using internal methods. What do you think? In any >> case, the published interface of Fame should now be stable. >> Yesterday I backported Fame from Squeak to VW even. >> >> >> cheers, >> AA >> >> >> >> On 4 Sep 2008, at 9:59 , st?phane ducasse wrote: >> >>> Hi guys >>> >>> Fame is changing so we have to fix Moose without knowing the >>> changes of Fame. >>> Adrian why don't use deprecated: because we are clients of FAME >>> and we cannot break each time you change something. >>> >>> So what do we do? >>> - solution 1: fork fame >>> - solution 2: code freeze >>> >>> Stef >>> >>> >> >> From akuhn at gmx.ch Thu Sep 4 11:32:13 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 4 Sep 2008 11:32:13 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> Message-ID: <421B96AE-93EE-450F-9A1D-EB3AFA67ECBA@gmx.ch> FMPragmaGenerator is part of the migration code written by Oscar and Toon. It may be that I have broken their code since it is not covered by tests. Please contact them for more help. cheers, AA On 4 Sep 2008, at 11:06 , St?phane Ducasse wrote: > How do I get FAMIX2 descriptions declared and used so that > FAMIX2Class mooseDescription works > > > > MooseModel resetMetaDescriptions > does not seem to > > On Sep 4, 2008, at 10:57 AM, St?phane Ducasse wrote: > >> I applied the FMPragmaGenerator and published a new version but I do >> not know >> how to access the description >> >> FAMIX2Class asMetaDescription does not work > > FAMIX2Class mooseDescription does not work > > >> From girba at iam.unibe.ch Thu Sep 4 11:37:24 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 11:37:24 +0200 Subject: [Moose-dev] Re: FAMIXNamedEntity>>belongsT In-Reply-To: <2338F933-0539-4C9E-8D79-91AE297DF91E@iam.unibe.ch> References: <842B4C5D-9C97-4109-AE5F-7CD2AA11E58F@iam.unibe.ch> <131FBCF2-7C0E-496F-A80D-8E65CB849E65@iam.unibe.ch> <2338F933-0539-4C9E-8D79-91AE297DF91E@iam.unibe.ch> Message-ID: <16B75B1D-A42B-4AD4-AD12-B03565F8FDB3@iam.unibe.ch> Mea culpa. It's called container, not parentScope. packagedIn is about packages, belongsTo is about namespaces. Doru On Sep 4, 2008, at 11:31 AM, Bergel, Alexandre wrote: >> FAMIXClass>>belongsTo >> ^self parentScope > > Should it be instead:? > FAMIXClass>>belongsTo > ^ self packagedIn > > parentScope is defined nowhere. > But packageIn returns nil (I guess no package has been defined, > woaa :-) > > >> FAMIXMethod>>belongsTo >> ^self parentClass > > This one was already there. > > Cheers, > Alexandre > > > >> >> >> Cheers, >> Doru >> >> On Sep 4, 2008, at 11:08 AM, Bergel, Alexandre wrote: >> >>>> >>> >>> I discovered this when pressing belongsTo in the MooseFinder: a >>> debugger opens. >>> >>>> So, for FAMIXMethod, belongsTo should return parentClass. For >>>> FAMIXClass, belongsTo should return parentScope. >>> >>> I do not know how to do this. I am waiting to get FAMIX2 meta >>> described instead. >>> >>>> Because we cannot encode this information in FM3, the decision was >>>> to >>>> just generate self shouldImplement. The rest should be done by >>>> hand. >>> >>> No idea how. >>> >>> Cheers, >>> Alexandre >>> >>> >>>> >>>> >>>> On Sep 4, 2008, at 10:04 AM, Alexandre Bergel wrote: >>>> >>>>> Hi! >>>>> >>>>> Is the following method the way it should be? >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> FAMIXNamedEntity>>belongsTo >>>>> >>>>> "This stub-code was automatically generated. Please fill in." >>>>> self notImplemented >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> When I run the following code, I get a rollback on this >>>>> notImplemented: >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> | class | >>>>> class := FAMIXClass new. >>>>> class name: 'AClass'. >>>>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>>>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>>>> yourself). >>>>> (class mooseDescription allAttributes detect: [:p | p name == >>>>> #belongsTo]) getFrom: class >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> Any idea ? >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.tudorgirba.com/blog >>>> >>>> "Problem solving should be concentrated on describing >>>> the problem in a way that is relevant for the solution." >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Be rather willing to give than demanding to get." From girba at iam.unibe.ch Thu Sep 4 11:40:25 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 11:40:25 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> Message-ID: <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> Hi Stef, I know it breaks. The errors that you mention are due to the fact that some old classes from VW do not conform to Fame. That is why I said that for the moment just put there FAMIX2ModelRoot and then I will take a look at the code in the afternoon. Cheers, Doru On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: > > On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: > >> Hi, >> >> FAMIX2Class mooseDescription works only if the repository is >> correctly >> setup :). >> >> If you look in the code, then "MooseModel>>meta" is the one that >> returns the meta-model. > > Ah > I thought that we could plug any metamodel under fame > > > Now I did > > MooseModel2 class>>metaTower > "self resetMetaDescriptions. self metaTower" > > | pp | > ^metaTower ifNil: [ > pp := FMPragmaProcessor new. > pp queue: MooseEntity withAllSubclasses. > pp run. > metaTower := pp asTower] > > and I got a wonderful error which is a bad smell to me. > > > Stef > > > > > > > > >> It is lazily created and in the current >> implementation is starts the lookup from FAMIXEntity which does not >> include FAMIX2. >> >> I would suggest to make it FAMIX2ModelRoot for the moment just to >> make >> it work with your code. >> >> > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "What we can governs what we wish." From stephane.ducasse at univ-savoie.fr Thu Sep 4 11:50:21 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 11:50:21 +0200 Subject: [Moose-dev] Re: from FAMIXClass to FAMIX2Class In-Reply-To: References: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> <242A11A1-0F00-415C-AA26-7BCCC0E7E353@iam.unibe.ch> Message-ID: Load the latest version of moose and do MooseModel2 resetMetaDescriptions. (FMRepository with: MooseModel2 meta). Stef On Sep 4, 2008, at 11:22 AM, Bergel, Alexandre wrote: > The image froze because moosePrintOn: called belongsTo, and it uses an > assertion to check that belongsTo is notNil. moosePrintOn: is called > by printOn:, which loops in a debugger. > > For now, FAMIX2Class cannot be browsed since asMooseDescription does > not work. The following code leads to an error: > > | class | > class := FAMIX2Class new. > class setName: 'AClass'. > class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). > class addMethod: (FAMIX2Method new setName: 'anotherMethod'; > yourself). > class mooseDescription. > > The reason is that the instance of FMMetaRepository has an instance > variable named classDict, which contains as keys the FAMIX3 classes, > and not the ones of the version 2. > > This looks like to be very deep in the fame, famix3, meta blob. I do > not know what should be done to fix this. > > Cheers, > Alexandre > > > On 4 Sep 2008, at 11:00, Tudor Girba wrote: > >> Actually, at the time I did work with FAMIXClass, not FAMIX2Class >> because FAMIX2 was not described in Fame yet. >> >> But it should work with FAMIX2 now as well. Does it still freeze with >> FAMIX code only? >> >> Cheers, >> Doru >> >> On Sep 4, 2008, at 10:52 AM, Bergel, Alexandre wrote: >> >>> I should have written: >>> >>> | class | >>> class := FAMIX2Class new. >>> class setName: 'AClass'. >>> class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). >>> class addMethod: (FAMIX2Method new setName: 'anotherMethod'; >>> yourself). >>> >>> (replaced addToMethods: by addMethod:) >>> But it is still interesting why it blocks the image. It has to do >>> with >>> BlockContext. >>> >>> Cheers, >>> Alexandre >>> >>> On 4 Sep 2008, at 10:31, Alexandre Bergel wrote: >>> >>>> Hi again, >>>> >>>> Doru, last week you wrote a small class definition for the >>>> MooseFinder. >>>> >>>> | class | >>>> class := FAMIXClass new. >>>> class name: 'AClass'. >>>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>>> yourself). >>>> >>>> Remember? >>>> I guess this should be the FAMIX 2 version of these 5 lines of >>>> code: >>>> >>>> | class | >>>> class := FAMIX2Class new. >>>> class setName: 'AClass'. >>>> class addToMethods: (FAMIX2Method new setName: 'aMethod'; >>>> yourself). >>>> class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; >>>> yourself). >>>> >>>> However it lamentably open debugger that cannot be closed. The >>>> image >>>> is unusable. >>>> >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "When people care, great things can happen." >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From ducasse at iam.unibe.ch Thu Sep 4 11:53:24 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 4 Sep 2008 11:53:24 +0200 Subject: [Moose-dev] deprecating initializeMeta Message-ID: <6A60C028-5077-430D-B9EF-1C7E2526D799@iam.unibe.ch> Doru could you have a look and replace initializeMeta by a correct invocation? We go to eat now. Stef From girba at iam.unibe.ch Thu Sep 4 12:02:10 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 12:02:10 +0200 Subject: [Moose-dev] Re: deprecating initializeMeta In-Reply-To: <6A60C028-5077-430D-B9EF-1C7E2526D799@iam.unibe.ch> References: <6A60C028-5077-430D-B9EF-1C7E2526D799@iam.unibe.ch> Message-ID: It should work now. Doru On Sep 4, 2008, at 11:53 AM, st?phane ducasse wrote: > Doru > > could you have a look and replace initializeMeta by a correct > invocation? > We go to eat now. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "What we can governs what we wish." From akuhn at gmx.ch Thu Sep 4 12:41:22 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 4 Sep 2008 12:41:22 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Message-ID: I guess the bug is due to the new contract of #getFrom: and #setOn:values: that treats all properties as if multivalued. Before those methods called the bare selectors, that is, worked diff for single- and multivalued properties. cheers, AA On 4 Sep 2008, at 10:59 , Tudor Girba wrote: > Hmm, > > Something is funny here. I have to take a closer look. > > Cheers, > Doru > > > On Sep 4, 2008, at 10:27 AM, Alexandre Bergel wrote: > >> Hi, >> >> | class | >> class := FAMIXClass new. >> class name: 'AClass'. >> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >> yourself). >> (class mooseDescription allAttributes detect: [:p | p name == >> #methods]) getFrom: class >> >> The following code returns: >> an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >> #anotherMethod)) >> >> Shouldn't it be instead?: >> an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >> #anotherMethod) >> >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "It's not what we do that matters most, it's how we do it." From stephane.ducasse at univ-savoie.fr Thu Sep 4 12:46:31 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 12:46:31 +0200 Subject: [Moose-dev] Re: deprecating initializeMeta In-Reply-To: References: <6A60C028-5077-430D-B9EF-1C7E2526D799@iam.unibe.ch> Message-ID: <3AA4A7DD-9085-486F-B07A-BF2DC758AC34@univ-savoie.fr> excellent! I continue to fix the test and the importer. Stef On Sep 4, 2008, at 12:02 PM, Tudor Girba wrote: > It should work now. > > Doru > > On Sep 4, 2008, at 11:53 AM, st?phane ducasse wrote: > >> Doru >> >> could you have a look and replace initializeMeta by a correct >> invocation? >> We go to eat now. >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "What we can governs what we wish." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From bergel at iam.unibe.ch Thu Sep 4 12:48:53 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 12:48:53 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Message-ID: <700EBBD4-D6C0-43DE-9BB9-A7AA4431D966@iam.unibe.ch> > I guess the bug is due to the new contract of #getFrom: and > #setOn:values: that treats all properties as if multivalued. Before > those methods called the bare selectors, that is, worked diff for > single- and multivalued properties. How can: (class mooseDescription allAttributes detect: [:p | p name == #methods]) getFrom: class return a collection of FAMIXMethods ? Is there a new way to get values from a property? Adrian, can you have a look at it please? Cheers, Alexandre > > > cheers, > AA > > > On 4 Sep 2008, at 10:59 , Tudor Girba wrote: > >> Hmm, >> >> Something is funny here. I have to take a closer look. >> >> Cheers, >> Doru >> >> >> On Sep 4, 2008, at 10:27 AM, Alexandre Bergel wrote: >> >>> Hi, >>> >>> | class | >>> class := FAMIXClass new. >>> class name: 'AClass'. >>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>> yourself). >>> (class mooseDescription allAttributes detect: [:p | p name == >>> #methods]) getFrom: class >>> >>> The following code returns: >>> an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>> #anotherMethod)) >>> >>> Shouldn't it be instead?: >>> an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>> #anotherMethod) >>> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "It's not what we do that matters most, it's how we do it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From bergel at iam.unibe.ch Thu Sep 4 13:15:27 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Thu, 4 Sep 2008 13:15:27 +0200 Subject: [Moose-dev] Re: from FAMIXClass to FAMIX2Class In-Reply-To: References: <721CC308-FE97-4302-8373-7367FFFCE517@inria.fr> <5E6B5090-2D07-40D8-BD8A-25F848155C48@iam.unibe.ch> <242A11A1-0F00-415C-AA26-7BCCC0E7E353@iam.unibe.ch> Message-ID: <6A7EDA87-D48E-476A-A495-E6E8DDC22E7D@iam.unibe.ch> It does not work. Doiting: FAMIX2Class mooseDescription leads to a debugger... Alexandre On 4 Sep 2008, at 11:50, St?phane Ducasse wrote: > Load the latest version of moose > and do > > MooseModel2 resetMetaDescriptions. > (FMRepository with: MooseModel2 meta). > > Stef > > > > On Sep 4, 2008, at 11:22 AM, Bergel, Alexandre wrote: > >> The image froze because moosePrintOn: called belongsTo, and it uses >> an >> assertion to check that belongsTo is notNil. moosePrintOn: is called >> by printOn:, which loops in a debugger. >> >> For now, FAMIX2Class cannot be browsed since asMooseDescription does >> not work. The following code leads to an error: >> >> | class | >> class := FAMIX2Class new. >> class setName: 'AClass'. >> class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). >> class addMethod: (FAMIX2Method new setName: 'anotherMethod'; >> yourself). >> class mooseDescription. >> >> The reason is that the instance of FMMetaRepository has an instance >> variable named classDict, which contains as keys the FAMIX3 classes, >> and not the ones of the version 2. >> >> This looks like to be very deep in the fame, famix3, meta blob. I do >> not know what should be done to fix this. >> >> Cheers, >> Alexandre >> >> >> On 4 Sep 2008, at 11:00, Tudor Girba wrote: >> >>> Actually, at the time I did work with FAMIXClass, not FAMIX2Class >>> because FAMIX2 was not described in Fame yet. >>> >>> But it should work with FAMIX2 now as well. Does it still freeze >>> with >>> FAMIX code only? >>> >>> Cheers, >>> Doru >>> >>> On Sep 4, 2008, at 10:52 AM, Bergel, Alexandre wrote: >>> >>>> I should have written: >>>> >>>> | class | >>>> class := FAMIX2Class new. >>>> class setName: 'AClass'. >>>> class addMethod: (FAMIX2Method new setName: 'aMethod'; yourself). >>>> class addMethod: (FAMIX2Method new setName: 'anotherMethod'; >>>> yourself). >>>> >>>> (replaced addToMethods: by addMethod:) >>>> But it is still interesting why it blocks the image. It has to do >>>> with >>>> BlockContext. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On 4 Sep 2008, at 10:31, Alexandre Bergel wrote: >>>> >>>>> Hi again, >>>>> >>>>> Doru, last week you wrote a small class definition for the >>>>> MooseFinder. >>>>> >>>>> | class | >>>>> class := FAMIXClass new. >>>>> class name: 'AClass'. >>>>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>>>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>>>> yourself). >>>>> >>>>> Remember? >>>>> I guess this should be the FAMIX 2 version of these 5 lines of >>>>> code: >>>>> >>>>> | class | >>>>> class := FAMIX2Class new. >>>>> class setName: 'AClass'. >>>>> class addToMethods: (FAMIX2Method new setName: 'aMethod'; >>>>> yourself). >>>>> class addToMethods: (FAMIX2Method new setName: 'anotherMethod'; >>>>> yourself). >>>>> >>>>> However it lamentably open debugger that cannot be closed. The >>>>> image >>>>> is unusable. >>>>> >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "When people care, great things can happen." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Thu Sep 4 13:17:28 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 13:17:28 +0200 Subject: [Moose-dev] can a mooseID be nil? Message-ID: <00D3077C-A0C8-4D24-B33F-3049210F3D25@inria.fr> because I have one method that has a nil mooseID Stef From stephane.ducasse at univ-savoie.fr Thu Sep 4 13:54:41 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 13:54:41 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> Message-ID: <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> Apparently when applying blindly the changes of oscar I broke FAMIX2 (argh) so I will take another image and check one by one the suggested changes and produce a new Famx20 package Stef On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: > Hi Stef, > > I know it breaks. The errors that you mention are due to the fact that > some old classes from VW do not conform to Fame. > > That is why I said that for the moment just put there FAMIX2ModelRoot > and then I will take a look at the code in the afternoon. > > Cheers, > Doru > > > On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: > >> >> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> FAMIX2Class mooseDescription works only if the repository is >>> correctly >>> setup :). >>> >>> If you look in the code, then "MooseModel>>meta" is the one that >>> returns the meta-model. >> >> Ah >> I thought that we could plug any metamodel under fame >> >> >> Now I did >> >> MooseModel2 class>>metaTower >> "self resetMetaDescriptions. self metaTower" >> >> | pp | >> ^metaTower ifNil: [ >> pp := FMPragmaProcessor new. >> pp queue: MooseEntity withAllSubclasses. >> pp run. >> metaTower := pp asTower] >> >> and I got a wonderful error which is a bad smell to me. >> >> >> Stef >> >> >> >> >> >> >> >> >>> It is lazily created and in the current >>> implementation is starts the lookup from FAMIXEntity which does not >>> include FAMIX2. >>> >>> I would suggest to make it FAMIX2ModelRoot for the moment just to >>> make >>> it work with your code. >>> >>> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "What we can governs what we wish." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From girba at iam.unibe.ch Thu Sep 4 14:01:21 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 14:01:21 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> Message-ID: <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> The error I mentioned before is not due to the changes of Oscar and Toon. It's just that Fame has a different contract than Meta. Doru On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: > Apparently when applying blindly the changes of oscar I broke FAMIX2 > (argh) > so I will take another image and check one by one the suggested > changes and produce a new Famx20 package > > Stef > On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: > >> Hi Stef, >> >> I know it breaks. The errors that you mention are due to the fact >> that >> some old classes from VW do not conform to Fame. >> >> That is why I said that for the moment just put there FAMIX2ModelRoot >> and then I will take a look at the code in the afternoon. >> >> Cheers, >> Doru >> >> >> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >> >>> >>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> FAMIX2Class mooseDescription works only if the repository is >>>> correctly >>>> setup :). >>>> >>>> If you look in the code, then "MooseModel>>meta" is the one that >>>> returns the meta-model. >>> >>> Ah >>> I thought that we could plug any metamodel under fame >>> >>> >>> Now I did >>> >>> MooseModel2 class>>metaTower >>> "self resetMetaDescriptions. self metaTower" >>> >>> | pp | >>> ^metaTower ifNil: [ >>> pp := FMPragmaProcessor new. >>> pp queue: MooseEntity withAllSubclasses. >>> pp run. >>> metaTower := pp asTower] >>> >>> and I got a wonderful error which is a bad smell to me. >>> >>> >>> Stef >>> >>> >>> >>> >>> >>> >>> >>> >>>> It is lazily created and in the current >>>> implementation is starts the lookup from FAMIXEntity which does not >>>> include FAMIX2. >>>> >>>> I would suggest to make it FAMIX2ModelRoot for the moment just to >>>> make >>>> it work with your code. >>>> >>>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "What we can governs what we wish." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com www.tudorgirba.com/blog "Problem solving efficiency grows with the abstractness level of problem understanding." From stephane.ducasse at univ-savoie.fr Thu Sep 4 14:18:26 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 14:18:26 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> Message-ID: <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> The problem is that in Famix20 we have lazzy initializers and they got replaced by direct accessor. So signature was for example not lazzily computed anymore, and breaking the debugger. :( So I do not know what is the contract stuff you are talking about but at the end it should be fixed. Stef On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: > The error I mentioned before is not due to the changes of Oscar and > Toon. It's just that Fame has a different contract than Meta. > > Doru > > > On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: > >> Apparently when applying blindly the changes of oscar I broke FAMIX2 >> (argh) >> so I will take another image and check one by one the suggested >> changes and produce a new Famx20 package >> >> Stef >> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >> >>> Hi Stef, >>> >>> I know it breaks. The errors that you mention are due to the fact >>> that >>> some old classes from VW do not conform to Fame. >>> >>> That is why I said that for the moment just put there >>> FAMIX2ModelRoot >>> and then I will take a look at the code in the afternoon. >>> >>> Cheers, >>> Doru >>> >>> >>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>> >>>> >>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> FAMIX2Class mooseDescription works only if the repository is >>>>> correctly >>>>> setup :). >>>>> >>>>> If you look in the code, then "MooseModel>>meta" is the one that >>>>> returns the meta-model. >>>> >>>> Ah >>>> I thought that we could plug any metamodel under fame >>>> >>>> >>>> Now I did >>>> >>>> MooseModel2 class>>metaTower >>>> "self resetMetaDescriptions. self metaTower" >>>> >>>> | pp | >>>> ^metaTower ifNil: [ >>>> pp := FMPragmaProcessor new. >>>> pp queue: MooseEntity withAllSubclasses. >>>> pp run. >>>> metaTower := pp asTower] >>>> >>>> and I got a wonderful error which is a bad smell to me. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> It is lazily created and in the current >>>>> implementation is starts the lookup from FAMIXEntity which does >>>>> not >>>>> include FAMIX2. >>>>> >>>>> I would suggest to make it FAMIX2ModelRoot for the moment just to >>>>> make >>>>> it work with your code. >>>>> >>>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "What we can governs what we wish." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at inria.fr Thu Sep 4 14:27:12 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 14:27:12 +0200 Subject: [Moose-dev] tired.... Message-ID: <55211543-8BBA-4F7E-B76B-9E8AE4F8A30B@inria.fr> So can somebody smart explain to me the following before in Squeak incomingInvocations was incomingInvocations incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. in oscar changes it is incomingInvocations ^ incomingInvocations values So what should I do. Because now I do not know! But I'm certainly stupid for sure. What I know is that this metastuff gets in our way. I do not care about reproducing complete code (which we cannot in FAME because lazy initialization and other useful code level idioms are not represented) and now instead of focusing on Moose I have to deal with meta representation concerns. Really I think that we got trapped there. Knowing where to stop is as important as doing it. Next time I will fight really hard against any smart cleaner cooler meta meta stuff. Which is sad because I know what I'm talking about. Stef From ducasse at iam.unibe.ch Thu Sep 4 14:46:52 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 4 Sep 2008 14:46:52 +0200 Subject: [Moose-dev] accessedByLists vs. accessedByList Message-ID: I'm confused. There are accessedByLists ^ accessedByLists but no instance variable the only one is accessedByList So what is the point? should I rename accessedByLists into accessedByList? Stef From girba at iam.unibe.ch Thu Sep 4 15:00:28 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 4 Sep 2008 15:00:28 +0200 Subject: [Moose-dev] Re: accessedByLists vs. accessedByList In-Reply-To: References: Message-ID: <5E691DC3-1BE9-419A-9683-924470DC1C32@iam.unibe.ch> This was a dirty fix for Meta to work on VW. You can remove accessedByLists. Doru On Sep 4, 2008, at 2:46 PM, st?phane ducasse wrote: > I'm confused. > > There are > > > accessedByLists > #accesses> > ^ accessedByLists > > but no instance variable > > the only one is accessedByList > > So what is the point? > > should I rename accessedByLists into accessedByList? > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "When people care, great things can happen." From akuhn at gmx.ch Thu Sep 4 15:40:38 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 4 Sep 2008 15:40:38 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Message-ID: <82427226-9056-4B31-84F0-5363C17FF5EA@gmx.ch> I can take a look. Do you have a test case that reproduces the error? If yes, which packages do I have to checkout and which test to run? Or even better, just upload me an image somewhere with an open debugger. PS ... you can use #attributeNamed: (class mooseDescription attributeNamed: #methods) getFrom: class cheers, AA > I guess the bug is due to the new contract of #getFrom: and > #setOn:values: that treats all properties as if multivalued. Before > those methods called the bare selectors, that is, worked diff for > single- and multivalued properties. How can: (class mooseDescription allAttributes detect: [:p | p name == #methods]) getFrom: class return a collection of FAMIXMethods ? Is there a new way to get values from a property? Adrian, can you have a look at it please? Cheers, Alexandre > > > cheers, > AA > > > On 4 Sep 2008, at 10:59 , Tudor Girba wrote: > >> Hmm, >> >> Something is funny here. I have to take a closer look. >> >> Cheers, >> Doru >> >> >> On Sep 4, 2008, at 10:27 AM, Alexandre Bergel wrote: >> >>> Hi, >>> >>> | class | >>> class := FAMIXClass new. >>> class name: 'AClass'. >>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>> yourself). >>> (class mooseDescription allAttributes detect: [:p | p name == >>> #methods]) getFrom: class >>> >>> The following code returns: >>> an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>> #anotherMethod)) >>> >>> Shouldn't it be instead?: >>> an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>> #anotherMethod) >>> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "It's not what we do that matters most, it's how we do it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Alexandre.Bergel at inria.fr Thu Sep 4 15:56:45 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Thu, 4 Sep 2008 15:56:45 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: <82427226-9056-4B31-84F0-5363C17FF5EA@gmx.ch> References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> <82427226-9056-4B31-84F0-5363C17FF5EA@gmx.ch> Message-ID: An image is available on http://www.bergel.eu/MooseSqueak.zip Just evaluate the following in a workspace: | class | class := FAMIXClass new. class name: 'AClass'. class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). class addToMethods: (FAMIXMethod new name: 'anotherMethod'; yourself). (class mooseDescription attributeNamed: #methods) getFrom: class Cheers, Alexandre On 4 Sep 2008, at 15:40, Adrian Kuhn wrote: > I can take a look. > > Do you have a test case that reproduces the error? If yes, which > packages do I have to checkout and which test to run? Or even better, > just upload me an image somewhere with an open debugger. > > PS ... you can use #attributeNamed: > > (class mooseDescription attributeNamed: #methods) getFrom: class > > cheers, > AA > >> I guess the bug is due to the new contract of #getFrom: and >> #setOn:values: that treats all properties as if multivalued. Before >> those methods called the bare selectors, that is, worked diff for >> single- and multivalued properties. > > > How can: > (class mooseDescription allAttributes detect: [:p | p name == > #methods]) getFrom: class > return a collection of FAMIXMethods ? > > Is there a new way to get values from a property? > > Adrian, can you have a look at it please? > > Cheers, > Alexandre > > >> >> >> cheers, >> AA >> >> >> On 4 Sep 2008, at 10:59 , Tudor Girba wrote: >> >>> Hmm, >>> >>> Something is funny here. I have to take a closer look. >>> >>> Cheers, >>> Doru >>> >>> >>> On Sep 4, 2008, at 10:27 AM, Alexandre Bergel wrote: >>> >>>> Hi, >>>> >>>> | class | >>>> class := FAMIXClass new. >>>> class name: 'AClass'. >>>> class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). >>>> class addToMethods: (FAMIXMethod new name: 'anotherMethod'; >>>> yourself). >>>> (class mooseDescription allAttributes detect: [:p | p name == >>>> #methods]) getFrom: class >>>> >>>> The following code returns: >>>> an Array(an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>>> #anotherMethod)) >>>> >>>> Shouldn't it be instead?: >>>> an OrderedCollection(a FAMIXMethod #aMethod a FAMIXMethod >>>> #anotherMethod) >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "It's not what we do that matters most, it's how we do it." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From oscar at iam.unibe.ch Thu Sep 4 20:10:16 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 4 Sep 2008 20:10:16 +0200 Subject: [Moose-dev] Re: tired.... In-Reply-To: <55211543-8BBA-4F7E-B76B-9E8AE4F8A30B@inria.fr> References: <55211543-8BBA-4F7E-B76B-9E8AE4F8A30B@inria.fr> Message-ID: Hm. Not sure which way it was in VW. My tendency is to throw away lazy initialization unless someone can prove that it is needed. I prefer to always see a comment explaining *why* lazy initialization is right. Cheers, - on On Sep 4, 2008, at 14:27, St?phane Ducasse wrote: > So can somebody smart explain to me the following > > before in Squeak incomingInvocations was > > incomingInvocations > incomingInvocations isNil ifTrue: [ incomingInvocations := > OrderedCollection new ]. > > > in oscar changes it is > > incomingInvocations > #candidates> > ^ incomingInvocations values > > > So what should I do. > Because now I do not know! But I'm certainly stupid for sure. > > What I know is that this metastuff gets in our way. > I do not care about reproducing complete code (which we cannot in FAME > because lazy initialization and other useful code level > idioms are not represented) and now instead of focusing on Moose I > have to deal with meta representation concerns. > Really I think that we got trapped there. > Knowing where to stop is as important as doing it. Next time I will > fight really hard against any smart cleaner cooler meta meta stuff. > Which is sad because I know what I'm talking about. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at univ-savoie.fr Thu Sep 4 21:44:05 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 4 Sep 2008 21:44:05 +0200 Subject: [Moose-dev] Re: accessedByLists vs. accessedByList In-Reply-To: <5E691DC3-1BE9-419A-9683-924470DC1C32@iam.unibe.ch> References: <5E691DC3-1BE9-419A-9683-924470DC1C32@iam.unibe.ch> Message-ID: <1A697BAE-9475-4ACC-91BA-A0B90A279258@univ-savoie.fr> Ok I did that even before sending the email :) On Sep 4, 2008, at 3:00 PM, Tudor Girba wrote: > This was a dirty fix for Meta to work on VW. You can remove > accessedByLists. > > Doru > > > On Sep 4, 2008, at 2:46 PM, st?phane ducasse wrote: > >> I'm confused. >> >> There are >> >> >> accessedByLists >> > #accesses> >> ^ accessedByLists >> >> but no instance variable >> >> the only one is accessedByList >> >> So what is the point? >> >> should I rename accessedByLists into accessedByList? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "When people care, great things can happen." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Fri Sep 5 08:58:16 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 5 Sep 2008 08:58:16 +0200 Subject: [Moose-dev] Re: tired.... In-Reply-To: References: <55211543-8BBA-4F7E-B76B-9E8AE4F8A30B@inria.fr> Message-ID: <1224C232-659E-43A0-974D-8E00B9948180@univ-savoie.fr> We used lazzy initialization because this is needed. When you have a lot of empty collection that are only used when they are used then it does not make sense to allocate them up front especially for FAMIX2Method objects. Stef > > Hm. > > Not sure which way it was in VW. My tendency is to throw away lazy > initialization unless someone can prove that it is needed. > > I prefer to always see a comment explaining *why* lazy initialization > is right. > > Cheers, > - on > > On Sep 4, 2008, at 14:27, St?phane Ducasse wrote: > >> So can somebody smart explain to me the following >> >> before in Squeak incomingInvocations was >> >> incomingInvocations >> incomingInvocations isNil ifTrue: [ incomingInvocations := >> OrderedCollection new ]. >> >> >> in oscar changes it is >> >> incomingInvocations >> > #candidates> >> ^ incomingInvocations values >> >> >> So what should I do. >> Because now I do not know! But I'm certainly stupid for sure. >> >> What I know is that this metastuff gets in our way. >> I do not care about reproducing complete code (which we cannot in >> FAME >> because lazy initialization and other useful code level >> idioms are not represented) and now instead of focusing on Moose I >> have to deal with meta representation concerns. >> Really I think that we got trapped there. >> Knowing where to stop is as important as doing it. Next time I will >> fight really hard against any smart cleaner cooler meta meta stuff. >> Which is sad because I know what I'm talking about. >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From girba at iam.unibe.ch Fri Sep 5 10:22:34 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 5 Sep 2008 10:22:34 +0200 Subject: [Moose-dev] Re: [Moose] problem install In-Reply-To: References: Message-ID: <893C7136-D3EC-4A9F-8E51-9495036EECB6@iam.unibe.ch> Hi Fabrizio Please try again, this time following the instructions from: http://moose.unibe.ch/download/scgstore Cheers, Doru On Sep 5, 2008, at 9:21 AM, Fabrizio Faustinoni wrote: > Good Morning, I am a student of University of MILAN (italy) > (universit? degli studi milano bicocca), > I need to install CodeDrawler ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > ), > I follow the seguent instruction ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > ) for install visualWorks, but after that i load > MooseSuiteLoaderFromSCGStore.pcl ( from the file brower of > visualWorks), it asked me to "Download lastest moose suite > development Version", then i click OK, after some operations there > is an error (attached images ), i try to solve de error but i > failed! Can you help me? > THanx and sorry for my bad english. > Fabrizio > > Scopri i nuovi giochi per il tuo Messenger. Mettiti in gioco! > _______________________________________________ > Moose mailing list > Moose at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose -- www.tudorgirba.com www.tudorgirba.com/blog "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From stephane.ducasse at gmail.com Fri Sep 5 11:25:07 2008 From: stephane.ducasse at gmail.com (stephane ducasse) Date: Fri, 5 Sep 2008 11:25:07 +0200 Subject: [Moose-dev] Fwd: [Moose] problem install References: Message-ID: Begin forwarded message: > From: Fabrizio Faustinoni > Date: September 5, 2008 9:21:23 AM CEDT > To: > Subject: [Moose] problem install > > Good Morning, I am a student of University of MILAN (italy) > (universit? degli studi milano bicocca), > I need to install CodeDrawler ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > ), > I follow the seguent instruction ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > ) for install visualWorks, but after that i load > MooseSuiteLoaderFromSCGStore.pcl ( from the file brower of > visualWorks), it asked me to "Download lastest moose suite > development Version", then i click OK, after some operations there > is an error (attached images ), i try to solve de error but i > failed! Can you help me? > THanx and sorry for my bad english. > Fabrizio > > Scopri i nuovi giochi per il tuo Messenger. Mettiti in gioco! > _______________________________________________ > Moose mailing list > Moose at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/moose-dev/attachments/20080905/f10fa182/attachment.html From girba at iam.unibe.ch Fri Sep 5 15:36:33 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 5 Sep 2008 15:36:33 +0200 Subject: [Moose-dev] Re: [Moose] problem install In-Reply-To: References: <893C7136-D3EC-4A9F-8E51-9495036EECB6@iam.unibe.ch> Message-ID: Hi Fabrizio, The problem is that CodeCrawler is not maintained since several years and it probably does not work with the latest version of Moose. So, I do not have an answer for you :(. Cheers, Doru On Sep 5, 2008, at 12:23 PM, Fabrizio Faustinoni wrote: > > Ok, i found how to install codeCrawler, but , i alwas more error.... > can you help me? thx > > > From: fabry_00 at hotmail.com > To: girba at iam.unibe.ch > Subject: RE: [Moose] problem install > Date: Fri, 5 Sep 2008 12:07:40 +0200 > > Thanks,Thanks,Thanks,Thanks for the help!!!! > > So, i follow the instruction ( there was another error ( error.jpg > attached) i pushed continue, but i thing that it isn't important) (i > try to load internalRelease and after Development, i have always the > same error), after tathl i didn't see the codeCrawler Icon as in > this videohttp://www.inf.unisi.ch/faculty/lanza/codecrawler.html . > So, after, i try again to load MooseSuiteLoaderFromSCGStore again, > but ther'is the same error that i posted befor! > How do i install codeCrawler? > Thanks again!. > Fabrizio > > > > > CC: moose-dev at iam.unibe.ch > > From: girba at iam.unibe.ch > > To: fabry_00 at hotmail.com > > Subject: Re: [Moose] problem install > > Date: Fri, 5 Sep 2008 10:22:34 +0200 > > > > Hi Fabrizio > > > > Please try again, this time following the instructions from: > > http://moose.unibe.ch/download/scgstore > > > > Cheers, > > Doru > > > > On Sep 5, 2008, at 9:21 AM, Fabrizio Faustinoni wrote: > > > > > Good Morning, I am a student of University of MILAN (italy) > > > (universit? degli studi milano bicocca), > > > I need to install CodeDrawler ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > > > ), > > > I follow the seguent instruction ( http://moose.unibe.ch/download?_s=lKodFeROpiPCfJhz&_k=KMXuKpsl&_n&80 > > > ) for install visualWorks, but after that i load > > > MooseSuiteLoaderFromSCGStore.pcl ( from the file brower of > > > visualWorks), it asked me to "Download lastest moose suite > > > development Version", then i click OK, after some operations there > > > is an error (attached images ), i try to solve de error but i > > > failed! Can you help me? > > > THanx and sorry for my bad english. > > > Fabrizio > > > > > > Scopri i nuovi giochi per il tuo Messenger. Mettiti in gioco! > > > _______________________________________________ > > > Moose mailing list > > > Moose at iam.unibe.ch > > > https://www.iam.unibe.ch/mailman/listinfo/moose > > > > -- > > www.tudorgirba.com > > www.tudorgirba.com/blog > > > > "If you interrupt the barber while he is cutting your hair, you will > > end up with a messy haircut." > > > > Foto, blog, amici. crea il tuo spazio online! C'? Spaces! > Scopri i nuovi giochi per il tuo Messenger. Mettiti in gioco! > -- www.tudorgirba.com www.tudorgirba.com/blog "The coherence of a trip is given by the clearness of the goal." From oscar at iam.unibe.ch Sat Sep 6 16:04:13 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sat, 6 Sep 2008 16:04:13 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> Message-ID: In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition that I did not realize. So although we patch up the lazy initializers, this may be done in the wrong order. I should sit together with Doru and have a look at it. - on On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: > The problem is that in Famix20 we have lazzy initializers and they got > replaced by direct accessor. > So signature was for example not lazzily computed anymore, and > breaking the debugger. :( > > So I do not know what is the contract stuff you are talking about but > at the end it should be fixed. > > Stef > > > On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: > >> The error I mentioned before is not due to the changes of Oscar and >> Toon. It's just that Fame has a different contract than Meta. >> >> Doru >> >> >> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >> >>> Apparently when applying blindly the changes of oscar I broke FAMIX2 >>> (argh) >>> so I will take another image and check one by one the suggested >>> changes and produce a new Famx20 package >>> >>> Stef >>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> I know it breaks. The errors that you mention are due to the fact >>>> that >>>> some old classes from VW do not conform to Fame. >>>> >>>> That is why I said that for the moment just put there >>>> FAMIX2ModelRoot >>>> and then I will take a look at the code in the afternoon. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>> >>>>> >>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>> correctly >>>>>> setup :). >>>>>> >>>>>> If you look in the code, then "MooseModel>>meta" is the one that >>>>>> returns the meta-model. >>>>> >>>>> Ah >>>>> I thought that we could plug any metamodel under fame >>>>> >>>>> >>>>> Now I did >>>>> >>>>> MooseModel2 class>>metaTower >>>>> "self resetMetaDescriptions. self metaTower" >>>>> >>>>> | pp | >>>>> ^metaTower ifNil: [ >>>>> pp := FMPragmaProcessor new. >>>>> pp queue: MooseEntity withAllSubclasses. >>>>> pp run. >>>>> metaTower := pp asTower] >>>>> >>>>> and I got a wonderful error which is a bad smell to me. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> It is lazily created and in the current >>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>> not >>>>>> include FAMIX2. >>>>>> >>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just to >>>>>> make >>>>>> it work with your code. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.tudorgirba.com/blog >>>> >>>> "What we can governs what we wish." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From itsme213 at hotmail.com Sat Sep 6 17:55:41 2008 From: itsme213 at hotmail.com (Itsme) Date: Sat, 6 Sep 2008 10:55:41 -0500 Subject: [Moose-dev] Quick Fame/FM3 question Message-ID: Hi. I am quite interested in using this to have more explicit representation of my models, and get some of the boiler-plate bits like accessors for 2-way associations code-generated. Is there anything like a short tutorial to help get started? I don't expect to be doing fancy meta-meta things for some time. Thanks! -- Sophie From girba at iam.unibe.ch Sat Sep 6 18:21:53 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Sat, 6 Sep 2008 18:21:53 +0200 Subject: [Moose-dev] Re: Quick Fame/FM3 question In-Reply-To: References: Message-ID: <0FF1B33E-2EF4-4A09-B51B-1C0BC5A246D9@iam.unibe.ch> Hi Sohpie, I think you will get more answers for this question on the fame-dev mailing list (in CC). Cheers, Doru On Sep 6, 2008, at 5:55 PM, Itsme wrote: > Hi. > > I am quite interested in using this to have more explicit > representation of > my models, and get some of the boiler-plate bits like accessors for > 2-way > associations code-generated. Is there anything like a short tutorial > to help > get started? I don't expect to be doing fancy meta-meta things for > some > time. > > Thanks! -- Sophie > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "No matter how many recipes we'll know, we'll still value a chef." From akuhn at gmx.ch Sat Sep 6 20:03:25 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Sat, 6 Sep 2008 20:03:25 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> Message-ID: <24017678-88D5-4B8C-8FED-DF4EF0128574@gmx.ch> Hi Alex, there is a typo in the pragmas of FAMIXClass >> #methods, replace with and then it works. NB as it seems, Squeak does compile methods with unknown pragmas where as WV throws an error if one uses an unknown pragma (which typically happens because of a typo). cheers, AA On 4 Sep 2008, at 15:15 , Alexandre Bergel wrote: > An image is available on http://www.bergel.eu/MooseSqueak.zip > > Just evaluate the following in a workspace: > | class | > class := FAMIXClass new. > class name: 'AClass'. > class addToMethods: (FAMIXMethod new name: 'aMethod'; yourself). > class addToMethods: (FAMIXMethod new name: 'anotherMethod'; > yourself). > (class mooseDescription attributeNamed: #methods) > getFrom: class > > Cheers, > Alexandre > > > On 4 Sep 2008, at 15:40, Adrian Kuhn wrote: > > > I can take a look. > > > > Do you have a test case that reproduces the error? If yes, which > > packages do I have to checkout and which test to run? Or even > better, > > just upload me an image somewhere with an open debugger. > > > > PS ... you can use #attributeNamed: > > > > (class mooseDescription attributeNamed: #methods) getFrom: class > > > > cheers, > > AA From renggli at gmail.com Sat Sep 6 20:54:07 2008 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 6 Sep 2008 20:54:07 +0200 Subject: [Moose-dev] Re: Bug in FAMIX? In-Reply-To: <24017678-88D5-4B8C-8FED-DF4EF0128574@gmx.ch> References: <0D15A9CB-5A70-405E-8565-45B53A344500@inria.fr> <24017678-88D5-4B8C-8FED-DF4EF0128574@gmx.ch> Message-ID: <67628d690809061154t21c330d4q87a4c3d8c9b89ad@mail.gmail.com> > NB as it seems, Squeak does compile methods with unknown pragmas > where as WV throws an error if one uses an unknown pragma (which > typically happens because of a typo). Yes, Squeak does not require pragmas to be declared. The compiler however throws a notification if you use an unknown selector and offers you to change it, similar to what it does when you use an unknown message send within normal code. In my opinion this is much more Smalltalk like than requiring a static declaration of pragmas. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From itsme213 at hotmail.com Sat Sep 6 21:13:48 2008 From: itsme213 at hotmail.com (Itsme) Date: Sat, 6 Sep 2008 14:13:48 -0500 Subject: [Moose-dev] Re: Quick Fame/FM3 question References: <0FF1B33E-2EF4-4A09-B51B-1C0BC5A246D9@iam.unibe.ch> Message-ID: Thanks. I just subscribed to that as well. Sophie ----- Original Message ----- From: "Tudor Girba" To: "Related to the development of Moose and other related tools" Cc: "Related to Fame and meta-modelling." Sent: Saturday, September 06, 2008 11:21 AM Subject: [Moose-dev] Re: Quick Fame/FM3 question > Hi Sohpie, > > I think you will get more answers for this question on the fame-dev > mailing list (in CC). > > Cheers, > Doru > > > On Sep 6, 2008, at 5:55 PM, Itsme wrote: > >> Hi. >> >> I am quite interested in using this to have more explicit >> representation of >> my models, and get some of the boiler-plate bits like accessors for >> 2-way >> associations code-generated. Is there anything like a short tutorial >> to help >> get started? I don't expect to be doing fancy meta-meta things for >> some >> time. >> >> Thanks! -- Sophie >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "No matter how many recipes we'll know, we'll still value a chef." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Sat Sep 6 21:30:49 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 6 Sep 2008 21:30:49 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> Message-ID: <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> Ok what I did was to go over all the changes you did (as they show up in the refactoring window) and check the code and evaluate what was changed. I put back most of the famix2 code (but let the annotations that were introduced by your changes). I think that there should be one or two cases where I was confused and it would be good if you can have a look. \ The most intriguing one was incomingInvocations ^ incomingInvocations values stef On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > > In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition > that I did not realize. > > So although we patch up the lazy initializers, this may be done in the > wrong order. > > I should sit together with Doru and have a look at it. > > - on > > On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: > >> The problem is that in Famix20 we have lazzy initializers and they >> got >> replaced by direct accessor. >> So signature was for example not lazzily computed anymore, and >> breaking the debugger. :( >> >> So I do not know what is the contract stuff you are talking about but >> at the end it should be fixed. >> >> Stef >> >> >> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >> >>> The error I mentioned before is not due to the changes of Oscar and >>> Toon. It's just that Fame has a different contract than Meta. >>> >>> Doru >>> >>> >>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>> >>>> Apparently when applying blindly the changes of oscar I broke >>>> FAMIX2 >>>> (argh) >>>> so I will take another image and check one by one the suggested >>>> changes and produce a new Famx20 package >>>> >>>> Stef >>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>> >>>>> Hi Stef, >>>>> >>>>> I know it breaks. The errors that you mention are due to the fact >>>>> that >>>>> some old classes from VW do not conform to Fame. >>>>> >>>>> That is why I said that for the moment just put there >>>>> FAMIX2ModelRoot >>>>> and then I will take a look at the code in the afternoon. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>> correctly >>>>>>> setup :). >>>>>>> >>>>>>> If you look in the code, then "MooseModel>>meta" is the one that >>>>>>> returns the meta-model. >>>>>> >>>>>> Ah >>>>>> I thought that we could plug any metamodel under fame >>>>>> >>>>>> >>>>>> Now I did >>>>>> >>>>>> MooseModel2 class>>metaTower >>>>>> "self resetMetaDescriptions. self metaTower" >>>>>> >>>>>> | pp | >>>>>> ^metaTower ifNil: [ >>>>>> pp := FMPragmaProcessor new. >>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>> pp run. >>>>>> metaTower := pp asTower] >>>>>> >>>>>> and I got a wonderful error which is a bad smell to me. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> It is lazily created and in the current >>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>> not >>>>>>> include FAMIX2. >>>>>>> >>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>> to >>>>>>> make >>>>>>> it work with your code. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.tudorgirba.com/blog >>>>> >>>>> "What we can governs what we wish." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "Problem solving efficiency grows with the abstractness level of >>> problem understanding." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From toon.verwaest at gmail.com Sun Sep 7 00:50:17 2008 From: toon.verwaest at gmail.com (Toon Verwaest) Date: Sun, 07 Sep 2008 00:50:17 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> Message-ID: <48C30929.9010301@igwe.vub.ac.be> This is probably because of the slot-objects which are generated by the codegenerator for properties with an opposite. This one clearly has an opposite so to get the actually value, in code where you use objects for slots, you have to call values on it. I guess that if you use a different strategy for handling opposites, you don't wont to have the "values" message sent. Or was there something else? St?phane Ducasse wrote: > Ok > what I did was to go over all the changes you did (as they show up in > the refactoring window) and check the code > and evaluate what was changed. I put back most of the famix2 code (but > let the annotations that were introduced by your changes). > I think that there should be one or two cases where I was confused and > it would be good if you can have a look. > \ > The most intriguing one was > incomingInvocations > #candidates> > ^ incomingInvocations values > > stef > > On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > > >> In the FAMIX2 Meta -> Fame stuff, there is apparently a race condition >> that I did not realize. >> >> So although we patch up the lazy initializers, this may be done in the >> wrong order. >> >> I should sit together with Doru and have a look at it. >> >> - on >> >> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >> >> >>> The problem is that in Famix20 we have lazzy initializers and they >>> got >>> replaced by direct accessor. >>> So signature was for example not lazzily computed anymore, and >>> breaking the debugger. :( >>> >>> So I do not know what is the contract stuff you are talking about but >>> at the end it should be fixed. >>> >>> Stef >>> >>> >>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>> >>> >>>> The error I mentioned before is not due to the changes of Oscar and >>>> Toon. It's just that Fame has a different contract than Meta. >>>> >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>> >>>> >>>>> Apparently when applying blindly the changes of oscar I broke >>>>> FAMIX2 >>>>> (argh) >>>>> so I will take another image and check one by one the suggested >>>>> changes and produce a new Famx20 package >>>>> >>>>> Stef >>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>> >>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I know it breaks. The errors that you mention are due to the fact >>>>>> that >>>>>> some old classes from VW do not conform to Fame. >>>>>> >>>>>> That is why I said that for the moment just put there >>>>>> FAMIX2ModelRoot >>>>>> and then I will take a look at the code in the afternoon. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>> >>>>>> >>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>> correctly >>>>>>>> setup :). >>>>>>>> >>>>>>>> If you look in the code, then "MooseModel>>meta" is the one that >>>>>>>> returns the meta-model. >>>>>>>> >>>>>>> Ah >>>>>>> I thought that we could plug any metamodel under fame >>>>>>> >>>>>>> >>>>>>> Now I did >>>>>>> >>>>>>> MooseModel2 class>>metaTower >>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>> >>>>>>> | pp | >>>>>>> ^metaTower ifNil: [ >>>>>>> pp := FMPragmaProcessor new. >>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>> pp run. >>>>>>> metaTower := pp asTower] >>>>>>> >>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is lazily created and in the current >>>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>>> not >>>>>>>> include FAMIX2. >>>>>>>> >>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>> to >>>>>>>> make >>>>>>>> it work with your code. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.tudorgirba.com/blog >>>>>> >>>>>> "What we can governs what we wish." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.tudorgirba.com/blog >>>> >>>> "Problem solving efficiency grows with the abstractness level of >>>> problem understanding." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Mon Sep 8 20:34:39 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Mon, 8 Sep 2008 20:34:39 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> Message-ID: <7349A11D-8C37-43A9-B73C-64CD95E204F2@iam.unibe.ch> Sorry, I have been swamped with meetings. I will try to sit with Doru and/or Toon on Tuesday afternoon to sort it out. - on On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: > Ok > what I did was to go over all the changes you did (as they show up in > the refactoring window) and check the code > and evaluate what was changed. I put back most of the famix2 code (but > let the annotations that were introduced by your changes). > I think that there should be one or two cases where I was confused and > it would be good if you can have a look. > \ > The most intriguing one was > incomingInvocations > #candidates> > ^ incomingInvocations values > > stef > > On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > >> >> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >> condition >> that I did not realize. >> >> So although we patch up the lazy initializers, this may be done in >> the >> wrong order. >> >> I should sit together with Doru and have a look at it. >> >> - on >> >> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >> >>> The problem is that in Famix20 we have lazzy initializers and they >>> got >>> replaced by direct accessor. >>> So signature was for example not lazzily computed anymore, and >>> breaking the debugger. :( >>> >>> So I do not know what is the contract stuff you are talking about >>> but >>> at the end it should be fixed. >>> >>> Stef >>> >>> >>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>> >>>> The error I mentioned before is not due to the changes of Oscar and >>>> Toon. It's just that Fame has a different contract than Meta. >>>> >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>> >>>>> Apparently when applying blindly the changes of oscar I broke >>>>> FAMIX2 >>>>> (argh) >>>>> so I will take another image and check one by one the suggested >>>>> changes and produce a new Famx20 package >>>>> >>>>> Stef >>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I know it breaks. The errors that you mention are due to the fact >>>>>> that >>>>>> some old classes from VW do not conform to Fame. >>>>>> >>>>>> That is why I said that for the moment just put there >>>>>> FAMIX2ModelRoot >>>>>> and then I will take a look at the code in the afternoon. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>> correctly >>>>>>>> setup :). >>>>>>>> >>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>> that >>>>>>>> returns the meta-model. >>>>>>> >>>>>>> Ah >>>>>>> I thought that we could plug any metamodel under fame >>>>>>> >>>>>>> >>>>>>> Now I did >>>>>>> >>>>>>> MooseModel2 class>>metaTower >>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>> >>>>>>> | pp | >>>>>>> ^metaTower ifNil: [ >>>>>>> pp := FMPragmaProcessor new. >>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>> pp run. >>>>>>> metaTower := pp asTower] >>>>>>> >>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is lazily created and in the current >>>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>>> not >>>>>>>> include FAMIX2. >>>>>>>> >>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>> to >>>>>>>> make >>>>>>>> it work with your code. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.tudorgirba.com/blog >>>>>> >>>>>> "What we can governs what we wish." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.tudorgirba.com/blog >>>> >>>> "Problem solving efficiency grows with the abstractness level of >>>> problem understanding." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Mon Sep 8 21:22:07 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 8 Sep 2008 21:22:07 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <7349A11D-8C37-43A9-B73C-64CD95E204F2@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <7349A11D-8C37-43A9-B73C-64CD95E204F2@iam.unibe.ch> Message-ID: No problem we are all swamped with meetings and works (and house fixing and kid juggling :)). Stef On Sep 8, 2008, at 8:34 PM, Oscar Nierstrasz wrote: > > Sorry, I have been swamped with meetings. > > I will try to sit with Doru and/or Toon on Tuesday afternoon to sort > it out. > > - on > > > On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: > >> Ok >> what I did was to go over all the changes you did (as they show up in >> the refactoring window) and check the code >> and evaluate what was changed. I put back most of the famix2 code >> (but >> let the annotations that were introduced by your changes). >> I think that there should be one or two cases where I was confused >> and >> it would be good if you can have a look. >> \ >> The most intriguing one was >> incomingInvocations >> > #candidates> >> ^ incomingInvocations values >> >> stef >> >> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >> >>> >>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>> condition >>> that I did not realize. >>> >>> So although we patch up the lazy initializers, this may be done in >>> the >>> wrong order. >>> >>> I should sit together with Doru and have a look at it. >>> >>> - on >>> >>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>> >>>> The problem is that in Famix20 we have lazzy initializers and they >>>> got >>>> replaced by direct accessor. >>>> So signature was for example not lazzily computed anymore, and >>>> breaking the debugger. :( >>>> >>>> So I do not know what is the contract stuff you are talking about >>>> but >>>> at the end it should be fixed. >>>> >>>> Stef >>>> >>>> >>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>> >>>>> The error I mentioned before is not due to the changes of Oscar >>>>> and >>>>> Toon. It's just that Fame has a different contract than Meta. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>> >>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>> FAMIX2 >>>>>> (argh) >>>>>> so I will take another image and check one by one the suggested >>>>>> changes and produce a new Famx20 package >>>>>> >>>>>> Stef >>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi Stef, >>>>>>> >>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>> fact >>>>>>> that >>>>>>> some old classes from VW do not conform to Fame. >>>>>>> >>>>>>> That is why I said that for the moment just put there >>>>>>> FAMIX2ModelRoot >>>>>>> and then I will take a look at the code in the afternoon. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>>> correctly >>>>>>>>> setup :). >>>>>>>>> >>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>> that >>>>>>>>> returns the meta-model. >>>>>>>> >>>>>>>> Ah >>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>> >>>>>>>> >>>>>>>> Now I did >>>>>>>> >>>>>>>> MooseModel2 class>>metaTower >>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>> >>>>>>>> | pp | >>>>>>>> ^metaTower ifNil: [ >>>>>>>> pp := FMPragmaProcessor new. >>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>> pp run. >>>>>>>> metaTower := pp asTower] >>>>>>>> >>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> It is lazily created and in the current >>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>> does >>>>>>>>> not >>>>>>>>> include FAMIX2. >>>>>>>>> >>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>>> to >>>>>>>>> make >>>>>>>>> it work with your code. >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.tudorgirba.com/blog >>>>>>> >>>>>>> "What we can governs what we wish." >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.tudorgirba.com/blog >>>>> >>>>> "Problem solving efficiency grows with the abstractness level of >>>>> problem understanding." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Tue Sep 9 16:06:02 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Tue, 9 Sep 2008 16:06:02 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> Message-ID: <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> Hi, Doru and I looked at FMPragmaGenerator and ran it again. The problem was that we needed to first set FMPragmaGenerator>>promptToAcceptChanges to return false so that the patches will be properly installed. We have committed FAMIX2-Model-on.32. It should be ok now. - on and tg PS: We used Fame-on.65 to avoid any potential compatibility problems with Adrian's latest changes. (We didn't check if there were any.) On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: > Ok > what I did was to go over all the changes you did (as they show up in > the refactoring window) and check the code > and evaluate what was changed. I put back most of the famix2 code (but > let the annotations that were introduced by your changes). > I think that there should be one or two cases where I was confused and > it would be good if you can have a look. > \ > The most intriguing one was > incomingInvocations > #candidates> > ^ incomingInvocations values > > stef > > On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > >> >> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >> condition >> that I did not realize. >> >> So although we patch up the lazy initializers, this may be done in >> the >> wrong order. >> >> I should sit together with Doru and have a look at it. >> >> - on >> >> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >> >>> The problem is that in Famix20 we have lazzy initializers and they >>> got >>> replaced by direct accessor. >>> So signature was for example not lazzily computed anymore, and >>> breaking the debugger. :( >>> >>> So I do not know what is the contract stuff you are talking about >>> but >>> at the end it should be fixed. >>> >>> Stef >>> >>> >>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>> >>>> The error I mentioned before is not due to the changes of Oscar and >>>> Toon. It's just that Fame has a different contract than Meta. >>>> >>>> Doru >>>> >>>> >>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>> >>>>> Apparently when applying blindly the changes of oscar I broke >>>>> FAMIX2 >>>>> (argh) >>>>> so I will take another image and check one by one the suggested >>>>> changes and produce a new Famx20 package >>>>> >>>>> Stef >>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I know it breaks. The errors that you mention are due to the fact >>>>>> that >>>>>> some old classes from VW do not conform to Fame. >>>>>> >>>>>> That is why I said that for the moment just put there >>>>>> FAMIX2ModelRoot >>>>>> and then I will take a look at the code in the afternoon. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>> correctly >>>>>>>> setup :). >>>>>>>> >>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>> that >>>>>>>> returns the meta-model. >>>>>>> >>>>>>> Ah >>>>>>> I thought that we could plug any metamodel under fame >>>>>>> >>>>>>> >>>>>>> Now I did >>>>>>> >>>>>>> MooseModel2 class>>metaTower >>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>> >>>>>>> | pp | >>>>>>> ^metaTower ifNil: [ >>>>>>> pp := FMPragmaProcessor new. >>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>> pp run. >>>>>>> metaTower := pp asTower] >>>>>>> >>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is lazily created and in the current >>>>>>>> implementation is starts the lookup from FAMIXEntity which does >>>>>>>> not >>>>>>>> include FAMIX2. >>>>>>>> >>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>> to >>>>>>>> make >>>>>>>> it work with your code. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.tudorgirba.com/blog >>>>>> >>>>>> "What we can governs what we wish." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.tudorgirba.com/blog >>>> >>>> "Problem solving efficiency grows with the abstractness level of >>>> problem understanding." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From tverwaes at infogroep.be Tue Sep 9 17:04:35 2008 From: tverwaes at infogroep.be (Toon Verwaest) Date: Tue, 9 Sep 2008 17:04:35 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> References: <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> Message-ID: <20080909150435.GA24133@infogroep.be> Oh right, that thing. I knew that we were going to forget that one :) On (09/09/08 16:06), Oscar Nierstrasz wrote: > From: Oscar Nierstrasz > To: Related to the development of Moose and other related tools > > Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations > metamodel explore > Date: Tue, 9 Sep 2008 16:06:02 +0200 > > > Hi, > > Doru and I looked at FMPragmaGenerator and ran it again. > > The problem was that we needed to first set > FMPragmaGenerator>>promptToAcceptChanges to return false so that the > patches will be properly installed. > > We have committed FAMIX2-Model-on.32. It should be ok now. > > - on and tg > > PS: We used Fame-on.65 to avoid any potential compatibility problems > with Adrian's latest changes. (We didn't check if there were any.) > > > On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: > > > Ok > > what I did was to go over all the changes you did (as they show up in > > the refactoring window) and check the code > > and evaluate what was changed. I put back most of the famix2 code (but > > let the annotations that were introduced by your changes). > > I think that there should be one or two cases where I was confused and > > it would be good if you can have a look. > > \ > > The most intriguing one was > > incomingInvocations > > > #candidates> > > ^ incomingInvocations values > > > > stef > > > > On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: > > > >> > >> In the FAMIX2 Meta -> Fame stuff, there is apparently a race > >> condition > >> that I did not realize. > >> > >> So although we patch up the lazy initializers, this may be done in > >> the > >> wrong order. > >> > >> I should sit together with Doru and have a look at it. > >> > >> - on > >> > >> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: > >> > >>> The problem is that in Famix20 we have lazzy initializers and they > >>> got > >>> replaced by direct accessor. > >>> So signature was for example not lazzily computed anymore, and > >>> breaking the debugger. :( > >>> > >>> So I do not know what is the contract stuff you are talking about > >>> but > >>> at the end it should be fixed. > >>> > >>> Stef > >>> > >>> > >>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: > >>> > >>>> The error I mentioned before is not due to the changes of Oscar and > >>>> Toon. It's just that Fame has a different contract than Meta. > >>>> > >>>> Doru > >>>> > >>>> > >>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: > >>>> > >>>>> Apparently when applying blindly the changes of oscar I broke > >>>>> FAMIX2 > >>>>> (argh) > >>>>> so I will take another image and check one by one the suggested > >>>>> changes and produce a new Famx20 package > >>>>> > >>>>> Stef > >>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: > >>>>> > >>>>>> Hi Stef, > >>>>>> > >>>>>> I know it breaks. The errors that you mention are due to the fact > >>>>>> that > >>>>>> some old classes from VW do not conform to Fame. > >>>>>> > >>>>>> That is why I said that for the moment just put there > >>>>>> FAMIX2ModelRoot > >>>>>> and then I will take a look at the code in the afternoon. > >>>>>> > >>>>>> Cheers, > >>>>>> Doru > >>>>>> > >>>>>> > >>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: > >>>>>> > >>>>>>> > >>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> FAMIX2Class mooseDescription works only if the repository is > >>>>>>>> correctly > >>>>>>>> setup :). > >>>>>>>> > >>>>>>>> If you look in the code, then "MooseModel>>meta" is the one > >>>>>>>> that > >>>>>>>> returns the meta-model. > >>>>>>> > >>>>>>> Ah > >>>>>>> I thought that we could plug any metamodel under fame > >>>>>>> > >>>>>>> > >>>>>>> Now I did > >>>>>>> > >>>>>>> MooseModel2 class>>metaTower > >>>>>>> "self resetMetaDescriptions. self metaTower" > >>>>>>> > >>>>>>> | pp | > >>>>>>> ^metaTower ifNil: [ > >>>>>>> pp := FMPragmaProcessor new. > >>>>>>> pp queue: MooseEntity withAllSubclasses. > >>>>>>> pp run. > >>>>>>> metaTower := pp asTower] > >>>>>>> > >>>>>>> and I got a wonderful error which is a bad smell to me. > >>>>>>> > >>>>>>> > >>>>>>> Stef > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> It is lazily created and in the current > >>>>>>>> implementation is starts the lookup from FAMIXEntity which does > >>>>>>>> not > >>>>>>>> include FAMIX2. > >>>>>>>> > >>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just > >>>>>>>> to > >>>>>>>> make > >>>>>>>> it work with your code. > >>>>>>>> > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moose-dev mailing list > >>>>>>> Moose-dev at iam.unibe.ch > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>>> -- > >>>>>> www.tudorgirba.com > >>>>>> www.tudorgirba.com/blog > >>>>>> > >>>>>> "What we can governs what we wish." > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> Moose-dev at iam.unibe.ch > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev at iam.unibe.ch > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> www.tudorgirba.com/blog > >>>> > >>>> "Problem solving efficiency grows with the abstractness level of > >>>> problem understanding." > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev at iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev at iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev at iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev at iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at univ-savoie.fr Tue Sep 9 22:09:40 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 9 Sep 2008 22:09:40 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> Message-ID: tell me more since I integrated your changes, do I have to do it again did you work directly on famix20 classes? did you change/fix the changes I did? Stef On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: > > Hi, > > Doru and I looked at FMPragmaGenerator and ran it again. > > The problem was that we needed to first set > FMPragmaGenerator>>promptToAcceptChanges to return false so that the > patches will be properly installed. > > We have committed FAMIX2-Model-on.32. It should be ok now. > > - on and tg > > PS: We used Fame-on.65 to avoid any potential compatibility problems > with Adrian's latest changes. (We didn't check if there were any.) > > > On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: > >> Ok >> what I did was to go over all the changes you did (as they show up in >> the refactoring window) and check the code >> and evaluate what was changed. I put back most of the famix2 code >> (but >> let the annotations that were introduced by your changes). >> I think that there should be one or two cases where I was confused >> and >> it would be good if you can have a look. >> \ >> The most intriguing one was >> incomingInvocations >> > #candidates> >> ^ incomingInvocations values >> >> stef >> >> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >> >>> >>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>> condition >>> that I did not realize. >>> >>> So although we patch up the lazy initializers, this may be done in >>> the >>> wrong order. >>> >>> I should sit together with Doru and have a look at it. >>> >>> - on >>> >>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>> >>>> The problem is that in Famix20 we have lazzy initializers and they >>>> got >>>> replaced by direct accessor. >>>> So signature was for example not lazzily computed anymore, and >>>> breaking the debugger. :( >>>> >>>> So I do not know what is the contract stuff you are talking about >>>> but >>>> at the end it should be fixed. >>>> >>>> Stef >>>> >>>> >>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>> >>>>> The error I mentioned before is not due to the changes of Oscar >>>>> and >>>>> Toon. It's just that Fame has a different contract than Meta. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>> >>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>> FAMIX2 >>>>>> (argh) >>>>>> so I will take another image and check one by one the suggested >>>>>> changes and produce a new Famx20 package >>>>>> >>>>>> Stef >>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi Stef, >>>>>>> >>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>> fact >>>>>>> that >>>>>>> some old classes from VW do not conform to Fame. >>>>>>> >>>>>>> That is why I said that for the moment just put there >>>>>>> FAMIX2ModelRoot >>>>>>> and then I will take a look at the code in the afternoon. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>>> correctly >>>>>>>>> setup :). >>>>>>>>> >>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>> that >>>>>>>>> returns the meta-model. >>>>>>>> >>>>>>>> Ah >>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>> >>>>>>>> >>>>>>>> Now I did >>>>>>>> >>>>>>>> MooseModel2 class>>metaTower >>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>> >>>>>>>> | pp | >>>>>>>> ^metaTower ifNil: [ >>>>>>>> pp := FMPragmaProcessor new. >>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>> pp run. >>>>>>>> metaTower := pp asTower] >>>>>>>> >>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> It is lazily created and in the current >>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>> does >>>>>>>>> not >>>>>>>>> include FAMIX2. >>>>>>>>> >>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment just >>>>>>>>> to >>>>>>>>> make >>>>>>>>> it work with your code. >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.tudorgirba.com/blog >>>>>>> >>>>>>> "What we can governs what we wish." >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.tudorgirba.com/blog >>>>> >>>>> "Problem solving efficiency grows with the abstractness level of >>>>> problem understanding." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at gmail.com Tue Sep 9 22:16:28 2008 From: stephane.ducasse at gmail.com (stephane ducasse) Date: Tue, 9 Sep 2008 22:16:28 +0200 Subject: [Moose-dev] Fwd: [Moose] Some problems when loading recent Moose Suite References: <48C54B3F.3050904@heeg.de> Message-ID: <1159F305-48C5-45B0-AB02-270F87B9AB7A@gmail.com> Begin forwarded message: > From: Holger Guhl > Date: September 8, 2008 5:56:47 PM CEDT > To: moose at iam.unibe.ch > Subject: [Moose] Some problems when loading recent Moose Suite > > Hi, folks, > maybe I'm not the first one to mention, but I have some problems when > loading the recent Moose Suite using the MooseSuiteLoader parcel. I > got > two unloadable reports: >> Warning: Package "Clustering" cannot be loaded. >> >> The following classes cannot be loaded because their superclasses are >> neither in the image nor in the package being loaded: >> ClusteringData (subclass of Root.Smalltalk.Hapax.SymetricMatrix) >> VectorItem (subclass of Root.Smalltalk.Hapax.VectorDecorator) >> ClusteringVector (subclass of Root.Smalltalk.Hapax.ArrayVector) >> DistanceSquare (subclass of Root.Smalltalk.Hapax.SymetricMatrix) >> CorrelationVector (subclass of Root.Smalltalk.Hapax.Vector) >> >> Warning: Package "SmallDudeUtils" cannot be loaded. >> >> The following classes cannot be loaded because their superclasses are >> neither in the image nor in the package being loaded: >> BooleanSymetricMatrix (subclass of >> Root.Smalltalk.Hapax.SymetricMatrix) >> BooleanVector (subclass of Root.Smalltalk.Hapax.Vector) >> BooleanMatrix (subclass of Root.Smalltalk.Hapax.Matrix) >> > I could fix it by manually loading LinearAlgebra > (2.1.72.matter.1,matter)= and then reload the packages listed above. I > hope it was correct to use the most recent versions. > The next problem I had was (after pressing the "Moose" button in the > VisualLauncher) > Unhandled exception: Key not found: > during SCG.Moose.MooseBrowser class>>buildHistoryIcon > The method wants to retrieve an icon from ToolbarIconLibrary. > This can easily be fixed: Just add UIPainter to the prerequisites. > > Best regards > > Holger Guhl > -- > Senior Consultant * Certified Scrum Master * Holger.Guhl at heeg.de > Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 > Georg Heeg eK Dortmund > Handelsregister: Amtsgericht Dortmund A 12812 > > _______________________________________________ > Moose mailing list > Moose at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose From girba at iam.unibe.ch Tue Sep 9 23:42:06 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Tue, 9 Sep 2008 23:42:06 +0200 Subject: [Moose-dev] Re: [Moose] Some problems when loading recent Moose Suite In-Reply-To: <48C54B3F.3050904@heeg.de> References: <48C54B3F.3050904@heeg.de> Message-ID: Hi, Thanks for the report. I know that MooseSuiteLoader parcel has problems connecting to our store for some strange reasons, but I do not have errors loading the latest version of Moose. If you want to try to load the latest version, please just load the package "Moose Config". This one has as prerequisites the various components of Moose. We usually set the "Load the latest Development" setting before loading. If you try it, please tell us if you still get the error. Cheers, Doru On Sep 8, 2008, at 5:56 PM, Holger Guhl wrote: > Hi, folks, > maybe I'm not the first one to mention, but I have some problems when > loading the recent Moose Suite using the MooseSuiteLoader parcel. I > got > two unloadable reports: >> Warning: Package "Clustering" cannot be loaded. >> >> The following classes cannot be loaded because their superclasses are >> neither in the image nor in the package being loaded: >> ClusteringData (subclass of Root.Smalltalk.Hapax.SymetricMatrix) >> VectorItem (subclass of Root.Smalltalk.Hapax.VectorDecorator) >> ClusteringVector (subclass of Root.Smalltalk.Hapax.ArrayVector) >> DistanceSquare (subclass of Root.Smalltalk.Hapax.SymetricMatrix) >> CorrelationVector (subclass of Root.Smalltalk.Hapax.Vector) >> >> Warning: Package "SmallDudeUtils" cannot be loaded. >> >> The following classes cannot be loaded because their superclasses are >> neither in the image nor in the package being loaded: >> BooleanSymetricMatrix (subclass of >> Root.Smalltalk.Hapax.SymetricMatrix) >> BooleanVector (subclass of Root.Smalltalk.Hapax.Vector) >> BooleanMatrix (subclass of Root.Smalltalk.Hapax.Matrix) >> > I could fix it by manually loading LinearAlgebra > (2.1.72.matter.1,matter)= and then reload the packages listed above. I > hope it was correct to use the most recent versions. > The next problem I had was (after pressing the "Moose" button in the > VisualLauncher) > Unhandled exception: Key not found: > during SCG.Moose.MooseBrowser class>>buildHistoryIcon > The method wants to retrieve an icon from ToolbarIconLibrary. > This can easily be fixed: Just add UIPainter to the prerequisites. > > Best regards > > Holger Guhl > -- > Senior Consultant * Certified Scrum Master * Holger.Guhl at heeg.de > Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 > Georg Heeg eK Dortmund > Handelsregister: Amtsgericht Dortmund A 12812 > > _______________________________________________ > Moose mailing list > Moose at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose -- www.tudorgirba.com www.tudorgirba.com/blog "Some battles are better lost than fought." From akuhn at gmx.ch Sun Sep 14 08:28:11 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Sun, 14 Sep 2008 08:28:11 +0200 Subject: [Moose-dev] [Fame for Squeak] Fame-Meta2Fame moved to FameUtil Message-ID: <0EE9DA20-2CC4-4221-9B96-D4129EF3D6AC@gmx.ch> If you update Fame, you will find that the FAMIX migration script has been moved from Fame to FameUtil. cheers, AA From oscar at iam.unibe.ch Sun Sep 14 09:19:35 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sun, 14 Sep 2008 09:19:35 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> Message-ID: Hi Stef, I am confused about the current status. I thought you rolled back to the previous FAMIX2 because you could not get the generated changes to work since the patches were missing. If our changes are already in FAMIX2, then all you need to do is to check the patches. They have moved to FameUtil. There is a protocol with several patch* methods. They can be run at any time. Just check if what you did is consistent with the patch* methods. FMPragmaGenerator>>patchAllFAMIXspecialCases I just loaded the latest version and checked the first patch: patchFAMIX2AbstractBehaviouralEntity FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" "all variable accesses contained in receiver" accesses isNil ifTrue: [ accesses := OrderedCollection new ]. ^ accesses'. ... However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see this: accesses self flag:#famix20Transfer. "in VW was incomingInvocations isNil ifTrue: [ incomingInvocations := OrderedCollection new ]. " ^ accesses So I guess the patches have not been run. To rerun the patches, simply evaluated the following: (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) patchAllFAMIXspecialCases This will put back all the lazy initializers and fix all the other broken stuff. I suggets you browse the patch* methods to see if you are convinced that they are ok. - on On Sep 9, 2008, at 22:09, St?phane Ducasse wrote: > tell me more > since I integrated your changes, do I have to do it again > did you work directly on famix20 classes? > did you change/fix the changes I did? > > Stef > > > On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: > >> >> Hi, >> >> Doru and I looked at FMPragmaGenerator and ran it again. >> >> The problem was that we needed to first set >> FMPragmaGenerator>>promptToAcceptChanges to return false so that the >> patches will be properly installed. >> >> We have committed FAMIX2-Model-on.32. It should be ok now. >> >> - on and tg >> >> PS: We used Fame-on.65 to avoid any potential compatibility problems >> with Adrian's latest changes. (We didn't check if there were any.) >> >> >> On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: >> >>> Ok >>> what I did was to go over all the changes you did (as they show up >>> in >>> the refactoring window) and check the code >>> and evaluate what was changed. I put back most of the famix2 code >>> (but >>> let the annotations that were introduced by your changes). >>> I think that there should be one or two cases where I was confused >>> and >>> it would be good if you can have a look. >>> \ >>> The most intriguing one was >>> incomingInvocations >>> >> #candidates> >>> ^ incomingInvocations values >>> >>> stef >>> >>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>> >>>> >>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>> condition >>>> that I did not realize. >>>> >>>> So although we patch up the lazy initializers, this may be done in >>>> the >>>> wrong order. >>>> >>>> I should sit together with Doru and have a look at it. >>>> >>>> - on >>>> >>>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>>> >>>>> The problem is that in Famix20 we have lazzy initializers and they >>>>> got >>>>> replaced by direct accessor. >>>>> So signature was for example not lazzily computed anymore, and >>>>> breaking the debugger. :( >>>>> >>>>> So I do not know what is the contract stuff you are talking about >>>>> but >>>>> at the end it should be fixed. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>> >>>>>> The error I mentioned before is not due to the changes of Oscar >>>>>> and >>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>>> >>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>> FAMIX2 >>>>>>> (argh) >>>>>>> so I will take another image and check one by one the suggested >>>>>>> changes and produce a new Famx20 package >>>>>>> >>>>>>> Stef >>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi Stef, >>>>>>>> >>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>> fact >>>>>>>> that >>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>> >>>>>>>> That is why I said that for the moment just put there >>>>>>>> FAMIX2ModelRoot >>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>>>> correctly >>>>>>>>>> setup :). >>>>>>>>>> >>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>>> that >>>>>>>>>> returns the meta-model. >>>>>>>>> >>>>>>>>> Ah >>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>> >>>>>>>>> >>>>>>>>> Now I did >>>>>>>>> >>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>> >>>>>>>>> | pp | >>>>>>>>> ^metaTower ifNil: [ >>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>> pp run. >>>>>>>>> metaTower := pp asTower] >>>>>>>>> >>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> It is lazily created and in the current >>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>> does >>>>>>>>>> not >>>>>>>>>> include FAMIX2. >>>>>>>>>> >>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>> just >>>>>>>>>> to >>>>>>>>>> make >>>>>>>>>> it work with your code. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.tudorgirba.com/blog >>>>>>>> >>>>>>>> "What we can governs what we wish." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.tudorgirba.com/blog >>>>>> >>>>>> "Problem solving efficiency grows with the abstractness level of >>>>>> problem understanding." >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Sun Sep 14 12:04:58 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sun, 14 Sep 2008 12:04:58 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> Message-ID: <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> Im confused too :( Here is what I did I took fame-on65 run it and merged it then I run fame-on65 and went over all the conflicts and took back the method body that the automatic changes removed. I was not aware of patch methods. So I will have a look at them. Stef > > Hi Stef, > > I am confused about the current status. I thought you rolled back to > the previous FAMIX2 because you could not get the generated changes to > work since the patches were missing. If our changes are already in > FAMIX2, then all you need to do is to check the patches. They have > moved to FameUtil. There is a protocol with several patch* methods. > They can be run at any time. Just check if what you did is consistent > with the patch* methods. > > FMPragmaGenerator>>patchAllFAMIXspecialCases > > I just loaded the latest version and checked the first patch: > > patchFAMIX2AbstractBehaviouralEntity > FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" > > > "all variable accesses contained in receiver" > accesses isNil ifTrue: [ accesses := OrderedCollection new ]. > ^ accesses'. > ... > > However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see > this: > > accesses > > > > self flag:#famix20Transfer. > "in VW was incomingInvocations isNil ifTrue: > [ incomingInvocations := OrderedCollection new ]. " > ^ accesses > > So I guess the patches have not been run. > > To rerun the patches, simply evaluated the following: > > (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) > patchAllFAMIXspecialCases > > This will put back all the lazy initializers and fix all the other > broken stuff. > > I suggets you browse the patch* methods to see if you are convinced > that they are ok. ok I will > > > - on > > On Sep 9, 2008, at 22:09, St?phane Ducasse wrote: > >> tell me more >> since I integrated your changes, do I have to do it again >> did you work directly on famix20 classes? >> did you change/fix the changes I did? >> >> Stef >> >> >> On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: >> >>> >>> Hi, >>> >>> Doru and I looked at FMPragmaGenerator and ran it again. >>> >>> The problem was that we needed to first set >>> FMPragmaGenerator>>promptToAcceptChanges to return false so that the >>> patches will be properly installed. >>> >>> We have committed FAMIX2-Model-on.32. It should be ok now. >>> >>> - on and tg >>> >>> PS: We used Fame-on.65 to avoid any potential compatibility problems >>> with Adrian's latest changes. (We didn't check if there were any.) >>> >>> >>> On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: >>> >>>> Ok >>>> what I did was to go over all the changes you did (as they show up >>>> in >>>> the refactoring window) and check the code >>>> and evaluate what was changed. I put back most of the famix2 code >>>> (but >>>> let the annotations that were introduced by your changes). >>>> I think that there should be one or two cases where I was confused >>>> and >>>> it would be good if you can have a look. >>>> \ >>>> The most intriguing one was >>>> incomingInvocations >>>> >>> opposite: >>>> #candidates> >>>> ^ incomingInvocations values >>>> >>>> stef >>>> >>>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>>> >>>>> >>>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>>> condition >>>>> that I did not realize. >>>>> >>>>> So although we patch up the lazy initializers, this may be done in >>>>> the >>>>> wrong order. >>>>> >>>>> I should sit together with Doru and have a look at it. >>>>> >>>>> - on >>>>> >>>>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>>>> >>>>>> The problem is that in Famix20 we have lazzy initializers and >>>>>> they >>>>>> got >>>>>> replaced by direct accessor. >>>>>> So signature was for example not lazzily computed anymore, and >>>>>> breaking the debugger. :( >>>>>> >>>>>> So I do not know what is the contract stuff you are talking about >>>>>> but >>>>>> at the end it should be fixed. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>>> >>>>>>> The error I mentioned before is not due to the changes of Oscar >>>>>>> and >>>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>>> >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>>>> >>>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>>> FAMIX2 >>>>>>>> (argh) >>>>>>>> so I will take another image and check one by one the suggested >>>>>>>> changes and produce a new Famx20 package >>>>>>>> >>>>>>>> Stef >>>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>>> >>>>>>>>> Hi Stef, >>>>>>>>> >>>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>>> fact >>>>>>>>> that >>>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>>> >>>>>>>>> That is why I said that for the moment just put there >>>>>>>>> FAMIX2ModelRoot >>>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> FAMIX2Class mooseDescription works only if the repository is >>>>>>>>>>> correctly >>>>>>>>>>> setup :). >>>>>>>>>>> >>>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>>>> that >>>>>>>>>>> returns the meta-model. >>>>>>>>>> >>>>>>>>>> Ah >>>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now I did >>>>>>>>>> >>>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>>> >>>>>>>>>> | pp | >>>>>>>>>> ^metaTower ifNil: [ >>>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>>> pp run. >>>>>>>>>> metaTower := pp asTower] >>>>>>>>>> >>>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> It is lazily created and in the current >>>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>>> does >>>>>>>>>>> not >>>>>>>>>>> include FAMIX2. >>>>>>>>>>> >>>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>>> just >>>>>>>>>>> to >>>>>>>>>>> make >>>>>>>>>>> it work with your code. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> www.tudorgirba.com/blog >>>>>>>>> >>>>>>>>> "What we can governs what we wish." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.tudorgirba.com/blog >>>>>>> >>>>>>> "Problem solving efficiency grows with the abstractness level of >>>>>>> problem understanding." >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Sun Sep 14 12:11:53 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sun, 14 Sep 2008 12:11:53 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> Message-ID: <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> You will probably find that the patch methods are doing what you tried to do by hand. (Of course we had to go through the methods by hand to build the patch methods, but at least the patches are documented.) Hope that helps. - on On Sep 14, 2008, at 12:04, St?phane Ducasse wrote: > Im confused too :( > > Here is what I did > > I took fame-on65 > run it and merged it > then I run fame-on65 and went over all the conflicts and > took back the method body that the automatic changes > removed. > > I was not aware of patch methods. So I will have a look at them. > Stef > >> >> Hi Stef, >> >> I am confused about the current status. I thought you rolled back to >> the previous FAMIX2 because you could not get the generated changes >> to >> work since the patches were missing. If our changes are already in >> FAMIX2, then all you need to do is to check the patches. They have >> moved to FameUtil. There is a protocol with several patch* methods. >> They can be run at any time. Just check if what you did is >> consistent >> with the patch* methods. >> >> FMPragmaGenerator>>patchAllFAMIXspecialCases >> >> I just loaded the latest version and checked the first patch: >> >> patchFAMIX2AbstractBehaviouralEntity >> FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" >> >> >> "all variable accesses contained in receiver" >> accesses isNil ifTrue: [ accesses := OrderedCollection new ]. >> ^ accesses'. >> ... >> >> However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see >> this: >> >> accesses >> >> >> >> self flag:#famix20Transfer. >> "in VW was incomingInvocations isNil ifTrue: >> [ incomingInvocations := OrderedCollection new ]. " >> ^ accesses >> >> So I guess the patches have not been run. >> >> To rerun the patches, simply evaluated the following: >> >> (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) >> patchAllFAMIXspecialCases >> >> This will put back all the lazy initializers and fix all the other >> broken stuff. >> >> I suggets you browse the patch* methods to see if you are convinced >> that they are ok. > > ok I will > >> >> >> - on >> >> On Sep 9, 2008, at 22:09, St?phane Ducasse wrote: >> >>> tell me more >>> since I integrated your changes, do I have to do it again >>> did you work directly on famix20 classes? >>> did you change/fix the changes I did? >>> >>> Stef >>> >>> >>> On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: >>> >>>> >>>> Hi, >>>> >>>> Doru and I looked at FMPragmaGenerator and ran it again. >>>> >>>> The problem was that we needed to first set >>>> FMPragmaGenerator>>promptToAcceptChanges to return false so that >>>> the >>>> patches will be properly installed. >>>> >>>> We have committed FAMIX2-Model-on.32. It should be ok now. >>>> >>>> - on and tg >>>> >>>> PS: We used Fame-on.65 to avoid any potential compatibility >>>> problems >>>> with Adrian's latest changes. (We didn't check if there were any.) >>>> >>>> >>>> On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: >>>> >>>>> Ok >>>>> what I did was to go over all the changes you did (as they show up >>>>> in >>>>> the refactoring window) and check the code >>>>> and evaluate what was changed. I put back most of the famix2 code >>>>> (but >>>>> let the annotations that were introduced by your changes). >>>>> I think that there should be one or two cases where I was confused >>>>> and >>>>> it would be good if you can have a look. >>>>> \ >>>>> The most intriguing one was >>>>> incomingInvocations >>>>> >>>> opposite: >>>>> #candidates> >>>>> ^ incomingInvocations values >>>>> >>>>> stef >>>>> >>>>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>>>> >>>>>> >>>>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>>>> condition >>>>>> that I did not realize. >>>>>> >>>>>> So although we patch up the lazy initializers, this may be done >>>>>> in >>>>>> the >>>>>> wrong order. >>>>>> >>>>>> I should sit together with Doru and have a look at it. >>>>>> >>>>>> - on >>>>>> >>>>>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>>>>> >>>>>>> The problem is that in Famix20 we have lazzy initializers and >>>>>>> they >>>>>>> got >>>>>>> replaced by direct accessor. >>>>>>> So signature was for example not lazzily computed anymore, and >>>>>>> breaking the debugger. :( >>>>>>> >>>>>>> So I do not know what is the contract stuff you are talking >>>>>>> about >>>>>>> but >>>>>>> at the end it should be fixed. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>>>> >>>>>>>> The error I mentioned before is not due to the changes of Oscar >>>>>>>> and >>>>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>>>> >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>>>>> >>>>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>>>> FAMIX2 >>>>>>>>> (argh) >>>>>>>>> so I will take another image and check one by one the >>>>>>>>> suggested >>>>>>>>> changes and produce a new Famx20 package >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>>>> >>>>>>>>>> Hi Stef, >>>>>>>>>> >>>>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>>>> fact >>>>>>>>>> that >>>>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>>>> >>>>>>>>>> That is why I said that for the moment just put there >>>>>>>>>> FAMIX2ModelRoot >>>>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> FAMIX2Class mooseDescription works only if the repository >>>>>>>>>>>> is >>>>>>>>>>>> correctly >>>>>>>>>>>> setup :). >>>>>>>>>>>> >>>>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the one >>>>>>>>>>>> that >>>>>>>>>>>> returns the meta-model. >>>>>>>>>>> >>>>>>>>>>> Ah >>>>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now I did >>>>>>>>>>> >>>>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>>>> >>>>>>>>>>> | pp | >>>>>>>>>>> ^metaTower ifNil: [ >>>>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>>>> pp run. >>>>>>>>>>> metaTower := pp asTower] >>>>>>>>>>> >>>>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Stef >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> It is lazily created and in the current >>>>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>>>> does >>>>>>>>>>>> not >>>>>>>>>>>> include FAMIX2. >>>>>>>>>>>> >>>>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>>>> just >>>>>>>>>>>> to >>>>>>>>>>>> make >>>>>>>>>>>> it work with your code. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> www.tudorgirba.com >>>>>>>>>> www.tudorgirba.com/blog >>>>>>>>>> >>>>>>>>>> "What we can governs what we wish." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.tudorgirba.com/blog >>>>>>>> >>>>>>>> "Problem solving efficiency grows with the abstractness level >>>>>>>> of >>>>>>>> problem understanding." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Mon Sep 15 21:25:24 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 15 Sep 2008 21:25:24 +0200 Subject: [Moose-dev] which version of fame can I use to continue loading and coding on moose? Message-ID: <4A41045D-9761-487C-BB55-203A689784DA@univ-savoie.fr> see above :) Stef From akuhn at gmx.ch Mon Sep 15 21:37:34 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Mon, 15 Sep 2008 21:37:34 +0200 Subject: [Moose-dev] Re: which version of fame can I use to continue loading and coding on moose? In-Reply-To: <4A41045D-9761-487C-BB55-203A689784DA@univ-savoie.fr> References: <4A41045D-9761-487C-BB55-203A689784DA@univ-savoie.fr> Message-ID: <77E03517-4BC6-4BB5-B82C-71141B6F95DE@gmx.ch> Try Fame-akuhn.98.mcz If you have errors, I need more information to help. I am working on the new code generation with Links, which is working all fine as far I can tell. However, I do not know enough about the current state of Moose to be able to advise a possible migration path. cheers, AA On 15 Sep 2008, at 21:25 , St?phane Ducasse wrote: > see above :) > > Stef From stephane.ducasse at univ-savoie.fr Mon Sep 15 21:49:17 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 15 Sep 2008 21:49:17 +0200 Subject: [Moose-dev] Re: which version of fame can I use to continue loading and coding on moose? In-Reply-To: <77E03517-4BC6-4BB5-B82C-71141B6F95DE@gmx.ch> References: <4A41045D-9761-487C-BB55-203A689784DA@univ-savoie.fr> <77E03517-4BC6-4BB5-B82C-71141B6F95DE@gmx.ch> Message-ID: Ok I may try. RIght now I'm considering abandoning the port. Stef On Sep 15, 2008, at 9:37 PM, Adrian Kuhn wrote: > Try Fame-akuhn.98.mcz > > If you have errors, I need more information to help. I am working on > the new code generation with Links, which is working all fine as far > I can tell. However, I do not know enough about the current state of > Moose to be able to advise a possible migration path. > > cheers, > AA > > > On 15 Sep 2008, at 21:25 , St?phane Ducasse wrote: > >> see above :) >> >> Stef > > From stephane.ducasse at univ-savoie.fr Mon Sep 15 21:59:44 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 15 Sep 2008 21:59:44 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> Message-ID: <393790BF-9E04-4F08-BD84-9173EFED650A@univ-savoie.fr> I do not understand I get folders ^ folders isNil ifTrue: [ folders := OrderedCollection new ]. in the code after applying the automatic conversion now in the patch I get FAMIX2Folder compile: 'folders "patched" folders isNil ifTrue: [ folders := OrderedCollection new ]. ^ folders' Which one is correct? Since I do not know fame I do not understand. Stef On Sep 14, 2008, at 12:11 PM, Oscar Nierstrasz wrote: > > You will probably find that the patch methods are doing what you tried > to do by hand. > (Of course we had to go through the methods by hand to build the patch > methods, but at least the patches are documented.) > > Hope that helps. > > - on > > On Sep 14, 2008, at 12:04, St?phane Ducasse wrote: > >> Im confused too :( >> >> Here is what I did >> >> I took fame-on65 >> run it and merged it >> then I run fame-on65 and went over all the conflicts and >> took back the method body that the automatic changes >> removed. >> >> I was not aware of patch methods. So I will have a look at them. >> Stef >> >>> >>> Hi Stef, >>> >>> I am confused about the current status. I thought you rolled back >>> to >>> the previous FAMIX2 because you could not get the generated changes >>> to >>> work since the patches were missing. If our changes are already in >>> FAMIX2, then all you need to do is to check the patches. They have >>> moved to FameUtil. There is a protocol with several patch* >>> methods. >>> They can be run at any time. Just check if what you did is >>> consistent >>> with the patch* methods. >>> >>> FMPragmaGenerator>>patchAllFAMIXspecialCases >>> >>> I just loaded the latest version and checked the first patch: >>> >>> patchFAMIX2AbstractBehaviouralEntity >>> FAMIX2AbstractBehaviouralEntity compile: 'accesses "patched" >>> >>> >>> "all variable accesses contained in receiver" >>> accesses isNil ifTrue: [ accesses := OrderedCollection new ]. >>> ^ accesses'. >>> ... >>> >>> However if I look at FAMIX2AbstractBehaviouralEntity>>accesses I see >>> this: >>> >>> accesses >>> >>> >>> >>> self flag:#famix20Transfer. >>> "in VW was incomingInvocations isNil ifTrue: >>> [ incomingInvocations := OrderedCollection new ]. " >>> ^ accesses >>> >>> So I guess the patches have not been run. >>> >>> To rerun the patches, simply evaluated the following: >>> >>> (FMPragmaGenerator packageName: 'FAMIX2' rootClass: FAMIX2ModelRoot) >>> patchAllFAMIXspecialCases >>> >>> This will put back all the lazy initializers and fix all the other >>> broken stuff. >>> >>> I suggets you browse the patch* methods to see if you are convinced >>> that they are ok. >> >> ok I will >> >>> >>> >>> - on >>> >>> On Sep 9, 2008, at 22:09, St?phane Ducasse wrote: >>> >>>> tell me more >>>> since I integrated your changes, do I have to do it again >>>> did you work directly on famix20 classes? >>>> did you change/fix the changes I did? >>>> >>>> Stef >>>> >>>> >>>> On Sep 9, 2008, at 4:06 PM, Oscar Nierstrasz wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> Doru and I looked at FMPragmaGenerator and ran it again. >>>>> >>>>> The problem was that we needed to first set >>>>> FMPragmaGenerator>>promptToAcceptChanges to return false so that >>>>> the >>>>> patches will be properly installed. >>>>> >>>>> We have committed FAMIX2-Model-on.32. It should be ok now. >>>>> >>>>> - on and tg >>>>> >>>>> PS: We used Fame-on.65 to avoid any potential compatibility >>>>> problems >>>>> with Adrian's latest changes. (We didn't check if there were >>>>> any.) >>>>> >>>>> >>>>> On Sep 6, 2008, at 21:30, St?phane Ducasse wrote: >>>>> >>>>>> Ok >>>>>> what I did was to go over all the changes you did (as they show >>>>>> up >>>>>> in >>>>>> the refactoring window) and check the code >>>>>> and evaluate what was changed. I put back most of the famix2 code >>>>>> (but >>>>>> let the annotations that were introduced by your changes). >>>>>> I think that there should be one or two cases where I was >>>>>> confused >>>>>> and >>>>>> it would be good if you can have a look. >>>>>> \ >>>>>> The most intriguing one was >>>>>> incomingInvocations >>>>>> >>>>> opposite: >>>>>> #candidates> >>>>>> ^ incomingInvocations values >>>>>> >>>>>> stef >>>>>> >>>>>> On Sep 6, 2008, at 4:04 PM, Oscar Nierstrasz wrote: >>>>>> >>>>>>> >>>>>>> In the FAMIX2 Meta -> Fame stuff, there is apparently a race >>>>>>> condition >>>>>>> that I did not realize. >>>>>>> >>>>>>> So although we patch up the lazy initializers, this may be done >>>>>>> in >>>>>>> the >>>>>>> wrong order. >>>>>>> >>>>>>> I should sit together with Doru and have a look at it. >>>>>>> >>>>>>> - on >>>>>>> >>>>>>> On Sep 4, 2008, at 14:18, St?phane Ducasse wrote: >>>>>>> >>>>>>>> The problem is that in Famix20 we have lazzy initializers and >>>>>>>> they >>>>>>>> got >>>>>>>> replaced by direct accessor. >>>>>>>> So signature was for example not lazzily computed anymore, and >>>>>>>> breaking the debugger. :( >>>>>>>> >>>>>>>> So I do not know what is the contract stuff you are talking >>>>>>>> about >>>>>>>> but >>>>>>>> at the end it should be fixed. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> On Sep 4, 2008, at 2:01 PM, Tudor Girba wrote: >>>>>>>> >>>>>>>>> The error I mentioned before is not due to the changes of >>>>>>>>> Oscar >>>>>>>>> and >>>>>>>>> Toon. It's just that Fame has a different contract than Meta. >>>>>>>>> >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 4, 2008, at 1:54 PM, St?phane Ducasse wrote: >>>>>>>>> >>>>>>>>>> Apparently when applying blindly the changes of oscar I broke >>>>>>>>>> FAMIX2 >>>>>>>>>> (argh) >>>>>>>>>> so I will take another image and check one by one the >>>>>>>>>> suggested >>>>>>>>>> changes and produce a new Famx20 package >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> On Sep 4, 2008, at 11:40 AM, Tudor Girba wrote: >>>>>>>>>> >>>>>>>>>>> Hi Stef, >>>>>>>>>>> >>>>>>>>>>> I know it breaks. The errors that you mention are due to the >>>>>>>>>>> fact >>>>>>>>>>> that >>>>>>>>>>> some old classes from VW do not conform to Fame. >>>>>>>>>>> >>>>>>>>>>> That is why I said that for the moment just put there >>>>>>>>>>> FAMIX2ModelRoot >>>>>>>>>>> and then I will take a look at the code in the afternoon. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Doru >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 4, 2008, at 11:26 AM, St?phane Ducasse wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sep 4, 2008, at 11:15 AM, Tudor Girba wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> FAMIX2Class mooseDescription works only if the repository >>>>>>>>>>>>> is >>>>>>>>>>>>> correctly >>>>>>>>>>>>> setup :). >>>>>>>>>>>>> >>>>>>>>>>>>> If you look in the code, then "MooseModel>>meta" is the >>>>>>>>>>>>> one >>>>>>>>>>>>> that >>>>>>>>>>>>> returns the meta-model. >>>>>>>>>>>> >>>>>>>>>>>> Ah >>>>>>>>>>>> I thought that we could plug any metamodel under fame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now I did >>>>>>>>>>>> >>>>>>>>>>>> MooseModel2 class>>metaTower >>>>>>>>>>>> "self resetMetaDescriptions. self metaTower" >>>>>>>>>>>> >>>>>>>>>>>> | pp | >>>>>>>>>>>> ^metaTower ifNil: [ >>>>>>>>>>>> pp := FMPragmaProcessor new. >>>>>>>>>>>> pp queue: MooseEntity withAllSubclasses. >>>>>>>>>>>> pp run. >>>>>>>>>>>> metaTower := pp asTower] >>>>>>>>>>>> >>>>>>>>>>>> and I got a wonderful error which is a bad smell to me. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Stef >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> It is lazily created and in the current >>>>>>>>>>>>> implementation is starts the lookup from FAMIXEntity which >>>>>>>>>>>>> does >>>>>>>>>>>>> not >>>>>>>>>>>>> include FAMIX2. >>>>>>>>>>>>> >>>>>>>>>>>>> I would suggest to make it FAMIX2ModelRoot for the moment >>>>>>>>>>>>> just >>>>>>>>>>>>> to >>>>>>>>>>>>> make >>>>>>>>>>>>> it work with your code. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> www.tudorgirba.com >>>>>>>>>>> www.tudorgirba.com/blog >>>>>>>>>>> >>>>>>>>>>> "What we can governs what we wish." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> www.tudorgirba.com/blog >>>>>>>>> >>>>>>>>> "Problem solving efficiency grows with the abstractness level >>>>>>>>> of >>>>>>>>> problem understanding." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Mon Sep 15 22:03:51 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 15 Sep 2008 22:03:51 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> Message-ID: <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> patchFAMIX2AbstractStructuralEntity FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" ^ accessedByList' but there is no accessedByLists so is is normal? Stef From akuhn at gmx.ch Mon Sep 15 22:12:10 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Mon, 15 Sep 2008 22:12:10 +0200 Subject: [Moose-dev] Re: which version of fame can I use to continue loading and coding on moose? In-Reply-To: References: <4A41045D-9761-487C-BB55-203A689784DA@univ-savoie.fr> <77E03517-4BC6-4BB5-B82C-71141B6F95DE@gmx.ch> Message-ID: Okay, here is a possible migration from slots to links path: 1. Load the latest version of both FameUtil and Fame 2. Load Moose 3. Make sure all tests run. 4. Create a tower and populate the metamodel with your classes t := FMTower new. t metamodel addSmalltalkClasses: { ... }. 5. Run code generation with these settings gen := FMDefaultCodeGenerator new. gen defaultSuperClass: aSmalltalkClass. gen defaultCategory: aString. gen skipDerivedMethods: true. gen visit: t metamode. gen previewChanges. 6. Apply the changes if okey. 7. Assert that the test bar is still green. 8. Write yourself a script that kills all deprecated (slots, add, remove, etc) methods, should be straight forward. 9. Assert that the test bar is still green. If you need to further customize the generated code (maybe to preserve custom initialization code, etc) it is best to subclass FMDefaultCodeGenerator and override the appropriate methods as needed. I have tried to take care that the logic is nicely decomposed into different method to facilitate possible customization. cheers, AA On 15 Sep 2008, at 21:49 , St?phane Ducasse wrote: > Ok I may try. > RIght now I'm considering abandoning the port. > > Stef > > On Sep 15, 2008, at 9:37 PM, Adrian Kuhn wrote: > >> Try Fame-akuhn.98.mcz >> >> If you have errors, I need more information to help. I am working >> on the new code generation with Links, which is working all fine >> as far I can tell. However, I do not know enough about the current >> state of Moose to be able to advise a possible migration path. >> >> cheers, >> AA >> >> >> On 15 Sep 2008, at 21:25 , St?phane Ducasse wrote: >> >>> see above :) >>> >>> Stef >> >> From oscar at iam.unibe.ch Mon Sep 15 22:58:58 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Mon, 15 Sep 2008 22:58:58 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> Message-ID: <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> I will check with Toon. There was a lot of confusion with singular and plural method names, especially accessedByList and accessedByLists, as I recall. - on On Sep 15, 2008, at 22:03, St?phane Ducasse wrote: > > > patchFAMIX2AbstractStructuralEntity > FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" > #accesses> > > ^ accessedByList' > > but there is no accessedByLists > so is is normal? > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From girba at iam.unibe.ch Mon Sep 15 23:01:24 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 15 Sep 2008 23:01:24 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> Message-ID: <3DE52E70-E5A5-42EA-99B6-B5D176E72EEC@iam.unibe.ch> This was a dirty quick fix to make Moose work in VW. accessedByLists should be removed altogether. Cheers, Doru On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote: > > I will check with Toon. > > There was a lot of confusion with singular and plural method names, > especially accessedByList and accessedByLists, as I recall. > > - on > > On Sep 15, 2008, at 22:03, St?phane Ducasse wrote: > >> >> >> patchFAMIX2AbstractStructuralEntity >> FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" >> > #accesses> >> >> ^ accessedByList' >> >> but there is no accessedByLists >> so is is normal? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com www.tudorgirba.com/blog "Next time you see your life passing by, say 'hi' and get to know her." From stephane.ducasse at univ-savoie.fr Tue Sep 16 08:55:44 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 16 Sep 2008 08:55:44 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> Message-ID: <0AC2F7C2-0210-41E0-B466-59081FABD7F7@univ-savoie.fr> For now I went over all the pacth methods, applied them by hand and apparently my previous green tests are green again. Stef On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote: > > I will check with Toon. > > There was a lot of confusion with singular and plural method names, > especially accessedByList and accessedByLists, as I recall. > > - on > > On Sep 15, 2008, at 22:03, St?phane Ducasse wrote: > >> >> >> patchFAMIX2AbstractStructuralEntity >> FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" >> > #accesses> >> >> ^ accessedByList' >> >> but there is no accessedByLists >> so is is normal? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Tue Sep 16 09:27:12 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Tue, 16 Sep 2008 09:27:12 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <0AC2F7C2-0210-41E0-B466-59081FABD7F7@univ-savoie.fr> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> <0AC2F7C2-0210-41E0-B4 66-59081FABD7F7@univ-savoie.fr> Message-ID: <98AEB867-1080-4A9D-9187-4295EE1D6708@iam.unibe.ch> OK, good. Sorry to have missed this point when we went over it at ESUG. So the FAMIX2 -> FAME translation is now complete? Cheers, - on On Sep 16, 2008, at 8:55, St?phane Ducasse wrote: > For now > I went over all the pacth methods, applied them by hand and apparently > my previous green tests are green again. > > Stef > > On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote: > >> >> I will check with Toon. >> >> There was a lot of confusion with singular and plural method names, >> especially accessedByList and accessedByLists, as I recall. >> >> - on >> >> On Sep 15, 2008, at 22:03, St?phane Ducasse wrote: >> >>> >>> >>> patchFAMIX2AbstractStructuralEntity >>> FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" >>> >> #accesses> >>> >>> ^ accessedByList' >>> >>> but there is no accessedByLists >>> so is is normal? >>> >>> Stef >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Tue Sep 16 09:36:28 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 16 Sep 2008 09:36:28 +0200 Subject: [Moose-dev] Re: FMPragmaGenerator generateFAMIX2annotations metamodel explore In-Reply-To: <98AEB867-1080-4A9D-9187-4295EE1D6708@iam.unibe.ch> References: <58877FEA-0518-4BF2-B5DF-9EEEF624DCE1@univ-savoie.fr> <61826A61-0335-4915-937C-B861103A9C43@univ-savoie.fr> <77F3C4D8-8C21-4150-9AB0-66CAA5CDFEA4@univ-savoie.fr> <32083FAD-1E5A-4CB4-9D22-ABB77456DD64@iam.unibe.ch> <6801C8B9-7689-42E6-A61D-0A68D6B93D9B@univ-savoie.fr> <5DBC4A3D-305E-46BE-B026-7CA9D7D3DC75@iam.unibe.ch> <1B56BA45-F0CA-40C5-9F0C-57AF07F77BB7@univ-savoie.fr> <739BBE67-AD33-48FF-B1C6-64250672BFDC@univ-savoie.fr> <3A03B91C-F833-4B41-9CF6-9B8C1F613915@iam.unibe.ch> <49F68564-4286-439C-898C-5DDE22D1A80E@univ-savoie.fr> <77CB91BF-E1A0-4290-8705-F349E868A8EA@iam.unibe.ch> <4160724E-2D6D-4C4E-9165-67A2D7B8A345@univ-savoie.fr> <0671FD48-E577-4871-A389-B289685218B8@iam.unibe.ch> <0AC2F7C2-0210-41E0-B4 66-5... Message-ID: <562B6FE2-3541-4922-8B73-117EDD6DC1E6@univ-savoie.fr> I imagine it is. I will check the old emails and this is done. Now where I would need help is to get Fame used as in the group and other UI... Alex could not make the repository filled up with the right description. I want to be able to do FAMIX2Class asDescription and get it. Stef On Sep 16, 2008, at 9:27 AM, Oscar Nierstrasz wrote: > > OK, good. Sorry to have missed this point when we went over it at > ESUG. > > So the FAMIX2 -> FAME translation is now complete? > > Cheers, > - on > > On Sep 16, 2008, at 8:55, St?phane Ducasse wrote: > >> For now >> I went over all the pacth methods, applied them by hand and >> apparently >> my previous green tests are green again. >> >> Stef >> >> On Sep 15, 2008, at 10:58 PM, Oscar Nierstrasz wrote: >> >>> >>> I will check with Toon. >>> >>> There was a lot of confusion with singular and plural method names, >>> especially accessedByList and accessedByLists, as I recall. >>> >>> - on >>> >>> On Sep 15, 2008, at 22:03, St?phane Ducasse wrote: >>> >>>> >>>> >>>> patchFAMIX2AbstractStructuralEntity >>>> FAMIX2AbstractStructuralEntity compile: 'accessedByLists "patched" >>>> >>> #accesses> >>>> >>>> ^ accessedByList' >>>> >>>> but there is no accessedByLists >>>> so is is normal? >>>> >>>> Stef >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From akuhn at gmx.ch Tue Sep 16 12:22:20 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Tue, 16 Sep 2008 12:22:20 +0200 Subject: [Moose-dev] Re: [Fame-dev] Invocation question In-Reply-To: <06C2BF40-B2A6-4FA0-838D-27E2E6F67872@lu.unisi.ch> References: <06C2BF40-B2A6-4FA0-838D-27E2E6F67872@lu.unisi.ch> Message-ID: <7AE9F2F0-27FB-4D83-862E-4DB95635C2B9@gmx.ch> Hello Jacopo, You cannot model initializers in FAMIX (neither field initialization, nor instance or static initialization blocks). The same applies for doublebrace initialization, and many other features of Java. The main reason why is that Famix is supposed to be language independent and thus a lossy model of software rather than a precise one, think of JPEG vs GIF. Which is okay as long Famix is used for coarse-grained high-level analysis, it is obvious that Famix would be a bad choice for eg program transformation. But you best address this question to the Moose mailing list (see foward in CC). Fame is about the (meta)metamodeling-infrastructure only, not about concrete metamodels such as Famix. I have left the Moose team start fo this year, and maybe what I just said above is obsolete in the meantime... cheers, AA On 16 Sep 2008, at 12:11 , Jacopo Malnati wrote: > Hello everybody, > > still in the context of exporting Java code to MSE, I don't know > how to handle a dependency that comes from the initialization of a > class field. > > Let's say that a class has a field "myField" of type "MyType" and > that it gets declared in the body of the class and initialized with > a constructor, in place. > Something like: > > MyClass { > MyType myField = new MyType(...) > > } > > Now, this is an invocation (of a constructor) but in Famix 2.2 an > invocation is between 2 AbstractBehaviouralEntity and in this case, > it's not. In fact the initialization of a class field can be > outside any method, therefore I don't know how to model this > dependency. > > Is there any way I can model it? Or Famix 2.2 doesn't allow me to > model this situation? > > Thanks :) > > Jacopo From stephane.ducasse at inria.fr Thu Sep 18 11:39:48 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 18 Sep 2008 11:39:48 +0200 Subject: [Moose-dev] what do we do with Meta entity Message-ID: Hi all I have metamodelBelongsTo ^(Property name: #belongsTo type: FAMIX2Namespace) strategy: MooseStrategy; oppositeName: #class; isComposite: true; yourself But Property is a Meta related entity so should we remove Property and the methods using it? Who said that it was obvious :( Stef From stephane.ducasse at inria.fr Thu Sep 18 12:37:27 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 18 Sep 2008 12:37:27 +0200 Subject: [Moose-dev] About MooseStrategy Message-ID: Hi all in FAMIX2Class I have metamodelBelongsTo ^(Property name: #belongsTo type: FAMIX2Namespace) strategy: MooseStrategy; oppositeName: #class; isComposite: true; yourself What is a MooseStrategy: an object that controls the way objects are stored but it looks like only used in Meta. Stef From girba at iam.unibe.ch Thu Sep 18 13:02:46 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 18 Sep 2008 13:02:46 +0200 Subject: [Moose-dev] Re: About MooseStrategy In-Reply-To: References: Message-ID: Hi Stef, all the metamodel* methods were used only in Meta and they should be deleted in Squeak. Cheers, Doru On Sep 18, 2008, at 12:37 PM, St?phane Ducasse wrote: > Hi all > > > in FAMIX2Class I have > > metamodelBelongsTo > ^(Property > name: #belongsTo > type: FAMIX2Namespace) > strategy: MooseStrategy; > oppositeName: #class; > isComposite: true; > yourself > > > What is a MooseStrategy: an object that controls the way objects are > stored > but it looks like only used in Meta. > > Stef > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From ducasse at iam.unibe.ch Thu Sep 18 13:09:13 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 18 Sep 2008 13:09:13 +0200 Subject: [Moose-dev] Looking for a MooseModel walker Message-ID: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> Hi guys We are looking for a model walker (visitor). Does any one of you already implement one? Stef From oscar at iam.unibe.ch Thu Sep 18 13:18:06 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Thu, 18 Sep 2008 13:18:06 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> Message-ID: <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> I guess you mean a default visitor with empty visit methods that can be subclassed? Yeah, we need that. - on On Sep 18, 2008, at 13:09, st?phane ducasse wrote: > Hi guys > > We are looking for a model walker (visitor). > Does any one of you already implement one? > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at univ-savoie.fr Thu Sep 18 14:05:18 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 18 Sep 2008 14:05:18 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> Message-ID: Ok we will code one with hani. Stef On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: > > I guess you mean a default visitor with empty visit methods that can > be subclassed? > > Yeah, we need that. > > - on > > On Sep 18, 2008, at 13:09, st?phane ducasse wrote: > >> Hi guys >> >> We are looking for a model walker (visitor). >> Does any one of you already implement one? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From jannick.menanteau at free.fr Fri Sep 19 10:39:29 2008 From: jannick.menanteau at free.fr (Menanteau Jannick) Date: Fri, 19 Sep 2008 10:39:29 +0200 Subject: [Moose-dev] Some questions about iplasma Message-ID: <8D501D4A-FF07-4150-8EA7-5FBF60AAA246@free.fr> Hi All, I would like to use iplasma and I have some questions about it : - is it always maintained ? - is there any important bugs ? - have you any idea about its future evolution ? Thanks Jannik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/moose-dev/attachments/20080919/74cbf235/attachment.html From girba at iam.unibe.ch Fri Sep 19 11:03:29 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 19 Sep 2008 11:03:29 +0200 Subject: [Moose-dev] Re: Some questions about iplasma In-Reply-To: <8D501D4A-FF07-4150-8EA7-5FBF60AAA246@free.fr> References: <8D501D4A-FF07-4150-8EA7-5FBF60AAA246@free.fr> Message-ID: Hi Jannick, iPlasma is built at the LOOSE Research Group, Politehnica University of Timisoara. It is maintained and up to date. Actually, they are now working on adding support for Java Annotations. As for bugs, there aren't any important ones that I know of. Anyway, better ask the people at: lrg at cs.upt.ro. Cheers, Doru On Sep 19, 2008, at 10:39 AM, Menanteau Jannick wrote: > Hi All, > > I would like to use iplasma and I have some questions about it : > - is it always maintained ? > - is there any important bugs ? > > - have you any idea about its future evolution ? > > Thanks > > Jannik > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Presenting is storytelling." From alexandre at bergel.eu Fri Sep 19 20:29:47 2008 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 19 Sep 2008 20:29:47 +0200 Subject: [Moose-dev] Re: Some questions about iplasma In-Reply-To: <8D501D4A-FF07-4150-8EA7-5FBF60AAA246@free.fr> References: <8D501D4A-FF07-4150-8EA7-5FBF60AAA246@free.fr> Message-ID: <6AF8AD51-3CDC-4997-B440-6D3579E09185@bergel.eu> Excellent Jannick, il nous faut cette expertise! Alexandre On 19 Sep 2008, at 10:39, Menanteau Jannick wrote: > Hi All, > > I would like to use iplasma and I have some questions about it : > - is it always maintained ? > - is there any important bugs ? > > - have you any idea about its future evolution ? > > Thanks > > Jannik > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From girba at iam.unibe.ch Sat Sep 20 23:33:14 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Sat, 20 Sep 2008 23:33:14 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> Message-ID: I am curious about the use case. Could you elaborate a bit on this one? Cheers, Doru On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: > > I guess you mean a default visitor with empty visit methods that can > be subclassed? > > Yeah, we need that. > > - on > > On Sep 18, 2008, at 13:09, st?phane ducasse wrote: > >> Hi guys >> >> We are looking for a model walker (visitor). >> Does any one of you already implement one? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Sun Sep 21 08:57:58 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sun, 21 Sep 2008 08:57:58 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> Message-ID: <8E07A0B2-A1A0-46AC-B222-F6FB59EB6AB7@univ-savoie.fr> we would like to copy selectively the model or export it in another format. Stef On Sep 20, 2008, at 11:33 PM, Tudor Girba wrote: > I am curious about the use case. Could you elaborate a bit on this > one? > > Cheers, > Doru > > > On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: > >> >> I guess you mean a default visitor with empty visit methods that can >> be subclassed? >> >> Yeah, we need that. >> >> - on >> >> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >> >>> Hi guys >>> >>> We are looking for a model walker (visitor). >>> Does any one of you already implement one? >>> >>> Stef >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Sun Sep 21 11:33:55 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sun, 21 Sep 2008 11:33:55 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> Message-ID: Well, if a visitor has to implement many visit methods, but not all visitors need to do something for visitable items, then it is handy to have a default visitor that implements all the visit methods with empty bodies. You then simply subclass this default visitor and override the few visit methods that you need. There is an example in the compiler construction course. https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/04ParsingPractice.ppt https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/Examples/StraightLinePL/src/compiler/CompilerVisitor.java Cheers, - on On Sep 20, 2008, at 23:33, Tudor Girba wrote: > I am curious about the use case. Could you elaborate a bit on this > one? > > Cheers, > Doru > > > On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: > >> >> I guess you mean a default visitor with empty visit methods that can >> be subclassed? >> >> Yeah, we need that. >> >> - on >> >> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >> >>> Hi guys >>> >>> We are looking for a model walker (visitor). >>> Does any one of you already implement one? >>> >>> Stef >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at univ-savoie.fr Sun Sep 21 12:44:19 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sun, 21 Sep 2008 12:44:19 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> Message-ID: <267108F9-F399-4014-A22F-59D62EC3D025@univ-savoie.fr> Yes exactly and I would like to use the importingContext of specify how to filter the model but in a conistent manner. Stef On Sep 21, 2008, at 11:33 AM, Oscar Nierstrasz wrote: > > Well, if a visitor has to implement many visit methods, but not all > visitors need to do something for visitable items, then it is handy to > have a default visitor that implements all the visit methods with > empty bodies. You then simply subclass this default visitor and > override the few visit methods that you need. > > There is an example in the compiler construction course. > > https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/04ParsingPractice.ppt > > https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/Examples/StraightLinePL/src/compiler/CompilerVisitor.java > > Cheers, > - on > > On Sep 20, 2008, at 23:33, Tudor Girba wrote: > >> I am curious about the use case. Could you elaborate a bit on this >> one? >> >> Cheers, >> Doru >> >> >> On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: >> >>> >>> I guess you mean a default visitor with empty visit methods that can >>> be subclassed? >>> >>> Yeah, we need that. >>> >>> - on >>> >>> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >>> >>>> Hi guys >>>> >>>> We are looking for a model walker (visitor). >>>> Does any one of you already implement one? >>>> >>>> Stef >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From girba at iam.unibe.ch Sun Sep 21 13:04:05 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Sun, 21 Sep 2008 13:04:05 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <267108F9-F399-4014-A22F-59D62EC3D025@univ-savoie.fr> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> <267108F9-F399-4014-A22F-59D62EC3D025@univ-savoie.fr> Message-ID: <680C51B5-A41C-4DE0-86A5-132858830991@iam.unibe.ch> It's not that I do not know what a visitor is, I was just curious of the use case, given that we have done quite a bit of things without one :). I believe that most Visitors can be nicely implemented using class extensions. Of course, when you have a tree and a very complex algorithm with many variation points, then having a visitor does improve the situation. But even then, there is no reason for not exposing the service as an extension method that then calls the visitor. This makes life much easier for the client because there is no need to know how to instantiate the visitor. Cheers, Doru On Sep 21, 2008, at 12:44 PM, St?phane Ducasse wrote: > Yes exactly and I would like to use the importingContext of specify > how to filter > the model but in a conistent manner. > > Stef > > On Sep 21, 2008, at 11:33 AM, Oscar Nierstrasz wrote: > >> >> Well, if a visitor has to implement many visit methods, but not all >> visitors need to do something for visitable items, then it is handy >> to >> have a default visitor that implements all the visit methods with >> empty bodies. You then simply subclass this default visitor and >> override the few visit methods that you need. >> >> There is an example in the compiler construction course. >> >> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/04ParsingPractice.ppt >> >> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/Examples/StraightLinePL/src/compiler/CompilerVisitor.java >> >> Cheers, >> - on >> >> On Sep 20, 2008, at 23:33, Tudor Girba wrote: >> >>> I am curious about the use case. Could you elaborate a bit on this >>> one? >>> >>> Cheers, >>> Doru >>> >>> >>> On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: >>> >>>> >>>> I guess you mean a default visitor with empty visit methods that >>>> can >>>> be subclassed? >>>> >>>> Yeah, we need that. >>>> >>>> - on >>>> >>>> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >>>> >>>>> Hi guys >>>>> >>>>> We are looking for a model walker (visitor). >>>>> Does any one of you already implement one? >>>>> >>>>> Stef >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com www.tudorgirba.com/blog "Be rather willing to give than demanding to get." From stephane.ducasse at univ-savoie.fr Sun Sep 21 18:24:45 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sun, 21 Sep 2008 18:24:45 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <680C51B5-A41C-4DE0-86A5-132858830991@iam.unibe.ch> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> <267108F9-F399-4014-A22F-59D62EC3D025@univ-savoie.fr> <680C51B5-A41C-4DE0-86A5-132858830991@iam.unibe.ch> Message-ID: <40F027C4-DC7F-463D-BEC4-8BD87707F09E@univ-savoie.fr> Doru I think that what I want this is graph traversal that I can specialize and the state of the traversing action should be stored into the model so in a visitor. Stef On Sep 21, 2008, at 1:04 PM, Tudor Girba wrote: > It's not that I do not know what a visitor is, I was just curious of > the use case, given that we have done quite a bit of things without > one :). > > I believe that most Visitors can be nicely implemented using class > extensions. Of course, when you have a tree and a very complex > algorithm with many variation points, then having a visitor does > improve the situation. But even then, there is no reason for not > exposing the service as an extension method that then calls the > visitor. This makes life much easier for the client because there is > no need to know how to instantiate the visitor. > > Cheers, > Doru > > On Sep 21, 2008, at 12:44 PM, St?phane Ducasse wrote: > >> Yes exactly and I would like to use the importingContext of specify >> how to filter >> the model but in a conistent manner. >> >> Stef >> >> On Sep 21, 2008, at 11:33 AM, Oscar Nierstrasz wrote: >> >>> >>> Well, if a visitor has to implement many visit methods, but not all >>> visitors need to do something for visitable items, then it is handy >>> to >>> have a default visitor that implements all the visit methods with >>> empty bodies. You then simply subclass this default visitor and >>> override the few visit methods that you need. >>> >>> There is an example in the compiler construction course. >>> >>> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/04ParsingPractice.ppt >>> >>> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/Examples/StraightLinePL/src/compiler/CompilerVisitor.java >>> >>> Cheers, >>> - on >>> >>> On Sep 20, 2008, at 23:33, Tudor Girba wrote: >>> >>>> I am curious about the use case. Could you elaborate a bit on this >>>> one? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: >>>> >>>>> >>>>> I guess you mean a default visitor with empty visit methods that >>>>> can >>>>> be subclassed? >>>>> >>>>> Yeah, we need that. >>>>> >>>>> - on >>>>> >>>>> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> We are looking for a model walker (visitor). >>>>>> Does any one of you already implement one? >>>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Be rather willing to give than demanding to get." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From oscar at iam.unibe.ch Sun Sep 21 18:36:02 2008 From: oscar at iam.unibe.ch (Oscar Nierstrasz) Date: Sun, 21 Sep 2008 18:36:02 +0200 Subject: [Moose-dev] Re: Looking for a MooseModel walker In-Reply-To: <40F027C4-DC7F-463D-BEC4-8BD87707F09E@univ-savoie.fr> References: <59061C62-7148-4A7B-BFFF-2BF1C21B459F@iam.unibe.ch> <6F91AEDB-121E-4A45-89BA-0276A6BBACB7@iam.unibe.ch> <267108F9-F399-4014-A22F-59D62EC3D025@univ-savoie.fr> <680C51B5-A41C-4DE0-86A5-132858830991@iam.unibe.ch> <40F027C4-DC7F-463D-BEC4-8BD87707F09E@univ-savoie.fr> Message-ID: <071D2E84-671B-4064-ADC5-C6BFD8F1A7A5@iam.unibe.ch> I think both techniques should be supported. There are situations where visitors nicely encapsulate all the visiting behaviour, and others where it makes more sense to consider the extra behaviour as an extension of the structure itself. - on On Sep 21, 2008, at 18:24, St?phane Ducasse wrote: > Doru I think that what I want this is graph traversal that I can > specialize > and the state of the traversing action should be stored into the model > so in a visitor. > > Stef > > On Sep 21, 2008, at 1:04 PM, Tudor Girba wrote: > >> It's not that I do not know what a visitor is, I was just curious of >> the use case, given that we have done quite a bit of things without >> one :). >> >> I believe that most Visitors can be nicely implemented using class >> extensions. Of course, when you have a tree and a very complex >> algorithm with many variation points, then having a visitor does >> improve the situation. But even then, there is no reason for not >> exposing the service as an extension method that then calls the >> visitor. This makes life much easier for the client because there is >> no need to know how to instantiate the visitor. >> >> Cheers, >> Doru >> >> On Sep 21, 2008, at 12:44 PM, St?phane Ducasse wrote: >> >>> Yes exactly and I would like to use the importingContext of specify >>> how to filter >>> the model but in a conistent manner. >>> >>> Stef >>> >>> On Sep 21, 2008, at 11:33 AM, Oscar Nierstrasz wrote: >>> >>>> >>>> Well, if a visitor has to implement many visit methods, but not all >>>> visitors need to do something for visitable items, then it is handy >>>> to >>>> have a default visitor that implements all the visit methods with >>>> empty bodies. You then simply subclass this default visitor and >>>> override the few visit methods that you need. >>>> >>>> There is an example in the compiler construction course. >>>> >>>> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/04ParsingPractice.ppt >>>> >>>> https://www.iam.unibe.ch/scg/svn_repos/Lectures/CompilerConstruction/Examples/StraightLinePL/src/compiler/CompilerVisitor.java >>>> >>>> Cheers, >>>> - on >>>> >>>> On Sep 20, 2008, at 23:33, Tudor Girba wrote: >>>> >>>>> I am curious about the use case. Could you elaborate a bit on this >>>>> one? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On Sep 18, 2008, at 1:18 PM, Oscar Nierstrasz wrote: >>>>> >>>>>> >>>>>> I guess you mean a default visitor with empty visit methods that >>>>>> can >>>>>> be subclassed? >>>>>> >>>>>> Yeah, we need that. >>>>>> >>>>>> - on >>>>>> >>>>>> On Sep 18, 2008, at 13:09, st?phane ducasse wrote: >>>>>> >>>>>>> Hi guys >>>>>>> >>>>>>> We are looking for a model walker (visitor). >>>>>>> Does any one of you already implement one? >>>>>>> >>>>>>> Stef >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Be rather willing to give than demanding to get." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From akuhn at gmx.ch Mon Sep 22 17:26:20 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Mon, 22 Sep 2008 17:26:20 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <48D7ADA1.2010708@heeg.de> References: <48D7ADA1.2010708@heeg.de> Message-ID: <2F5F64A6-C496-43D1-ACC0-2F3FB1F1DDEC@gmx.ch> On 22 Sep 2008, at 16:37 , Holger Guhl wrote: > The project is for company CAST that has software for software > quality assessment. I know them, that's cool! > I have a simple question: Do you have more analysis methods and > metrics that are not yet published with Moose? You can find a pre-release of (some of) my current work here http://www.iam.unibe.ch/~akuhn/d/Kuhn-2008-WCRE-SoftwareMap.pdf > And how about correctness of the measured values? The class comment > states: "Right now only Number of MessageSends is computed in a > correct manner." On the first glance, I cannot see which of the > measured values could be wrong. Any hint on inappropriate > computation or improvement would be appreciated. The only thing I > see a bit confusing is the computation of two McCabe numbers > #cyclomaticNumber and #cyclomaticNumber2. Unfortunately, the class > comment does not tell enough. Correctness of measured values is a big issue. The correctness of the numbers that Moose produces is unknown. Even such simple measurements as the number of classes or method invocations might be wrong! Why? Moose uses the FAMIX model that has the aim to be language independent, which can only be achieved at the cost of less precision. Famix is this a lossy representation of software rather than precise, think JPEG vs PNG. For that reason I suggested some time ago to add an error range to all numbers, and started to take a look at some of the numbers. That is why there are two diff McCabe measurements. As far I recall, #cyclomaticNumber2 is more correct than #cyclomaticNumber. I only looked at McCabe and found it is not correct, so I guess other measurements need careful review too. But alas, I did not have time to complete that work... cheers, AA From stephane.ducasse at univ-savoie.fr Mon Sep 22 21:11:07 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 22 Sep 2008 21:11:07 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <2F5F64A6-C496-43D1-ACC0-2F3FB1F1DDEC@gmx.ch> References: <48D7ADA1.2010708@heeg.de> <2F5F64A6-C496-43D1-ACC0-2F3FB1F1DDEC@gmx.ch> Message-ID: > Hi holger >> The project is for company CAST that has software for software >> quality assessment. The castSoftware company http://www.castsoftware.com/? Can you tell us more? Because another company told me that their metrics were fuzzy too :) >> > > I know them, that's cool! > >> I have a simple question: Do you have more analysis methods and >> metrics that are not yet published with Moose? > > > You can find a pre-release of (some of) my current work here > > http://www.iam.unibe.ch/~akuhn/d/Kuhn-2008-WCRE-SoftwareMap.pdf > >> And how about correctness of the measured values? The class comment >> states: "Right now only Number of MessageSends is computed in a >> correct manner." On the first glance, I cannot see which of the >> measured values could be wrong. Any hint on inappropriate >> computation or improvement would be appreciated. The only thing I >> see a bit confusing is the computation of two McCabe numbers >> #cyclomaticNumber and #cyclomaticNumber2. Unfortunately, the class >> comment does not tell enough. > > Correctness of measured values is a big issue. The correctness of the > numbers that Moose produces is unknown. Even such simple measurements > as the number of classes or method invocations might be wrong! I think that adrian is a bit simplifying too much. What is the language that you want to analyse? For Smalltalk, since the langage is dynamically typed nobody on earth can be precise when talking about invocations! Now for the number of classes I think that this is correct. Now if you take any "professional" tools you have to ask yourself > Why? > Moose uses the FAMIX model that has the aim to be language > independent, which can only be achieved at the cost of less > precision. Famix is this a lossy representation of software rather > than precise, think JPEG vs PNG. This is not only that. With certain program you do no have statically the information. Now for example for C++ we do not have pointer analysis tools. Moose is not that. > For that reason I suggested some > time ago to add an error range to all numbers, I do not see how this would really help. If you do not have the pointer analysis or call-flow analysis the range error can be as meaningless than certain metrics. > and started to take a > look at some of the numbers. That is why there are two diff McCabe > measurements. As far I recall, #cyclomaticNumber2 is more correct > than #cyclomaticNumber. I only looked at McCabe and found it is not > correct, so I guess other measurements need careful review too. But > alas, I did not have time to complete that work... Holger we use moose for a lot of projects and we did not notice problems. For basic metrics Moose is correct. Now of course we may have different definition but as with any non trivail measuring tools we have check and calibrate it first > Stef From jannick.menanteau at free.fr Mon Sep 22 21:34:00 2008 From: jannick.menanteau at free.fr (Menanteau Jannick) Date: Mon, 22 Sep 2008 21:34:00 +0200 Subject: [Moose-dev] List of Properties Message-ID: Hi all, I would like to add some properties in the list "Select properties to add:" when I push "+" button. I have added this in my fonction in FamoosClass : but it don't appear in the list. Thanks for help Jannik From girba at iam.unibe.ch Mon Sep 22 21:41:49 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 22 Sep 2008 21:41:49 +0200 Subject: [Moose-dev] Re: List of Properties In-Reply-To: References: Message-ID: <7AEFEA1F-F711-4489-A203-00659102AC9D@iam.unibe.ch> You have to reinitialize the meta descriptions: AbstractEntity initializeAllMofDescriptions Cheers, Doru On Sep 22, 2008, at 9:34 PM, Menanteau Jannick wrote: > Hi all, > > I would like to add some properties in the list "Select properties to > add:" when I push "+" button. > > I have added this in my fonction in FamoosClass : > longName: 'Lake of cohesion' > description: 'Lake of cohesion' >> > > but it don't appear in the list. > > Thanks for help > > > Jannik > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jannick.menanteau at free.fr Mon Sep 22 21:58:15 2008 From: jannick.menanteau at free.fr (Menanteau Jannick) Date: Mon, 22 Sep 2008 21:58:15 +0200 Subject: [Moose-dev] Re: List of Properties In-Reply-To: <7AEFEA1F-F711-4489-A203-00659102AC9D@iam.unibe.ch> References: <7AEFEA1F-F711-4489-A203-00659102AC9D@iam.unibe.ch> Message-ID: <2531E456-1CC4-4108-9A02-5BE3098C07C8@free.fr> ok thanks it works :) Jannik Le 22 sept. 08 ? 21:41, Tudor Girba a ?crit : > You have to reinitialize the meta descriptions: > AbstractEntity initializeAllMofDescriptions > > Cheers, > Doru > > > On Sep 22, 2008, at 9:34 PM, Menanteau Jannick wrote: > >> Hi all, >> >> I would like to add some properties in the list "Select properties to >> add:" when I push "+" button. >> >> I have added this in my fonction in FamoosClass : >> > longName: 'Lake of cohesion' >> description: 'Lake of cohesion' >>> >> >> but it don't appear in the list. >> >> Thanks for help >> >> >> Jannik >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From akuhn at gmx.ch Wed Sep 24 16:20:50 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Wed, 24 Sep 2008 16:20:50 +0200 Subject: [Moose-dev] [Reminder] This friday, Fame sprint. Message-ID: <91880285-0DBE-4325-B06A-EC0B271B4772@gmx.ch> Dear All, this Friday, a Fame sprint will take place in Bern. Program - 11:00 rehearsal of Models at Runtime presentation. - Afterwards, happy hacking and pair programing. Links - http://www.iam.unibe.ch/~akuhn/d/Kuhn-2008-MRT-Fame.pdf - http://smallwiki.unibe.ch/fame/issues You are welcome to participate and/or attend the rehearsal. @Moose - if you have feature requests, please reply to this mail or add them on the wiki page! For example, I have seen that you are about to impl a visitor, this sounds like a nice job for Fame code generation. cheers, Adrian -- Adrian Kuhn Software Composition Group University of Bern, Switzerland http://www.iam.unibe.ch/~akuhn From stephane.ducasse at inria.fr Thu Sep 25 11:01:56 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 25 Sep 2008 11:01:56 +0200 Subject: [Moose-dev] how in the script editor Message-ID: can we get all the packages from a list of classes? Doru is there a way that the script does not just need a predicate and return a subset but can get a full block If I have a list of classes I would like to get a group with all the packages of the classes. So a kind of flatCollect on the result Stef From girba at iam.unibe.ch Thu Sep 25 11:09:38 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 25 Sep 2008 11:09:38 +0200 Subject: [Moose-dev] Re: how in the script editor In-Reply-To: References: Message-ID: <0FFC869C-07E9-4E03-8036-A6416E87DE14@iam.unibe.ch> Hi Stef, The problem is that the editor is just a selection, not a navigation. That means that if you have a set of entities you can get a subset using the query. In your case, you want to get packages from classes. The default browser does not support navigation (only the Widgetry one does that). To navigate you need to Inspect, add your code and then you can open the result in a browser by self openInBrowser. You can find out more about what you can do with the script from here: http://moose.unibe.ch/tools/moosefinder The grammar of the language is here: http://moose.unibe.ch/tools/moosefinder/queryGrammar Cheers, Doru On Sep 25, 2008, at 11:01 AM, St?phane Ducasse wrote: > can we get all the packages from a list of classes? > > Doru > is there a way that the script does not just need a predicate and > return a subset but can get a full block > > If I have a list of classes I would like to get a group with all the > packages of the classes. > So a kind of flatCollect on the result > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Some battles are better lost than fought." From stephane.ducasse at inria.fr Thu Sep 25 11:14:56 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 25 Sep 2008 11:14:56 +0200 Subject: [Moose-dev] How to I get all the packages ... Message-ID: <9CB61C01-1695-4278-939B-B5A47443CA16@inria.fr> Hi doru I want to go from classes to packages. But when I click on 'all classes' item and select navigation packages I get 0. is it a bug? Stef From Alexandre.Bergel at inria.fr Thu Sep 25 14:43:32 2008 From: Alexandre.Bergel at inria.fr (Alexandre Bergel) Date: Thu, 25 Sep 2008 14:43:32 +0200 Subject: [Moose-dev] Browse source code Message-ID: <85ED9A4A-5BDC-4323-A8FD-25EB7C2AAA17@inria.fr> Dear List, When I am browsing a Java model, let's say ArgoUML, I cannot browse the source code of the model. Pressing 'Browsing source code' when right clicking on an entity seems ineffective. Is there a way to fix this? If no, I could work on this. Any hint where to start? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From itsme213 at hotmail.com Thu Sep 25 14:43:33 2008 From: itsme213 at hotmail.com (Itsme) Date: Thu, 25 Sep 2008 07:43:33 -0500 Subject: [Moose-dev] Re: [Reminder] This friday, Fame sprint. References: <91880285-0DBE-4325-B06A-EC0B271B4772@gmx.ch> Message-ID: Any way to remotely join (mostly as an observer)? Thanks ... Sophie ----- Original Message ----- From: "Adrian Kuhn" To: "Moose-dev Moose-dev" Sent: Wednesday, September 24, 2008 9:20 AM Subject: [Moose-dev] [Reminder] This friday, Fame sprint. > Dear All, > > this Friday, a Fame sprint will take place in Bern. > > Program > - 11:00 rehearsal of Models at Runtime presentation. > - Afterwards, happy hacking and pair programing. > > Links > - http://www.iam.unibe.ch/~akuhn/d/Kuhn-2008-MRT-Fame.pdf > - http://smallwiki.unibe.ch/fame/issues > > You are welcome to participate and/or attend the rehearsal. > > @Moose - if you have feature requests, please reply to this mail or > add them on the wiki page! For example, I have seen that you are > about to impl a visitor, this sounds like a nice job for Fame code > generation. > > cheers, > Adrian > > -- > Adrian Kuhn > Software Composition Group > University of Bern, Switzerland > http://www.iam.unibe.ch/~akuhn > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From girba at iam.unibe.ch Thu Sep 25 14:56:01 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 25 Sep 2008 14:56:01 +0200 Subject: [Moose-dev] Re: Browse source code In-Reply-To: <85ED9A4A-5BDC-4323-A8FD-25EB7C2AAA17@inria.fr> References: <85ED9A4A-5BDC-4323-A8FD-25EB7C2AAA17@inria.fr> Message-ID: <68191C91-DA93-4743-94C3-3FAA9BE6DB9F@iam.unibe.ch> Yes, there is a way, but it should be improved. There is a browseSource selector that answers the text from the sourceText selector in an entity. At the moment, sourceText just searches for the filename related to a class based on the name of the class and it expects the file to be relative to ./src (from where the image is). This is kind of not so nice :). It would be cool to have a dialog for asking for the initial path. Cheers, Doru On Sep 25, 2008, at 2:43 PM, Alexandre Bergel wrote: > Dear List, > > When I am browsing a Java model, let's say ArgoUML, I cannot browse > the source code of the model. > Pressing 'Browsing source code' when right clicking on an entity seems > ineffective. > > Is there a way to fix this? If no, I could work on this. Any hint > where to start? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Be rather willing to give than demanding to get." From stephane.ducasse at univ-savoie.fr Thu Sep 25 15:12:20 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 25 Sep 2008 15:12:20 +0200 Subject: [Moose-dev] Re: how in the script editor In-Reply-To: <0FFC869C-07E9-4E03-8036-A6416E87DE14@iam.unibe.ch> References: <0FFC869C-07E9-4E03-8036-A6416E87DE14@iam.unibe.ch> Message-ID: Thanks doru. Stef On Sep 25, 2008, at 11:09 AM, Tudor Girba wrote: > Hi Stef, > > The problem is that the editor is just a selection, not a navigation. > That means that if you have a set of entities you can get a subset > using the query. In your case, you want to get packages from classes. > > The default browser does not support navigation (only the Widgetry one > does that). To navigate you need to Inspect, add your code and then > you can open the result in a browser by self openInBrowser. > > You can find out more about what you can do with the script from here: > http://moose.unibe.ch/tools/moosefinder > > The grammar of the language is here: > http://moose.unibe.ch/tools/moosefinder/queryGrammar > > Cheers, > Doru > > On Sep 25, 2008, at 11:01 AM, St?phane Ducasse wrote: > >> can we get all the packages from a list of classes? >> >> Doru >> is there a way that the script does not just need a predicate and >> return a subset but can get a full block >> >> If I have a list of classes I would like to get a group with all the >> packages of the classes. >> So a kind of flatCollect on the result >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Some battles are better lost than fought." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From akuhn at gmx.ch Thu Sep 25 23:16:51 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Thu, 25 Sep 2008 23:16:51 +0200 Subject: [Moose-dev] Re: [Reminder] This friday, Fame sprint. Message-ID: <7BFF57DA-B74F-4F6A-851A-1A7D76B711A3@gmx.ch> We are on freenode irc://chat.freenode.net/fame-dev cheers, AA > Any way to remotely join (mostly as an observer)? > > Thanks ... Sophie > > ----- Original Message ----- > > > Dear All, > > > > this Friday, a Fame sprint will take place in Bern. > > > > Program > > - 11:00 rehearsal of Models at Runtime presentation. > > - Afterwards, happy hacking and pair programing. > > > > Links > > - http://www.iam.unibe.ch/~akuhn/d/Kuhn-2008-MRT-Fame.pdf > > - http://smallwiki.unibe.ch/fame/issues > > > > You are welcome to participate and/or attend the rehearsal. > > > > @Moose - if you have feature requests, please reply to this mail or > > add them on the wiki page! For example, I have seen that you are > > about to impl a visitor, this sounds like a nice job for Fame code > > generation. > > > > cheers, > > Adrian > > > > -- > > Adrian Kuhn > > Software Composition Group > > University of Bern, Switzerland > > http://www.iam.unibe.ch/~akuhn > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev at iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > From akuhn at gmx.ch Fri Sep 26 00:24:21 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Fri, 26 Sep 2008 00:24:21 +0200 Subject: [Moose-dev] Re: More metrics in Moose? Message-ID: > >> And how about correctness of the measured values? The class comment > >> states: "Right now only Number of MessageSends is computed in a > >> correct manner." On the first glance, I cannot see which of the > >> measured values could be wrong. Any hint on inappropriate > >> computation or improvement would be appreciated. The only thing I > >> see a bit confusing is the computation of two McCabe numbers > >> #cyclomaticNumber and #cyclomaticNumber2. Unfortunately, the class > >> comment does not tell enough. > > > > Correctness of measured values is a big issue. The correctness of > the > > numbers that Moose produces is unknown. Even such simple > measurements > > as the number of classes or method invocations might be wrong! > > I think that adrian is a bit simplifying too much. > What is the language that you want to analyse? > For Smalltalk, since the langage is dynamically typed nobody on earth > can be precise when talking about invocations! > Now for the number of classes I think that this is correct. > > Now if you take any "professional" tools you have to ask yourself Example of error range in senders: FAMIX does not model shared variables and their initializers, thus any sender in an initializer is lost. If you browse senders with VW you get them. And RBCrawler gets them as well, but filters senders by the result of a flow analysis with method scope (by doing the same abstract interpretation as RoelTyper does, as I found out later when comparing the two tools). That is, three numbers with different precision for the same metric. Example of error range in number of classes and methods: Fame uses 4 anonymous subclasses of Fame.MetaDescription to instantiate primitive descriptions. FAMIX will not model them, but Object withAllSubclasses will list them. That is, two numbers for the same metric. i.e., even something as simple as the number of classes is more than one number and thus the correct number of classes is rather a range of possible numbers. In physics error ranges are given as N+/-Err, in software analysis they could be given by making clear what has been measured and what is missing. See examples above. Of course, whether the above errors matter or not will depend on your use case. For some use cases they might be no problem, for other use cases they are critical or at least annoying. Whether you care are not also depends on your distance from source code. Consider for example a class blueprint. In smalltalk most #new methods call an #initialize method that typically creates new objects of a different type by calling #new again. Moose will thus visualize the two methods as calling each other even though any developer can tell they do not! For a consultant doing an offline analysis at 10'000 feet altitude that might be good enough, but for the developer using the tool while working at ground level the visualization must be precise or they stop using it because its results are obviously false... and this is why RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :) cheers, AA From private at hans-n-beck.de Fri Sep 26 06:58:42 2008 From: private at hans-n-beck.de (Hans N Beck) Date: Fri, 26 Sep 2008 06:58:42 +0200 Subject: [Moose-dev] [OT] info about Metrics Message-ID: <2042F9A3-213E-4CA0-B6FE-20149925B93E@hans-n-beck.de> Hi, is there a good web site about oo metrics ? I need to get an overview over different metrics (independent if moose implement them or not) Greetings Hans From stephane.ducasse at univ-savoie.fr Fri Sep 26 07:28:39 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 07:28:39 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: References: Message-ID: <084B03E0-B04A-483A-8B4A-F69A15AEEE50@univ-savoie.fr> >> > > Example of error range in senders: > FAMIX does not model shared variables and their initializers, thus > any sender in an initializer is lost. Adrian your importer removed them. Because old crap did it! And I will reintroduce it. > If you browse senders with VW > you get them. And RBCrawler gets them as well, but filters senders by > the result of a flow analysis with method scope (by doing the same > abstract interpretation as RoelTyper does, as I found out later when > comparing the two tools). > That is, three numbers with different precision for the same metric. Come on this is a dynamic typed language so nobody on earth find the exact set to any of my code if I decide it. > > Example of error range in number of classes and methods: > Fame uses 4 anonymous subclasses of Fame.MetaDescription to > instantiate primitive descriptions. FAMIX will not model them, but > Object withAllSubclasses will list them. > That is, two numbers for the same metric. Moose does support reflective use like anonymous subclasses. > i.e., even something as simple as the number of classes is more than > one number and thus the correct number of classes is rather a range > of possible numbers. In physics error ranges are given as N+/-Err, in > software analysis they could be given by making clear what has been > measured and what is missing. See examples above. Thanks prof. > Of course, whether the above errors matter or not will depend on your > use case. For some use cases they might be no problem, for other use > cases they are critical or at least annoying. > > Whether you care are not also depends on your distance from source > code. Consider for example a class blueprint. In smalltalk most #new > methods call an #initialize method that typically creates new objects > of a different type by calling #new again. Moose will thus visualize > the two methods as calling each other even though any developer can > tell they do not! For a consultant doing an offline analysis at > 10'000 feet altitude that might be good enough, but for the developer > using the tool while working at ground level the visualization must > be precise or they stop using it because its results are obviously > false... and this is why RBCrawler takes the whole pain of running a > flow analysis, because I was eating my own dogfood :) You are so much better than us > > > cheers, > AA > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at univ-savoie.fr Fri Sep 26 07:30:48 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 07:30:48 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: References: Message-ID: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> Where can I load that? Because I would like to see how accurate it is? Stef On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: > RBCrawler takes the whole pain of running a > flow analysis, because I was eating my own dogfood :) From stephane.ducasse at univ-savoie.fr Fri Sep 26 07:33:26 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 07:33:26 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: References: Message-ID: <45FC1263-97A1-499E-A01B-CA7F55EDB192@univ-savoie.fr> First Moose is not about model reflective smalltalk programs - this was never the goal. Second, your range error does not solve any of the problems. Because you can we know the error range for some metrics for which you do not have the reflective query at hand! Stef On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: > i.e., even something as simple as the number of classes is more than > one number and thus the correct number of classes is rather a range > of possible numbers. In physics error ranges are given as N+/-Err, in > software analysis they could be given by making clear what has been > measured and what is missing. See examples above. From stephane.ducasse at univ-savoie.fr Fri Sep 26 07:39:05 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 07:39:05 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <084B03E0-B04A-483A-8B4A-F69A15AEEE50@univ-savoie.fr> References: <084B03E0-B04A-483A-8B4A-F69A15AEEE50@univ-savoie.fr> Message-ID: <4D78DFB3-7032-43E4-916E-EE5035DFFCEE@univ-savoie.fr> On Sep 26, 2008, at 7:28 AM, St?phane Ducasse wrote: >>> >> >> Example of error range in senders: >> FAMIX does not model shared variables and their initializers, thus >> any sender in an initializer is lost. > > Adrian your importer removed them. > Because old crap did it! > And I will reintroduce it. > >> If you browse senders with VW >> you get them. And RBCrawler gets them as well, but filters senders by >> the result of a flow analysis with method scope (by doing the same >> abstract interpretation as RoelTyper does, as I found out later when >> comparing the two tools). >> That is, three numbers with different precision for the same metric. > > Come on this is a dynamic typed language so nobody on earth find the > exact > set to any of my code if I decide it. >> >> Example of error range in number of classes and methods: >> Fame uses 4 anonymous subclasses of Fame.MetaDescription to >> instantiate primitive descriptions. FAMIX will not model them, but >> Object withAllSubclasses will list them. >> That is, two numbers for the same metric. > > Moose does NOT > support reflective use like anonymous subclasses. > > >> i.e., even something as simple as the number of classes is more than >> one number and thus the correct number of classes is rather a range >> of possible numbers. In physics error ranges are given as N+/-Err, in >> software analysis they could be given by making clear what has been >> measured and what is missing. See examples above. > > Thanks prof. > > >> Of course, whether the above errors matter or not will depend on your >> use case. For some use cases they might be no problem, for other use >> cases they are critical or at least annoying. >> >> Whether you care are not also depends on your distance from source >> code. Consider for example a class blueprint. In smalltalk most #new >> methods call an #initialize method that typically creates new objects >> of a different type by calling #new again. Moose will thus visualize >> the two methods as calling each other even though any developer can >> tell they do not! For a consultant doing an offline analysis at >> 10'000 feet altitude that might be good enough, but for the developer >> using the tool while working at ground level the visualization must >> be precise or they stop using it because its results are obviously >> false... and this is why RBCrawler takes the whole pain of running a >> flow analysis, because I was eating my own dogfood :) > > You are so much better than us > >> >> >> cheers, >> AA >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at univ-savoie.fr Fri Sep 26 07:40:31 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 07:40:31 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <45FC1263-97A1-499E-A01B-CA7F55EDB192@univ-savoie.fr> References: <45FC1263-97A1-499E-A01B-CA7F55EDB192@univ-savoie.fr> Message-ID: <55614E0F-DBD6-484C-B02F-7170F843751E@univ-savoie.fr> > > Because you cannot not know the error range for some metrics for > which you > do not have the reflective query at hand! show not type email when people are talking to you in another language early the morning. From bergel at iam.unibe.ch Fri Sep 26 08:35:54 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Fri, 26 Sep 2008 08:35:54 +0200 Subject: [Moose-dev] Re: [OT] info about Metrics In-Reply-To: <2042F9A3-213E-4CA0-B6FE-20149925B93E@hans-n-beck.de> References: <2042F9A3-213E-4CA0-B6FE-20149925B93E@hans-n-beck.de> Message-ID: <2D36B33A-A1E8-4C56-83E6-ADE4A0EF5C84@iam.unibe.ch> Hi Hans, There is a few books on this. Maybe the most common is "Object- Oriented Software Metrics" by Mark Lorez and Jeff Kidd There is also the one of Michele and Radu "Object-Oriented Metrics in Practice" http://www.springer.com/computer/programming/book/978-3-540-24429-5 About a web site, I do not know. Cheers, Alexandre On 26 Sep 2008, at 06:58, Hans N Beck wrote: > Hi, > > is there a good web site about oo metrics ? I need to get an overview > over different metrics (independent if moose implement them or not) > > Greetings > > Hans > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From klaus.witzel at cobss.com Fri Sep 26 08:45:43 2008 From: klaus.witzel at cobss.com (Klaus D. Witzel) Date: Fri, 26 Sep 2008 08:45:43 +0200 Subject: [Moose-dev] Re: [OT] info about Metrics In-Reply-To: <2D36B33A-A1E8-4C56-83E6-ADE4A0EF5C84@iam.unibe.ch> References: <2042F9A3-213E-4CA0-B6FE-20149925B93E@hans-n-beck.de> <2D36B33A-A1E8-4C56-83E6-ADE4A0EF5C84@iam.unibe.ch> Message-ID: On Fri, 26 Sep 2008 08:35:54 +0200, Bergel, Alexandre wrote: > Hi Hans, > > There is a few books on this. Maybe the most common is "Object- > Oriented Software Metrics" by Mark Lorez and Jeff Kidd > There is also the one of Michele and Radu "Object-Oriented Metrics in > Practice" > http://www.springer.com/computer/programming/book/978-3-540-24429-5 > > About a web site, I do not know. There is an excellent one in German and I confess I visit them every now and then, because this site combines problems and projects and methodology and experience (and not just talks about things). Enter "Metrik" in their search field here - http://www.software-kompetenz.de/ Cheers, Klaus > Cheers, > Alexandre > > > On 26 Sep 2008, at 06:58, Hans N Beck wrote: > >> Hi, >> >> is there a good web site about oo metrics ? I need to get an overview >> over different metrics (independent if moose implement them or not) >> >> Greetings >> >> Hans >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From bergel at iam.unibe.ch Fri Sep 26 13:23:23 2008 From: bergel at iam.unibe.ch (Bergel, Alexandre) Date: Fri, 26 Sep 2008 13:23:23 +0200 Subject: [Moose-dev] Re: Browse source code In-Reply-To: <68191C91-DA93-4743-94C3-3FAA9BE6DB9F@iam.unibe.ch> References: <85ED9A4A-5BDC-4323-A8FD-25EB7C2AAA17@inria.fr> <68191C91-DA93-4743-94C3-3FAA9BE6DB9F@iam.unibe.ch> Message-ID: I will do some experiment with Moose. Thanks Doru, Alexandre On 25 Sep 2008, at 14:56, Tudor Girba wrote: > Yes, there is a way, but it should be improved. There is a > browseSource selector that answers the text from the sourceText > selector in an entity. At the moment, sourceText just searches for the > filename related to a class based on the name of the class and it > expects the file to be relative to ./src (from where the image is). > > This is kind of not so nice :). It would be cool to have a dialog for > asking for the initial path. > > Cheers, > Doru > > On Sep 25, 2008, at 2:43 PM, Alexandre Bergel wrote: > >> Dear List, >> >> When I am browsing a Java model, let's say ArgoUML, I cannot browse >> the source code of the model. >> Pressing 'Browsing source code' when right clicking on an entity >> seems >> ineffective. >> >> Is there a way to fix this? If no, I could work on this. Any hint >> where to start? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Be rather willing to give than demanding to get." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From akuhn at gmx.ch Fri Sep 26 13:38:23 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Fri, 26 Sep 2008 13:38:23 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> References: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> Message-ID: <98E94782-7233-43C5-96D7-CAB7D4B56703@gmx.ch> It is part of RBCrawler, look for a subclass of InstructionStream (or whatever name that core class to iterate over bytecodes has). If you like to use it in Moose, I can distribute it as a separate package. AA On 26 Sep 2008, at 7:30 , St?phane Ducasse wrote: > Where can I load that? > Because I would like to see how accurate it is? > > Stef > > On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: > >> RBCrawler takes the whole pain of running a >> flow analysis, because I was eating my own dogfood :) From stephane.ducasse at inria.fr Fri Sep 26 14:18:22 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 14:18:22 +0200 Subject: [Moose-dev] Doru SqMoose needs U Message-ID: <5140C805-B3C9-46DD-82E3-814D199380F9@inria.fr> Hi doru I have a problem with the tests: #testMinimalStateofEntity #testReferenceModelInEntities Could you help me? Stef From girba at iam.unibe.ch Fri Sep 26 14:32:18 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 26 Sep 2008 14:32:18 +0200 Subject: [Moose-dev] Re: Doru SqMoose needs U In-Reply-To: <5140C805-B3C9-46DD-82E3-814D199380F9@inria.fr> References: <5140C805-B3C9-46DD-82E3-814D199380F9@inria.fr> Message-ID: Hi Stef, The second one is probably related to the ID. I can try to take a look at them over the weekend. Cheers, Doru On Sep 26, 2008, at 2:18 PM, St?phane Ducasse wrote: > Hi doru > > I have a problem with the tests: > > #testMinimalStateofEntity > #testReferenceModelInEntities > > Could you help me? > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Every thing has its own flow." From laborator at web.de Fri Sep 26 14:39:04 2008 From: laborator at web.de (Thomas Schrader) Date: Fri, 26 Sep 2008 14:39:04 +0200 Subject: [Moose-dev] bible code visualization / STom Message-ID: <1322690662@web.de> Look, this image from The Bible got placed in the International Science and Engineering Visualization Challenge http://www.spiegel.de/fotostrecke/fotostrecke-35617-7.html The bar in the very middle must be a "God" class. Thomas -- mailto thomas.j.schrader at web de ________________________________________________________________________ Schon geh?rt? Bei WEB.DE gibt' s viele kostenlose Spiele: http://games.entertainment.web.de/de/entertainment/games/free/index.html From stephane.ducasse at univ-savoie.fr Fri Sep 26 18:18:51 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 18:18:51 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <98E94782-7233-43C5-96D7-CAB7D4B56703@gmx.ch> References: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> <98E94782-7233-43C5-96D7-CAB7D4B56703@gmx.ch> Message-ID: Ok I think that in RB they got a class RB*Guess*Type Now I would like to see how such information can be used since this is what roeltyper is doing. Stef On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote: > It is part of RBCrawler, look for a subclass of InstructionStream > (or whatever name that core class to iterate over bytecodes has). > > If you like to use it in Moose, I can distribute it as a separate > package. > > AA > > > On 26 Sep 2008, at 7:30 , St?phane Ducasse wrote: > >> Where can I load that? >> Because I would like to see how accurate it is? >> >> Stef >> >> On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: >> >>> RBCrawler takes the whole pain of running a >>> flow analysis, because I was eating my own dogfood :) > > From akuhn at gmx.ch Fri Sep 26 18:23:02 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Fri, 26 Sep 2008 18:23:02 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: References: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> <98E94782-7233-43C5-96D7-CAB7D4B56703@gmx.ch> Message-ID: <8205BEDB-6835-4A2A-BF67-ECDD739DB41E@gmx.ch> RoelTyper does not use RBGuessType. RoelType runs a byte code flow analysis and types inst vars. RBCrawler runs a byte code flow analysis and types message sends. AA On 26 Sep 2008, at 18:18 , St?phane Ducasse wrote: > Ok > I think that in RB they got a class RB*Guess*Type > Now I would like to see how such information can be used since this > is what roeltyper is doing. > > Stef > > On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote: > >> It is part of RBCrawler, look for a subclass of InstructionStream >> (or whatever name that core class to iterate over bytecodes has). >> >> If you like to use it in Moose, I can distribute it as a separate >> package. >> >> AA >> >> >> On 26 Sep 2008, at 7:30 , St?phane Ducasse wrote: >> >>> Where can I load that? >>> Because I would like to see how accurate it is? >>> >>> Stef >>> >>> On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: >>> >>>> RBCrawler takes the whole pain of running a >>>> flow analysis, because I was eating my own dogfood :) >> >> From stephane.ducasse at univ-savoie.fr Fri Sep 26 18:35:22 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 18:35:22 +0200 Subject: [Moose-dev] Re: More metrics in Moose? In-Reply-To: <8205BEDB-6835-4A2A-BF67-ECDD739DB41E@gmx.ch> References: <158A8A91-5026-4C75-815C-083EE0898FE0@univ-savoie.fr> <98E94782-7233-43C5-96D7-CAB7D4B56703@gmx.ch> <8205BEDB-6835-4A2A-BF67-ECDD739DB41E@gmx.ch> Message-ID: <8A2AD973-2979-40D6-B73E-AB42B0C8FBB9@univ-savoie.fr> On Sep 26, 2008, at 6:23 PM, Adrian Kuhn wrote: > RoelTyper does not use RBGuessType. I know. > RoelType runs a byte code flow analysis and types inst vars. > RBCrawler runs a byte code flow analysis and types message sends. Ok do you mean that you get the type of receivers? I think that it would be good to integrate all that to Moose. First SqMoose...running Stef > > > AA > > > On 26 Sep 2008, at 18:18 , St?phane Ducasse wrote: > >> Ok >> I think that in RB they got a class RB*Guess*Type >> Now I would like to see how such information can be used since this >> is what roeltyper is doing. >> >> Stef >> >> On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote: >> >>> It is part of RBCrawler, look for a subclass of InstructionStream >>> (or whatever name that core class to iterate over bytecodes has). >>> >>> If you like to use it in Moose, I can distribute it as a separate >>> package. >>> >>> AA >>> >>> >>> On 26 Sep 2008, at 7:30 , St?phane Ducasse wrote: >>> >>>> Where can I load that? >>>> Because I would like to see how accurate it is? >>>> >>>> Stef >>>> >>>> On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote: >>>> >>>>> RBCrawler takes the whole pain of running a >>>>> flow analysis, because I was eating my own dogfood :) >>> >>> > > From stephane.ducasse at univ-savoie.fr Fri Sep 26 18:35:57 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 26 Sep 2008 18:35:57 +0200 Subject: [Moose-dev] Re: Doru SqMoose needs U In-Reply-To: References: <5140C805-B3C9-46DD-82E3-814D199380F9@inria.fr> Message-ID: Tx I'm working on the other. Today we got class extensions working. Stef On Sep 26, 2008, at 2:32 PM, Tudor Girba wrote: > Hi Stef, > > The second one is probably related to the ID. I can try to take a look > at them over the weekend. > > Cheers, > Doru > > > On Sep 26, 2008, at 2:18 PM, St?phane Ducasse wrote: > >> Hi doru >> >> I have a problem with the tests: >> >> #testMinimalStateofEntity >> #testReferenceModelInEntities >> >> Could you help me? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Every thing has its own flow." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From stephane.ducasse at free.fr Sat Sep 27 17:46:40 2008 From: stephane.ducasse at free.fr (stephane ducasse) Date: Sat, 27 Sep 2008 17:46:40 +0200 Subject: [Moose-dev] About classVar in presence of metaclass /class merging Message-ID: <40F883ED-0968-41C9-94EE-C668B37456D5@free.fr> Hi all I'm fixing the classVar/sharedVar import in SqMoose and after I will do it in VW. Now I have a question: when we make the distinction between a class and its metaclass this is easy. when we merge a class and its metaclass: a metaclass instVar will become a "class variable" But we really need a way to make the distinction between a sharedvariable and merged class inst var. so I would like to have isShared in attribute or SmalltalkFamix extension: how do I do that in Famix20? Famix30? Then if I have the same variable name at the instance and class side when I merge I have a conflict with name and the importer will break. So I could modify the importer to have another mapping and let in the resulting model two attributes with the same name but different scope or I could modify the name of the mapped class inst var with something like CL-x (would means I was a class var but I was merged). Of course this solution is uglier but easier to implement. Stef From ducasse at iam.unibe.ch Sat Sep 27 21:51:19 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Sat, 27 Sep 2008 21:51:19 +0200 Subject: [Moose-dev] About stub creation Message-ID: <11CEFC89-0D80-4836-A538-A6F0B82B16FD@iam.unibe.ch> Hi I'm working on making shared variable available in sqmoose and I got the following situation When I import referenceModel When I reify TheRoot (from referenceModel) the importer create all the superclass up to protoobject and more..... Object class, .... Behavior... Just because it is importing recursively all the superclass chain. For my point of view this is wrong. I'm quite sure that the old importer did not go all the way up. It was creating the superclass as a stub and stopped there. I'm checking in VWoose to see what is the behavior but I propose to fix it too if this is not a squeakish behavior of the importer. What do you think? Stef From stephane.ducasse at inria.fr Sat Sep 27 22:46:34 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 27 Sep 2008 22:46:34 +0200 Subject: [Moose-dev] about propertyAt:ifAbsent: Message-ID: <36AF3E95-CE80-4C8C-AD99-209574AE7BB5@inria.fr> Hi I wanted to know why such method is not present in moose. There is only propertyAt:ifAbsentPut: I will add it. Stef From girba at iam.unibe.ch Sat Sep 27 22:55:05 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Sat, 27 Sep 2008 22:55:05 +0200 Subject: [Moose-dev] Re: about propertyAt:ifAbsent: In-Reply-To: <36AF3E95-CE80-4C8C-AD99-209574AE7BB5@inria.fr> References: <36AF3E95-CE80-4C8C-AD99-209574AE7BB5@inria.fr> Message-ID: Hi Stef, There is such a method in AbstractEntity>>propertyNamed: propertyName ifNil: aBlock Doru On Sep 27, 2008, at 10:46 PM, St?phane Ducasse wrote: > Hi > > I wanted to know why such method is not present in moose. > There is only > propertyAt:ifAbsentPut: > > I will add it. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com www.tudorgirba.com/blog "Every now and then stop and ask yourself if the war you're fighting is the right one." From stephane.ducasse at univ-savoie.fr Sun Sep 28 09:20:35 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Sun, 28 Sep 2008 09:20:35 +0200 Subject: [Moose-dev] Re: about propertyAt:ifAbsent: In-Reply-To: References: <36AF3E95-CE80-4C8C-AD99-209574AE7BB5@inria.fr> Message-ID: <2C76A17D-18CD-4DBD-A806-8D15D7940A4C@univ-savoie.fr> I did not see it because it is not in accessing as some of the other methods. I will group all the methods together in property I tried to understand the difference between property:ifAbsent: Basically this is the fact that ifNil: check to see if the property could be computed because metadescribed. I imagine that this is correct. Now when the property cannot be computed this is ok to use ifNil too. Now I have a question how do I make this guy working? self mooseDescription I still do not remember how to access meta stuff in fame. propertyNamed: propertyName ifNil: aBlock "Return the value of the property named propertyName, return nil if the property does not exist" ^self privateState at: propertyName asSymbol ifAbsent: [| property propertyOperator | [propertyOperator := self mooseDescription computableAttributeNamed: propertyName. property := self mmGet: propertyOperator] on: Error do: [:ex | property := nil]. property ifNil: [aBlock value]] On Sep 27, 2008, at 10:55 PM, Tudor Girba wrote: > Hi Stef, > > There is such a method in AbstractEntity>>propertyNamed: propertyName > ifNil: aBlock > > Doru > > > On Sep 27, 2008, at 10:46 PM, St?phane Ducasse wrote: > >> Hi >> >> I wanted to know why such method is not present in moose. >> There is only >> propertyAt:ifAbsentPut: >> >> I will add it. >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Every now and then stop and ask yourself if the war you're fighting > is the right one." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From deniersi at iro.umontreal.ca Mon Sep 29 15:43:49 2008 From: deniersi at iro.umontreal.ca (Simon Denier) Date: Mon, 29 Sep 2008 15:43:49 +0200 Subject: [Moose-dev] MSE file for FAMIX3? Message-ID: <9034106C-9153-4783-8D1E-573169DCB532@iro.umontreal.ca> Hi all I'm looking for the mse file describing FAMIX3.0 - I couldnt find it on the moose website. We want to load it with Fame VW and Fame for Java. Did anyone try that already? -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Universit? de Montr?al From richard.wettel at lu.unisi.ch Mon Sep 29 20:17:31 2008 From: richard.wettel at lu.unisi.ch (Richard Wettel) Date: Mon, 29 Sep 2008 20:17:31 +0200 Subject: [Moose-dev] Installing Moose from parcel breaks In-Reply-To: <9034106C-9153-4783-8D1E-573169DCB532@iro.umontreal.ca> References: <9034106C-9153-4783-8D1E-573169DCB532@iro.umontreal.ca> Message-ID: <8F6FDD4E-F4B8-4E09-9702-3B0590DD5800@lu.unisi.ch> Hi, I tried to install Moose from parcel and it breaks while loading HapaxDevelopment. Cheers, Ricky From girba at iam.unibe.ch Tue Sep 30 12:25:52 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Tue, 30 Sep 2008 12:25:52 +0200 Subject: [Moose-dev] Re: [scg-staff] Eyesee examples as copypastable text? In-Reply-To: <0FAD3753-60D7-4CD0-A111-9E7851C1B3DE@gmx.ch> References: <0FAD3753-60D7-4CD0-A111-9E7851C1B3DE@gmx.ch> Message-ID: You can find more examples in the EyeSee.Examples class. Cheers, Doru On Sep 30, 2008, at 12:15 PM, Adrian Kuhn wrote: > http://moose.unibe.ch/tools/eyesee/examples > > Are these examples available as copypastable text? > And, are there more examples? > > cheers, > AA > > -- www.tudorgirba.com www.tudorgirba.com/blog "We cannot reach the flow of things unless we let go." From akuhn at gmx.ch Tue Sep 30 13:30:07 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Tue, 30 Sep 2008 13:30:07 +0200 Subject: [Moose-dev] Re: [scg-staff] Re: Eyesee examples as copypastable text? In-Reply-To: References: <0FAD3753-60D7-4CD0-A111-9E7851C1B3DE@gmx.ch> Message-ID: Does not work, raises DNU: Unhandled exception: Message not understood: #isEmpty UndefinedObject(Object)>>doesNotUnderstand: EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height EyeSee.BottomAxisStrategy>>setBorders: EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>setUpperLowerBorder EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>createAxis EyeSee.LineDiagram(EyeSee.AbstractDiagram)>>setup EyeSee.DiagramRenderer>>open EyeSee.Examples>>lineDiagram ---------------------------------------------------------------------- UndefinedObject(Object)>>doesNotUnderstand: Receiver: an UndefinedObject Arguments: aMessage = a Message with selector: #isEmpty and arguments: #() Temporaries: excpt = a MessageNotUnderstood resumeValue = nil Context PC = 25 ---------------------------------------------------------------------- EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height Receiver: a EyeSee.BaseLineDecorator Instance Variables: preferedMaxValue = nil preferedMinValue = nil maxValue = nil minValue = nil values = nil start = nil end = nil label = nil color = nil labelRepresentation = nil rotatedLabels = nil normalLabelOrientation = nil labelDistanceBlock = nil labelPointCalculationBlock = nil textStyle = nil anAxis = an EyeSee.Axis minTickDistance = 15 centerIdentifiers = true Temporaries: maxStringValue = nil Context PC = 6 ---------------------------------------------------------------------- EyeSee.BottomAxisStrategy>>setBorders: Receiver: a EyeSee.BottomAxisStrategy Arguments: aDiagram = an EyeSee.LineDiagram Context PC = 29 ---------------------------------------------------------------------- EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>setUpperLowerBorder Receiver: a EyeSee.LineDiagram Instance Variables: layerHolder = an EyeSee.LayerHolder elements = an OrderedCollection[0] scale = 1 at 1 contentTranslation = 0 at 0 contentScale = 1 at 1 diagramTranslation = 0 at 0 height = 300 width = 400 xPadding = 20 yPadding = 20 models = an OrderedCollection[9] axisColor = ColorValue black defaultColor = CodeFoo.Color blue labels = BlockClosure [] in EyeSee.AbstractDiagram>>initialize rotatedLabels = true leftBorder = 48 upperBorder = 0 rightBorder = 69 lowerBorder = 0 defaultFontSize = 12 color = nil colorDict = a Dictionary[0] availableColors = an OrderedCollection[4] displayLegend = true legendHeight = 30 legendWidth = nil diagramTitle = nil titleFontHeight = 18 horizontalLegend = true gcWrapper = an EyeSee.DiagramGraphicsContextWrapper legendOrigin = nil titleAlignment = nil axisFontSize = 8 legend = nil labelDistance = nil decorators = a Dictionary[0] decorationPadding = 0 hasOrientationLeftRight = true hasOrientationBottomTop = true xAxis = an EyeSee.BaseLineDecorator yAxis = an EyeSee.TitleDecorator xAxisStrategy = an EyeSee.BottomAxisStrategy movedXAxis = false movedYAxis = false yAxisStrategy = an EyeSee.LeftAxisStrategy xAxisLabel = nil yAxisLabel = 'LoC' xAxisTranslation = 0 at 0 yAxisTranslation = 0 at 0 xAxisScale = 1 at 1 yAxisScale = 1 at 1 preferredAxisMaxX = nil preferredAxisMaxY = nil preferredAxisMinX = nil preferredAxisMinY = 3346 xDeviationValue = nil yDeviationValue = (39157/9) xDeviationDescription = nil yDeviationDescription = 'average' xAxisDecorators = an OrderedCollection[1] yAxisDecorators = an OrderedCollection[3] showBorder = false identifier = #versionNumber valueBlock = #loc cachedValues = an OrderedCollection[9] dotSize = 0 mathematical = false lineWidth = 1 Context PC = 6 ---------------------------------------------------------------------- EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>createAxis Receiver: a EyeSee.LineDiagram Instance Variables: layerHolder = an EyeSee.LayerHolder elements = an OrderedCollection[0] scale = 1 at 1 contentTranslation = 0 at 0 contentScale = 1 at 1 diagramTranslation = 0 at 0 height = 300 width = 400 xPadding = 20 yPadding = 20 models = an OrderedCollection[9] axisColor = ColorValue black defaultColor = CodeFoo.Color blue labels = BlockClosure [] in EyeSee.AbstractDiagram>>initialize rotatedLabels = true leftBorder = 48 upperBorder = 0 rightBorder = 69 lowerBorder = 0 defaultFontSize = 12 color = nil colorDict = a Dictionary[0] availableColors = an OrderedCollection[4] displayLegend = true legendHeight = 30 legendWidth = nil diagramTitle = nil titleFontHeight = 18 horizontalLegend = true gcWrapper = an EyeSee.DiagramGraphicsContextWrapper legendOrigin = nil titleAlignment = nil axisFontSize = 8 legend = nil labelDistance = nil decorators = a Dictionary[0] decorationPadding = 0 hasOrientationLeftRight = true hasOrientationBottomTop = true xAxis = an EyeSee.BaseLineDecorator yAxis = an EyeSee.TitleDecorator xAxisStrategy = an EyeSee.BottomAxisStrategy movedXAxis = false movedYAxis = false yAxisStrategy = an EyeSee.LeftAxisStrategy xAxisLabel = nil yAxisLabel = 'LoC' xAxisTranslation = 0 at 0 yAxisTranslation = 0 at 0 xAxisScale = 1 at 1 yAxisScale = 1 at 1 preferredAxisMaxX = nil preferredAxisMaxY = nil preferredAxisMinX = nil preferredAxisMinY = 3346 xDeviationValue = nil yDeviationValue = (39157/9) xDeviationDescription = nil yDeviationDescription = 'average' xAxisDecorators = an OrderedCollection[1] yAxisDecorators = an OrderedCollection[3] showBorder = false identifier = #versionNumber valueBlock = #loc cachedValues = an OrderedCollection[9] dotSize = 0 mathematical = false lineWidth = 1 Context PC = 46 ---------------------------------------------------------------------- EyeSee.LineDiagram(EyeSee.AbstractDiagram)>>setup Receiver: a EyeSee.LineDiagram Instance Variables: layerHolder = an EyeSee.LayerHolder elements = an OrderedCollection[0] scale = 1 at 1 contentTranslation = 0 at 0 contentScale = 1 at 1 diagramTranslation = 0 at 0 height = 300 width = 400 xPadding = 20 yPadding = 20 models = an OrderedCollection[9] axisColor = ColorValue black defaultColor = CodeFoo.Color blue labels = BlockClosure [] in EyeSee.AbstractDiagram>>initialize rotatedLabels = true leftBorder = 48 upperBorder = 0 rightBorder = 69 lowerBorder = 0 defaultFontSize = 12 color = nil colorDict = a Dictionary[0] availableColors = an OrderedCollection[4] displayLegend = true legendHeight = 30 legendWidth = nil diagramTitle = nil titleFontHeight = 18 horizontalLegend = true gcWrapper = an EyeSee.DiagramGraphicsContextWrapper legendOrigin = nil titleAlignment = nil axisFontSize = 8 legend = nil labelDistance = nil decorators = a Dictionary[0] decorationPadding = 0 hasOrientationLeftRight = true hasOrientationBottomTop = true xAxis = an EyeSee.BaseLineDecorator yAxis = an EyeSee.TitleDecorator xAxisStrategy = an EyeSee.BottomAxisStrategy movedXAxis = false movedYAxis = false yAxisStrategy = an EyeSee.LeftAxisStrategy xAxisLabel = nil yAxisLabel = 'LoC' xAxisTranslation = 0 at 0 yAxisTranslation = 0 at 0 xAxisScale = 1 at 1 yAxisScale = 1 at 1 preferredAxisMaxX = nil preferredAxisMaxY = nil preferredAxisMinX = nil preferredAxisMinY = 3346 xDeviationValue = nil yDeviationValue = (39157/9) xDeviationDescription = nil yDeviationDescription = 'average' xAxisDecorators = an OrderedCollection[1] yAxisDecorators = an OrderedCollection[3] showBorder = false identifier = #versionNumber valueBlock = #loc cachedValues = an OrderedCollection[9] dotSize = 0 mathematical = false lineWidth = 1 Context PC = 25 ---------------------------------------------------------------------- EyeSee.DiagramRenderer>>open Receiver: a EyeSee.DiagramRenderer Instance Variables: diagram = an EyeSee.LineDiagram backgroundColor = CodeFoo.Color white Context PC = 8 ---------------------------------------------------------------------- EyeSee.Examples>>lineDiagram Receiver: an EyeSee.Examples Temporaries: diag = an EyeSee.DiagramRenderer Context PC = 54 On 30 Sep 2008, at 12:25 , Tudor Girba wrote: > You can find more examples in the EyeSee.Examples class. > > Cheers, > Doru > > > On Sep 30, 2008, at 12:15 PM, Adrian Kuhn wrote: > >> http://moose.unibe.ch/tools/eyesee/examples >> >> Are these examples available as copypastable text? >> And, are there more examples? >> >> cheers, >> AA >> >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "We cannot reach the flow of things unless we let go." > From girba at iam.unibe.ch Tue Sep 30 13:42:31 2008 From: girba at iam.unibe.ch (Tudor Girba) Date: Tue, 30 Sep 2008 13:42:31 +0200 Subject: [Moose-dev] Re: [scg-staff] Re: Eyesee examples as copypastable text? In-Reply-To: References: <0FAD3753-60D7-4CD0-A111-9E7851C1B3DE@gmx.ch> Message-ID: <25C40C81-B276-4562-83E6-40ADE1E3C5A2@iam.unibe.ch> All of them raise DNU? I guess not. So which script produces that? Doru Sent from my iPhone On Sep 30, 2008, at 13:30, Adrian Kuhn wrote: > Does not work, raises DNU: > > Unhandled exception: Message not understood: #isEmpty > UndefinedObject(Object)>>doesNotUnderstand: > EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height > EyeSee.BottomAxisStrategy>>setBorders: > EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>setUpperLowerBorder > EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>createAxis > EyeSee.LineDiagram(EyeSee.AbstractDiagram)>>setup > EyeSee.DiagramRenderer>>open > EyeSee.Examples>>lineDiagram > > ---------------------------------------------------------------------- > UndefinedObject(Object)>>doesNotUnderstand: > Receiver: > an UndefinedObject > Arguments: > aMessage = a Message with selector: #isEmpty and arguments: #() > Temporaries: > excpt = a MessageNotUnderstood > resumeValue = nil > Context PC = 25 > > ---------------------------------------------------------------------- > EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height > Receiver: > a EyeSee.BaseLineDecorator > Instance Variables: > preferedMaxValue = nil > preferedMinValue = nil > maxValue = nil > minValue = nil > values = nil > start = nil > end = nil > label = nil > color = nil > labelRepresentation = nil > rotatedLabels = nil > normalLabelOrientation = nil From akuhn at gmx.ch Tue Sep 30 13:42:51 2008 From: akuhn at gmx.ch (Adrian Kuhn) Date: Tue, 30 Sep 2008 13:42:51 +0200 Subject: [Moose-dev] Re: [scg-staff] Re: Re: Re: Eyesee examples as copypastable text? In-Reply-To: <25C40C81-B276-4562-83E6-40ADE1E3C5A2@iam.unibe.ch> References: <0FAD3753-60D7-4CD0-A111-9E7851C1B3DE@gmx.ch> <25C40C81-B276-4562-83E6-40ADE1E3C5A2@iam.unibe.ch> Message-ID: Method in question, see stack trace. All line diagrams do it, including Collection#openPlot. AA On 30 Sep 2008, at 13:42 , Tudor Girba wrote: > All of them raise DNU? > > I guess not. So which script produces that? > > Doru > > Sent from my iPhone > > On Sep 30, 2008, at 13:30, Adrian Kuhn wrote: > >> Does not work, raises DNU: >> >> Unhandled exception: Message not understood: #isEmpty >> UndefinedObject(Object)>>doesNotUnderstand: >> EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height >> EyeSee.BottomAxisStrategy>>setBorders: >> EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>setUpperLowerBorder >> EyeSee.LineDiagram(EyeSee.Abstract2DDiagram)>>createAxis >> EyeSee.LineDiagram(EyeSee.AbstractDiagram)>>setup >> EyeSee.DiagramRenderer>>open >> EyeSee.Examples>>lineDiagram >> >> --------------------------------------------------------------------- >> - >> UndefinedObject(Object)>>doesNotUnderstand: >> Receiver: >> an UndefinedObject >> Arguments: >> aMessage = a Message with selector: #isEmpty and arguments: #() >> Temporaries: >> excpt = a MessageNotUnderstood >> resumeValue = nil >> Context PC = 25 >> >> --------------------------------------------------------------------- >> - >> EyeSee.BaseLineDecorator(EyeSee.AbstractAxisDecorator)>>height >> Receiver: >> a EyeSee.BaseLineDecorator >> Instance Variables: >> preferedMaxValue = nil >> preferedMinValue = nil >> maxValue = nil >> minValue = nil >> values = nil >> start = nil >> end = nil >> label = nil >> color = nil >> labelRepresentation = nil >> rotatedLabels = nil >> normalLabelOrientation = nil From stephane.ducasse at inria.fr Tue Sep 30 19:06:07 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 30 Sep 2008 19:06:07 +0200 Subject: [Moose-dev] is it possible that an entity has a nil mooseID? Message-ID: <5A17F059-0371-44A2-94C4-F88832F1E1B2@inria.fr> Stef From stephane.ducasse at inria.fr Tue Sep 30 19:08:07 2008 From: stephane.ducasse at inria.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 30 Sep 2008 19:08:07 +0200 Subject: [Moose-dev] is MooseIDGenerator deprecated? Message-ID: From ducasse at iam.unibe.ch Tue Sep 30 19:12:44 2008 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 30 Sep 2008 19:12:44 +0200 Subject: [Moose-dev] Another question Message-ID: Hi I was reading MooseElement>>mooseID "Returns an unique identifier of this entity. This method is mandatory, and must return an Integer that unqiuely identifies this entity within the entire Moose environ- ment. The return value must not be nil, and must never change." nil = mooseID ifTrue: [mooseID := MooseModel freshID]. ^mooseID and I wonder why this is MooseModel freshID since freshID is only implemented on MooseElement class>>freshID Stef From stephane.ducasse at univ-savoie.fr Tue Sep 30 19:18:22 2008 From: stephane.ducasse at univ-savoie.fr (=?ISO-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 30 Sep 2008 19:18:22 +0200 Subject: [Moose-dev] Re: is it possible that an entity has a nil mooseID? In-Reply-To: <5A17F059-0371-44A2-94C4-F88832F1E1B2@inria.fr> References: <5A17F059-0371-44A2-94C4-F88832F1E1B2@inria.fr> Message-ID: <29B1AD3F-8A3B-47B3-B36B-5567050D0A16@univ-savoie.fr> In VW I get accesses with nil mooseID in Squeak I get namespace with nil mooseID :-/ Stef On Sep 30, 2008, at 7:06 PM, St?phane Ducasse wrote: > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev