netlogo / netlogo Goto Github PK
View Code? Open in Web Editor NEWturtles, patches, and links for kids, teachers, and scientists
Home Page: http://ccl.northwestern.edu/netlogo/
turtles, patches, and links for kids, teachers, and scientists
Home Page: http://ccl.northwestern.edu/netlogo/
e.g. this line:
"" " set-plot-x-range min [fitness] of individuals - 20 max [fitness] of individuals + 20"
won't load because of the space before set-plot-x-range
:
Caused by: java.lang.RuntimeException: Plot 'fitness histogram' contains invalid setup and/or update code: "" " set-plot-x-range min [fitness] of individuals - 20 max [fitness] of individuals + 20"
at scala.sys.package$.error(package.scala:27)
at org.nlogo.plot.PlotLoader$.parsePlot(PlotLoader.scala:32)
at org.nlogo.window.AbstractPlotWidget.load(AbstractPlotWidget.scala:255)
the mode of failure is different is you begin pen update code (instead of plot update code) with a space; there is no exception, but the code doesn't load and is lost.
Under window managers which do not reparent root windows, such as DWM, there will be various menu and window drawing issues. Windows may appear blank, and menus may pop-up and disappear.
Users wanting to work around these issues should refer to the solutions suggested at http://awesome.naquadah.org/wiki/Problems_with_Java
the problem line is:
cd "`dirname "$0"`"
it's there to ensure that when NetLogo starts, the NetLogo installation directory is the current working directory, since the app expects that. but if there's a symlink to the script, $0
points to the symlink, rather than to the target, so we end up in the wrong directory
reported by Fred Drueck
because this happens:
cd "`dirname "$0"`
before the line that starts NetLogo runs, any relative pathnames passed on the command line will no longer point to the right place
it's not clear to me if this is even fixable as long as the app expects that the NetLogo directory must be the current working directory when NetLogo starts
reported by Fred Drueck
run Trails Example 3D to see the problem. the line segments in the trail are oriented incorrectly
the regression happened between 5.0beta4 and 5.0RC1
add extensions [profiler]
to the Code tab then type profiler:start
in the command center.
or add this to headless/TestCompiler.Scala
:
test("isReporter on extension prims") {
workspace.initForTesting(-5, 5, -5, 5, "extensions [profiler]")
expect(false) { workspace.isReporter("profiler:start") }
expect(true) { workspace.isReporter("profiler:report") }
}
it fails.
compare e.g. Crystallization Basic in 4.1 versus 5.0
reported by Christopher Watts
these tests (if added to test/commands/Stop.txt
) fail.
StopFromForeach2
to test foreach [1 2 3] [ if ? = 2 [ stop ] set glob1 glob1 + ? ] end
O> test
glob1 => 1
StopFromForeach3
to test1 test2 test2 end
to test2 foreach [1 2 3 4 5] [ set glob1 glob1 + ? stop ] end
O> test1
glob1 => 2
reported by Onno Steenbergen
Kevin Zollman supplied the example System Dynamics Modeler diagram below.
in the GUI, this is read in by JHotDraw, which handles it correctly. but we can't use JHotDraw from org.nlogo.headless, so we rolled our own code in sdm.AggregateManagerLite
to read SDM diagrams, and that code fails on this case.
NetLogo 4.1 has the same issue.
0.01
org.nlogo.sdm.gui.AggregateDrawing 9
org.nlogo.sdm.gui.ConverterFigure "attributes" "attributes" 1 "FillColor" "Color" 130 188 183 242 296 50 50
org.nlogo.sdm.gui.WrappedConverter "type-1 + ( type-2 * 3)" "type-1-fitness"
org.nlogo.sdm.gui.ConverterFigure "attributes" "attributes" 1 "FillColor" "Color" 130 188 183 369 293 50 50
org.nlogo.sdm.gui.WrappedConverter "type-2 * 2" "type-2-fitness"
org.nlogo.sdm.gui.StockFigure "attributes" "attributes" 1 "FillColor" "Color" 225 225 182 177 107 60 40
org.nlogo.sdm.gui.WrappedStock "type-1" "0.01" 0
org.nlogo.sdm.gui.StockFigure "attributes" "attributes" 1 "FillColor" "Color" 225 225 182 479 108 60 40
org.nlogo.sdm.gui.WrappedStock "type-2" "0.99" 0
org.nlogo.sdm.gui.ConverterFigure "attributes" "attributes" 1 "FillColor" "Color" 130 188 183 501 286 50 50
org.nlogo.sdm.gui.WrappedConverter "(type-1 * type-1-fitness) + (type-2 * type-2-fitness)" "ave-fitness"
org.nlogo.sdm.gui.ReservoirFigure "attributes" "attributes" 1 "FillColor" "Color" 192 192 192 103 101 30 30
org.nlogo.sdm.gui.RateConnection 3 133 117 149 119 165 121 NULL NULL 0 0 0
org.jhotdraw.figures.ChopEllipseConnector REF 11
org.jhotdraw.standard.ChopBoxConnector REF 5
org.nlogo.sdm.gui.WrappedRate "type-1 * (type-1-fitness - ave-fitness)" "t1-replicator"
org.nlogo.sdm.gui.WrappedReservoir REF 6 0
org.nlogo.sdm.gui.ReservoirFigure "attributes" "attributes" 1 "FillColor" "Color" 192 192 192 396 110 30 30
org.nlogo.sdm.gui.RateConnection 3 426 125 446 125 467 126 NULL NULL 0 0 0
org.jhotdraw.figures.ChopEllipseConnector REF 17
org.jhotdraw.standard.ChopBoxConnector REF 7
org.nlogo.sdm.gui.WrappedRate "type-2 * (type-2-fitness - ave-fitness)" "t2-replicator"
org.nlogo.sdm.gui.WrappedReservoir REF 8 0
in the generated code, in system-dynamics-go
in the GUI we see:
let new-type-1 ( type-1 + local-t1-replicator )
let new-type-2 ( type-2 + local-t2-replicator )
but from headless (adding println(source)
to AggregateManagerLite.load
and running headless.Main
with run --model /Users/tisue/Desktop/PD-replicator.nlogo --experiment experiment
) we see:
let new-type-1 ( type-1 + local-t1-replicator )
let new-type-2 ( type-2 )
promoted:
Francisco J. Miguel Quesada reports that this was working before in 5.0beta2 on Windows, but had stopped working by 5.0RC2.
for now we worked around this for ABMPLUS by using a special build that doesn't have rich info tabs, but obviously that's no good
We have discovered a problem on at least some versions of Linux where the exp
primitive sometimes returns a slightly different answer (differing only in the last decimal place) for the same input. According to an engineer at Sun, this should only happen on Linux kernel versions 2.4.19 and earlier, but we have observed the problem on more recent kernel versions. We imagine the problem is Linux-specific and does not happen on other Unix-based systems. We are not sure if the problem ever occurs in practice during actual NetLogo model runs, or only occurs in the context of our automated test regimen. The bug is in Sun's Java VM, and not in NetLogo itself. We hope that only the exp
is affected, but we can't be entirely sure.
Users are encouraged to visit http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5023712 (free registration required) and vote for Sun to fix this bug.
if the old model was generating output, the last part of the output can end up appearing in the new model
the easiest way to see it happen is enter loop [ print timer ]
in the Command Center and then do File —> New Model
so e.g. if you enter gjfgkjfhgkj
, isReporter thinks it's a reporter (TYPE_IDENT
) and adds show
, and the offsets are wrong when it tries to highlight the offending token
WORKAROUND: Corey Brady discovered that you can re-enable the menus by opening a modal dialog and then closing it again. For example, a quick way is to press Command-M to open the Models Library dialog with Command-M, then press Esc key to dismiss it.
the keyboard shortcuts for the grayed out menu items still work, so it's clearly Apple's bug. though it would be good if we could find some kind of workaround to put in the code so users don't have to use the workaround above
a user reports that Mac OS X 10.5 works fine. it's broken on 10.6 and 10.7
both NetLogo 3D 4 and 5 are affected
you can start up NetLogo OK, but then when you try to open almost any model it blows up with e.g.
java.util.MissingResourceException: Can't find bundle for base name Errors, locale ru_RU
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1427)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1250)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:777)
at org.nlogo.api.I18N$BundleKind.getBundle(I18N.scala:60)
at org.nlogo.api.I18N$BundleKind.<init>(I18N.scala:58)
at org.nlogo.api.I18N$.errors(I18N.scala:94)
at org.nlogo.compiler.SetVisitor.<init>(SetVisitor.scala:18)
the problem is also reproducible simply by running test-fast
in sbt with the system language set to Russian
making ticket in this repo so it gets included in the main change list
...making it no longer fullscreen
steps to reproduce:
although NetLogo remains in fullscreen mode, the window doesn't actually fill the screen anymore
reported by Nathan Holbert
this should give a nice error message instead:
% make goshell
NetLogo 5.0RC4 (November 4, 2011)
print task [?0]
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at scala.collection.mutable.ResizableArray$class.apply(ResizableArray.scala:45)
at scala.collection.mutable.ArrayBuffer.apply(ArrayBuffer.scala:44)
at org.nlogo.prim._reportertask.getFormal(_reportertask.scala:25)
at org.nlogo.compiler.TaskVisitor.visitReporterApp(TaskVisitor.scala:33)
at org.nlogo.compiler.ReporterApp.accept(AstNode.scala:168)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitReporterApp$1.apply(AstVisitor.scala:27)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitReporterApp$1.apply(AstVisitor.scala:27)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:44)
at scala.collection.TraversableProxyLike$class.foreach(TraversableProxyLike.scala:28)
at org.nlogo.compiler.ReporterApp.foreach(AstNode.scala:158)
at org.nlogo.compiler.DefaultAstVisitor.visitReporterApp(AstVisitor.scala:27)
at org.nlogo.compiler.TaskVisitor.visitReporterApp(TaskVisitor.scala:22)
at org.nlogo.compiler.ReporterApp.accept(AstNode.scala:168)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitReporterApp$1.apply(AstVisitor.scala:27)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitReporterApp$1.apply(AstVisitor.scala:27)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:44)
at scala.collection.TraversableProxyLike$class.foreach(TraversableProxyLike.scala:28)
at org.nlogo.compiler.ReporterApp.foreach(AstNode.scala:158)
at org.nlogo.compiler.DefaultAstVisitor.visitReporterApp(AstVisitor.scala:27)
at org.nlogo.compiler.TaskVisitor.visitReporterApp(TaskVisitor.scala:38)
at org.nlogo.compiler.ReporterApp.accept(AstNode.scala:168)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitStatement$1.apply(AstVisitor.scala:29)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitStatement$1.apply(AstVisitor.scala:29)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:44)
at scala.collection.TraversableProxyLike$class.foreach(TraversableProxyLike.scala:28)
at org.nlogo.compiler.Statement.foreach(AstNode.scala:99)
at org.nlogo.compiler.DefaultAstVisitor.visitStatement(AstVisitor.scala:29)
at org.nlogo.compiler.Statement.accept(AstNode.scala:106)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitStatements$1.apply(AstVisitor.scala:30)
at org.nlogo.compiler.DefaultAstVisitor$$anonfun$visitStatements$1.apply(AstVisitor.scala:30)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:44)
at scala.collection.TraversableProxyLike$class.foreach(TraversableProxyLike.scala:28)
at org.nlogo.compiler.Statements.foreach(AstNode.scala:75)
at org.nlogo.compiler.DefaultAstVisitor.visitStatements(AstVisitor.scala:30)
at org.nlogo.compiler.Statements.accept(AstNode.scala:92)
at org.nlogo.compiler.DefaultAstVisitor.visitProcedureDefinition(AstVisitor.scala:25)
at org.nlogo.compiler.TaskVisitor.visitProcedureDefinition(TaskVisitor.scala:15)
at org.nlogo.compiler.ProcedureDefinition.accept(AstNode.scala:66)
at org.nlogo.compiler.CompilerMain$$anonfun$compile$2.apply(CompilerMain.scala:43)
at org.nlogo.compiler.CompilerMain$$anonfun$compile$2.apply(CompilerMain.scala:39)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:60)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:44)
at org.nlogo.compiler.CompilerMain$.compile(CompilerMain.scala:39)
at org.nlogo.compiler.Compiler$.compileMoreCode(Compiler.scala:35)
The chances are of this ever getting fixed are low. The specification and implementation difficulties are too great.
If a change were to be made, it would probably be in the direction of giving run on strings less access to local context, not more.
Disallowing access to the local lexical environment would be in line with how eval
behaves in other Lisp dialects:
eval
] is evaluated in the current dynamic environment and a null lexical environment" (CLtL2 20.1)eval
requires an explicit environment argument and there is no standard provision for reifying the local lexical environment. (see R5RS 6.5 for details)(included in docs/issues.html)
add this to TestImportExport.scala:
@Test def testImportingArrayInsideArray() {
val filename = getUniqueFilename
new java.io.File( filename ).delete()
workspace.initForTesting(5, "globals [ar1] extensions [ array ]" )
testCommand( "set ar1 array:from-list (list array:from-list [5])" )
testCommand( "export-world \"" + filename + "\"" )
testCommand( "ca" )
testCommand( "import-world \"" + filename + "\"" )
testReporter( "array:to-list array:item ar1 0", "[5]")
}
result is:
got a nonfatal error Warning: Error importing arrays: Error Importing at Line 176: Expected breed
Action to be Taken: This array will be ignored
There was 1 failure:
1) testImportingArrayInsideArray(org.nlogo.headless.TestImportExport)
org.nlogo.nvm.EngineException: Extension exception: 0 is not a valid index into an array of length 0
the original exception is:
Expected breed at position 4 in
at org.nlogo.compiler.CompilerExceptionThrowers$.exception(CompilerExceptionThrowers.scala:12)
at org.nlogo.compiler.CompilerExceptionThrowers$.cAssert(CompilerExceptionThrowers.scala:6)
at org.nlogo.compiler.ConstantParser.parseConstantAgentOrAgentSet(ConstantParser.scala:206)
at org.nlogo.compiler.ConstantParser.readConstantPrefix(ConstantParser.scala:99)
at org.nlogo.compiler.ConstantParser.parseConstantList(ConstantParser.scala:127)
at org.nlogo.compiler.ConstantParser.readConstantPrefix(ConstantParser.scala:97)
at org.nlogo.compiler.ConstantParser.getConstantValue(ConstantParser.scala:64)
at org.nlogo.compiler.Compiler$.readFromString(Compiler.scala:79)
at org.nlogo.workspace.Evaluator.readFromString(Evaluator.java:290)
at org.nlogo.workspace.AbstractWorkspace.readFromString(AbstractWorkspace.java:867)
at org.nlogo.workspace.ExtensionManager.readFromString(ExtensionManager.java:527)
at org.nlogo.extensions.array.ArrayExtension.readExtensionObject(ArrayExtension.java:184)
at org.nlogo.workspace.ExtensionManager.readExtensionObject(ExtensionManager.java:560)
at org.nlogo.compiler.ConstantParser.parseConstantLiteral(ConstantParser.scala:138)
at org.nlogo.compiler.ConstantParser.readConstantPrefix(ConstantParser.scala:93)
at org.nlogo.compiler.ConstantParser.getConstantValue(ConstantParser.scala:64)
at org.nlogo.compiler.Compiler$.readFromString(Compiler.scala:79)
at org.nlogo.workspace.Evaluator.readFromString(Evaluator.java:290)
at org.nlogo.workspace.AbstractWorkspace.readFromString(AbstractWorkspace.java:867)
at org.nlogo.workspace.ExtensionManager.readFromString(ExtensionManager.java:527)
at org.nlogo.extensions.array.ArrayExtension.importWorld(ArrayExtension.java:151)
at org.nlogo.workspace.ExtensionManager.importExtensionData(ExtensionManager.java:833)
at org.nlogo.workspace.AbstractWorkspace.importExtensionData(AbstractWorkspace.java:111)
at org.nlogo.agent.Importer.importExtensionData(Importer.java:471)
at org.nlogo.agent.Importer.importWorld(Importer.java:177)
at org.nlogo.agent.World.importWorld(World.java:193)
at org.nlogo.workspace.AbstractWorkspace$4.doImport(AbstractWorkspace.java:650)
at org.nlogo.workspace.AbstractWorkspace.doImport(AbstractWorkspace.java:713)
at org.nlogo.workspace.AbstractWorkspace.importWorld(AbstractWorkspace.java:643)
at org.nlogo.prim.etc._importworld$1.run(_importworld.java:28)
at org.nlogo.headless.HeadlessWorkspace.waitFor(HeadlessWorkspace.java:162)
at org.nlogo.prim.etc._importworld.perform(_importworld.java:23)
at org.nlogo.nvm.Context.stepConcurrent(Context.java:95)
at org.nlogo.nvm.ConcurrentJob.step(ConcurrentJob.java:95)
at org.nlogo.job.JobThread.runPrimaryJobs(JobThread.java:194)
at org.nlogo.job.JobThread.run(JobThread.java:117)
exported world has:
"EXTENSIONS"
"array"
"{{array: 0: 5}}"
"{{array: 1: {{array: 0}}}}"
https://github.com/sirthias/pegdown/blob/master/CHANGELOG shows 1.1.0 has been out for a few weeks now
If NetLogo is not already running, then the model may or may not open; the bug is intermittent. (If NetLogo is already running, the model always opens.)
This bug has been a problem for many years now.
As file-close
doesn't throw errors if you try to close file that isn't open, an easy workaround is to use file-close
before code like this:
; Delete a file if exists
if [file-exists filename][
file-delete filename
]
Although the workaround exists, it would still really be better if the system closed all open files when a runtime error (unhandled by carefully
) occurs.
reported by Onno Steenbergen
both TreeAgentSet and ArrayAgentSet are affected
I made a benchmark to measure it, models/test/other/One-Of Turtles Benchmark.nlogo
TreeAgentSet and ArrayAgentSet are different problems.
in the TreeAgentSet case, we know the sets contain no dead agents. we could go straight to a random agent in O(log n) time if we were using a tree that knew the size of it's subtrees. e.g. starting at root if we have 10 agents on the left and 7 on the right, we have a 1 in 18 chance to stop, a 10 in 18 to go left, and a 7 in 18 to go right. but java's TreeMap.Entry doesn't store this information.
in the ArrayAgentSet case, the array may contain dead agents. we could pick randomly and if we hit a dead agent pick again, but then the worst-case runtime is unbounded. can we be cleverer? we can't pick a random location and scan forward for the next live turtle, because that would favor live turtles that follow clusters of dead ones.
steps to reproduce:
bug is reproducible in 5.0RC1 and 5.0RC6, but not 5.0beta1
the bug still happens if you resave the model in 5.0RC6 first
the bug doesn't happen until after reset-ticks
has run. (you can test this by renaming startup
so it doesn't run automatically, then running the commands in the body manually, testing for the bug after each one)
I was unable to reproduce the bug with two other HubNet models (Gridlock, Tragedy of the Commons.)
reported by Corey Brady
the following error details seem to indicate that temporary plot pens are the culprit ("run 1" is the name of a temporary pen)
java.util.NoSuchElementException: key not found: PlotPen(run 1, Plot(Number Sick))
at scala.collection.MapLike$class.default(MapLike.scala:224)
at scala.collection.JavaConversions$JMapWrapper.default(JavaConversions.scala:792)
at scala.collection.MapLike$class.apply(MapLike.scala:135)
at scala.collection.JavaConversions$JMapWrapper.apply(JavaConversions.scala:792)
at org.nlogo.plot.PlotManager.getPenSetupError(PlotManager.scala:179)
at org.nlogo.plot.PlotManager.hasErrors(PlotManager.scala:177)
at org.nlogo.plot.PlotManager$$anonfun$hasErrors$1.apply(PlotManager.scala:172)
at org.nlogo.plot.PlotManager$$anonfun$hasErrors$1.apply(PlotManager.scala:172)
at scala.collection.LinearSeqOptimized$class.exists(LinearSeqOptimized.scala:79)
at scala.collection.immutable.List.exists(List.scala:45)
at org.nlogo.plot.PlotManager.hasErrors(PlotManager.scala:172)
at org.nlogo.window.AbstractPlotWidget.anyErrors(AbstractPlotWidget.scala:287)
at org.nlogo.window.AbstractPlotWidget.recolor(AbstractPlotWidget.scala:269)
at org.nlogo.window.AbstractPlotWidget.handle(AbstractPlotWidget.scala:282)
at org.nlogo.window.Events$CompiledEvent.beHandledBy(Events.java:213)
at org.nlogo.window.Event.doRaise(Event.java:198)
at org.nlogo.window.Event.raise(Event.java:122)
at org.nlogo.window.CompilerManager.compileProcedures(CompilerManager.java:124)
at org.nlogo.window.CompilerManager.compileAll(CompilerManager.java:88)
at org.nlogo.window.CompilerManager.handle(CompilerManager.java:310)
at org.nlogo.window.Events$CompileAllEvent.beHandledBy(Events.java:175)
at org.nlogo.window.Event.doRaise(Event.java:198)
at org.nlogo.window.Event.raise(Event.java:122)
at org.nlogo.app.ProceduresTab.recompile(ProceduresTab.scala:125)
at org.nlogo.app.ProceduresTab.handle(ProceduresTab.scala:103)
at org.nlogo.app.Events$SwitchedTabsEvent.beHandledBy(Events.java:42)
it worked in 5.0beta3:
it's broken in 5.0beta5 and all of the release candidates:
the error is an AccessControlException in org.nlogo.api.RemoteFile.getAbsolutePath(RemoteFile.scala:72)
: http://cl.ly/3D1F100G3z160m3Q1H1u
thanks to Jim Westervelt for discovering and reporting this
amackenzieus writes:
I'm in the midst of some changes to my linear programming
solver extension, and it was brought to my attention that
there were some issues when using the extension in a model
with behaviorspace, specifically when spread across
multiple processors.Since the extension makes a call to a native library (.dll), the
initial thread's classloader already has the .dll loaded.
As I understand it, only a single classloader can have a
native library open and be calling to it.Is there a potential to identify the specific classloader
that's calling the native library and then utilize that
classloader to make multiple calls to the library, or
does the architecture behind behaviorspace make
that impossible?
I'm not sure yet if it will be fixable by changing the code in the extension, or if we'll need to make some change to NetLogo in a 5.0.x release
that line in the file ends up blank, so the model loader thinks it marks the end of the GRAPHICS-WINDOW section
reported by Jim Lyons
with my system language set to Russian on Mac OS X, I get:
> test-fast
[info] == org.nlogo.plot.PlotPenTests ==
[info] PlotPenTests:
[info] - PlotModeConstants *** FAILED *** (28 milliseconds)
[info] Expected "[Line]", but got "[Линия]" (PlotPenTests.scala:8)
[info]
[info] == org.nlogo.window.UpdateManagerTests ==
[info] UpdateManagerTests:
[info] - tick-based: default speed *** FAILED *** (36 milliseconds)
[info] "...0, frameRateGap = 30[,00 fps, nanoGap = Infinity fps, slowdown = 0,0 ms, every 1,]000 ticks" did not equal "...0, frameRateGap = 30[.00 fps, nanoGap = Infinity fps, slowdown = 0.0 ms, every 1.]000 ticks" (UpdateManagerTests.scala:28)
[info] - tick-based: max speed *** FAILED *** (1 millisecond)
[info] "...rameRateGap = 498256[,10 fps, nanoGap = 0,33 fps, slowdown = 0,0 ms, every 1000026,]000 ticks" did not equal "...rameRateGap = 498256[.10 fps, nanoGap = 0.33 fps, slowdown = 0.0 ms, every 1000026.]000 ticks" (UpdateManagerTests.scala:32)
[info] - tick-based: min speed *** FAILED *** (1 millisecond)
[info] "...50, frameRateGap = 0[,15 fps, nanoGap = Infinity fps, slowdown = 9000,0 ms, every 0,]010 ticks" did not equal "...50, frameRateGap = 0[.15 fps, nanoGap = Infinity fps, slowdown = 9000.0 ms, every 0.]010 ticks" (UpdateManagerTests.scala:36)
[info] - tick-based: all speeds *** FAILED *** (25 milliseconds)
[info] "...50, frameRateGap = 0[,15 fps, nanoGap = Infinity fps, slowdown = 9000,0 ms, every 0,010 ticks
[info] speed = -49, frameRateGap = 0,17 fps, nanoGap = Infinity fps, slowdown = 7501,0 ms, every 0,011 ticks
[info] speed = -48, frameRateGap = 0,19 fps, nanoGap = Infinity fps, slowdown = 6252,0 ms, every 0,012 ticks
...
perhaps there are more failing tests that aren't part of test-fast
. all of nightly.sh
should be checked.
export-world is supposed to save all state, but this is a piece of state that isn't being saved.
(included in docs/issues.html)
and anyway export-world doesn't export enough information for a re-import to be possible anyway
this is a missing feature, not merely a bug
example code that's substantially slower in 5.0 than 4.1: sort-by [[p] of ?1 < [p] of ?2] my-patch-set
and insert the show
command automatically
advantages:
show
command, which they'll need in the Code tabthis is a missing feature.
but there is also a bug in that the old tasks might not even work anymore, if the declarations in the Code tab changed, because the tasks might have references to the old indices of agent variables
multiple users are reporting:
Startup error
An error has occurred during startup:
java.lang.IllegalStateException: Error parsing command line arguments: you can only specify one model to open at startup.
at org.nlogo.app.App$.processCommandLineArguments(App.scala:172)
at org.nlogo.app.App$.main(App.scala:82)
perhaps an accidental side effect of c278463
The carefully example doesn't work in 5.0RC4:
carefully [ show 1 / 0 ] [ print error-message ]
Gives:
ERROR: Runtime error: Division by zero.
to bomb
ca crt 1
ask turtles [
let c 0
ask self [ set label task [c] ]
__ignore runresult label
]
end
It bombs running the task, trying to access c
the outer ask
can equally well be a foreach
error (NullPointerException)
while observer running ASK
called by procedure BOMB
called by Button 'bomb'
java.lang.NullPointerException
at org.nlogo.nvm.Context.getLet(Context.java:278)
at org.nlogo.nvm.Context.getLet(Context.java:278)
at org.nlogo.prim._asm_procedurebomb_letvariable_6.report(:1)
at org.nlogo.nvm.ReporterTask.report(Task.scala:51)
at org.nlogo.prim.etc._runresult.report(_runresult.scala:51)
at org.nlogo.prim.etc._ignore.perform(_ignore.java:24)
at org.nlogo.nvm.Context.runExclusive(Context.java:118)
at org.nlogo.nvm.ExclusiveJob.run(ExclusiveJob.java:54)
at org.nlogo.nvm.Context.runExclusiveJob(Context.java:160)
at org.nlogo.prim._asm_procedurebomb_ask_1.perform(:1)
at org.nlogo.nvm.Context.stepConcurrent(Context.java:90)
at org.nlogo.nvm.ConcurrentJob.step(ConcurrentJob.java:80)
at org.nlogo.job.JobThread.org$nlogo$job$JobThread$$runPrimaryJobs(JobThread.scala:125)
Christoph Möslinger reports:
I was trying to implement my own flocking simulation with the latest
NetLogo 3D version and came upon a bug with the "in-cone" primitive:When the pitch of the turtle is 0 degrees then it works as it should,
but as soon as the pitch of the turtle increases, the cone is more and
more "cut" and is (much) less than half of its usual size if the turtle
pitch is 90 degrees.
the bug is demonstrated visually in models/benchmarks/other/3D Cone Tester.nlogo
a test should also be added to tests/commands/InCone.txt
there are now commented-out tests for this in TestImportExport and TokenizerTests.
a string like this: {{array: 0: "}}" "{{"}}
confuses the tokenizer because it doesn't know the }} are part of the string rather than terminating the array
I'm not sure how fixable this even is without redesigning the export format
add to TokenizerTests:
test("array of strings containing doubled curly braces") {
val tokens = tokenize("{{array: 0: \"}}\" \"{{\"}}")
expect(1)(tokens.size)
expect("Token({{array: 0: \"}}\" \"{{\"}},LITERAL,{{array: 0: \"}}\" \"{{\"}})")(
tokens.mkString)
add to TestImportExport:
test("testImportingArrayContainingStringsWithBraces") {
roundTripHelper("set a array:from-list [\"}}\" \"{{\"]",
"extensions [array] globals [a]")
}
maybe ideally it would do the same auto-conversions that the app does, but in practice it's unlikely to happen. so it at least ought to notice the NetLogo version doesn't match and print a warning.
for now, we advise users to resave their old models in the GUI before running them headless in a new version
this means that button names, slider names, and so on that look fine on the model author's computer might be cut off when somebody else looks at the model.
for now, it is advisable to leave some extra space in the sizes of buttons, sliders, etc. in any model that isn't intended merely for personal use.
so for example read-from-string (word table:make)
results in:
java.lang.NumberFormatException: For input string: "[]"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:410)
at java.lang.Long.parseLong(Long.java:468)
at org.nlogo.extensions.table.TableExtension.readExtensionObject(TableExtension.java:406)
at org.nlogo.workspace.ExtensionManager.readExtensionObject(ExtensionManager.java:504)
at org.nlogo.compiler.ConstantParser.parseConstantLiteral(ConstantParser.scala:140)
this isn't just a bug, it's a missing feature.
we may need to rethink our whole approach on serializing extension types; see also #12, #13
we have two reports now (from Steve Railsback and Rainer Joswig) of errors on Windows that went away when the -Xss parameter was reduced.
and on Linux, I had OutOfMemoryErrors on Ubuntu (running under VirtualBox) until I reduced the setting
currently we have -Xss16m; try 8m, or even 4m?
also, at http://groups.yahoo.com/group/netlogo-users/message/13628 Ivan Sopov suggests setting the stack size for NetLogo job threads only using an alternate Thread constructor, rather than setting it VM-wide. he's right.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.