The adapted code I used looks like this:
------------------------------------------------------------------------------------------
import org.nlogo.app.App;
public class OtherFile {
public static void main(String[] argv) {
App.main(argv);
try {
java.awt.EventQueue.invokeAndWait(
new Runnable() {
public void run() {
try {
App.app().open(
"C:/{...}/Exercise1.nlogo"); //{...} is where I added the path to the
model, (which is in the same folder as the project root)
}
catch(java.io.IOException ex) {
ex.printStackTrace();
}}});
App.app().command("set N 62");
App.app().command("random-seed 0");
App.app().command("setup");
App.app().command("repeat 50 [ go ]");
System.out.println(
App.app().report("count turtles"));
}
catch(Exception ex) {
ex.printStackTrace();
}
}
}
-----------------------------------------------------------------------------
I adapted some commands to use the variables of the other model.
For compiling and running the model, I used DrJava, by creating a project
to set the working directory to be the Netlogo directory.
Also Netlogo.jar is added to the classpath. The settings and the model can
be seen in the attachment.For me, the alternative model will only run if I disable the Bytecode generator in the JVM, while the fire example will run just fine, even if I place the fire model inside the alternative location. So, anything else done differently could be the commands, but they seem to be recognised by the program when running with the disabled bytecode generator. Thank you for your attention and I hope this clears up the setup of my code sufficiently. Thomas Op woensdag 15 mei 2019 18:49:20 UTC+2 schreef Seth Tisue: > > On Wed, May 15, 2019 at 1:41 AM Thomas Pelgrim <tho...@thepelgrims.nl > <javascript:>> wrote: > >> Thank you for the quick response. After testing both options it seems >> disabling the bytecode generator made it work! >> Do you happen to know why this makes it work? >> > > Well, I have to begin by saying that it doesn't seem plausible to me, in > your description of your experience with this, the *only* difference is > whether you used Fire.nlogo or your own model, and nothing else was > different between the success scenario and the failure scenario. I would > have to be able to reproduce that myself on my own computer to accept that. > > In general, the bytecode generator is sensitive to what classloader > environment it's being run in. (For example, see the discussion at > https://github.com/NetLogo/NetLogo/issues/1516#issuecomment-344997187.) That > shouldn't matter if you're just doing the basic example given in the > Controlling API docs. You're not doing *anything* else different...? > > Seth > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/netlogo-devel/94234508-bbac-4b9a-a0fc-49fdeae158ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Exercise1.nlogo
Description: Binary data
