Hi John, In fact you can eval "into" a module and thus add functions/variables without reloading the whole thing. Juno supports this, I am working on ESS to provide the same functionality. What IDE are you using?
Best, Tamas On Wed, Feb 25 2015, [email protected] wrote: > I found a solution. If something is wrong, please correct it in this thread. > > -- To make a module, you must put code in a single module expression > 'module MyModule ... end'. > You may 'include' other files within this expression which has the > effect of literally writing the contents > inside the module expression. > -- Once the module expression is executed, you cannot add functions (or > other things, like global constants ?) > to the module. If you again load code with a module expression naming > the same module, it will overwrite > the original module. (you can have a submodule MyModule within > MyModule. You will get a warning that > MyModule is being overwritten, but in fact it is not. But, this may > have been fixed by now.) So if you > change anything in a module, you must reload the entire module. But, > this is not quite true. If a function > already exists from the previous module expression, you can redefine it > by qualifying it with > 'MyModule.funcname(...'. In this function, you also have to qualify > all types that were defined inside the > module, (and maybe other things ?) > -- Reloading the module may cause warnings to be printed at the repl. For > instance, for me, methods that extend > base functions cause 'new definition is ambiguous with' warnings, and > 'Method definition ... overwritten' warnings. > I don't know the significance of these warnings. But you may have > problems (see below). I don't know if they > are related to the warnings printed at the repl. > -- After reloading the entire module, code, in particular test code, may > fail with error messages printed. Restarting > Julia, of course will fix this. > -- But, here is a solution that lets me edit a line in a module, reload > it and run the tests relatively quickly: > Run the test code. At the line number named in the error message, > qualify calls to a macro with the name > of the module, eg. 'MyModule.@mymacro'. Probably the same applies to > function calls. You may need to > qualify calls in some preceding lines, as well. Run the test suite > again, and repeat the previous step. In the > end, I am able to run the entire test suite with about 5 percent of > the calls (every call in this test suite is to > one of two macros) qualified. If you understand the problem better, > you may be able to predict which calls > need to be qualified. Anyway, after doing this, my workflow is > unstuck! I read a lot of posts on how to deal > with this problem. Fortunately, there is a line in a post by Tim Holy > mentioning qualifying calls to module > functions in test code. Thanks, Tim! > > -- John
