On 27 Nov 2007, at 20:05 , Toon Verwaest wrote:

I do have a list of remarks on the mess of FM3 / MSE that is currently online. There doesn't seem to be too much consistency anymore, since the things that have been changing recently. At the office I have a bigger list of things; but things that I currently remember:

It is a mess, and maybe, in addition, the version on the new site is not based forked from the latest version on smallwiki. @Doru, when did you fork the new site?

• you state that those primitive objects are the only ones which

shouldn't necessarily be defined in a package. I seem to recall that at some point we had entries like: (MSE.Class (back then it was still mse) (id:...) (name: Boolean)) as a toplevel statement; not in a package; to which we referred by id.

This was a bug.

Now all of a sudden I see in the FM3 file that you have used ref: (which looks like the primitive: in the EMOF version), but which is not defined in FM3. Does ref: mean that you do some lookup, or is this only for primitives, or ... where does it come from? And where -did- those primitive declarations go? They don't have to be declared anymore? Oh, and then... object is not a primitive type. Which means that if that is the definition; object should be declared... so I guess you don't have to write "the objects known to the reader" (reserved instances as you call them), and are ref:-able?

Lets call them built-in types: Object, String, Number, Boolean and Date. In the mse file, you must not include them and can refer to them using named references, eg (ref: String). An implementation of named references must implement the lookup of names such that these built-in types precede any user defined name, ie it must be impossible to shadow these names.

• I started noticing while implementing my python-version of FM3, that

you only specify that the field attributes of class can not contain attributes of the allAttributes of the superclass. Does this allow for attributes to have duplicates? I haven't seen the word "set" on that page. It just states "multivalued" which doesn't say anything about the actual values. Which is normal; because for normal models we probably -do- want to be able to have duplicates.

That needs more work, eg shadowing of attributes is not yet specified.

In general, multivalued properties are an unordered list of unique elements, ie set. Why? YAGNI, in Famix 2, even though there was support for bags, lists and ordered sets, nobody ever made use of that.

I just noticed that FAMIX3.0 spec is only online in EMOF? (or at least, that is the only version I found in a quick search) Shouldn't we at least have an FM3 version somewhere?

java -ea -cp famix.jar Fetch fm3

(works with the latest version of famix.jar)

Then the "good" news: today I finished a prototype implementation of an FM3 metarepository builder, which unlike the smalltalk version, builds the repository in single pass, and doesn't use 10 different dictionaries for building it up. Actually, the builder itself hasn't got any dictionary and fills up the model from scratch without doing intermediate things itself.

Cool! Where is it available?

Actually; I guess that we can do a similar single-pass MSE-reader for smalltalk (and maybe python too); which shouldn't be too difficult if we use "become" to swap "most-specific instances known up to a certain point" by "more specific instances".

Become is about an order of magnitude slower than doing a two pass import, in particular for large mse files (10 MB and more). Become is an extremely slow operation.

For FM3 that isn't an issue since at all times we know the exact type of what should be were, even if it isn't read yet. The metarepository builder is something special anyway :)

true

Then at some point I might put in that opposite/derived/type story I told Adrian and Doru; if I am working on this anyway. For those who are not following and still reading (you must be really bored :P)

