Add old mailing list archives

1 files changed, 1740 insertions, 0 deletions

diff --git a/archives/extend/2014-March.txt b/archives/extend/2014-March.txt
new file mode 100644
index 00000000..f510662a
--- /dev/null
+++ b/archives/extend/2014-March.txt
@@ -0,0 +1,1740 @@
+From psihonavt at gmail.com  Mon Mar  3 21:49:33 2014
+From: psihonavt at gmail.com (Anton Koval')
+Date: Mon, 3 Mar 2014 22:49:33 +0200
+Subject: [99s-extend] usage of make_* command
+Message-ID: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com>
+
+Hello,
+
+I have next structure of my project:
+.
+??? deps
+?   ??? cowboy
+?   ??? cowlib
+?   ??? erlang_iconv
+?   ??? erlydtl
+?   ??? mochiweb_xpath
+?   ??? ranch
+??? ebin
+?   ??? fetchers.beam
+?   ??? parsers.beam
+?   ??? wasearch_sup.beam
+??? erlang.mk
+??? Makefile
+??? _rel
+?   ??? ....
+??? relx
+??? relx.config
+??? src
+?   ??? fetchers.erl
+?   ??? main_handler.erl
+?   ??? parsers.erl
+?   ??? tests
+?   ?   ??? parsers_SUITE_data
+?   ?   ??? parsers_SUITE.erl
+?   ?   ??? ....
+?   ??? wasearch_app.erl
+?   ??? wasearch.app.src
+?   ??? wasearch_sup.erl
+??? templates
+    ??? index.dtl
+
+I would prefer to store tests not in `src` directory but rather in `tests`
+subdirectory.
+Erlang.mk README says: You can run an individual test suite by using the
+special test_* targets. For example if you have a common_test suite named
+spdy and you want to run only this suite and not the others, you can use
+the make test_spdy command.
+And of course `make test_parsers`  returns `no rule to make target` error.
+Is there a way to run suites from custom directory with
+`make_<mod_name_with_suite>` command?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140303/52007acc/attachment.html>
+
+From mark.nijhof at cre8ivethought.com  Thu Mar  6 00:47:08 2014
+From: mark.nijhof at cre8ivethought.com (Mark Nijhof)
+Date: Thu, 6 Mar 2014 00:47:08 +0100
+Subject: [99s-extend] Cowboy pre request filter
+Message-ID: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com>
+
+Hi,
+
+I want to create a module that basically sits between the incoming request
+and the http handler for that request to ensure a request is authenticated
+(using a cookie), if the request is not authenticated then I like to
+redirect to a specific login page (which should not be filtered).
+
+Is this possible with Cowboy? Should I use the onrequest hook (not sure if
+I can force redirects from there) for that or is there a better way?
+
+Cheers,
+
+-Mark
+
+-- 
+Mark Nijhof
+t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+s:  marknijhof
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/a517215b/attachment.html>
+
+From mark.nijhof at cre8ivethought.com  Thu Mar  6 10:52:01 2014
+From: mark.nijhof at cre8ivethought.com (Mark Nijhof)
+Date: Thu, 6 Mar 2014 10:52:01 +0100
+Subject: [99s-extend] Cowboy pre request filter
+In-Reply-To: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com>
+References: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com>
+Message-ID: <CACE=TJqaoxrqsCSnN44s_5x4MabgWBVfaN_pecVrShnUuU-9aQ@mail.gmail.com>
+
+I also found the answer to my own question: custom middleware
+
+I just created:
+
+   1 -module(authentication_middleware).
+   2
+   3 -behaviour(cowboy_middleware).
+   4
+   5 -export([execute/2]).
+   6
+   7 execute(Req, Env) ->
+   8
+   9     {Path, Req1} = cowboy_req:path(Req),
+  10
+  11     case Path of
+  12         <<"/login.html">> ->
+  13             {ok, Req1, Env};
+  14         <<"/do_login">> ->
+  15             {ok, Req1, Env};
+  16         _ ->
+  17             case id3as_security:is_request_authenticated(Req1) of
+  18                 {error, eauth, Req2} ->
+  19                     {ok, Req4} = cowboy_req:reply(303,
+[{<<"Location">>, <<"/login.html">>}], "", Req2),
+  20                     {halt, Req4};
+  21                 {authenticated, _Id, Req2} ->
+  22                    {ok, Req2, Env}
+  23             end
+  24     end.
+
+And put this between the cowboy_router and cowboy_handler and life is all
+good.
+
+-Mark
+
+
+
+On Thu, Mar 6, 2014 at 12:47 AM, Mark Nijhof <mark.nijhof at cre8ivethought.com
+> wrote:
+
+> Hi,
+>
+> I want to create a module that basically sits between the incoming request
+> and the http handler for that request to ensure a request is authenticated
+> (using a cookie), if the request is not authenticated then I like to
+> redirect to a specific login page (which should not be filtered).
+>
+> Is this possible with Cowboy? Should I use the onrequest hook (not sure if
+> I can force redirects from there) for that or is there a better way?
+>
+> Cheers,
+>
+> -Mark
+>
+> --
+> Mark Nijhof
+> t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+> s:  marknijhof
+>
+>
+
+
+-- 
+Mark Nijhof
+t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+s:  marknijhof
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/24422ef2/attachment.html>
+
+From essen at ninenines.eu  Thu Mar  6 15:40:59 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Thu, 06 Mar 2014 15:40:59 +0100
+Subject: [99s-extend] usage of make_* command
+In-Reply-To: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com>
+References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Tests should be in ./tests, not ./src/tests.
+
+If you put them in ./tests everything you mentioned will work.
+
+On 03/03/2014 09:49 PM, Anton Koval' wrote:
+> Hello,
+>
+> I have next structure of my project:
+> .
+> ??? deps
+> ?   ??? cowboy
+> ?   ??? cowlib
+> ?   ??? erlang_iconv
+> ?   ??? erlydtl
+> ?   ??? mochiweb_xpath
+> ?   ??? ranch
+> ??? ebin
+> ?   ??? fetchers.beam
+> ?   ??? parsers.beam
+> ?   ??? wasearch_sup.beam
+> ??? erlang.mk <http://erlang.mk>
+> ??? Makefile
+> ??? _rel
+> ?   ??? ....
+> ??? relx
+> ??? relx.config
+> ??? src
+> ?   ??? fetchers.erl
+> ?   ??? main_handler.erl
+> ?   ??? parsers.erl
+> ?   ??? tests
+> ?   ?   ??? parsers_SUITE_data
+> ?   ?   ??? parsers_SUITE.erl
+> ?   ?   ??? ....
+> ?   ??? wasearch_app.erl
+> ?   ??? wasearch.app.src
+> ?   ??? wasearch_sup.erl
+> ??? templates
+>      ??? index.dtl
+>
+> I would prefer to store tests not in `src` directory but rather in
+> `tests` subdirectory.
+> Erlang.mk README says: You can run an individual test suite by using the
+> special |test_*| targets. For example if you have a common_test suite
+> named |spdy| and you want to run only this suite and not the others, you
+> can use the |make test_spdy| command.
+> And of course `make test_parsers`  returns `no rule to make target` error.
+> Is there a way to run suites from custom directory with
+> `make_<mod_name_with_suite>` command?
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From psihonavt at gmail.com  Thu Mar  6 15:50:01 2014
+From: psihonavt at gmail.com (Anton Koval')
+Date: Thu, 6 Mar 2014 16:50:01 +0200
+Subject: [99s-extend] usage of make_* command
+In-Reply-To: <[email protected]>
+References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com>
+
+Thank you for answer.
+Is it common way (for OTP-based application) to store tests in `tests`
+subdirectory rather then in `src/tests/`?
+
+
+On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> Tests should be in ./tests, not ./src/tests.
+>
+> If you put them in ./tests everything you mentioned will work.
+>
+>
+> On 03/03/2014 09:49 PM, Anton Koval' wrote:
+>
+>> Hello,
+>>
+>> I have next structure of my project:
+>> .
+>> ??? deps
+>> ?   ??? cowboy
+>> ?   ??? cowlib
+>> ?   ??? erlang_iconv
+>> ?   ??? erlydtl
+>> ?   ??? mochiweb_xpath
+>> ?   ??? ranch
+>> ??? ebin
+>> ?   ??? fetchers.beam
+>> ?   ??? parsers.beam
+>> ?   ??? wasearch_sup.beam
+>> ??? erlang.mk <http://erlang.mk>
+>>
+>> ??? Makefile
+>> ??? _rel
+>> ?   ??? ....
+>> ??? relx
+>> ??? relx.config
+>> ??? src
+>> ?   ??? fetchers.erl
+>> ?   ??? main_handler.erl
+>> ?   ??? parsers.erl
+>> ?   ??? tests
+>> ?   ?   ??? parsers_SUITE_data
+>> ?   ?   ??? parsers_SUITE.erl
+>> ?   ?   ??? ....
+>> ?   ??? wasearch_app.erl
+>> ?   ??? wasearch.app.src
+>> ?   ??? wasearch_sup.erl
+>> ??? templates
+>>      ??? index.dtl
+>>
+>> I would prefer to store tests not in `src` directory but rather in
+>> `tests` subdirectory.
+>> Erlang.mk README says: You can run an individual test suite by using the
+>> special |test_*| targets. For example if you have a common_test suite
+>> named |spdy| and you want to run only this suite and not the others, you
+>> can use the |make test_spdy| command.
+>> And of course `make test_parsers`  returns `no rule to make target` error.
+>> Is there a way to run suites from custom directory with
+>> `make_<mod_name_with_suite>` command?
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Lo?c Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/6fa8fe3b/attachment.html>
+
+From essen at ninenines.eu  Thu Mar  6 15:51:58 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Thu, 06 Mar 2014 15:51:58 +0100
+Subject: [99s-extend] usage of make_* command
+In-Reply-To: <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com>
+References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com>	<[email protected]>
+ <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Sorry I meant ./test/ not ./tests/
+
+But yes. That's how OTP does it.
+
+On 03/06/2014 03:50 PM, Anton Koval' wrote:
+> Thank you for answer.
+> Is it common way (for OTP-based application) to store tests in `tests`
+> subdirectory rather then in `src/tests/`?
+>
+>
+> On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Tests should be in ./tests, not ./src/tests.
+>
+>     If you put them in ./tests everything you mentioned will work.
+>
+>
+>     On 03/03/2014 09:49 PM, Anton Koval' wrote:
+>
+>         Hello,
+>
+>         I have next structure of my project:
+>         .
+>         ??? deps
+>         ?   ??? cowboy
+>         ?   ??? cowlib
+>         ?   ??? erlang_iconv
+>         ?   ??? erlydtl
+>         ?   ??? mochiweb_xpath
+>         ?   ??? ranch
+>         ??? ebin
+>         ?   ??? fetchers.beam
+>         ?   ??? parsers.beam
+>         ?   ??? wasearch_sup.beam
+>         ??? erlang.mk <http://erlang.mk> <http://erlang.mk>
+>
+>         ??? Makefile
+>         ??? _rel
+>         ?   ??? ....
+>         ??? relx
+>         ??? relx.config
+>         ??? src
+>         ?   ??? fetchers.erl
+>         ?   ??? main_handler.erl
+>         ?   ??? parsers.erl
+>         ?   ??? tests
+>         ?   ?   ??? parsers_SUITE_data
+>         ?   ?   ??? parsers_SUITE.erl
+>         ?   ?   ??? ....
+>         ?   ??? wasearch_app.erl
+>         ?   ??? wasearch.app.src
+>         ?   ??? wasearch_sup.erl
+>         ??? templates
+>               ??? index.dtl
+>
+>         I would prefer to store tests not in `src` directory but rather in
+>         `tests` subdirectory.
+>         Erlang.mk README says: You can run an individual test suite by
+>         using the
+>         special |test_*| targets. For example if you have a common_test
+>         suite
+>         named |spdy| and you want to run only this suite and not the
+>         others, you
+>         can use the |make test_spdy| command.
+>         And of course `make test_parsers`  returns `no rule to make
+>         target` error.
+>         Is there a way to run suites from custom directory with
+>         `make_<mod_name_with_suite>` command?
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         https://lists.ninenines.eu/__listinfo/extend
+>         <https://lists.ninenines.eu/listinfo/extend>
+>
+>
+>     --
+>     Lo?c Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From lloyd at writersglen.com  Thu Mar  6 21:29:59 2014
+From: lloyd at writersglen.com (lloyd at writersglen.com)
+Date: Thu, 6 Mar 2014 15:29:59 -0500 (EST)
+Subject: [99s-extend] Trying to grok erlang.mk
+Message-ID: <[email protected]>
+
+Hello,
+
+To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this:
+
+min
+   erlang.mk
+   Makefile
+   src
+      min.app.src
+      min.erl
+
+*** Where Makefile is:
+
+PROJECT = min
+
+include erlang.mk
+
+*** min.app.src is:
+
+{application, min,
+         [{description,[]},
+          {vsn,"0.1.0"},
+          {registered,[]},
+          {applications,[kernel,stdlib]},
+          {env,[]},
+          {modules,[]}]}.
+
+*** and min.erl is:
+
+-module(min).
+
+-export([hello/0]).
+
+hello() ->
+   io:format("Hello min!~n~n").
+
+*** But when I call make, I get this:
+
+/min$ make
+ ERLC   min.erl
+ APP    min .app.src
+cat: src/min: No such file or directory
+cat: .app.src: No such file or directory
+sed: can't read .app: No such file or directory
+make: *** [app] Error 2
+
+*** Observations
+
+min.erl compiles just  fine
+min.app.src breaks the compile
+
+*** Questions: 
+
+1) How can I correct this?
+2) How can I structure directories and make files for a project that involves several applications?
+
+Many thanks,
+
+LRP
+
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+From ivan at llaisdy.com  Fri Mar  7 13:37:27 2014
+From: ivan at llaisdy.com (Ivan Uemlianin)
+Date: Fri, 07 Mar 2014 12:37:27 +0000
+Subject: [99s-extend] Trying to grok erlang.mk
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+Dear Lloyd
+
+I've just tried this with file layout and contents copied from your 
+email, and make works fine here I'm afraid.
+
+One odd thing I noticed in your make output ...
+
+ > /min$ make
+ >   ERLC   min.erl
+ >   APP    min .app.src
+ > cat: src/min: No such file or directory
+ > cat: .app.src: No such file or directory
+ > sed: can't read .app: No such file or directory
+ > make: *** [app] Error 2
+
+... is that in the APP line, the filename min.app.src has a space in it, 
+and it looks (in the cat lines) like it's broken down into src/min and 
+.app.src (ie ./.app.src).  I can't imagine why that's happening, but 
+that's what's causing the problem I should think.
+
+ > 2) How can I structure directories and make files for a project
+ >    that involves several applications?
+
+I don't know if it's the "correct" way with erlang.mk but, as a refugee 
+from rebar, I have apps set out rebar-style and use old-school recursive 
+make. e.g.:
+
+max/
+   erlang.mk
+   Makefile
+   apps/
+     app1/
+       Makefile
+       src/
+     app2/
+       Makefile
+       src/
+
+Top level Makefile doesn't need to include erlang.mk, and has lines like:
+
+all:
+	$(MAKE) -C apps/app1
+	$(MAKE) -C apps/app2
+
+Lower level Makefiles include erlang.mk.
+
+Best wishes
+
+Ivan
+
+
+On 06/03/2014 20:29, lloyd at writersglen.com wrote:
+> Hello,
+>
+> To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this:
+>
+> min
+>     erlang.mk
+>     Makefile
+>     src
+>        min.app.src
+>        min.erl
+>
+> *** Where Makefile is:
+>
+> PROJECT = min
+>
+> include erlang.mk
+>
+> *** min.app.src is:
+>
+> {application, min,
+>           [{description,[]},
+>            {vsn,"0.1.0"},
+>            {registered,[]},
+>            {applications,[kernel,stdlib]},
+>            {env,[]},
+>            {modules,[]}]}.
+>
+> *** and min.erl is:
+>
+> -module(min).
+>
+> -export([hello/0]).
+>
+> hello() ->
+>     io:format("Hello min!~n~n").
+>
+> *** But when I call make, I get this:
+>
+> /min$ make
+>   ERLC   min.erl
+>   APP    min .app.src
+> cat: src/min: No such file or directory
+> cat: .app.src: No such file or directory
+> sed: can't read .app: No such file or directory
+> make: *** [app] Error 2
+>
+> *** Observations
+>
+> min.erl compiles just  fine
+> min.app.src breaks the compile
+>
+> *** Questions:
+>
+> 1) How can I correct this?
+> 2) How can I structure directories and make files for a project that involves several applications?
+>
+> Many thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+From essen at ninenines.eu  Fri Mar  7 17:56:01 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Fri, 07 Mar 2014 17:56:01 +0100
+Subject: [99s-extend] Trying to grok erlang.mk
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote:
+> PROJECT = min
+
+You probably have an extra space at the end here, and erlang.mk doesn't 
+trim them I guess. Please open a ticket!
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From ivan at llaisdy.com  Fri Mar  7 17:58:40 2014
+From: ivan at llaisdy.com (Ivan Uemlianin)
+Date: Fri, 07 Mar 2014 16:58:40 +0000
+Subject: [99s-extend] Trying to grok erlang.mk
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+Yes, that's it!  I've just tried it.
+
+Good old make :)
+
+On 07/03/2014 16:56, Lo?c Hoguin wrote:
+> On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote:
+>> PROJECT = min
+>
+> You probably have an extra space at the end here, and erlang.mk doesn't
+> trim them I guess. Please open a ticket!
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+From lloyd at writersglen.com  Mon Mar 10 20:44:27 2014
+From: lloyd at writersglen.com (lloyd at writersglen.com)
+Date: Mon, 10 Mar 2014 15:44:27 -0400 (EDT)
+Subject: [99s-extend] =?utf-8?q?Getting_started_error=3A___behaviour_cowbo?=
+ =?utf-8?q?y=5Fhttp=5Fhandler_undefined?=
+Message-ID: <[email protected]>
+
+Hello,
+
+I've slavishly emulated the "Getting started" example in the guide: 
+
+http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+
+But, when I compile I get this error:
+
+yada yada
+ ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+compile: warnings being treated as errors
+src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+make: *** [ebin/hello_erlang.app] Error 1
+
+Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+
+However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+
+% -behavior(cowboy_http_handler).
+
+Could this be a bug in Getting started or some dunder-headed thing on my end?
+
+Thanks,
+
+LRP
+
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+From essen at ninenines.eu  Mon Mar 10 21:36:22 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Mon, 10 Mar 2014 21:36:22 +0100
+Subject: [99s-extend] Getting started error: behaviour
+ cowboy_http_handler undefined
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+Try updating Erlang or Cowboy, this isn't the first time this happens 
+and I fixed something at some point.
+
+Also see if you have ERL_LIBS already defined, in which case there might 
+be a bug in Cowboy.
+
+On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> I've slavishly emulated the "Getting started" example in the guide:
+>
+> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>
+> But, when I compile I get this error:
+>
+> yada yada
+>   ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+> compile: warnings being treated as errors
+> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+> make: *** [ebin/hello_erlang.app] Error 1
+>
+> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>
+> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>
+> % -behavior(cowboy_http_handler).
+>
+> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>
+> Thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From lloyd at writersglen.com  Wed Mar 12 23:51:04 2014
+From: lloyd at writersglen.com (lloyd at writersglen.com)
+Date: Wed, 12 Mar 2014 18:51:04 -0400 (EDT)
+Subject: [99s-extend]
+ =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?=
+ =?utf-8?q?=5Fhttp=5Fhandler_undefined?=
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+Hi Lo?c,
+
+Thanks for help.
+
+I'm running cowboy master from GitHub and Erlang R16B02.
+
+$ echo $ERL_LIBS
+
+...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+
+E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+
+I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+
+Thanks again,
+
+LRP
+
+-----Original Message-----
+From: "Lo?c Hoguin" <essen at ninenines.eu>
+Sent: Monday, March 10, 2014 4:36pm
+To: lloyd at writersglen.com, extend at lists.ninenines.eu
+Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+
+Try updating Erlang or Cowboy, this isn't the first time this happens 
+and I fixed something at some point.
+
+Also see if you have ERL_LIBS already defined, in which case there might 
+be a bug in Cowboy.
+
+On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> I've slavishly emulated the "Getting started" example in the guide:
+>
+> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>
+> But, when I compile I get this error:
+>
+> yada yada
+>   ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+> compile: warnings being treated as errors
+> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+> make: *** [ebin/hello_erlang.app] Error 1
+>
+> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>
+> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>
+> % -behavior(cowboy_http_handler).
+>
+> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>
+> Thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+
+
+From essen at ninenines.eu  Wed Mar 12 23:57:16 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 12 Mar 2014 23:57:16 +0100
+Subject: [99s-extend] Getting started error: behaviour
+ cowboy_http_handler undefined
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]> <[email protected]>
+Message-ID: <[email protected]>
+
+Can you try again after running "unset ERL_LIBS"?
+
+On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+> Hi Lo?c,
+>
+> Thanks for help.
+>
+> I'm running cowboy master from GitHub and Erlang R16B02.
+>
+> $ echo $ERL_LIBS
+>
+> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>
+> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>
+> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>
+> Thanks again,
+>
+> LRP
+>
+> -----Original Message-----
+> From: "Lo?c Hoguin" <essen at ninenines.eu>
+> Sent: Monday, March 10, 2014 4:36pm
+> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Try updating Erlang or Cowboy, this isn't the first time this happens
+> and I fixed something at some point.
+>
+> Also see if you have ERL_LIBS already defined, in which case there might
+> be a bug in Cowboy.
+>
+> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>> Hello,
+>>
+>> I've slavishly emulated the "Getting started" example in the guide:
+>>
+>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>
+>> But, when I compile I get this error:
+>>
+>> yada yada
+>>    ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>> compile: warnings being treated as errors
+>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>> make: *** [ebin/hello_erlang.app] Error 1
+>>
+>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>
+>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>
+>> % -behavior(cowboy_http_handler).
+>>
+>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>
+>> Thanks,
+>>
+>> LRP
+>>
+>>
+>> *********************************************
+>> My books:
+>>
+>> THE GOSPEL OF ASHES
+>> http://thegospelofashes.com
+>>
+>> Strength is not enough. Do they have the courage
+>> and the cunning? Can they survive long enough to
+>> save the lives of millions?
+>>
+>> FREEIN' PANCHO
+>> http://freeinpancho.com
+>>
+>> A community of misfits help a troubled boy find his way
+>>
+>> AYA TAKEO
+>> http://ayatakeo.com
+>>
+>> Star-crossed love, war and power in an alternative
+>> universe
+>>
+>> Available through Amazon or by request from your
+>> favorite bookstore
+>>
+>>
+>> **********************************************
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From lloyd at writersglen.com  Thu Mar 13 00:43:16 2014
+From: lloyd at writersglen.com (lloyd at writersglen.com)
+Date: Wed, 12 Mar 2014 19:43:16 -0400 (EDT)
+Subject: [99s-extend]
+ =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?=
+ =?utf-8?q?=5Fhttp=5Fhandler_undefined?=
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]> 
+ <[email protected]> <[email protected]>
+Message-ID: <[email protected]>
+
+Hi,
+
+That fixed it!
+
+But where can I go to understand why and prevent it in future? 
+
+I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system?
+
+Many thanks!
+
+Lloyd
+
+-----Original Message-----
+From: "Lo?c Hoguin" <essen at ninenines.eu>
+Sent: Wednesday, March 12, 2014 6:57pm
+To: lloyd at writersglen.com
+Cc: extend at lists.ninenines.eu
+Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+
+Can you try again after running "unset ERL_LIBS"?
+
+On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+> Hi Lo?c,
+>
+> Thanks for help.
+>
+> I'm running cowboy master from GitHub and Erlang R16B02.
+>
+> $ echo $ERL_LIBS
+>
+> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>
+> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>
+> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>
+> Thanks again,
+>
+> LRP
+>
+> -----Original Message-----
+> From: "Lo?c Hoguin" <essen at ninenines.eu>
+> Sent: Monday, March 10, 2014 4:36pm
+> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Try updating Erlang or Cowboy, this isn't the first time this happens
+> and I fixed something at some point.
+>
+> Also see if you have ERL_LIBS already defined, in which case there might
+> be a bug in Cowboy.
+>
+> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>> Hello,
+>>
+>> I've slavishly emulated the "Getting started" example in the guide:
+>>
+>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>
+>> But, when I compile I get this error:
+>>
+>> yada yada
+>>    ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>> compile: warnings being treated as errors
+>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>> make: *** [ebin/hello_erlang.app] Error 1
+>>
+>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>
+>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>
+>> % -behavior(cowboy_http_handler).
+>>
+>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>
+>> Thanks,
+>>
+>> LRP
+>>
+>>
+>> *********************************************
+>> My books:
+>>
+>> THE GOSPEL OF ASHES
+>> http://thegospelofashes.com
+>>
+>> Strength is not enough. Do they have the courage
+>> and the cunning? Can they survive long enough to
+>> save the lives of millions?
+>>
+>> FREEIN' PANCHO
+>> http://freeinpancho.com
+>>
+>> A community of misfits help a troubled boy find his way
+>>
+>> AYA TAKEO
+>> http://ayatakeo.com
+>>
+>> Star-crossed love, war and power in an alternative
+>> universe
+>>
+>> Available through Amazon or by request from your
+>> favorite bookstore
+>>
+>>
+>> **********************************************
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+
+
+From essen at ninenines.eu  Thu Mar 13 00:46:57 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Thu, 13 Mar 2014 00:46:57 +0100
+Subject: [99s-extend] Getting started error: behaviour
+ cowboy_http_handler undefined
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]> <[email protected]>
+Message-ID: <[email protected]>
+
+It's explained here: http://www.erlang.org/doc/man/code.html
+
+I am not sure why it caused issues on your system, possibly Erlang 
+ignored it because there was an invalid folder in there. I don't really 
+know.
+
+On 03/13/2014 12:43 AM, lloyd at writersglen.com wrote:
+> Hi,
+>
+> That fixed it!
+>
+> But where can I go to understand why and prevent it in future?
+>
+> I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system?
+>
+> Many thanks!
+>
+> Lloyd
+>
+> -----Original Message-----
+> From: "Lo?c Hoguin" <essen at ninenines.eu>
+> Sent: Wednesday, March 12, 2014 6:57pm
+> To: lloyd at writersglen.com
+> Cc: extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Can you try again after running "unset ERL_LIBS"?
+>
+> On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+>> Hi Lo?c,
+>>
+>> Thanks for help.
+>>
+>> I'm running cowboy master from GitHub and Erlang R16B02.
+>>
+>> $ echo $ERL_LIBS
+>>
+>> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>>
+>> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>>
+>> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>>
+>> Thanks again,
+>>
+>> LRP
+>>
+>> -----Original Message-----
+>> From: "Lo?c Hoguin" <essen at ninenines.eu>
+>> Sent: Monday, March 10, 2014 4:36pm
+>> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+>> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>>
+>> Try updating Erlang or Cowboy, this isn't the first time this happens
+>> and I fixed something at some point.
+>>
+>> Also see if you have ERL_LIBS already defined, in which case there might
+>> be a bug in Cowboy.
+>>
+>> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>>> Hello,
+>>>
+>>> I've slavishly emulated the "Getting started" example in the guide:
+>>>
+>>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>>
+>>> But, when I compile I get this error:
+>>>
+>>> yada yada
+>>>     ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>>> compile: warnings being treated as errors
+>>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>>> make: *** [ebin/hello_erlang.app] Error 1
+>>>
+>>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>>
+>>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>>
+>>> % -behavior(cowboy_http_handler).
+>>>
+>>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>>
+>>> Thanks,
+>>>
+>>> LRP
+>>>
+>>>
+>>> *********************************************
+>>> My books:
+>>>
+>>> THE GOSPEL OF ASHES
+>>> http://thegospelofashes.com
+>>>
+>>> Strength is not enough. Do they have the courage
+>>> and the cunning? Can they survive long enough to
+>>> save the lives of millions?
+>>>
+>>> FREEIN' PANCHO
+>>> http://freeinpancho.com
+>>>
+>>> A community of misfits help a troubled boy find his way
+>>>
+>>> AYA TAKEO
+>>> http://ayatakeo.com
+>>>
+>>> Star-crossed love, war and power in an alternative
+>>> universe
+>>>
+>>> Available through Amazon or by request from your
+>>> favorite bookstore
+>>>
+>>>
+>>> **********************************************
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From joshua.mcquistan at mcq.io  Thu Mar 13 02:41:12 2014
+From: joshua.mcquistan at mcq.io (Joshua McQuistan)
+Date: Thu, 13 Mar 2014 01:41:12 +0000
+Subject: [99s-extend] Updating Cowboy applications
+Message-ID: <[email protected]>
+
+Hello all,
+
+I have written a Cowboy application that works fine over localhost. I'm
+now looking at ways of deploying and updating it i.e., moving from dev
+to prod in a nice manner.
+
+I have dug around the archives and have found that Cowboy does not
+support hot code reloading meaning either a restart of the vm or playing
+with code:reload_file is necessary.
+
+The latter suggests a possible rewriting of OTP's code loading mechanism
+and seems like it might be sensible to avoid.
+
+The other approach then is a restart. In previous (non-Cowboy) set ups
+I've used nginx on port 80 / 443 that talks to the web app via a unix
+socket (e.g., "web/socket"). When updating I'll start a new instance on
+a new socket (e.g., "web/socket.new") then rely on the file system's
+"mv" to switch it to "web/socket"; this works because the underlying
+file system guarantees mv to be atomic (or at least to never see a
+missing file). I can then ask the old process to shut down nicely in the
+background.
+
+For this to work it would require Cowby / Ranch to be able to listen on
+unix sockets. A glance at the documentation suggests that unix sockets
+aren't available, is this the case? What's the feasibility of it getting
+added?
+
+It might just be simpler to load-balance across multiple servers and
+safely take them out one at a time while updating.
+
+My other question is, how do others approach this problem? Did I miss
+something vitally obvious?
+
+Regards,
+Joshua
+
+
+From essen at ninenines.eu  Thu Mar 13 14:22:03 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Thu, 13 Mar 2014 14:22:03 +0100
+Subject: [99s-extend] Updating Cowboy applications
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+Deploying is easy: releases.
+
+The "getting started" chapter of the guide, and all the examples use 
+that and it should be pretty easy to do.
+
+You can reload Cowboy modules directly using l(module). You can reload 
+most Ranch modules too but some of them will require using sys. Ranch 
+will get support for upgrades as soon as I finish the upgrade test 
+suite, but it's still low priority.
+
+And upgrade of Cowboy processes can only be added after we make them 
+special processes, which is still a way to go.
+
+There is no plans for supporting unix sockets for the simple reason that 
+it is not portable. On the other hand, if you use a separate library to 
+open a socket and give it to Ranch (socket option), possibly writing a 
+specific transport module for it, then it's very possible that you can 
+use unix sockets (and if it works, please do send feedback).
+
+On 03/13/2014 02:41 AM, Joshua McQuistan wrote:
+> Hello all,
+>
+> I have written a Cowboy application that works fine over localhost. I'm
+> now looking at ways of deploying and updating it i.e., moving from dev
+> to prod in a nice manner.
+>
+> I have dug around the archives and have found that Cowboy does not
+> support hot code reloading meaning either a restart of the vm or playing
+> with code:reload_file is necessary.
+>
+> The latter suggests a possible rewriting of OTP's code loading mechanism
+> and seems like it might be sensible to avoid.
+>
+> The other approach then is a restart. In previous (non-Cowboy) set ups
+> I've used nginx on port 80 / 443 that talks to the web app via a unix
+> socket (e.g., "web/socket"). When updating I'll start a new instance on
+> a new socket (e.g., "web/socket.new") then rely on the file system's
+> "mv" to switch it to "web/socket"; this works because the underlying
+> file system guarantees mv to be atomic (or at least to never see a
+> missing file). I can then ask the old process to shut down nicely in the
+> background.
+>
+> For this to work it would require Cowby / Ranch to be able to listen on
+> unix sockets. A glance at the documentation suggests that unix sockets
+> aren't available, is this the case? What's the feasibility of it getting
+> added?
+>
+> It might just be simpler to load-balance across multiple servers and
+> safely take them out one at a time while updating.
+>
+> My other question is, how do others approach this problem? Did I miss
+> something vitally obvious?
+>
+> Regards,
+> Joshua
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From joshua.mcquistan at mcq.io  Thu Mar 13 15:23:09 2014
+From: joshua.mcquistan at mcq.io (Joshua McQuistan)
+Date: Thu, 13 Mar 2014 14:23:09 +0000
+Subject: [99s-extend] Updating Cowboy applications
+In-Reply-To: <[email protected]>
+References: <[email protected]> <[email protected]>
+Message-ID: <[email protected]>
+
+> 
+> I wish I knew enough to answer your question. But I do hope you publish a tutorial documenting your solution for those following you down the trail.
+
+Will do.
+
+On 13/03/14 13:22, Lo?c Hoguin wrote:
+> 
+> There is no plans for supporting unix sockets for the simple reason that
+> it is not portable. On the other hand, if you use a separate library to
+> open a socket and give it to Ranch (socket option), possibly writing a
+> specific transport module for it, then it's very possible that you can
+> use unix sockets (and if it works, please do send feedback).
+
+I had missed this last night, I will try passing the socket down and see
+if it works.
+
+I can also see the gen_tcp:listen in ranch_tcp but I'd prefer to avoid that.
+
+
+From Christopher.Phillips at turner.com  Fri Mar 14 19:52:07 2014
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Fri, 14 Mar 2014 18:52:07 +0000
+Subject: [99s-extend] Cowboy unexpectedly timing out when reading the body
+Message-ID: <CF48C816.16B3B%[email protected]>
+
+On a dev server I had a Cowboy app suddenly start returning timeouts when calling cowboy_req:body_qs(Request), with surprising frequency, which in turn led to 500s back to the calling client. It only appeared to happen when hitting one particular resource, and was sporadic, and I was wondering if there might be some explanation related to Cowboy (as opposed to maybe really weird VM issues). For full disclosure, we would first check the body with cowboy_req:body(Request) as part of an access log, then ignore the returned cowboy_req:req() that call passed back, since we could not then stream the body off of it again. It was working fine, so I don't think it was related, but it seems more solid now after I removed it and I don't know if that's related or not.
+
+
+
+Here is an example request that dumped when the process died -
+
+
+{req,[{socket,#Port<0.7113>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1805.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{10,188,32,225},53188}},{host,<<"bps-feedschedulervip1.turner.com">>},{host_info,undefined},{port,8091},{path,<<"/encoders/Player1/record">>},{path_info,[<<"record">>]},{qs,<<"authToken=...">>},{qs_vals,[{<<"authToken">>,<<"...">>}]},{bindings,[{id,<<"Player1">>}]},{headers,[{<<"host">>,<<"bps-feedschedulervip1.turner.com:8091">>},{<<"content-type">>,<<"application/x-www-form-urlencoded; charset=UTF-8">>},{<<"origin">>,<<"http://bps-newstrondev1.turner.com">>},{<<"content-length">>,<<"48">>},{<<"connection">>,<<"keep-alive">>},{<<"accept">>,<<"application/json, text/javascript, */*; q=0.01">>},{<<"user-agent">>,<<"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9">>},{<<"referer">>,<<"http://bps-newstrondev1.turner.com/newstron/record/record.html">>},{<<"accept-language">>,<<"en-us">>},{<<"accept-encoding">>,<<"gzip, deflate">>}]},{p_headers,[{<<"content-type">>,{<<"application">>,<<"x-www-form-urlencoded">>,[{<<"charset">>,<<"utf-8">>}]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"application">>,<<"json">>,[]},1000,[]},{{<<"text">>,<<"javascript">>,[]},1000,[]},{{<<"*">>,<<"*">>,[]},10,[]}]},{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[{charset,undefined},{media_type,{<<"application">>,<<"json">>,[]}}]},{body_state,waiting},{multipart,undefined},{buffer,<<>>},{resp_compress,false},{resp_state,waiting},{resp_headers,[{<<"content-type">>,[<<"application">>,<<"/">>,<<"json">>,<<>>]},{<<"Access-Control-Allow-Origin">>,<<"*">>}]},{resp_body,<<>>},{onresponse,#Fun<access_log_responder.onresponse.4>}]}
+
+
+
+
+As I said, it may be just due to VM issues or something, but I figured I'd ask in case there was any obvious issue.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140314/b2f802d3/attachment.html>
+
+From essen at ninenines.eu  Fri Mar 14 19:56:38 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Fri, 14 Mar 2014 19:56:38 +0100
+Subject: [99s-extend] Cowboy unexpectedly timing out when reading the
+ body
+In-Reply-To: <CF48C816.16B3B%[email protected]>
+References: <CF48C816.16B3B%[email protected]>
+Message-ID: <[email protected]>
+
+Cowboy does have a timeout too small, that will be fixed soon (by making 
+it configurable, per body-reading call). It will be in the next release.
+
+On the other hand there's something weird in what you said.
+
+On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+> first check the body with cowboy_req:body(Request) as part of an access
+> log, then ignore the returned cowboy_req:req() that call passed back,
+> since we could not then stream the body off of it again. It was working
+> fine, so I don't think it was related, but it seems more solid now after
+> I removed it and I don't know if that's related or not.
+
+If you ignore the Req being returned, especially after a body-reading 
+call, then Cowboy will not be able to figure out that you actually read 
+it, and will attempt to read it again to skip it, leading to issues.
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From Christopher.Phillips at turner.com  Fri Mar 14 20:07:40 2014
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Fri, 14 Mar 2014 19:07:40 +0000
+Subject: [99s-extend] Cowboy unexpectedly timing out when reading the
+ body
+In-Reply-To: <[email protected]>
+References: <CF48C816.16B3B%[email protected]>
+ <[email protected]>
+Message-ID: <CF48CAF9.16B5A%[email protected]>
+
+  This body is -small-. 48 bytes was my test data (per the
+content-length). That shouldn't take 5 seconds to read, and usually it
+took a millisecond or two, and returned to the client (despite actually
+controlling some hardware across a network and such) within a second. And
+it was ND; I tested this thing a couple of times locally and it appeared
+to work, and even deployed onto a VM it worked some of the time (as I
+said, might have been hardware or some other weirdness).
+
+  So can we only read the body once? Or what's the right approach if I
+want to access the body in both a module registered to the
+onrequest/onresponse callbacks, and in the REST handler?
+
+On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+
+>Cowboy does have a timeout too small, that will be fixed soon (by making
+>it configurable, per body-reading call). It will be in the next release.
+>
+>On the other hand there's something weird in what you said.
+>
+>On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>> first check the body with cowboy_req:body(Request) as part of an access
+>> log, then ignore the returned cowboy_req:req() that call passed back,
+>> since we could not then stream the body off of it again. It was working
+>> fine, so I don't think it was related, but it seems more solid now after
+>> I removed it and I don't know if that's related or not.
+>
+>If you ignore the Req being returned, especially after a body-reading
+>call, then Cowboy will not be able to figure out that you actually read
+>it, and will attempt to read it again to skip it, leading to issues.
+>
+>-- 
+>Lo?c Hoguin
+>http://ninenines.eu
+
+
+
+From essen at ninenines.eu  Fri Mar 14 20:11:27 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Fri, 14 Mar 2014 20:11:27 +0100
+Subject: [99s-extend] Cowboy unexpectedly timing out when reading the
+ body
+In-Reply-To: <CF48CAF9.16B5A%[email protected]>
+References: <CF48C816.16B3B%[email protected]>
+ <[email protected]>
+ <CF48CAF9.16B5A%[email protected]>
+Message-ID: <[email protected]>
+
+Yep, only once. All functions that return {ok, ...} are like this. 
+There's no right approach, that's left as an exercise to the developer. :-)
+
+You can probably use cowboy_req:set_meta/meta if you really need to pass 
+it around.
+
+On 03/14/2014 08:07 PM, Phillips, Christopher wrote:
+>    This body is -small-. 48 bytes was my test data (per the
+> content-length). That shouldn't take 5 seconds to read, and usually it
+> took a millisecond or two, and returned to the client (despite actually
+> controlling some hardware across a network and such) within a second. And
+> it was ND; I tested this thing a couple of times locally and it appeared
+> to work, and even deployed onto a VM it worked some of the time (as I
+> said, might have been hardware or some other weirdness).
+>
+>    So can we only read the body once? Or what's the right approach if I
+> want to access the body in both a module registered to the
+> onrequest/onresponse callbacks, and in the REST handler?
+>
+> On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+>
+>> Cowboy does have a timeout too small, that will be fixed soon (by making
+>> it configurable, per body-reading call). It will be in the next release.
+>>
+>> On the other hand there's something weird in what you said.
+>>
+>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>>> first check the body with cowboy_req:body(Request) as part of an access
+>>> log, then ignore the returned cowboy_req:req() that call passed back,
+>>> since we could not then stream the body off of it again. It was working
+>>> fine, so I don't think it was related, but it seems more solid now after
+>>> I removed it and I don't know if that's related or not.
+>>
+>> If you ignore the Req being returned, especially after a body-reading
+>> call, then Cowboy will not be able to figure out that you actually read
+>> it, and will attempt to read it again to skip it, leading to issues.
+>>
+>> --
+>> Lo?c Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+
+From Christopher.Phillips at turner.com  Fri Mar 14 20:13:31 2014
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Fri, 14 Mar 2014 19:13:31 +0000
+Subject: [99s-extend] Cowboy unexpectedly timing out when reading the
+ body
+In-Reply-To: <[email protected]>
+References: <CF48C816.16B3B%[email protected]>
+ <[email protected]>
+ <CF48CAF9.16B5A%[email protected]>
+ <[email protected]>
+Message-ID: <CF48CD10.16B7C%[email protected]>
+
+  Hmm, okay. Thanks Loic.
+
+On 3/14/14, 3:11 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+
+>Yep, only once. All functions that return {ok, ...} are like this.
+>There's no right approach, that's left as an exercise to the developer.
+>:-)
+>
+>You can probably use cowboy_req:set_meta/meta if you really need to pass
+>it around.
+>
+>On 03/14/2014 08:07 PM, Phillips, Christopher wrote:
+>>    This body is -small-. 48 bytes was my test data (per the
+>> content-length). That shouldn't take 5 seconds to read, and usually it
+>> took a millisecond or two, and returned to the client (despite actually
+>> controlling some hardware across a network and such) within a second.
+>>And
+>> it was ND; I tested this thing a couple of times locally and it appeared
+>> to work, and even deployed onto a VM it worked some of the time (as I
+>> said, might have been hardware or some other weirdness).
+>>
+>>    So can we only read the body once? Or what's the right approach if I
+>> want to access the body in both a module registered to the
+>> onrequest/onresponse callbacks, and in the REST handler?
+>>
+>> On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+>>
+>>> Cowboy does have a timeout too small, that will be fixed soon (by
+>>>making
+>>> it configurable, per body-reading call). It will be in the next
+>>>release.
+>>>
+>>> On the other hand there's something weird in what you said.
+>>>
+>>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>>>> first check the body with cowboy_req:body(Request) as part of an
+>>>>access
+>>>> log, then ignore the returned cowboy_req:req() that call passed back,
+>>>> since we could not then stream the body off of it again. It was
+>>>>working
+>>>> fine, so I don't think it was related, but it seems more solid now
+>>>>after
+>>>> I removed it and I don't know if that's related or not.
+>>>
+>>> If you ignore the Req being returned, especially after a body-reading
+>>> call, then Cowboy will not be able to figure out that you actually read
+>>> it, and will attempt to read it again to skip it, leading to issues.
+>>>
+>>> --
+>>> Lo?c Hoguin
+>>> http://ninenines.eu
+>>
+>
+>-- 
+>Lo?c Hoguin
+>http://ninenines.eu
+
+
+