I should put in big, bold letters up here, that the following is ALL vaporware at this point. For discussion ONLY.
The problem is that there's four general categories of extensions: core - bundled as they are now. Things like the file system primitives would go in a core (as would array, etc). These things enhance the language in meaningful ways, and get used across a variety of models ccl authored and mainted, but not core - things like the gogo extension, where the extension is special use for only certain models community authored, well maintained, often used models - things like gis community authored and not well maintained For models that use any of the latter three, there's a serious problem for model authors and extension authors in that netlogo gives no mechanism to get the extension, or to check for bug fixes and updates. For instance, if we fix the gogo extension because the small number of users find a critical error, we must release an entire new version of NetLogo with all that entails, which affects all NetLogo users. The only other option is have each user maintain the gogo extension on each hard drive with no information about whether the current version they are using has the bug fix or not. If, however, NetLogo goes and figures out that "hey, there's a new gogo extension, would you like to get it?" And we make netlogo aware of the versioning of extensions its aware of, a lot of user problems just become solved. This also gives us some freedom to implement extensions with less rigorous testing because they aren't bundled with NetLogo. For users who are writing programs for the first time with NetLogo, this allows them to easily go see a page on the internet explaining some neat extension and start using it immediately rather than learning how NetLogo handles extensions on their file system and keeping up to date with what the extension does. It also gives us freedom to implement larger extensions. One of our bundled extensions is quickly becoming the size of the NetLogo program itself, required each user to download a substantial file in order to just get NetLogo, even though they will likely never use that extension. And yes, there's a lot of potential issues with versioning. I think we would look to various package management systems (maven, ivy, apt, windows update, apple update) for inspiration on how to best solve those for netlogo. Frank On Thu, Mar 19, 2015 at 06:13:27AM -0700, Alan Isaac wrote: > My impression is that my undergraduate students are always connected -- at > least those living on campus -- but I have not surveyed them. I have had > graduate students who could not afford internet access at home and so were > connected only on campus, but I do not know how common that is. > > I am curious why it is not desirable to simply package core extensions, > following the current practice. Fetching extensions seems to raise all > kinds of potential issues, including versioning issues. > > Alan > > > On Thursday, March 19, 2015 at 8:35:30 AM UTC-4, Frank Duncan wrote: > > > > One last question, with extensions. Do you run into situations where > > students are using NetLogo without being connected to the internet? > > Would dynamically fetching extensions the first time they are run into > > by netlogo (the first time a model is opened that uses one) be a > > problem? > > > > > > -- > 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.
