Community
Participate
Working Groups
Using the latest drop, I launched a runtime environment and imported the example models. Two of the example models had errors for the models themselves, Demographic.. and Markets. Most of the other models had errors like the below: Description Resource Path Location Type heatCellProto cannot be resolved Heatbugs.java /org.eclipse.amp.amf.examples.escape/srcgen/org/eclipse/amp/examples/heatbugs line 384 Java Problem Of course, this is just more incentive to fix the code generation testing infrastructure. In terms of the changes themselves, we should talk about the generated code. I'd neglected to give good feedback and ideas before do perhaps this would be a good thread to discuss various overall unstated design goals/guidelines for the host environment. I've been up till know holding these in my own head so there is no way that they would have been know to anyone else. :) 1. We should avoid at almost all costs explicit dependencies on amp/escape API for the generated model. (e.g. org.eclipse.amp.escape.runtime.extension.IAgentChild). I know this is a bit counter-intuitive, even perverse, ;D but the reason is that Escape has a mandate to be an exemplar of an ABM target without any such dependencies and more practically, we want Escape and Ascape code to be able to co-exist without significant porting changes required between environments. Now, an objection is that we actually do have SWT and AMP (but *not* Escape, except for a couple of special cases) dependencies in the model, but those are all view dependencies without which we could not of course run the environment within Eclipse. 2. Going along with this, even though they are far from perfect, we should follow the overall Ascape "way of doing things" for the generated code. In other words, generated code should be ideally indistinguishable from hand-written code and we should have to resort to much code generation magic to accomplish high-level functionality. Instead, we should look to the Ascape patterns and adopt them. For: public void executeOnMembers() { int timeStep = getRunner().getPeriod(); startSimulationAgentChild(timeStep); ((HeatBug) heatBugScape.getPrototypeAgent()) .startSimulationAgentChild(timeStep); ((HeatCell) heatCellScape.getPrototypeAgent()) .startSimulationAgentChild(timeStep); super.executeOnMembers(); calculateTimeStep(timeStep); ((HeatBug) heatBugScape.getPrototypeAgent()) .calculateTimeStep(timeStep); ((HeatCell) heatCellScape.getPrototypeAgent()) .calculateTimeStep(timeStep); } /** * <!-- begin-user-doc --> * * <!-- end-user-doc --> * @generated */ public void startSimulationAgentChild(int timeStep) { if (timeStep == getRoot().getRunner().getEarliestPeriod()) { for (IAgentChild tmp : children) { tmp.startSimulation(timeStep); } } } Let's talk about what we're trying to accomplish here and how we could do it within Ascape paradigm. I realize that this adds an additional perhaps unwelcome constraint but I believe these are important design objectives. Now, in the bigger picture, I am not saying that it is inappropriate to generate code that makes use of what we can infer from the meta-model. We should be looking to do exactly that as it will support a very open ended environment without legacy entanglements from Ascape and a much lighter weight API. But that's I think more of a new effort. I hope this makes sense.
*** Bug 343788 has been marked as a duplicate of this bug. ***
*** Bug 343789 has been marked as a duplicate of this bug. ***
*** Bug 343790 has been marked as a duplicate of this bug. ***
*** Bug 343791 has been marked as a duplicate of this bug. ***
*** Bug 343792 has been marked as a duplicate of this bug. ***
I've tried to run builders in the example projects. I can reproduce the errors on the code snipped you've mentioned above. So here is what I've found out: 1. There is a new plugin we forgot to mention when refactoring earlier: org.eclipse.amp.escape.amf.ide3d It contains Escape 3D features. Buckminster should import this plugin automatically into the workspace. Could you add it to Buckminster materializer, please? 2. The ID of the 3D builder has changed! The reason is the new plugin I mentioned above. I'm changing this in the .project file of the example plugins so builders will run again. 3. In the example plugins you're referring to a builder called "org.eclipse.amp.escape.amf.ide.escapeBuilder2". This builder seems not to exist anymore. I've found "org.eclipse.amp.amf.gen.ide.baseBuilder". Is this a replacement for the first one? Is the Base Builder needed at all? 4. When running builders for the DemographicPrisioner_sDilemma example, I'm getting errors on the console. The Java compiler will report errors related to IAgentChild. But I think the code generator is the main problem that causes the Java compiler to report errors. So here's the stack trace from the console: ERROR: Ambiguous operations String expression(AInput input,List[AAct] path,Boolean inner) and String expression(AEvaluate eval,List[AAct] path,Boolean inner) for param types [Void, List[Object], Boolean] ERROR: Error in Component javaGenerator of type org.eclipse.xpand2.Generator: EvaluationException : Ambiguous operations String expression(AInput input,List[AAct] path,Boolean inner) and String expression(AEvaluate eval,List[AAct] path,Boolean inner) for param types [Void, List[Object], Boolean] metaabm::tmpl::Java.xpt[16569,34] on line 602 'agentCount.expression(path,inner)' metaabm::tmpl::Java.xpt[15212,42] on line 574 'EXPAND BeginBlock(path, inner) FOREACH exp' metaabm::tmpl::Java.xpt[15508,61] on line 580 'EXPAND SerialBlock(expansionSerial(path), path, inner, true)' metaabm::tmpl::Java.xpt[15768,41] on line 585 'EXPAND SerialBlock(newPath, inner, true)' metaabm::tmpl::Java.xpt[15311,48] on line 576 'EXPAND Block(path, inner, genNegate) FOREACH exp' metaabm::tmpl::Java.xpt[15508,61] on line 580 'EXPAND SerialBlock(expansionSerial(path), path, inner, true)' metaabm::tmpl::Java.xpt[15768,41] on line 585 'EXPAND SerialBlock(newPath, inner, true)' metaabm::tmpl::Java.xpt[15311,48] on line 576 'EXPAND Block(path, inner, genNegate) FOREACH exp' metaabm::tmpl::Java.xpt[15508,61] on line 580 'EXPAND SerialBlock(expansionSerial(path), path, inner, true)' metaabm::tmpl::Java.xpt[15768,41] on line 585 'EXPAND SerialBlock(newPath, inner, true)' metaabm::tmpl::Java.xpt[15311,48] on line 576 'EXPAND Block(path, inner, genNegate) FOREACH exp' metaabm::tmpl::Java.xpt[15508,61] on line 580 'EXPAND SerialBlock(expansionSerial(path), path, inner, true)' metaabm::tmpl::Java.xpt[15768,41] on line 585 'EXPAND SerialBlock(newPath, inner, true)' metaabm::tmpl::Java.xpt[15311,48] on line 576 'EXPAND Block(path, inner, genNegate) FOREACH exp' metaabm::tmpl::Java.xpt[15508,61] on line 580 'EXPAND SerialBlock(expansionSerial(path), path, inner, true)' metaabm::tmpl::Java.xpt[15768,41] on line 585 'EXPAND SerialBlock(newPath, inner, true)' metaabm::tmpl::Java.xpt[7401,29] on line 282 'EXPAND Block({}, false, true)' metaabm::tmpl::Java.xpt[5738,17] on line 226 'EXPAND ActionBody' metaabm::tmpl::Java.xpt[4974,17] on line 198 'EXPAND MethodImpl' metaabm::tmpl::Java.xpt[6463,13] on line 250 'EXPAND Method' metaabm::tmpl::Java.xpt[6005,47] on line 237 'EXPAND MethodPotential(within) FOREACH members' metaabm::tmpl::Java.xpt[6981,46] on line 270 'EXPAND MethodPotential(null) FOR rootActivity' metaabm::tmpl::Java.xpt[2938,14] on line 108 'EXPAND Methods' metaabm::tmpl::Java.xpt[3778,26] on line 146 'EXPAND ClassImplementation' metaabm::tmpl::Java.xpt[2482,12] on line 86 'EXPAND Class' metaabm::tmpl::Java.xpt[676,16] on line 31 'EXPAND ClassText' metaabm::escape::tmpl::EscapeAspect.xpt[2957,37] on line 77 'EXPAND metaabm::tmpl::Java::ClassFile' metaabm::tmpl::Java.xpt[394,12] on line 19 'EXPAND Files' metaabm::tmpl::Java.xpt[315,27] on line 15 'EXPAND Model FOREACH agents' [23,43] on line 1 'EXPAND metaabm::tmpl::Java::Model FOR model' This error does _not_ appear in a simple MetaABM model I've just put together. It seems to be related to some conditions that are true in the DemographicPrisioner_sDilemma example. Any ideas how to solve that error?
(In reply to comment #6) > 1. > There is a new plugin we forgot to mention when refactoring earlier: > org.eclipse.amp.escape.amf.ide3d > It contains Escape 3D features. Buckminster should import this plugin > automatically into the workspace. Could you add it to Buckminster materializer, > please? Done. Note that now that we have Buckminster properly setup there is no need to touch any of that. Instead, you simply have to add a dependency to that plugin into a feature! In this case I've put it into agf3d-feature, but we really will need to move it into its own amp.amf.agf3d feature as people may want to use agf3d without bringing in the AMF dependency. Note that this also means that we need a plain AGF3D Escape project feature.
(In reply to comment #6) > This error does _not_ appear in a simple MetaABM model I've just put together. > It seems to be related to some conditions that are true in the > DemographicPrisioner_sDilemma example. Any ideas how to solve that error? OK, as you very politely hinted, I get the credit for some of these. I had not thought about the case where ACreateAgent agentCount is null. You get credit for the ones where code is being generated for model components that don't exist. The errors are coming from the changes made to the model generation in 595befa72fea19199fd69f1f8ef560cfb71d6033. I've «REM» these out for now so that we can get a working build. The problem is in code like this: for (IAgentChild tmp : playCellProto.getChildren()) { tmp.addDataCollectors(this); } playCellProto doesn't exist because playCellProto is a cell member of a grid. This is a special case where modelers don't have to create an explicit agent for a cell. If one isn't supplied, it is assumed that we can use default. In this case you can also safely ignore the cell because it won't have any state of its own. But again there is the bigger issue of whether we really want to do things this way or can't we adopt existing Ascape mechanisms. For example, we have an entire data collection library for this sort of thing.
> 2. > The ID of the 3D builder has changed! The reason is the new plugin I mentioned > above. I'm changing this in the .project file of the example plugins so > builders will run again. OK, I'm concerned about backward compatibility for existing projects. It's not a huge deal, but if we are breaking existing projects we need to document that for people. > 3. > In the example plugins you're referring to a builder called > "org.eclipse.amp.escape.amf.ide.escapeBuilder2". This builder seems not to > exist anymore. I've found "org.eclipse.amp.amf.gen.ide.baseBuilder". Is this a > replacement for the first one? Is the Base Builder needed at all? All that does is create skeleton classes. I think it might be useful to keep around.
Currently I am working on the SD reintegration. And now all examples (org.eclipse.amp.amf.examples.escape) could be compiled without compile errors. Before I publish the patch I would like to create some test. Could someone tell me where the tests should be placed? Currently I have made changes (local copy) in the plugins org.eclipse.amp.amf.gen.ascape and org.eclipse.amp.amf.gen.escape
(In reply to comment #10) > Currently I am working on the SD reintegration. And now all examples > (org.eclipse.amp.amf.examples.escape) could be compiled without compile errors. > Before I publish the patch I would like to create some test. Could someone tell > me where the tests should be placed? Currently I have made changes (local copy) > in the plugins org.eclipse.amp.amf.gen.ascape and > org.eclipse.amp.amf.gen.escape Are these additional models to be built? We have gen..test projects already created; look in org.eclipse.amp.amf/tests. They're designed to be run in an a host plugin environment.
