Menu
▾
▴
reuseware-developer — The Reuseware Composition Framework developer mailing list.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jendrik J. <Jen...@tu...> - 2008-03-12 07:54:27
|
Version 0.8 of the Reuseware Composition Framework has been released and is now available for download. With this release, the Reuseware Composition Framework fully supports metamodel-based languages. New concepts and new tooling make it even easier to define composition systems for arbitrary languages. The core of the framework has been rewritten for this version: Reuseware-based composition systems now integrate smoothly with many Eclipse- and EMF-based tools. * Visit: http://reuseware.org * Learn about the new features of Reuseware watching this screencast that introduces a composition system for UML: http://reuseware.org/index.php/UML_Activity_Diagram_Extension_Screencast * Learn more about different applications of Reuseware for modeling languages: http://reuseware.org/index.php/Applications * Install Reuseware and try it out yourself! http://reuseware.org/index.php/Reuseware_Installation_Screencast |
|
From: Jendrik J. <jen...@tu...> - 2007-09-17 07:29:16
|
Hi,
I won't reply in detail. I think we should discuss this offline. I
wonder if you really need this type casting, or if the two types
(QuotedString and Location) should actually both be replaced by the
primitive type String. Then we would need primitive types in the type
system and need to define how primitive elements can be composed. Which
seems to be the most natural way for me.
The "casting" you propose may be incompatible wit the type system we
have, since we already have a type hierarchy for which casting could be
introduced.
Cheers,
Jendrik
Jakob Henriksson wrote:
> On Fri, 07 Sep 2007 23:38:44 +0200, Sven Karol
> <s78...@in...> wrote:
>
>> Hello again!
>>
>> We could do something which compares attribute types of two fragment
>> types to determine if a cast is possible. And if the attributes are
>> compatible we could create a new fragment of the type to which we want
>> to cast having the same values as the old fragment. But this is in fact
>> not casting, it is more like cloning or converting, since casting (in
>> the classical java sence) allways threats one object/fragment which
>> might be referenced by different variables/fragmentlists.
>>
>> >However, I'm guessing that this situation will appear in other
>> scenarios
>> >in the future as well. So, the question is what we should do.
>>
>> It happend allready to me, but I thought the string concatenation was
>> the way to go because it was implemented and used in some examples.
>
> Right, it works, which is nice for the moment. But in the long run it's
> not really desirable, since it is type unsafe.
>
> Cheers,
> Jakob
>
>> Sven.
>>
>>
>>
>>
>> Jakob Henriksson schrieb:
>>> Hi,
>>>
>>> They might not be type compatible, I'm not really sure. What I'm sure
>>> about is that I want a solution which doesn't step outside the type
>>> system (which is currently the case). Maybe a solution for Modular
>>> Xcerpt is possible to find, by using different types from Xcerpt, not
>>> to use componentmodel.Location etc. I don't know exactly in this very
>>> moment how it can be solved, but probably somehow.
>>>
>>> However, I'm guessing that this situation will appear in other
>>> scenarios in the future as well. So, the question is what we should do.
>>>
>>> Going back to the example. What I want to bind is a QuotedString (i.e.
>>> the slot). What I have is a Location. The value of a location is a
>>> string. If you define a QuotedString to be:
>>>
>>> QuotedString = "\"" value:S "\"";
>>>
>>> (or something to that effect), then the values of Location and
>>> QuotedString are really the same. Here, the '"'s are really just
>>> concrete syntax, aren't they? Somehow it seems that the values from
>>> the different types in this case can be cast to each other (it might
>>> not always be possible, but in this case it is, which is why we could
>>> successfully employ a cast).
>>>
>>> Anyway, discussion will hopefully continue.
>>>
>>> Please CC "Reuseware Developer"
>>> <reu...@li...> on all mailing discussions
>>> so that everybody can follow the discussions and so that it will end
>>> up in the mailing list archives later on. It will be interesting to
>>> have. It also shows some activity to the outside world ;)
>>>
>>> Cheers,
>>> Jakob
>>>
>>>
>>> On Fri, 07 Sep 2007 17:37:20 +0200, Sven Karol
>>> <s78...@in...> wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> I really dont know if a simple cast would be the right solution here,
>>>> since "componentmodel.Location" and "xcerpt.QuotedString" are not
>>>> type compatible (aren't they?). Because of that, you really need
>>>> that information about concrete syntax as it is used by the string
>>>> concatenation, so something like
>>>>
>>>> > bind moduleID on qtWrapper with
>>>> (xcerpt.QuotedString)'"'moduleID'"'.mxcerpt;
>>>>
>>>> is possible to be implemented. If we really want to have
>>>>
>>>> > bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;
>>>>
>>>> reuseware would have to check all concrete Syntaxes registered as
>>>> parser/printer for "xcerpt.QuotedString" for prefixes and suffixes
>>>> ('"' and '"' in the case of mxcerpt) and do the string concatenation
>>>> internally. Of course this would work in some very special cases only
>>>> and has no clear semantics to the user. Additionally I currently do
>>>> not know if the concrete Syntax is accessible as far as one would
>>>> need for implementation of that feature, but I guess not.
>>>>
>>>>
>>>> greetz,
>>>> Sven.
>>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Reuseware-developer mailing list
>>> Reu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
>>>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Reuseware-developer mailing list
> Reu...@li...
> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
|
|
From: Jendrik J. <jen...@tu...> - 2007-09-17 07:20:38
|
Hi,
to "extend" a language, you define a new (abstract syntax) grammar and
refer in it to constructs of other languages ("language.construct"
notation) to reuse them.
The concrete syntax, you should probably re-define completely (or use
the inheritance mechanism (EXTENDS keyword), which does not always work
very well yet). It does not influence the interpretation. Note, that the
first rule in the concrete syntax will determine the start symbol for
the parser. So the concrete syntax definition for an extended
composition language should start with the rule for
"minimalcl.CompositionProgram".
Cheers,
Jendrik
Jakob Henriksson wrote:
> Hi,
>
> Yes, that would of course be ideal. But I never tried to extend an
> extended language before. Even though conceptually there is no real
> difference, it doesn't seem to be straight-forward from a practical
> point-of-view. But, I will try it out a little and report back on my
> experiences ;)
>
> Cheers,
> Jakob
>
> On Wed, 12 Sep 2007 10:09:15 +0200, Steffen Zschaler
> <Ste...@tu...> wrote:
>
>> Hi,
>>
>> I'm not sure, but wouldn't it be better to develop a new plugin with
>> only your new concepts instead of changing
>> de.tudresden.reuseware.fracola? And couldn't you, there, define a new
>> language using the grammar inheritance mechanisms of Reuseware?
>>
>> Just guessing...
>>
>> Steffen
>>
>> Jakob Henriksson schrieb:
>>> Hi again,
>>>
>>> It's not what it seems, I'm not talking to myself. Instead I talked to
>>> Steffen offline who pointed me in the right direction. New interpreters
>>> for the composition language can be added to
>>> de.tudresden.reuseware.fracola and registered in the corresponding
>>> plugin.xml file (but perhaps no-one should commit any drastic changes
>>> without checking with the people involved first? Which I guess is Sven
>>> now?) Anyway, I tried it on my local copy and it worked fine.
>>>
>>> But, then it becomes interesting how one can extend the basiccl language
>>> into a specific composition language used for a specific DCS (dedicated
>>> composition system). For example, if I want a "callmytool" construct in
>>> the language in which I write composition operators for Modular Xcerpt,
>>> how do I extend the basiccl language into 'mybasiccl' so I only make
>>> modifications to this extension and not the core language (basiccl)?
>>>
>>> The search continues...
>>>
>>> Jakob
>>>
>>> On Tue, 11 Sep 2007 14:11:23 +0200, Jakob Henriksson
>>> <jak...@tu...> wrote:
>>>
>>>
>>>> Hi hackers,
>>>>
>>>> For some experimental development I want to have the possibility to
>>>> call
>>>> an external tool during execution of a composition operator, i.e, to
>>>> write something like this:
>>>>
>>>> exec("path-to-tool", param_1, ..., param_n);
>>>>
>>>> or perhaps even something more specific:
>>>>
>>>> USEMYTOOL WITH PARAMS param_1, ..., param_n;
>>>>
>>>> I can extend the composition language to allow such statements, but
>>>> where can I treat the parameters and implement the actions to take on
>>>> execution of such a statement?
>>>>
>>>> Can someone point me in the direction, or describe how to create some
>>>> boiler-plate code that can later be augmented for the exact purpose of
>>>> the execution of those statements?
>>>>
>>>> In short: I want a Java-method to interpret those statements, where
>>>> does
>>>> the code go?
>>>>
>>>> Thanks,
>>>> Jakob
>>>>
>>>>
>>>
>>>
>>>
>
>
>
--
Dipl.-Medieninf. Jendrik Johannes
Research Assistant
Technische Universität Dresden
Department of Computer Science
Phone +49 351 463 42073
Fax +49 351 463 38459
Email jen...@tu...
|
|
From: Jakob H. <jak...@tu...> - 2007-09-17 07:06:50
|
Hi,
Yes, that would of course be ideal. But I never tried to extend an
extended language before. Even though conceptually there is no real
difference, it doesn't seem to be straight-forward from a practical
point-of-view. But, I will try it out a little and report back on my
experiences ;)
Cheers,
Jakob
On Wed, 12 Sep 2007 10:09:15 +0200, Steffen Zschaler
<Ste...@tu...> wrote:
> Hi,
>
> I'm not sure, but wouldn't it be better to develop a new plugin with
> only your new concepts instead of changing
> de.tudresden.reuseware.fracola? And couldn't you, there, define a new
> language using the grammar inheritance mechanisms of Reuseware?
>
> Just guessing...
>
> Steffen
>
> Jakob Henriksson schrieb:
>> Hi again,
>>
>> It's not what it seems, I'm not talking to myself. Instead I talked to
>> Steffen offline who pointed me in the right direction. New interpreters
>> for the composition language can be added to
>> de.tudresden.reuseware.fracola and registered in the corresponding
>> plugin.xml file (but perhaps no-one should commit any drastic changes
>> without checking with the people involved first? Which I guess is Sven
>> now?) Anyway, I tried it on my local copy and it worked fine.
>>
>> But, then it becomes interesting how one can extend the basiccl language
>> into a specific composition language used for a specific DCS (dedicated
>> composition system). For example, if I want a "callmytool" construct in
>> the language in which I write composition operators for Modular Xcerpt,
>> how do I extend the basiccl language into 'mybasiccl' so I only make
>> modifications to this extension and not the core language (basiccl)?
>>
>> The search continues...
>>
>> Jakob
>>
>> On Tue, 11 Sep 2007 14:11:23 +0200, Jakob Henriksson
>> <jak...@tu...> wrote:
>>
>>
>>> Hi hackers,
>>>
>>> For some experimental development I want to have the possibility to
>>> call
>>> an external tool during execution of a composition operator, i.e, to
>>> write something like this:
>>>
>>> exec("path-to-tool", param_1, ..., param_n);
>>>
>>> or perhaps even something more specific:
>>>
>>> USEMYTOOL WITH PARAMS param_1, ..., param_n;
>>>
>>> I can extend the composition language to allow such statements, but
>>> where can I treat the parameters and implement the actions to take on
>>> execution of such a statement?
>>>
>>> Can someone point me in the direction, or describe how to create some
>>> boiler-plate code that can later be augmented for the exact purpose of
>>> the execution of those statements?
>>>
>>> In short: I want a Java-method to interpret those statements, where
>>> does
>>> the code go?
>>>
>>> Thanks,
>>> Jakob
>>>
>>>
>>
>>
>>
>>
>
--
REWERSE WG I3 Assistant
Dresden - Technical University
Office: +49 (0) 351 463 38608
Mobile: +49 (0) 172 490 3086
|
|
From: Sven K. <s78...@in...> - 2007-09-12 09:04:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi!<br>
<br>
For me it would be intresting what kind of tool you want to be called
by your exec statement.<br>
<br>
I had allready something similar in mind - i wanted to allow the
invocation of the execution of complex composers in composition recipes
and additionally I wanted to establish the usage of the
Interpreterinterface as an alternative to the standard complex
composers, which would be very useful for very complex composers. But
for this we would need to clearly redefine the componentmodel.<br>
<br>
<blockquote>
<pre wrap="">>But, then it becomes interesting how one can extend the basiccl language
>into a specific composition language used for a specific DCS (dedicated
>composition system). For example, if I want a "callmytool" construct in
>the language in which I write composition operators for Modular Xcerpt,
>how do I extend the basiccl language into 'mybasiccl' so I only make
>modifications to this extension and not the core language (basiccl)?</pre>
</blockquote>
You would have to go the same way as with reuselanguages. Firstly you
create a new AS mybasiccl containing the abstract syntax of the exec
operator, then you define it as a minimalcl.CompositionStatement = ...
. Additionally you would have to somehow refer to basiccl to include
its features in the model of mybasiccl too (maby we need some import
statement in the AS language....). Im currently not sure how this could
be done, a simple redefinition might do it (for example try to include
"basiccl.Prune;" in the AS of mybasiccl).<br>
The concrete syntax would finally be defined like<br>
<br>
<blockquote>CONCRETESYNTAX mybc FOR mybasiccl EXTENDS bc<br>
<br>
minimalcl.CompositionProgram ::= "composition" "program"
statementList;<br>
minimalcl.ComposerDefinition ::= "define" "composer" construct "("
arguments ("," arguments)* ")" "{" statementList ("return"
returnFragment ";")? "}";<br>
<br>
ToolExcecution ::= "exec" "(" .....")" ";" ;<br>
<br>
</blockquote>
Now you should be able to use mybs instead of bc. (Maby something more
is needed to be programmed in the core...not sure)<br>
<br>
hopefully helped,<br>
Sven.<br>
<br>
PS: If you really think, the toolexecution is useful, you should
introduce it into bc ;).<br>
<br>
Jakob Henriksson schrieb:
<blockquote cite="mid...@st..."
type="cite">
<pre wrap="">Hi again,
It's not what it seems, I'm not talking to myself. Instead I talked to
Steffen offline who pointed me in the right direction. New interpreters
for the composition language can be added to
de.tudresden.reuseware.fracola and registered in the corresponding
plugin.xml file (but perhaps no-one should commit any drastic changes
without checking with the people involved first? Which I guess is Sven
now?) Anyway, I tried it on my local copy and it worked fine.
But, then it becomes interesting how one can extend the basiccl language
into a specific composition language used for a specific DCS (dedicated
composition system). For example, if I want a "callmytool" construct in
the language in which I write composition operators for Modular Xcerpt,
how do I extend the basiccl language into 'mybasiccl' so I only make
modifications to this extension and not the core language (basiccl)?
The search continues...
Jakob
On Tue, 11 Sep 2007 14:11:23 +0200, Jakob Henriksson
<a class="moz-txt-link-rfc2396E" href="mailto:jak...@tu..."><jak...@tu...></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi hackers,
For some experimental development I want to have the possibility to call
an external tool during execution of a composition operator, i.e, to
write something like this:
exec("path-to-tool", param_1, ..., param_n);
or perhaps even something more specific:
USEMYTOOL WITH PARAMS param_1, ..., param_n;
I can extend the composition language to allow such statements, but
where can I treat the parameters and implement the actions to take on
execution of such a statement?
Can someone point me in the direction, or describe how to create some
boiler-plate code that can later be augmented for the exact purpose of
the execution of those statements?
In short: I want a Java-method to interpret those statements, where does
the code go?
Thanks,
Jakob
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Steffen Z. <Ste...@tu...> - 2007-09-12 08:09:02
|
Hi,
I'm not sure, but wouldn't it be better to develop a new plugin with
only your new concepts instead of changing
de.tudresden.reuseware.fracola? And couldn't you, there, define a new
language using the grammar inheritance mechanisms of Reuseware?
Just guessing...
Steffen
Jakob Henriksson schrieb:
> Hi again,
>
> It's not what it seems, I'm not talking to myself. Instead I talked to
> Steffen offline who pointed me in the right direction. New interpreters
> for the composition language can be added to
> de.tudresden.reuseware.fracola and registered in the corresponding
> plugin.xml file (but perhaps no-one should commit any drastic changes
> without checking with the people involved first? Which I guess is Sven
> now?) Anyway, I tried it on my local copy and it worked fine.
>
> But, then it becomes interesting how one can extend the basiccl language
> into a specific composition language used for a specific DCS (dedicated
> composition system). For example, if I want a "callmytool" construct in
> the language in which I write composition operators for Modular Xcerpt,
> how do I extend the basiccl language into 'mybasiccl' so I only make
> modifications to this extension and not the core language (basiccl)?
>
> The search continues...
>
> Jakob
>
> On Tue, 11 Sep 2007 14:11:23 +0200, Jakob Henriksson
> <jak...@tu...> wrote:
>
>
>> Hi hackers,
>>
>> For some experimental development I want to have the possibility to call
>> an external tool during execution of a composition operator, i.e, to
>> write something like this:
>>
>> exec("path-to-tool", param_1, ..., param_n);
>>
>> or perhaps even something more specific:
>>
>> USEMYTOOL WITH PARAMS param_1, ..., param_n;
>>
>> I can extend the composition language to allow such statements, but
>> where can I treat the parameters and implement the actions to take on
>> execution of such a statement?
>>
>> Can someone point me in the direction, or describe how to create some
>> boiler-plate code that can later be augmented for the exact purpose of
>> the execution of those statements?
>>
>> In short: I want a Java-method to interpret those statements, where does
>> the code go?
>>
>> Thanks,
>> Jakob
>>
>>
>
>
>
>
--
Dr. rer. nat. Steffen Zschaler
Research Assistant
Technische Universität Dresden
Department of Computer Science
Phone +49 351 463 38555
Fax +49 351 463 38459
Email Ste...@tu...
WWW http://www.steffen-zschaler.de/
---
Also, consider coming to OCL4All, the OCL workshop at
MoDELS 2007:
http://st.inf.tu-dresden.de/Ocl4All2007
|
|
From: Jakob H. <jak...@tu...> - 2007-09-12 07:58:51
|
Hi again,
It's not what it seems, I'm not talking to myself. Instead I talked to
Steffen offline who pointed me in the right direction. New interpreters
for the composition language can be added to
de.tudresden.reuseware.fracola and registered in the corresponding
plugin.xml file (but perhaps no-one should commit any drastic changes
without checking with the people involved first? Which I guess is Sven
now?) Anyway, I tried it on my local copy and it worked fine.
But, then it becomes interesting how one can extend the basiccl language
into a specific composition language used for a specific DCS (dedicated
composition system). For example, if I want a "callmytool" construct in
the language in which I write composition operators for Modular Xcerpt,
how do I extend the basiccl language into 'mybasiccl' so I only make
modifications to this extension and not the core language (basiccl)?
The search continues...
Jakob
On Tue, 11 Sep 2007 14:11:23 +0200, Jakob Henriksson
<jak...@tu...> wrote:
> Hi hackers,
>
> For some experimental development I want to have the possibility to call
> an external tool during execution of a composition operator, i.e, to
> write something like this:
>
> exec("path-to-tool", param_1, ..., param_n);
>
> or perhaps even something more specific:
>
> USEMYTOOL WITH PARAMS param_1, ..., param_n;
>
> I can extend the composition language to allow such statements, but
> where can I treat the parameters and implement the actions to take on
> execution of such a statement?
>
> Can someone point me in the direction, or describe how to create some
> boiler-plate code that can later be augmented for the exact purpose of
> the execution of those statements?
>
> In short: I want a Java-method to interpret those statements, where does
> the code go?
>
> Thanks,
> Jakob
>
--
REWERSE WG I3 Assistant
Dresden - Technical University
Office: +49 (0) 351 463 38608
Mobile: +49 (0) 172 490 3086
|
|
From: Jakob H. <jak...@tu...> - 2007-09-11 12:12:03
|
Hi hackers,
For some experimental development I want to have the possibility to call
an external tool during execution of a composition operator, i.e, to write
something like this:
exec("path-to-tool", param_1, ..., param_n);
or perhaps even something more specific:
USEMYTOOL WITH PARAMS param_1, ..., param_n;
I can extend the composition language to allow such statements, but where
can I treat the parameters and implement the actions to take on execution
of such a statement?
Can someone point me in the direction, or describe how to create some
boiler-plate code that can later be augmented for the exact purpose of the
execution of those statements?
In short: I want a Java-method to interpret those statements, where does
the code go?
Thanks,
Jakob
--
REWERSE WG I3 Assistant
Dresden - Technical University
Office: +49 (0) 351 463 38608
Mobile: +49 (0) 172 490 3086
|
|
From: Jakob H. <jak...@tu...> - 2007-09-08 00:55:25
|
On Fri, 07 Sep 2007 23:38:44 +0200, Sven Karol =
<s78...@in...> wrote:
> Hello again!
>
> We could do something which compares attribute types of two fragment =
> types to determine if a cast is possible. And if the attributes are =
> compatible we could create a new fragment of the type to which we wan=
t =
> to cast having the same values as the old fragment. But this is in fac=
t =
> not casting, it is more like cloning or converting, since casting (in =
=
> the classical java sence) allways threats one object/fragment which =
> might be referenced by different variables/fragmentlists.
>
> >However, I'm guessing that this situation will appear in other =
> scenarios
> >in the future as well. So, the question is what we should do.
>
> It happend allready to me, but I thought the string concatenation was =
=
> the way to go because it was implemented and used in some examples.
Right, it works, which is nice for the moment. But in the long run it's =
=
not really desirable, since it is type unsafe.
Cheers,
Jakob
>
> Sven.
>
>
>
>
> Jakob Henriksson schrieb:
>> Hi,
>>
>> They might not be type compatible, I'm not really sure. What I'm sure=
=
>> about is that I want a solution which doesn't step outside the type =
>> system (which is currently the case). Maybe a solution for Modular =
>> Xcerpt is possible to find, by using different types from Xcerpt, no=
t =
>> to use componentmodel.Location etc. I don't know exactly in this ver=
y =
>> moment how it can be solved, but probably somehow.
>>
>> However, I'm guessing that this situation will appear in other =
>> scenarios in the future as well. So, the question is what we should =
do.
>>
>> Going back to the example. What I want to bind is a QuotedString (i.e=
. =
>> the slot). What I have is a Location. The value of a location is a =
>> string. If you define a QuotedString to be:
>>
>> QuotedString =3D "\"" value:S "\"";
>>
>> (or something to that effect), then the values of Location and =
>> QuotedString are really the same. Here, the '"'s are really just =
>> concrete syntax, aren't they? Somehow it seems that the values from =
=
>> the different types in this case can be cast to each other (it might=
=
>> not always be possible, but in this case it is, which is why we coul=
d =
>> successfully employ a cast).
>>
>> Anyway, discussion will hopefully continue.
>>
>> Please CC "Reuseware Developer" =
>> <reu...@li...> on all mailing discussion=
s =
>> so that everybody can follow the discussions and so that it will end=
=
>> up in the mailing list archives later on. It will be interesting to =
=
>> have. It also shows some activity to the outside world ;)
>>
>> Cheers,
>> Jakob
>>
>>
>> On Fri, 07 Sep 2007 17:37:20 +0200, Sven Karol =
>> <s78...@in...> wrote:
>>
>>
>>> Hi!
>>>
>>> I really dont know if a simple cast would be the right solution here=
, =
>>> since "componentmodel.Location" and "xcerpt.QuotedString" are not =
>>> type compatible (aren't they?). Because of that, you really need =
>>> that information about concrete syntax as it is used by the string=
=
>>> concatenation, so something like
>>>
>>> > bind moduleID on qtWrapper with =
>>> (xcerpt.QuotedString)'"'moduleID'"'.mxcerpt;
>>>
>>> is possible to be implemented. If we really want to have
>>>
>>> > bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;=
>>>
>>> reuseware would have to check all concrete Syntaxes registered as =
>>> parser/printer for "xcerpt.QuotedString" for prefixes and suffixes =
>>> ('"' and '"' in the case of mxcerpt) and do the string concatenatio=
n =
>>> internally. Of course this would work in some very special cases onl=
y =
>>> and has no clear semantics to the user. Additionally I currently do =
=
>>> not know if the concrete Syntax is accessible as far as one would =
>>> need for implementation of that feature, but I guess not.
>>>
>>>
>>> greetz,
>>> Sven.
>>>
>>
>>
>>
>> ---------------------------------------------------------------------=
----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browse=
r.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Reuseware-developer mailing list
>> Reu...@li...
>> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
>>
|
|
From: Sven K. <s78...@in...> - 2007-09-07 21:38:53
|
Hello again!
We could do something which compares attribute types of two fragment
types to determine if a cast is possible. And if the attributes are
compatible we could create a new fragment of the type to which we want
to cast having the same values as the old fragment. But this is in fact
not casting, it is more like cloning or converting, since casting (in
the classical java sence) allways threats one object/fragment which
might be referenced by different variables/fragmentlists.
>However, I'm guessing that this situation will appear in other scenarios
>in the future as well. So, the question is what we should do.
It happend allready to me, but I thought the string concatenation was
the way to go because it was implemented and used in some examples.
Sven.
Jakob Henriksson schrieb:
> Hi,
>
> They might not be type compatible, I'm not really sure. What I'm sure
> about is that I want a solution which doesn't step outside the type system
> (which is currently the case). Maybe a solution for Modular Xcerpt is
> possible to find, by using different types from Xcerpt, not to use
> componentmodel.Location etc. I don't know exactly in this very moment how
> it can be solved, but probably somehow.
>
> However, I'm guessing that this situation will appear in other scenarios
> in the future as well. So, the question is what we should do.
>
> Going back to the example. What I want to bind is a QuotedString (i.e. the
> slot). What I have is a Location. The value of a location is a string. If
> you define a QuotedString to be:
>
> QuotedString = "\"" value:S "\"";
>
> (or something to that effect), then the values of Location and
> QuotedString are really the same. Here, the '"'s are really just concrete
> syntax, aren't they? Somehow it seems that the values from the different
> types in this case can be cast to each other (it might not always be
> possible, but in this case it is, which is why we could successfully
> employ a cast).
>
> Anyway, discussion will hopefully continue.
>
> Please CC "Reuseware Developer"
> <reu...@li...> on all mailing discussions so
> that everybody can follow the discussions and so that it will end up in
> the mailing list archives later on. It will be interesting to have. It
> also shows some activity to the outside world ;)
>
> Cheers,
> Jakob
>
>
> On Fri, 07 Sep 2007 17:37:20 +0200, Sven Karol
> <s78...@in...> wrote:
>
>
>> Hi!
>>
>> I really dont know if a simple cast would be the right solution here,
>> since "componentmodel.Location" and "xcerpt.QuotedString" are not type
>> compatible (aren't they?). Because of that, you really need that
>> information about concrete syntax as it is used by the string
>> concatenation, so something like
>>
>> > bind moduleID on qtWrapper with
>> (xcerpt.QuotedString)'"'moduleID'"'.mxcerpt;
>>
>> is possible to be implemented. If we really want to have
>>
>> > bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;
>>
>> reuseware would have to check all concrete Syntaxes registered as
>> parser/printer for "xcerpt.QuotedString" for prefixes and suffixes ('"'
>> and '"' in the case of mxcerpt) and do the string concatenation
>> internally. Of course this would work in some very special cases only
>> and has no clear semantics to the user. Additionally I currently do not
>> know if the concrete Syntax is accessible as far as one would need for
>> implementation of that feature, but I guess not.
>>
>>
>> greetz,
>> Sven.
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Reuseware-developer mailing list
> Reu...@li...
> https://lists.sourceforge.net/lists/listinfo/reuseware-developer
>
|
|
From: Jakob H. <jak...@tu...> - 2007-09-07 19:20:19
|
Hi,
They might not be type compatible, I'm not really sure. What I'm sure =
about is that I want a solution which doesn't step outside the type syst=
em =
(which is currently the case). Maybe a solution for Modular Xcerpt is =
possible to find, by using different types from Xcerpt, not to use =
componentmodel.Location etc. I don't know exactly in this very moment ho=
w =
it can be solved, but probably somehow.
However, I'm guessing that this situation will appear in other scenarios=
=
in the future as well. So, the question is what we should do.
Going back to the example. What I want to bind is a QuotedString (i.e. t=
he =
slot). What I have is a Location. The value of a location is a string. I=
f =
you define a QuotedString to be:
QuotedString =3D "\"" value:S "\"";
(or something to that effect), then the values of Location and =
QuotedString are really the same. Here, the '"'s are really just concret=
e =
syntax, aren't they? Somehow it seems that the values from the different=
=
types in this case can be cast to each other (it might not always be =
possible, but in this case it is, which is why we could successfully =
employ a cast).
Anyway, discussion will hopefully continue.
Please CC "Reuseware Developer" =
<reu...@li...> on all mailing discussions s=
o =
that everybody can follow the discussions and so that it will end up in =
=
the mailing list archives later on. It will be interesting to have. It =
also shows some activity to the outside world ;)
Cheers,
Jakob
On Fri, 07 Sep 2007 17:37:20 +0200, Sven Karol =
<s78...@in...> wrote:
> Hi!
>
> I really dont know if a simple cast would be the right solution here, =
=
> since "componentmodel.Location" and "xcerpt.QuotedString" are not typ=
e =
> compatible (aren't they?). Because of that, you really need that =
> information about concrete syntax as it is used by the string =
> concatenation, so something like
>
> > bind moduleID on qtWrapper with =
> (xcerpt.QuotedString)'"'moduleID'"'.mxcerpt;
>
> is possible to be implemented. If we really want to have
>
> > bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;
>
> reuseware would have to check all concrete Syntaxes registered as =
> parser/printer for "xcerpt.QuotedString" for prefixes and suffixes ('"=
' =
> and '"' in the case of mxcerpt) and do the string concatenation =
> internally. Of course this would work in some very special cases only =
=
> and has no clear semantics to the user. Additionally I currently do no=
t =
> know if the concrete Syntax is accessible as far as one would need for=
=
> implementation of that feature, but I guess not.
>
>
> greetz,
> Sven.
|
|
From: Jakob H. <jak...@tu...> - 2007-09-07 14:29:01
|
Maybe the developer list is more appropriate for this... see below.
Cheers,
Jakob
------- Forwarded message -------
From: "Jakob Henriksson" <jak...@tu...>
To: "Reuseware Users" <reu...@li...>
Cc:
Subject: type casting in composition programs
Date: Fri, 07 Sep 2007 14:09:16 +0200
Hi,
One of the modular xcerpt composers currently look like this (slightly
modified from SVN version to show the point):
define composer modularxcerpt.QualifiedQueryTermComposer(moduleName,
queryTerm) {
// Resolve the fragment name into a location (URI, the module ID)
fragmentlist componentmodel.Location moduleID =3D ->moduleName;
// Use store: "out"
fragmentlist xcerpt.QueryTerm qtWrapper =3D
'store [ modul [ <<moduleID>> ], visibility [ "out" ], <<qTerm>>
]'.mxcerpt;
=
fragmentlist xcerpt.QuotedString quotedModuleID =3D '"' + moduleID
+ '"'.mxcerpt;
bind moduleID on qtWrapper with quotedModuleID;
=
// Bind intentional query term to store wrapper
bind qTerm on qtWrapper with queryTerm;
// Return store wrapper
return qtWrapper;
}
The QuotedString quotedModuleID is constructed with a "hack": untyped
string concatenation. I want to bind the slot 'moduleID' with the value =
of
the fragment moduleID (of type Location). Instead of Lines 10-11, removi=
ng
the "hack", I want to write:
bind moduleID on qtWrapper with (xcerpt.QuotedString)moduleID;
Thus casting the type of moduleID from Location to QuotedString (which i=
s
possible, since the value of the fragment can be represented both as a
Location and as a quoted string). Notice that the '"' of the quoted
strings are (should be) just concrete syntax, so they shouldn't be a
problem.
Is this a reasonable solution? Can we implement it? Is this relevant to
Sven's improvements of the composition language?
Let me know what you think.
Cheers,
Jakob
ps. is this the right forum for these kinds of issues? ds.
-- =
REWERSE WG I3 Assistant
Dresden - Technical University
Office: +49 (0) 351 463 38608
Mobile: +49 (0) 172 490 3086
|
|
From: Jendrik J. <jen...@tu...> - 2007-04-10 15:23:20
|
Hallo, ich habe euch alle auf der reuseware-devel Mailingliste eingetragen, welche dazu dienen soll interne Absprachen und Ankündigungen durchzuführen. Wenn jemand nicht auf der Liste seien möchte, bitte wieder austragen. :) Desweiteren kündige ich hiermit an, dass das zweiwöchige Treffen morgen wieder stattfindet, allerdings erst um 17 Uhr! Außerdem hat Jakob eine Wiki-Seite für die Treffen eingerichtet: ---- Dear all, I put up a Reuseware meetings page on the wiki: http://reuseware.sourceforge.net/index.php?title=Restricted:Reuseware_Meetings The idea was to have some sort of simple agenda proposal for every upcoming meeting there and perhaps also references to past meetings - as some sort of logging mechanism, at least for the agenda points. Of course, the meetings are quite flexible, but if you think of something between meetings that should be discussed, add it to the list and that way we will not forget it at the next meeting. So, if you want to bring something up at the next meeting, add it to the list and let's see how it works. Best regards, Jakob ---- Jendrik |
