I just realized that none of that works since `setup` usually calls `clear-all`... duh. I think I may have a fix, though, for the second workaround, though I want to test first to be sure this time.
On Fri, Oct 17, 2014 at 5:20 PM, Bryan Head <[email protected]> wrote: > Here are a couple workarounds: > > 1) This is a little verbose, but you could include a flag for each global, > like so > > globals [ > first-param > first-param-set? > second-param > second-param-set? > ] > > > then in `setup-globals`, you'd do: > > to setup-globals > if first-param-set? != 0 [ set first-param 13 ] > if second-param-set? != 0 [ set second-param 72 ] > end > > > In BS, you can then specify which globals you want to override by setting > those flags, eg: > > set first-param 0 > set first-param-set? true > > or > > ["first-param" [0 1 10]] > ["first-param-set?" true] > > > 2) Less verbose, but perhaps a little dirtier, and less flexible. Have a > global called `initialized-globals` or something. Then make the following > procedure: > > to initialize-global [ global-name value ] > if not is-list? initialized-globals [ set initialized-globals [] ] > > if not member? global-name initialized-globals [ > run (word "set " global-name " " value) > set initialized-globals lput global-name initialized-globals > ] > end > > > Then, in `setup-globals` and BS, do > > initialize-global "some-param" 5 > > > to initialize each global. `initialize-global` will only set each global > once. > > This has a couple limitations. First, `initialize-global` has to be > tweaked if you need to set globals to values who's string representation > doesn't evaluate to the value itself (I think this only arises with > extensions). Second, it's a little awkward when doing parameter varying in > BS. I suppose you could do it as follows: > > ["first-param" [0 1 10]] > > ["second-param" [-5 1 5]] > > > and then in the BS setup, do: > > set initialized-globals ["first-param" "second-param"] > > or via > > initialize-global "first-param" first-param > ... > > Hope this helps as a workaround! > Bryan > > PS- > > I'll cross-post this to the related github issue: > https://github.com/NetLogo/NetLogo/issues/179 > > On Fri, Oct 17, 2014 at 4:19 PM, Alan Isaac <[email protected]> wrote: > >> There is no good workaround. The developers have not suggested a >> workaround. This is a widely recognized problem. I personally do not see >> how it will be adequately addressed unless initialization of non-interface >> globals is changed. I would love to hear how the developers are thinking >> about this problem, which poses very real problems for serious NetLogo >> users. >> >> My recommendation would be to plan a transition. Immediately, introduce >> a new keyword for the declarations section, allowing specification of the >> default value for non-interface globals. (E.g., `__global-default`.) >> Ideally, this would immediately be supported by the introduction of a new >> value (e.g., `undefined`). Users who want this functionality now would be >> able to include the declaration >> >> __global-default undefined >> >> In a future version, this would become the default behavior. >> >> I plead that the developers take this design flaw seriously and that it >> not be passed on to Tortoise! >> >> Alan >> >> -- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
