> > Also worth noting, is that while workspace() is great in many cases, it's > quite easy to shoot yourself in the foot, mainly because of > https://github.com/JuliaLang/julia/issues/265 - if you define *and run* a > function, and then run workspace(), the old function version is left > intact; so, if you then define a new function, or a new version of a type > that that function takes as argument, you might get unexpected results.
Do you have an example where this is an issue? I would consider any kind of crosstalk behavior to be a bug, so please file one if you have an example. While it is true that previous definitions will still exist in memory (and be accessible via LastMain.whatever), re-defined functions or re-imported modules should exist in a separate namespace with independent binding lookup and code (re-)generation. I use `workspace()` extensively and have not had any issues so far. More concretely, if you run `using Gadfly` after `workspace()` then it should take exactly the same amount of time as when importing in a new session. On the other hand, if you are not working on Gadfly itself, running `using LastMain.Gadfly` should have no ill-effects and will make it available nearly instantaneous. The fact that Julia's modules are essentially static after generation is a big advantage here. On Thu, Jan 1, 2015 at 8:16 AM, Tomas Lycken <[email protected]> wrote: > Also worth noting, is that while workspace() is great in many cases, it's > quite easy to shoot yourself in the foot, mainly because of > https://github.com/JuliaLang/julia/issues/265 - if you define *and run* a > function, and then run workspace(), the old function version is left > intact; so, if you then define a new function, or a new version of a type > that that function takes as argument, you might get unexpected results. I > haven't experimented thoroughly with this so I don't know if it applies in > all circumstances or just in some (that I have happened to stumble upon), > but at least for me Julia's startup is now so fast that I don't mind > reloading the kernel if I have to. > > I guess the main reason to want to avoid restarting the kernel is if you > load packages that take a lot of time, e.g. Gadfly. In that case, putting > your own code in a module and using reload("YourModule") might be a better > way of reloading; then you can have using Gadfly inside your module, and on > reload you won't have to reload Gadfly too. > > // Tomas > > > On Thursday, January 1, 2015 4:19:43 AM UTC+1, Tony Fong wrote: >> >> Lint.jl relies on julia's built-in parser which only generates line >> number, not column number, in the abstract syntax tree, so it won't help on >> the 2nd question, either. >> >> On Thursday, January 1, 2015 2:30:42 AM UTC+7, Isaiah wrote: >>> >>> 1) workspace() >>> 2) maybe Lint.jl could help here? Not sure (haven't used it myself yet, >>> although I probably should). There are various open issues about better >>> error messages although I don't remember one about this specifically. It >>> will probably be a bit more tractable as an up-for-grabs project if/when we >>> move to the pure-Julia parser. >>> >>> On Wed, Dec 31, 2014 at 2:16 PM, Zahirul ALAM <[email protected]> >>> wrote: >>> >>>> how would one clear values of variable, or change the type: for >>>> instance if I declare a = 5 and after evaluation, if I fix the statement >>>> reevaluate const a = 5, I get error that a is already defined. How would I >>>> get a out of the memory without restarting the entire kernel? >>>> >>>> Second question is if there is a syntax error, Julia says the line >>>> number where the syntanx error is. But for a long mathematical expression >>>> it is helpful if it says the character number as well. Sometime I find this >>>> frustrating because I have mistyped one less bracket or missed a plus sign. >>>> >>> >>>
