8 Dec
2007
8 Dec
'07
12:17 a.m.
Please find below the latest draft of the MSE format
There is a new mse element, annotations, which can be used twofold
(1) To structure mse files into multiple documents. For example an
mse file may contain an @mse header document and both a @metamodel
and @model document, or even multiple @version1 @version2 ...
documents. The only reserved annotation would be @mse for the leading
header document.
So a valid document could eg look like this
@mse ((MSE.File
(metamodel 'http://moose.unibe.ch/spec/famix/3.0')
(model '@model'))
@model
((FAMIX.Package (id: 1)
(name 'LAN')
(classes
(FAMIX.Class ...
...
...
))))
(2) Annotations for elements. Attribute names may start with an @ to
indicate an attribute not conforming to the metamodel, for example
the longDesc of a Moose measurement, or the category of a Moose meny
entry would use this feature. But also the variable indexed slots of
Magritte elements.
(MA.Element
(name 'ABC')
(attr 0.5 0.75 -1 0.2)
(@1 'foo')
(@2 'bar')
(@3 nil)
(@4 'qux'))
Also there are two new primitives
- Nil
- Datetime
Nil is not to be confused with unset values, which may have a default
value different from nil
(...
absent = default value
(attr ) = default value
(attr nil) = nil value
(attr "..some..") = some value
...)
Similar to SAX, there is a ParserClient interface for reading MSE
documents using callbacks. This interface allows an application to
register for MSE document parsing. The sequence of callbacks is
limited to the following protocol
MAIN := beginFile ( annotation* beginDocument ELEM* endDocument )*
endFile
ELEM := beginElement serial? (beginAttribute ( primitive | reference
| ELEM )* endAttribute) endElement
which is based on this grammer and tokens
root := fragment | file
fragment := elementNode
file := document*
document := annotation* "(" elementNode* ")"
annotation := AT_NAME
elementNode := "(" elementName serial? attributeNode* ")"
elementName := NAME
attributeNode := "(" attributeName valueNode* ")"
attributeName := NAME | AT_NAME
valueNode := primitive | id-reference | reference | elementNode
primitive := STRING | NUMBER | BOOLEAN | DATE | NIL
serial := "(" "id:" INTEGER ")"
id-reference := "(" "idref:" INTEGER ")"
reference := "(" "ref:" NAME ")"
Breaks input-stream into tokens. Accepts the following grammar
Tokens
Open ::= "("
Close ::= ")"
AtName ::= "@" ( Letter | Digit )+
Keyword ::= "id:" | "idref:" | "ref:"
Name ::= Letter ( Letter | Digit )* ( "." ( Letter | Digit )+ )*
String ::= ( "'" [ˆ']* "'" )+
Boolean ::= "true" | "false"
Nil ::= "nil"
Date ::= Digit{4} "-" Digit{2} "-" Digit{2} ( ","
Digit{2}
":" Digit{2} ":" Digit{2} )
Number ::= "-"? Digit+ ( "." Digit+ )? ( "e" (
"-"? Digit+ ))?
Terminals
Digit ::= [0-9]
Letter ::= [a-zA-Z_]
Whitespace
Whitespace ::= Space Tab ecetera...
Comment ::= "\"" [ˆ"] "\""
----
What do you think?
AA
8 Dec
8 Dec
12:41 a.m.
On 8 Dec 2007, at 0:17 , Adrian Kuhn wrote:
root := fragment | file
fragment := elementNode
file := document*
document := annotation* "(" elementNode* ")"
annotation := AT_NAME
Me again, this should have been
root := fragment | document | file
file := "@mse" document ( documentName document )*
documentName := AT_NAME
document := "(" elementNode* ")"
fragment := elementNode
AA
1:52 p.m.
On 8 déc. 07, at 00:17, Adrian Kuhn wrote:
Please find below the latest draft of the MSE format
There is a new mse element, annotations, which can be used twofold
(1) To structure mse files into multiple documents.
do we want that?
because we will have to uniquely identify the metamodel associated
with a model?
How do we distinguish versions? because there is a number in the tag?
For example an
mse file may contain an @mse header document and both a @metamodel
and @model document, or even multiple @version1 @version2 ...
documents. The only reserved annotation would be @mse for the leading
header document.
So a valid document could eg look like this
@mse ((MSE.File
(metamodel 'http://moose.unibe.ch/spec/famix/3.0')
(model '@model'))
we had something similar in CDIF and never used it for validation :)
@model
((FAMIX.Package (id: 1)
(name 'LAN')
(classes
(FAMIX.Class ...
...
...
))))
(2) Annotations for elements. Attribute names may start with an @ to
indicate an attribute not conforming to the metamodel, for example
the longDesc of a Moose measurement, or the category of a Moose meny
entry would use this feature. But also the variable indexed slots of
Magritte elements.
(MA.Element
(name 'ABC')
(attr 0.5 0.75 -1 0.2)
(@1 'foo')
(@2 'bar')
(@3 nil)
(@4 'qux'))
Also there are two new primitives
- Nil
- Datetime
Nil is not to be confused with unset values, which may have a default
value different from nil
I see.
(...
absent = default value
(attr ) = default value
(attr nil) = nil value
(attr "..some..") = some value
...)
ok above defaultValue means nil in Smalltalk?
Similar to SAX, there is a ParserClient interface for reading MSE
documents using callbacks. This interface allows an application to
register for MSE document parsing.
cool
The sequence of callbacks is
limited to the following protocol
MAIN := beginFile ( annotation* beginDocument ELEM* endDocument )*
endFile
ELEM := beginElement serial? (beginAttribute ( primitive | reference
| ELEM )* endAttribute) endElement
which is based on this grammer and tokens
root := fragment | file
fragment := elementNode
file := document*
document := annotation* "(" elementNode* ")"
annotation := AT_NAME
elementNode := "(" elementName serial? attributeNode* ")"
elementName := NAME
attributeNode := "(" attributeName valueNode* ")"
attributeName := NAME | AT_NAME
valueNode := primitive | id-reference | reference | elementNode
primitive := STRING | NUMBER | BOOLEAN | DATE | NIL
serial := "(" "id:" INTEGER ")"
id-reference := "(" "idref:" INTEGER ")"
reference := "(" "ref:" NAME ")"
Breaks input-stream into tokens. Accepts the following grammar
Tokens
Open ::= "("
Close ::= ")"
AtName ::= "@" ( Letter | Digit )+
Keyword ::= "id:" | "idref:" | "ref:"
Name ::= Letter ( Letter | Digit )* ( "." ( Letter | Digit )
+ )*
String ::= ( "'" [ˆ']* "'" )+
Boolean ::= "true" | "false"
Nil ::= "nil"
Date ::= Digit{4} "-" Digit{2} "-" Digit{2} ( ","
Digit{2}
":" Digit{2} ":" Digit{2} )
Number ::= "-"? Digit+ ( "." Digit+ )? ( "e" (
"-"? Digit+ ))?
Terminals
Digit ::= [0-9]
Letter ::= [a-zA-Z_]
Whitespace
Whitespace ::= Space Tab ecetera...
Comment ::= "\"" [ˆ"] "\""
----
What do you think?
AA
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:54 p.m.
(1) To
structure mse files into multiple documents.
do we want that?
because we will have to uniquely identify the metamodel associated
with a model?
How do we distinguish versions? because there is a number in the tag?
@mse ((MSE.File
(metamodel 'http://moose.unibe.ch/spec/famix/3.0')
(model '@model'))
we had something similar in CDIF and never used it for validation :)
(...
absent = default value
(attr ) = default value
(attr nil) = nil value
(attr "..some..") = some value
...)
ok above defaultValue means nil in Smalltalk?
3:12 p.m.
On 8 Dec 2007, at 14:54 , Toon Verwaest wrote:
Default value in smalltalk means what the class puts as default
value in
"initialize" I guess. This would be the smalltalk variant of what I am
currently doing in Python.
Default value for booleans is false and for numbers it is 0, see FM3
(draft) spec.
Currently FM3 does not allow other default, question is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
Defaults for primitve attributes are straight forward, whereas
default values for other attributes lead into the whole meta-behavior
mess...
AA
(...
absent = default value
(attr ) = default value
(attr nil) = nil value
(attr "..some..") = some value
...)
ok above defaultValue means nil in Smalltalk?
3:29 p.m.
Currently FM3 does not allow other default, question
is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
Defaults for primitve attributes are straight forward, whereas
default values for other attributes lead into the whole meta-behavior
mess...
I would default values to be class-defined... For boolean = False is ok
for our purpose with Famix (that's then also where it came from, me
noticing that there were too many false's in the text), but this is not
really a good solution for all situations. Lukas already told me that
his default value for some booleans where true. I really think that
(since for the files itself it doesn't really matter) it would be better
to have some "default" tag in fm3-specified documents, so you can
customize. (equivalent is the body of the initialize)
5:03 p.m.
Currently FM3 does not allow other default, question
is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and
booleans. Attributes can have a different default value. As Toon
explained I have examples where the default value for a boolean is
true or the one for a number is 17 ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5:49 p.m.
Hi,
The main use case in Magritte for the nil initial value is that you
want to distinguish between something that is specifically set and
something that is not. The same use case we would have for
distinguishing between the case when a parser could not say about a
class that it isAbstract and another case when it could say that it is
not.
The other use case is when we could not compute some metric for some
reason.
I think, these are good use cases.
On the other hand, I do not like that a Boolean can have 3 values
because this hinders later on the queries and proliferates guard
conditions (which is a pain). So, if we take this road, then I would
like to have an ExtendedBoolean and an ExtendedNumber that deal with
the special cases.
But, somehow I would rather go for the simplest case when we do not
allow such undecided values, because this puts more pressure on the
parsers to produce better results.
Doru
On Dec 8, 2007, at 5:03 PM, Lukas Renggli wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"It's not what we do that matters most, it's how we do it."
Currently FM3
does not allow other default, question is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and
booleans. Attributes can have a different default value. As Toon
explained I have examples where the default value for a boolean is
true or the one for a number is 17 ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10 Dec
10 Dec
8:53 a.m.
I shoud say that I do not really understand the goal of what you are
doing.
Using Famix for code generation? representing parser results?
I have the impression that when you have a boolean and the parser
give you nil
then you know that this is not the value but unknown.
May be this is what you do not like doru (I got confused).
But the isKnown was the solution to this problem at that ancient time :)
Stef
Hi,
The main use case in Magritte for the nil initial value is that you
want to distinguish between something that is specifically set and
something that is not. The same use case we would have for
distinguishing between the case when a parser could not say about a
class that it isAbstract and another case when it could say that it is
not.
The other use case is when we could not compute some metric for some
reason.
I think, these are good use cases.
On the other hand, I do not like that a Boolean can have 3 values
because this hinders later on the queries and proliferates guard
conditions (which is a pain). So, if we take this road, then I would
like to have an ExtendedBoolean and an ExtendedNumber that deal with
the special cases.
But, somehow I would rather go for the simplest case when we do not
allow such undecided values, because this puts more pressure on the
parsers to produce better results.
Doru
On Dec 8, 2007, at 5:03 PM, Lukas Renggli wrote:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Currently
FM3 does not allow other default, question is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and
booleans. Attributes can have a different default value. As Toon
explained I have examples where the default value for a boolean is
true or the one for a number is 17 ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:19 a.m.
Stéphane Ducasse wrote:
I shoud say that I do not really understand the goal
of what you are
doing.
Using Famix for code generation? representing parser results?
I have the impression that when you have a boolean and the parser
give you nil
then you know that this is not the value but unknown.
May be this is what you do not like doru (I got confused).
But the isKnown was the solution to this problem at that ancient time :)
Stef
Mmmmh... I can't say that I really like the "isKnown" solution.
The idea of our talk (at least my side) is that if default values -are-
primitive values; we might as well include them in the FAMIX.fm3.mse
specification. This would allow code generation in different platforms
to actually write the correct initialization for those values. And then
famix-files would be allowed to omit values which are the default ones.
As we saw for famix specified in fm3 where we specified default values
(Adrian got a bit mixed up and reused these default values also for
other metamodels); this shortens the length of some files quite a lot.
(and reduces the time needed for parsing and initializing obviously...)
Toon
10:07 p.m.
On 10 déc. 07, at 11:19, Toon Verwaest wrote:
Stéphane Ducasse wrote:
without a metamodel it was good enough.
I shoud say that I do not really understand the
goal of what you are
doing.
Using Famix for code generation? representing parser results?
I have the impression that when you have a boolean and the parser
give you nil
then you know that this is not the value but unknown.
May be this is what you do not like doru (I got confused).
But the isKnown was the solution to this problem at that ancient
time :)
Stef
Mmmmh... I can't say that I really like the "isKnown" solution.
The idea of our talk (at least my side) is that if
default values -
are-
primitive values; we might as well include them in the FAMIX.fm3.mse
specification.
But how can you make sure that these default values are the same in
all the languages.
Is it the importer that will do the mapping?
I did that in CDIF converting idiot -TRUE- into true and this is
boring and slowing everything.
So mse will be slower or mse will favor a language (if this is
Smalltalk this is ok too).
now if the default value is a boolean, will I get true or nil if in
the model it was not set?
This would allow code generation in different
platforms
to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used.
But this was fun to do that just to learn that old MOF way of
representing relationship was crap
and created overly complex queries for code generation.
And then famix-files would be allowed to omit values
which are the
default ones.
As we saw for famix specified in fm3 where we specified default values
(Adrian got a bit mixed up and reused these default values also for
other metamodels); this shortens the length of some files quite a lot.
(and reduces the time needed for parsing and initializing
obviously...)
Toon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:30 p.m.
But how can you make sure that these default values
are the same in
all the languages.
This is equivalent to how all primitive values are set. If you have an
attribute and you want to give it a value; you always need to translate
the text in a way so that the language interpreting it understands it.
"preferring a language" is not really relevant since you will probably
always read it as a token first and then change tokens into actual
values. The standard way of writing parsers.
Is it the importer that will do the mapping?
I did that in CDIF converting idiot -TRUE- into true and this is
boring and slowing everything.
As said before; this does -not- slow -anything- down. You always have
to do that. If you write "true" in your workspace in Visualworks or
whatever you use; you also have to read and parse this. It's not
because it looks like the language does this automagically that your
smalltalk does not read and parse it anyway.
So mse will be slower or mse will favor a language (if
this is
Smalltalk this is ok too).
So this is an invalid argument. See above.
now if the default value is a boolean, will I get true
or nil if in
the model it was not set?
If no default is specified, this will be the default "unset" value of
the language in question. In python this will be None, in java this
will be null or 0 for int or false for boolean. For ...... and
smalltalk this will be nil.
This would
allow code generation in different platforms
to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used.
But this was fun to do that just to learn that old MOF way of
representing relationship was crap
and created overly complex queries for code generation.
10:35 p.m.
FAME implementations available (for java and python)
at:
https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte
plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
11 Dec
11 Dec
2:23 p.m.
Hi lukas,
do you parse mse?
or generate it because I did a mse exporter to save all the version
of seaside
last year.
MCHttpRepository
location: 'http://www.squeaksource.com/MSE'
user: ''
password: ''
did you rewrite everything?
Which version of mse are you supporting?
I wrote that code for the first version of mse and know I do not
understand
anything.
Stef
FAME
implementations available (for java and python) at:
https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte
plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:10 p.m.
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects
based on meta-descriptions (like the one in VW). For example, he can
use the Magritte descriptions.
One of the goals was to build a format for storing Pier in text files,
so with this occasion we reused a bit the effort :).
Cheers,
Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse?
or generate it because I did a mse exporter to save all the version
of seaside
last year.
MCHttpRepository
location: 'http://www.squeaksource.com/MSE'
user: ''
password: ''
did you rewrite everything?
Which version of mse are you supporting?
I wrote that code for the first version of mse and know I do not
understand
anything.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
FAME
implementations available (for java and python) at:
https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte
plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:41 p.m.
I see.
I could not check the code because I had no internet access in a bad
room with no plug during the complete day.
Stef
On 11 déc. 07, at 19:10, Tudor Girba wrote:
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects
based on meta-descriptions (like the one in VW). For example, he can
use the Magritte descriptions.
cool I'm interested since I did a stupid exporting based on magritte
for my comix
app but I was too lazy to do the rest.
I was planning to use Sixx but the xml part was pushing me away
One of the goals was to build a format for storing
Pier in text files,
so with this occasion we reused a bit the effort :).
E x c e l l e n t
Stef
Cheers,
Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse?
or generate it because I did a mse exporter to save all the version
of seaside
last year.
MCHttpRepository
location: 'http://www.squeaksource.com/MSE'
user: ''
password: ''
did you rewrite everything?
Which version of mse are you supporting?
I wrote that code for the first version of mse and know I do not
understand
anything.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
FAME
implementations available (for java and python) at:
https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte
plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:11 p.m.
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects
based on meta-descriptions (like the one in VW). For example, he can
use the Magritte descriptions.
One of the goals was to build a format for storing Pier in text files,
so with this occasion we reused a bit the effort :).
Cheers,
Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse?
or generate it because I did a mse exporter to save all the version
of seaside
last year.
MCHttpRepository
location: 'http://www.squeaksource.com/MSE'
user: ''
password: ''
did you rewrite everything?
Which version of mse are you supporting?
I wrote that code for the first version of mse and know I do not
understand
anything.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
FAME
implementations available (for java and python) at:
https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte
plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:15 p.m.
Hi Stef,
do you parse mse?
yes, both. I wrote a generic reader and a generic writer.
or generate it because I did a mse exporter to save
all the version
of seaside
last year.
I know that code. The goal of my implementation is a bit different, it
does not (necessarily) generate output to be consumed by FAMIX.
Which version of mse are you supporting?
I think the version from Monday, but frankly it is quite a mess with
these versions lately. The parser is based on SmaCC so I can fairly
quick adopt it, if necessary.
I wrote that code for the first version of mse and
know I do not
understand anything.
What? I don't get it ;-)
Let me explain what I did:
- I wrote a generic MSEParser. You give it a valid MSE string and it
will return you a graph of Associations, OrderedCollection, and
Dictionaries. That's the default and directly maps to the MSE
structure. Obviously this is not really useful. Now it is possible to
subclass MSEParser and override some hock methods that allow you to
instantiate and build 'real' objects. How you instantiate and
initialize your real objects is up to you or your meta-model. I've
written such parsers for Magritte and for the Smalltalk object model.
- I wrote a generic MSEWriter. You give it a tree of objects and it
writes everything out as a graph. Again the default implementation is
totally stupid, but you can subclass it to tell the engine how to
traverse your objects and what to serialize. I've done this for
Magritte and the Smalltalk object model.
So for me this is merely a way to serialize objects (e.g. for Pier).
This is not much different than what SIXX, JSON, or Hessian are
already doing, except that I can combine it nicely with any read/write
strategy. Of course it would also be possible to enable it to
read/write FAMIX models, but I did not do that right now.
For example:
MSESmalltalkWriter write: 1 @ #( 'mse' 1.1 $a $a ) asOrderedCollection.
'(Point (id: 1)
(x 1)
(y (OrderedCollection (id: 2)
(array
(Array (id: 3)
(_var
''mse''
(Character (id: 4)
(value 97))
(idref: 4))))
(firstIndex 1)
(lastIndex 3))))'
Parsing back that string I get the same object as I wrote out.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5:27 p.m.
But how can
you make sure that these default values are the same in
all the languages.
This is equivalent to how all primitive values are set. If you have an
attribute and you want to give it a value; you always need to
translate
the text in a way so that the language interpreting it understands it.
"preferring a language" is not really relevant since you will probably
always read it as a token first and then change tokens into actual
values. The standard way of writing parsers. Is it the
importer that will do the mapping?
I did that in CDIF converting idiot -TRUE- into true and this is
boring and slowing everything.
As said before; this does -not- slow -anything- down. You always have
to do that. If you write "true" in your workspace in Visualworks or
whatever you use; you also have to read and parse this. It's not
because it looks like the language does this automagically that your
smalltalk does not read and parse it anyway. So mse will be
slower or mse will favor a language (if this is
Smalltalk this is ok too).
So this is an invalid argument. See above.
now if the default value is a boolean, will I get
true or nil if in
the model it was not set?
If no default is specified, this will be the default "unset" value of
the language in question. In python this will be None, in java this
will be null or 0 for int or false for boolean. For ...... and
smalltalk this will be nil.
This
would allow code generation in different platforms
to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used.
But this was fun to do that just to learn that old MOF way of
representing relationship was crap
and created overly complex queries for code generation.
11:10 p.m.
On 11 Dec 2007, at 17:27 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
cheers,
AA
12 Dec
12 Dec
9:34 a.m.
Apparently
this is no what I understood from the first mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
9:01 p.m.
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Just because I would like to know for Squeak potential speed.
Why was the VW parser slower?
what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
AA
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian
can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
13 Dec
13 Dec
12:31 a.m.
On (12/12/07 21:01), Adrian Kuhn wrote:
From: Adrian Kuhn <akuhn(a)gmx.ch>
To: Related to the development of Moose and other related tools
<moose-dev(a)iam.unibe.ch>
Subject: [Moose-dev] Re: MSE Format, latest draft
Date: Wed, 12 Dec 2007 21:01:15 +0100
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Just because I would like to know for Squeak potential speed.
Why was the VW parser slower?
what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
Unless you are "crazy" enough to do manual tweakings :D Which is not
even sure to speed up the process anyway...
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian
can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
3:30 p.m.
My question was can we reuse what you did to speed up the
default Squeak Smalltalk parser. But I get that you speed up the mse
one.
Stef
On 12 déc. 07, at 21:01, Adrian Kuhn wrote:
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Just because I would like to know for Squeak potential speed.
Why was the VW parser slower?
what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
AA
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian
can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we
use a
custom scanner / parser as this is faster.
3:35 p.m.
Apparently
this is no what I understood from the first mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
5:50 p.m.
Me too, I subclass from Scanner (see yourself Meta.MSEParser)
AA
On 13 Dec 2007, at 15:35 , Stéphane Ducasse wrote:
ok if you have your dedicated scanner then this is different. I
thought that you reused
the one of Smalltalk. The original CDIF one used the one of Smalltalk
since serge did not use Smacc.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian
can
you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a
custom scanner / parser as this is faster.
11 Dec
11 Dec
11:12 p.m.
On 11 Dec 2007, at 17:27 , Stéphane Ducasse wrote:
At least when the Smalltalk parser parses a literal
array, it creates
literal objects at compile-time
and you do not have to do another translation.
It reads a string and then does string == "true" ifTrue: [ ^true ]
same for nil false etc. No magic in there, Toon is right.
AA
12 Dec
12 Dec
3:55 a.m.
Thanks for the lesson. (Toon could you consider that
even if I ask
extremely
naive (or looking naive) question I'm not totally brainwashed, at
least I believe so
let me with my dreams.)
I did not mean to do no harm.
Apparently this is no what I understood from the first
mse format.
Adrian's first implementation used a literal array representation
just to avoid to do the -TRUE- to true kind of conversion. Adrian can
you comment on that?
So here... I guess this is just that ... the closer a syntax is to the
syntax of the (mainly) used language itself; the easier it is to read
and parse it. (Here easier refers to the amount of work for the
programmer; not for the machine).
If you look at an MSE-file without any MSE-strings in it (since they are
"smalltalk-optimized"); you could just open a scheme-evaluator and
evaluate it as a list (by just putting a ' in front of it). Then scheme
does all the parsing work for you since it just looks exactly the same
as what normal scheme lists would look like. Numbers are read probably
since scheme uses the same kind of numbers; names are scheme-symbols...
and if you don't use '' inside a string to denote '; even strings are
read properly like it should. However; true and false are read as
symbols true and false instead of the boolean values. Whereas, if the
booleans would be #t and #f in the fileformat; this would automatically
yield the scheme-true and scheme-false after read-evalling the list. And
here the same holds for Smalltalk I guess; if you put # in front of an
mse-expression; it just looks like an Array. And smalltalk does all the
"hard" work for you.
Actually; when I did my first scheme-mse-reader; I just did some basic
string-translations on the document which changed true and false into #t
and #f; and those strings ('[^']*')+ into things with "\"".
Then I just
read it as a list. In order to then "parse" it; I don't have to think
about "tokens" etc etc; I just traverse a scheme-list in normal recursion.
I hope that this clarifies your question?
cheers,
and now really of to bed :)
Toon
9 Dec
9 Dec
8:36 p.m.
Currently FM3
does not allow other default, question is if we really
need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and
booleans. Attributes can have a different default value. As Toon
explained I have examples where the default value for a boolean is
true or the one for a number is 17 ;-)
9:48 p.m.
In general, default values do not fit well into a
meta-layer
architecture, as a value of the model level is to be specified at the
meta-level. A default value can be constant or derived and primitive
or non-primitive, of these cases only constant primitive default
values fit well with a meta-layer architecture.
For other cases we could currently just specify the same as what we do
for derived but non-opposite attributes and the methods we generate
for them. => raise NotImplementedError() #This is a stub-method.
We want to give as much support for automation as possible, but
where impossible to do without the current mse-suport; the programmer
has to fill in the blanks in the generated code.
As far as I see default values declarations are only important for
code generation. For all other cases; you just use what's in the
"initialize" as default value.
I wouldn't immediately start providing support for other things by
means of a query language; this would convert the fileformat MSE into
a language of its own (which is then translatable to all the other
languages which use MSE???) which is also not the purpose I guess.
10 Dec
10 Dec
8:48 a.m.
I do not understand why you want to put a default value for languages
where you cannot know it.
>>>
>>>> (...
>>>> absent = default value
>>>> (attr ) = default value
>>>> (attr nil) = nil value
>>>> (attr "..some..") = some value
>>>> ...)
>>>
>>>
>>> ok above defaultValue means nil in Smalltalk?
>>>
>> Default value in smalltalk means what the class puts as default
>> value in
>> "initialize" I guess. This would be the smalltalk variant of what
>> I am
>> currently doing in Python.
>
> Default value for booleans is false and for numbers it is 0, see FM3
> (draft) spec.
>
> Currently FM3 does not allow other default, question is if we really
> need that, as we have no usecase yet. @Lukas, how is it in Magritte?
> Defaults for primitve attributes are straight forward, whereas
> default values for other attributes lead into the whole meta-behavior
> mess...
>
> AA
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:49 a.m.
The underlying question is aren;t you redoing yet another XMI
XLink... stuff.
and ow mcuh are you reusing from their design because may there is
something to learn
from their approach (besides dropping XML).
stef
On 8 déc. 07, at 14:54, Toon Verwaest wrote:
I am not
sure what exactly was meant in this part. The title seems to
say something different from the body. Me and Doru have had a small
discussion about external files (what I understand from the title) and
loading in files which you might need at some point to reference to
types etc outside the scope of files. In order for this to work,
idref:-s need to be consistent in some way. So we thought of something
like: (MSE.File (filename: "....") (id: "...")) which allows you
then to
ref over files (idref: <fileid>.<objectid>) or local refs: (idref:
<objectid>). This is similar to how imports are handled in Python.
In order to fix diamond-shaped loadings etc, the absolute filename has
to be used inside readers instead of <fileid> to distinguish objects.
It would be handy however... this would allow us to generate code in
case the classes belonging to it are not there yet :)
Default value in smalltalk means what the class puts as default
value in
"initialize" I guess. This would be the smalltalk variant of what I am
currently doing in Python.
Toon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
(1) To
structure mse files into multiple documents.
do we want that?
because we will have to uniquely identify the metamodel associated
with a model?
How do we distinguish versions? because there is a number in the tag?
@mse ((MSE.File
(metamodel 'http://moose.unibe.ch/spec/famix/3.0')
(model '@model'))
we had something similar in CDIF and never used it for validation :)
(...
absent = default value
(attr ) = default value
(attr nil) = nil value
(attr "..some..") = some value
...)
ok above defaultValue means nil in Smalltalk?
5991
days inactive
5997
days old
32 comments
6 participants
participants (6)
-
Adrian Kuhn -
Lukas Renggli -
Stéphane Ducasse -
Toon Verwaest -
Toon Verwaest -
Tudor Girba