All the times I've had problems have been in early, exploratory sessions in the REPL, so unfortunately I don't have any code sample close at hand. From what I can remember, it was mostly problems with dispatching when types were redefined; the function bindings wouldn't be reloaded, so I'd get (quite confusing) method errors when calling f(x::MyType) because I had a variable x::MyType, but for a different version of MyType than f expected.
I'll try to make a point of using workspace() rather than restarting, though, and see if I can reproduce anything - if I do, I'll report it. // Tomas On Thursday, January 1, 2015 3:17:39 PM UTC+1, Isaiah 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. > > > 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] > <javascript:>> 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. >>>>> >>>> >>>> >