(... (name "type1") (property (name "prop1") (derived true) (type "type2") (opp "prop2") ....)

(... (name "type2") (property (name "prop2") (type "type1") (opp "prop1") ....)

has duplicated info and could be reduced to: (... (name "type1") (property (name "prop1") (type "type2") (opp "prop2") ....)

(... (name "type2") (property (name "prop2") ....)

-> if you link to a prop of another type; that prop of that other type automatically links back to you (prop) with as type, the class in which that prop was defined. The one stating the opposite link is automatically the derived version. 1 special case: if a prop has itself as opposite (i.e. the opposite property of FM3.Property), it is not derived.

This comes from the fact that while defining the original drafts for FAMIX3.0, I had to type out this info. And having to copy all that data over and over again... is quite a hassle. And well, duplicated info is never good anyway.

Enough for one mail. Cheers, Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

...

• you state that those primitive objects are the only ones which

shouldn't necessarily be defined in a package. I seem to recall that at some point we had entries like: (MSE.Class (back then it was still mse) (id:...) (name: Boolean)) as a toplevel statement; not in a package; to which we referred by id.

This was a bug.

Since you force classes to be in packages, if instead of saying "you don't have to specify built-in objects", you would say "you are not allowed to specify built-in objects", this would solve the problem. Then all classes are named "Package.Class", and if there is no "." in the string, this means it's a ref to one of the built-ins. It would also make developing an MSE-reader more straightforward.

Lets call them built-in types: Object, String, Number, Boolean and Date. In the mse file, you must not include them and can refer to them using named references, eg (ref: String). An implementation of named references must implement the lookup of names such that these built-in types precede any user defined name, ie it must be impossible to shadow these names.

Will you make sure that I will be able to load a model of the class String in Moose via mse. I guess so but I decided to ask.

Mac does not have java 6, you must use Parallels...

Files are available here

https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix/MSE4Java/src/ examples/FM3.fm3.mse https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix/MSE4Java/src/ examples/FAMIX30.fm3.mse

cheers, AA

On 1 Dec 2007, at 14:12 , Toon Verwaest wrote:

...

java -ea -cp famix.jar Fetch fm3

macnamara:MSE4Java tverwaes$ java -ea -cp famix.jar Fetch fm3 Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java: 124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:316) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)

--> might be convenient just to have the file somewhere :) _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 27 nov. 07, at 20:05, Toon Verwaest wrote:

Adrian Kuhn wrote:

...

I am working on the handling of primitives in FM3 and Famix 3, and would like to make a small survey on how primitives had been used in Famix 2

• who used the custom primitives fature in Meta?
• who added a custom primitive other than Timestamp/Date/Time?
• which primitives are you missing?

I saw that dates are used in many projects (Chronia, Dude, etc...) and hence suggest to include them in FM3 as built-in primitives. The list of primitives is thus

String Boolean Number Date (new)

with MSE format

string ::= ( "'" [^']* "'" )+ boolean ::= "true" | "false" date ::= digit{4} "-" digit{2} "-" digit{2} ( ","digit{2} ":" digit {2} ":" digit{2} ) number ::= "-"? digit+ ( "." digit+ )? ( "e" ( "-"? digit+ ))?

@toon, can you extend the MSEParser in Smalltalk to recognize this token? I have only poor Store access here.

No problem. I will do that the end of this week or next week.

I do have a list of remarks on the mess of FM3 / MSE that is currently online. There doesn't seem to be too much consistency anymore, since the things that have been changing recently. At the office I have a bigger list of things; but things that I currently remember:

• you state that those primitive objects are the only ones which

shouldn't necessarily be defined in a package. I seem to recall that at some point we had entries like: (MSE.Class (back then it was still mse) (id:...) (name: Boolean)) as a toplevel statement; not in a package; to which we referred by id. Now all of a sudden I see in the FM3 file that you have used ref: (which looks like the primitive: in the EMOF version), but which is not defined in FM3. Does ref: mean that you do some lookup, or is this only for primitives, or ... where does it come from? And where -did- those primitive declarations go? They don't have to be declared anymore? I didn't understand this by just looking at the available specification online. Oh, and then... object is not a primitive type. Which means that if that is the definition; object should be declared... so I guess you don't have to write "the objects known to the reader" (reserved instances as you call them), and are ref:-able?

• I started noticing while implementing my python-version of FM3, that

you only specify that the field attributes of class can not contain attributes of the allAttributes of the superclass. Does this allow for attributes to have duplicates? I haven't seen the word "set" on that page. It just states "multivalued" which doesn't say anything about the actual values. Which is normal; because for normal models we probably -do- want to be able to have duplicates.

• I just noticed that FAMIX3.0 spec is only online in EMOF? (or at

least, that is the only version I found in a quick search) Shouldn't we at least have an FM3 version somewhere?

Then the "good" news: today I finished a prototype implementation of an FM3 metarepository builder, which unlike the smalltalk version, builds the repository in single pass, and doesn't use 10 different dictionaries for building it up. Actually, the builder itself hasn't got any dictionary and fills up the model from scratch without doing intermediate things itself. Actually; I guess that we can do a similar single-pass MSE-reader for smalltalk (and maybe python too); which shouldn't be too difficult if we use "become" to swap "most-specific instances known up to a certain point" by "more specific instances". For FM3 that isn't an issue since at all times we know the exact type of what should be were, even if it isn't read yet. The metarepository builder is something special anyway :)

Can you explain what you are doing? What is the metarepository builder?

Then at some point I might put in that opposite/derived/type story I told Adrian and Doru; if I am working on this anyway. For those who are not following and still reading (you must be really bored :P)

Indeed I was wondering if we should understand it.

(... (name "type1") (property (name "prop1") (derived true) (type "type2") (opp "prop2") ....)

(... (name "type2") (property (name "prop2") (type "type1") (opp "prop1") ....)

has duplicated info and could be reduced to: (... (name "type1") (property (name "prop1") (type "type2") (opp "prop2") ....)

(... (name "type2") (property (name "prop2") ....)

-> if you link to a prop of another type; that prop of that other type automatically links back to you (prop) with as type, the class in which that prop was defined. The one stating the opposite link is automatically the derived version. 1 special case: if a prop has itself as opposite (i.e. the opposite property of FM3.Property), it is not derived.

This comes from the fact that while defining the original drafts for FAMIX3.0, I had to type out this info. And having to copy all that data over and over again... is quite a hassle. And well, duplicated info is never good anyway.

Enough for one mail. Cheers, Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

...

Then the "good" news: today I finished a prototype implementation of an FM3 metarepository builder, which unlike the smalltalk version, builds the repository in single pass, and doesn't use 10 different dictionaries for building it up. Actually, the builder itself hasn't got any dictionary and fills up the model from scratch without doing intermediate things itself. Actually; I guess that we can do a similar single-pass MSE-reader for smalltalk (and maybe python too); which shouldn't be too difficult if we use "become" to swap "most-specific instances known up to a certain point" by "more specific instances". For FM3 that isn't an issue since at all times we know the exact type of what should be were, even if it isn't read yet. The metarepository builder is something special anyway :)

Can you explain what you are doing? What is the metarepository builder?

I am implementing Fame including code generator and MSE-reader/writer in Python, which is useful to afterwards be able to do some more analysis on Python programs. However mostly to force myself to actually rewrite most of the code from scratch, based on what was done for Smalltalk. This has the advantage that I do not only read/copy, but also improve the implementation. Afterwords I will go back to Smalltalk, and move my python version to smalltalk, so it works with FM3. This is a step in the way of moving towards the use of FAMIX3.0 in Moose.

The python-code is available @ scg svn (https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix/Python)