FYI, Autoreload.jl has this `@ausing` macro that will autoreload the module 
on modification AND update the Main symbols, so there's no need to qualify 
the module name all the time. It's much more convenient than Julia's 
default behaviour IMO.

On Tuesday, May 24, 2016 at 3:29:44 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> Tim,
>
> Thanks for the detailed explanation!  If I understand correctly, you would 
> give the following advice.  In an edit-debug-retry mode carried out from 
> the REPL, it is inadvisable to issue a 'using' directive for a file that is 
> being actively debugged.  This is because 'using' will freeze the current 
> version of the module inside Main.  And the matter of whether one is 
> debugging a macro or function is irrelevant for this advice.
>
> I submitted an apparently incorrect PR to the 'workflow' section of the 
> Julia manual; I want to retract my PR and provide some correct advice 
> regarding workflow.
>
> Thanks,
> Steve
>
>
> On Tuesday, May 24, 2016 at 2:54:12 PM UTC-4, Tim Holy wrote:
>>
>> If you reloaded the whole package each time some code said 
>>     using Compat 
>> you'd be very, very unhappy. Once the module is defined in Main, that's 
>> where 
>> it fetches it from (which is why it's so fast). 
>>
>> If you reload the package with `reload("Compat")`, then any future 
>> `using` 
>> statements refer to the new Compat. If module A depends on module B, and 
>> you 
>> modify B, you can reload both (in order B, then A) to refresh everything. 
>>
>> Inside Main, when you say `using Foo`, now all the names exported by Foo 
>> are 
>> part of Main. That's why you need the `Foo.@mac` henceforth; you want to 
>> refer 
>> to Foo's (new) definition of `@mac`, not Main's stale definition of 
>> `@mac`. 
>>
>> Because Foo might export types and you might have some object of the 
>> (old) 
>> types in your workspace, julia avoids re-importing the names into Main 
>> (since 
>> otherwise that would lead to broken objects). 
>>
>> Best, 
>> --Tim 
>>
>> On Tuesday, May 24, 2016 10:24:41 AM Cedric St-Jean wrote: 
>> > On Tuesday, May 24, 2016 at 11:13:29 AM UTC-4, vav...@uwaterloo.ca 
>> wrote: 
>> > > Cedric, 
>> > > 
>> > > Yes, you have identified the issue: when I say "using file.@mac" 
>> followed 
>> > > by "macroexpand(:(@mac expr))" at the REPL prompt, then future 
>> 'include' 
>> > > statements do not reload the macro definition.  However, if I skip 
>> the 
>> > > "using" directive and qualify the name as file.@mac in the 
>> macroexpand 
>> > > call, then future 'include' statements do reload the macro. 
>> > > 
>> > > This behavior runs counter to my expectation of how "using" operates. 
>>  Can 
>> > > you explain in more detail what "using" does? 
>> > 
>> > It's magic to me too, TBH. The manual says 
>> > 
>> > The statement using Lib means that a module called Lib will be 
>> available 
>> > 
>> > > for resolving names as needed. 
>> > 
>> > but I don't understand how its implementation interacts with 
>> > reload/include. 
>> > 
>> > > -- Steve 
>> > > 
>> > > On Tuesday, May 24, 2016 at 8:15:25 AM UTC-4, Cedric St-Jean wrote: 
>> > >> Are you `using` the module? In general, `using` and reloading don't 
>> play 
>> > >> very nice with each other. I just tried with a module like 
>> > >> 
>> > >> module foo 
>> > >> macro aa() 
>> > >> 
>> > >>     20 
>> > >> 
>> > >> end 
>> > >> end 
>> > >> 
>> > >> and when I use the module name 
>> > >> 
>> > >> include("foo.jl") 
>> > >> foo.@aa 
>> > >> 
>> > >> it works out. 
>> > >> 
>> > >> On Tue, May 24, 2016 at 12:21 AM, <vav...@uwaterloo.ca> wrote: 
>> > >>> Cedric, 
>> > >>> 
>> > >>> I encountered this issue in the following context: the macro is 
>> defined 
>> > >>> inside a module.  I test it from the REPL using the macroexpand 
>> > >>> function. 
>> > >>> When macroexpand bombs or else gives me the wrong expansion, I edit 
>> the 
>> > >>> file with the macro definition and reload the module via include. 
>> > >>> However, 
>> > >>> the next invocation of macroexpand from the REPL still uses the old 
>> > >>> definition. 
>> > >>> 
>> > >>> The suggestion from Kaj Wiik to use the workspace() command seems 
>> to 
>> > >>> have addressed the issue.  In fact, I just submitted a PR to the 
>> Julia 
>> > >>> manual with a couple of sentences to explain this. 
>> > >>> 
>> > >>> -- Steve 
>> > >>> 
>> > >>> On Tuesday, May 24, 2016 at 12:03:24 AM UTC-4, Cedric St-Jean 
>> wrote: 
>> > >>>> Maybe you already know this, but macros are applied at parsing 
>> time (or 
>> > >>>> right after parsing - not sure). This means that if you have 
>> > >>>> 
>> > >>>> # In Macro.jl 
>> > >>>> macro macmac(x) 
>> > >>>> ... 
>> > >>>> end 
>> > >>>> 
>> > >>>> # In Fun.jl 
>> > >>>> function foo(x) 
>> > >>>> 
>> > >>>>    macmac(something) 
>> > >>>> 
>> > >>>> end 
>> > >>>> 
>> > >>>> 
>> > >>>> Then whenever you've changed Macro.jl, you need to reload both 
>> Macro.jl 
>> > >>>> and Fun.jl, because as far as Julia is concerned, 
>> `macmac(something)` 
>> > >>>> isn't 
>> > >>>> "a reference to the macmac macro"; once Fun.jl has been loaded, 
>> > >>>> `macmac` is 
>> > >>>> completely gone from foo's definition, and replaced with its 
>> > >>>> macroexpansion. 
>> > >>>> 
>> > >>>> Doing that, I've never had any issue with reloading macros. Do you 
>> have 
>> > >>>> another problem in mind, or more specific code? 
>> > >>>> 
>> > >>>> On Monday, May 23, 2016 at 5:31:37 PM UTC-4, vav...@uwaterloo.ca 
>> wrote: 
>> > >>>>> First, thanks to Matt Baumann for answering my previous post so 
>> > >>>>> quickly! 
>> > >>>>> 
>> > >>>>> Next question: it seems that for developing and debugging a 
>> macro, the 
>> > >>>>> usual REPL cycle of edit/include/edit/include does not work.,  I 
>> find 
>> > >>>>> that 
>> > >>>>> using 'include' to reload the macro definition defined inside a 
>> module 
>> > >>>>> does 
>> > >>>>> not overwrite its previous definition.  It seems that to replace 
>> a 
>> > >>>>> macro 
>> > >>>>> definition, I need to exit the REPL and start a new REPL.  Is 
>> there 
>> > >>>>> some 
>> > >>>>> other way? 
>> > >>>>> 
>> > >>>>> Thanks, 
>> > >>>>> Steve Vavasis 
>>
>>

Reply via email to