I just re-read your issues; the recompiling works ... as long as you don't add 
new functions.
If you perform a code change on ANYTHING existing, it works.

Controllers:
There is actually a ticket open to fix this very annoying bug.  I troubleshot 
this even with Evan and it's a pesky error.  I hope that someone in the core 
team fixes this very soon.
Elixir is able to recompile and pick up the newly added function(s), so it is 
not a short coming of the Erlang VM itself, it's ChicagoBoss dropping the ball 
somewhere in the modified compiler-chain(s).

Other code directories (lib and others):
The reloader doesn't pickup added functions up as well (see above).
Adding new modules works, but again, newly added functions are skipped/ignored.

Also, I think I had seen that you had referred to one of the controllers just 
by _web_controller and not smsengine_web:* ; if that's the case, that would be 
a user error.  That could also explain why it does not work in either mode, 
development as well as production.

Cheers,
--Kai

Sent from my non-google-device

> On Jan 11, 2015, at 16:26, Emacs the Viking <[email protected]> wrote:
> 
> Ironically it seems to be consistently rebuilding both but only logging to 
> the console...perhaps there is something up with lager configuration? Here 
> are the first few lines of both controllers:
> 
>     -module(smsengine_inbound_controller, [Req]).
>     -compile(export_all).
> and:
>     -module(smsengine_web_controller, [Req]).
>     -compile(export_all).
> 
> I have spent more time digging around the boss source code to no avail. I 
> even ran "observer:start()" and in development and deploy modes, the number 
> of boss routes was the same (three) and looked to be correct.
> 
> 
> 
> 
> 
> 
>> On Sunday, 11 January 2015 19:18:25 UTC, Kai Janson wrote:
>> The nofile message means it's in development mode and just reloading the 
>> code.  Confusing, yes, but it is working.  Sort of.  I recall that at times 
>> it doesn't load the changed code.
>> 
>> But the main issue is that it is in development mode and not production.
>> 
>> --Kai
>> 
>> Sent from my non-google-device
>> 
>>> On Jan 11, 2015, at 05:53, emacstheviking <[email protected]> wrote:
>>> 
>>> Even odder: I have two controller files, both in "src/controller" and one 
>>> of them does not recompile when I make changes and one of them does.
>>> 
>>> Sigh. I hate stuff like this!
>>> 
>>> If I add three blank lines to the end of "smsengine_inbound_controller.erl" 
>>> nothing happens but adding three blank lines to 
>>> "smsengine_web_controller.erl" gives:
>>>     Reloading smsengine_web_controller ... fail: nofile.
>>> 
>>> What gives? Ironically this is the *same* controller that doesn't work in 
>>> "deploy" mode.
>>> 
>>> 
>>> 
>>> :(
>>> 
>>> Stopping because it is Sunday and I don't want the stress this early in the 
>>> day!
>>> 
>>> 
>>>> On 11 January 2015 at 10:46, Emacs the Viking <[email protected]> wrote:
>>>> Whilst investing a route related problem I have noticed that one error I 
>>>> had:
>>>> 
>>>>  Unhandled Error: error:undef. Stacktrace: [{utils,no_auth,[[
>>>> 
>>>> Seems to be caused by the fact that files "src/controller" seem to be 
>>>> ercompiled on a save from Emacs but when I changed the code in a file in 
>>>> the "src/lib" folder, the change was not detected and so my new function 
>>>> was not present.
>>>> 
>>>> Can somebody state clearly what folders are subject to auto-rebuild of 
>>>> their content?
>>>> 
>>>> Thanks.
>>>> 
>>>> Sean.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "ChicagoBoss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to [email protected].
>>>> Visit this group at http://groups.google.com/group/chicagoboss.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/chicagoboss/903de0c3-914a-4a2f-83ad-413087c6fdb2%40googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "ChicagoBoss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to [email protected].
>>> Visit this group at http://groups.google.com/group/chicagoboss.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/chicagoboss/CAEiEuULLknrTHh%2BCVGpSBazAhEVzLDcNuvQQeCskpHOSRSvy6A%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> Visit this group at http://groups.google.com/group/chicagoboss.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/chicagoboss/af42bdd1-5258-4d24-9a69-f3fdf40b0f6c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/chicagoboss/B11358B8-7052-4D47-9065-50BF7C80FB0A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to