You know, what we really need is just to do a telecon. I know we has one planned, but we should have one just to discuss these issues, I think. This week is quite full for me, but let me know if there is a good time to set that up?
On Jun 22, 2011, at 11:59 AM, Miles Parker wrote: On Jun 21, 2011, at 11:10 PM, Urs Frei wrote: Hi Miles,
I think there was a slight missunderstanding
concearning the IAgentChild issue. All we tried to accomplish here was
just to get all tests and all examples running.
Yes, that's what we intended. I just wasn't sure when it got it and want to make sure we follow up on it. I'm aware that you do not agree with
the design we've chosen to add SD codegen functionality. We definitely
need to talk about that again. I think I didn't quite get your point when
you last mentioned your concearns. I think it's quite challenging to talk
about design issues on e-mail basis.
True! The design we've chosen is a very global
one. But it's not the only way to go. It was just the one we've decided
to take. So we're very open for change requests. In our opinion, this design
is the base to get a common sense of what we're trying to accomplish.
A big problem is the fact, that a lot
of requirements exist neither as tests nor as developer documentation.
This makes it really hard (if not impossible) for us to add or change anything
in the AMP environment. In fact, this will make contributions of every
committer difficult. How would I know if I'm not breaking anything when
committing?
I can see your frustration very well. :) I also see that we're making progress on the testing, which is great. But of course even if we had perfect test coverage that wouldn't address higher level design issues.
But one thing I should point out is that the high-level design approach for Ascape is pretty well described, both in papers and documentation. See e.g.:
And in Javadoc (though some of this may be a bit out-of-date):
The semantics of rule execution and agent structural hierarchy in particular are well defined.
Now...I am *not* saying that this is the best way to do things, only that it is one way that has worked at least for the particular target domain. Now that we are bringing SD in to the picture we will want to modify that or even throw it out altogether, but I think that the Acape frame -- with Escape as a simple exemplar extension -- gives us a relatively simple place to start. In fact, I know that there are things that are wrong with Ascape API, for example Agents have to explicitly extend a subclass and it would be better if they could implement an interface.
So..the reason that the IAgentChild thing is hard for me to understand the need for is that Ascape already has support for Agent hierarchies, as does MetaABM/Acore. We also have semantics for starting a simulation and so on. So I think I just need help understanding why those existing mechanisms can't be reused. It feels like I'm missing some essential point here. I'll also take a look at the new example models ... perhaps that will make it clear.
But no matter what we do, we don't want want to break the existing Ascape API codegen. If we need to we can just break that apart further. But right now, Scape.xpt is used for both the Escape and Ascape targets so even if we decide that it makes sense to change Escape, we Probably want to keep Ascape backward compatible.
Another completely reasonable option is to just declare the existing codegen mature and being discussing an entirely fresh approach to all of this, using Eclipse idioms such as providers, etc.. I am completely open to that, and in fact that's what the ICompositionProvider and other features are designed to support.
Getting back to the Ascape issue...
What is it exactly that doesn't run with Ascape? How does Ascape reference
outside classes? And what exaclty are the "outside" classes?
It was not our intension to change Ascape models at all. SD is supposed
to end only in Escape models. Which test can I run to see if my future
changes will fix the problem?
The Ascape generated code now imports IAgentChild, requiring a dependency on the o.e.a namespace that didn't exist before.
The git repo shows the same log as my
local repo. When pushing my changes to git yesterday, nothing got changed
in the log. So what git is telling you is correct. :-)
Good news. :)
cheers,
Miles
Cheers,
Jonas & Urs
Von:
Miles Parker <milesparker@xxxxxxxxx>
An:
AMP developer mailing
list <amp-dev@xxxxxxxxxxx>
Datum:
22.06.2011 02:57
Betreff:
Re: [amp-dev]
IAgentChild
Gesendet von:
amp-dev-bounces@xxxxxxxxxxx
I looked a little closer at this, and it seems that the changes did not
get into the Indigo build...I was actually going against a slightly newer
version. Weird. :)
On Jun 21, 2011, at 5:53 PM, Miles Parker wrote:
>
> Hi guys,
>
> The good news is that it looks like some of the important SD stuff
got back into the final build, though technically we shouldn't have been
making any changes. :) The bad news is that we ended up with a regression.
See below.
>
> I'm a little worried that some stuff might have gotten written over
in the process but I haven't looked carefully through everything. I'm honestly
completely confused about when changes happened and what got into the build.
:) I'm not sure what we decided to do with the whole IAgentChild thing.
I guess perhaps get things working and then revisit. On balance, it is
probably better to have the SD stuff working than to worry about having
the "perfect" codegen for Escape. That's sort of the point of
codegen. The problem though with the below is that it breaks the Ascape
models since the definitely can't reference outside classes. Can we put
the change back in so that this only affects the Escape generation? This
won't work for Indigo but we can have a fix in the update site. Do you
know when you put that back in and then when it was merged back and pushed
to the main repos? I'm not trusting what git is telling me anymore.
>
> More generally, now that we're though the Indigo crunch, let's get
back to the issue of how we can get the functionality below using the existing
Ascape API as much as possible. Let's follow up on the relevant bug(s).
>
> http://git.eclipse.org/c/amp/org.eclipse.amp.git/commit/org.eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.escape/src/metaabm/escape/tmpl/EscapeAspect.xpt?id=a50c6901bc1abb1f1b5276b76af4af56ba0e527b
>
> Unfortunatly,
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
______________________________ Miles T. Parker President and Chief Software Architect Metascape, LLC Project Lead Eclipse Agent Modeling Project
tel: 509-643-4441 skype: milestravisparker ______________________________
|
