From jay@REDACTED Sun Jun 1 01:03:54 2014 From: jay@REDACTED (Jay Nelson) Date: Sat, 31 May 2014 16:03:54 -0700 Subject: [erlang-questions] PropEr testing of a fixed set of atoms Message-ID: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> All the PropEr documentation seems to indicate that only random generators are possible when testing. Maybe I?m missing something obvious, but I would like to do a simple exhaustive test on the following example: -type epode_dict_type() :: vbisect | dict | orddict. -spec is_dict(epode_dict_type(), any()) -> boolean(). I currently do the following to test it, assuming 6 tries will oversample the set of three values and nearly always test all three cases: -define(TM, my_dict_module). check_new_dict() -> Test_New = ?FORALL(Dict_Type, epode_dict_type(), valid_empty_dict(Dict_Type, ?TM:new(Dict_Type)), proper:quickcheck(Test_New, [{num_tests, 6}]). valid_empty_dict(Dict_Type, Dict) -> true = ?TM:is_dict(Dict_Type, Dict), 0 =:= ?TM:size(Dict). I would like a deterministic generator that would provide a list of all the dictionary types. I want to be able to update only the epode_dict_type() and have the test automatically execute for the new types. I imagine something like: ?FORALL(Dict_Type, proper:enumerate(epode_dict_type()), ?) or ?LET(Dict_Types, proper:enumerate(epode_dict_type()), [test(DT) || DT <- Dict_Types]) Are there any deterministic generators? jay From erlang@REDACTED Sun Jun 1 11:09:19 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 1 Jun 2014 11:09:19 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1401561861.18413033@apps.rackspace.com> References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: On Sat, May 31, 2014 at 8:44 PM, wrote: > Hi Joe, > > I've resorted to approach 0 many times and much appreciate the generous > help I've received from the community. Indeed, response from the author of > my Erlang bible is particularly awesome. I hope one day to be competent > enough to play it forward. > > I also spend a great deal of time in the Erlang man pages. Problem is that > I'm one of those soft-headed liberal arts types. So, I often find the man > pages near incomprehensible (and not only Erlang). Yes, I perhaps should > have taken more math classes to grasp the elegant concision. But my mind > doesn't seem to be wired that way. > > I can't tell you how many times I've looked at the foldl/n docs and tried > to understand what the hell is going on. I get the general drift, but can't > bring it down to useful code. There's just too much inside-baseball. > > As a self-taught-from-books-and-web Erlang aspirant, I find concrete > examples and well-written tutorials most helpful. This gives me leverage to > apply your approach 3. In general, the concepts of Erlang are simple enough > once I grasp them. In fact, I marvel at the pragmatic elegance. Your books > provide particularly lucid explications. But the man pages? My how I wish I > had the time and chops to write a parallel set for noobies. > > Indeed, would it be helpful if I walked through and commented on the man > doc items that give me headaches? > Absolutely - There is a problem here - which I think should be addressed as soon as possible - "It is not easy to common and ask question about man pages" - I'd really like to see commenting in the style of the real world Haskell book. If you're interested take a look at http://book.realworldhaskell.org/read/types-and-functions.html - in particular look at how comments are added to the text. The erlang man pages are generated from XML so a commenting system should be easy to make. I'd like to see questions about the man pages discussed "inside the man pages" if you see what I mean - not "outside the man pages" (ie here) ... Folds are very common there are the "iterators with an accumulator" In an imperative language you might say state = state0 for(i in x){ state = update(state, f(i)) } In erlang this is a fold fold(F, State0, X) F is a function of I and State which returns a new state, and I iterates over the values in X so fold(fun(I, S) -> I + S end, 0, L) is the same as S = 0; for(I in L){ S = S + I } This is a very common programming pattern Cheers /Joe > Many thanks again for your kind help, > > Lloyd > > -----Original Message----- > From: "Joe Armstrong" > Sent: Saturday, May 31, 2014 1:53pm > To: "Lloyd Prentice" > Cc: "Erlang-Questions Questions" > Subject: Re: [erlang-questions] How to return all records in dets > > The thing to Google for is "dets man erlang" - which should get you the man > page > (even better is to store the man pages locally and do "erl -man dets") > > You want to "list" all records (I'm not sure what list means here - it > might mean > "print" or "make a list of"). > > To make a list of all records you could say: > > dets:foldl(fun(X, L) -> [X|L] end, [], Name) > > (Most collections - ie dets, ets, dict, etc. offer some kind of fold > operation that > traverses all objects in the collection) > > To print all records > > dets:traverse(Name, fun(X) -> > io:format("~p~n",[X]), > continue > end) > > No need to worry about match specifications. > > The best place to start is usually by reading the man pages. > > Now that Erlang is is becoming popular you'll find a lot of incorrect > solutions to problems posted on stackoverlow. > > Best approach is > > 0) ask an expert > 1) read the man pages for the module, in question > 2) experiment with the functions in the man pages in the shell > 3) ask/tell this list if the manual pages are ambiguous or > incomprehensible > 4) search Google/stackoverflow > > Cheers > > /Joe > > > > On Fri, May 30, 2014 at 9:56 PM, wrote: > > > Hello, > > > > I'm cross-eyed from looking at match specifications. All I want to do is > > list all records in my small dets table. I once ran across a very neat > > query to accomplish that, but for the life can't Google it up. > > > > Can some kind soul give me a query that works? > > > > Many thanks, > > > > LRP > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Sun Jun 1 11:38:01 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sun, 1 Jun 2014 11:38:01 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: Just a thought on commenting, but adding a disqus comment section to each page might be a real quick way to enable that. Just add it to the templates you use for generating the html. Later it should also be rather easy to migrate them somewhere else if needed. -Mark On Jun 1, 2014 11:09 AM, "Joe Armstrong" wrote: > > > > On Sat, May 31, 2014 at 8:44 PM, wrote: > >> Hi Joe, >> >> I've resorted to approach 0 many times and much appreciate the generous >> help I've received from the community. Indeed, response from the author of >> my Erlang bible is particularly awesome. I hope one day to be competent >> enough to play it forward. >> >> I also spend a great deal of time in the Erlang man pages. Problem is >> that I'm one of those soft-headed liberal arts types. So, I often find the >> man pages near incomprehensible (and not only Erlang). Yes, I perhaps >> should have taken more math classes to grasp the elegant concision. But my >> mind doesn't seem to be wired that way. >> >> I can't tell you how many times I've looked at the foldl/n docs and tried >> to understand what the hell is going on. I get the general drift, but can't >> bring it down to useful code. There's just too much inside-baseball. >> >> As a self-taught-from-books-and-web Erlang aspirant, I find concrete >> examples and well-written tutorials most helpful. This gives me leverage to >> apply your approach 3. In general, the concepts of Erlang are simple enough >> once I grasp them. In fact, I marvel at the pragmatic elegance. Your books >> provide particularly lucid explications. But the man pages? My how I wish I >> had the time and chops to write a parallel set for noobies. >> >> Indeed, would it be helpful if I walked through and commented on the man >> doc items that give me headaches? >> > > Absolutely - There is a problem here - which I think should be addressed > as soon as > possible - "It is not easy to common and ask question about man pages" - > I'd really like to see commenting in the style of the real world Haskell > book. > > If you're interested take a look at > http://book.realworldhaskell.org/read/types-and-functions.html - in > particular look at how comments are added to the text. > > The erlang man pages are generated from XML so a commenting system should > be > easy to make. > > I'd like to see questions about the man pages discussed "inside the man > pages" > if you see what I mean - not "outside the man pages" (ie here) > > ... > > Folds are very common there are the "iterators with an accumulator" > > In an imperative language you might say > > state = state0 > for(i in x){ > state = update(state, f(i)) > } > > In erlang this is a fold > > fold(F, State0, X) > > F is a function of I and State which returns a new state, and I iterates > over the values in X > > so > > fold(fun(I, S) -> I + S end, 0, L) > > is the same as > > S = 0; > for(I in L){ > S = S + I > } > > This is a very common programming pattern > > Cheers > > /Joe > > > >> Many thanks again for your kind help, >> >> Lloyd >> >> -----Original Message----- >> From: "Joe Armstrong" >> Sent: Saturday, May 31, 2014 1:53pm >> To: "Lloyd Prentice" >> Cc: "Erlang-Questions Questions" >> Subject: Re: [erlang-questions] How to return all records in dets >> >> The thing to Google for is "dets man erlang" - which should get you the >> man >> page >> (even better is to store the man pages locally and do "erl -man dets") >> >> You want to "list" all records (I'm not sure what list means here - it >> might mean >> "print" or "make a list of"). >> >> To make a list of all records you could say: >> >> dets:foldl(fun(X, L) -> [X|L] end, [], Name) >> >> (Most collections - ie dets, ets, dict, etc. offer some kind of fold >> operation that >> traverses all objects in the collection) >> >> To print all records >> >> dets:traverse(Name, fun(X) -> >> io:format("~p~n",[X]), >> continue >> end) >> >> No need to worry about match specifications. >> >> The best place to start is usually by reading the man pages. >> >> Now that Erlang is is becoming popular you'll find a lot of incorrect >> solutions to problems posted on stackoverlow. >> >> Best approach is >> >> 0) ask an expert >> 1) read the man pages for the module, in question >> 2) experiment with the functions in the man pages in the shell >> 3) ask/tell this list if the manual pages are ambiguous or >> incomprehensible >> 4) search Google/stackoverflow >> >> Cheers >> >> /Joe >> >> >> >> On Fri, May 30, 2014 at 9:56 PM, wrote: >> >> > Hello, >> > >> > I'm cross-eyed from looking at match specifications. All I want to do is >> > list all records in my small dets table. I once ran across a very neat >> > query to accomplish that, but for the life can't Google it up. >> > >> > Can some kind soul give me a query that works? >> > >> > Many thanks, >> > >> > LRP >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Jun 1 13:03:10 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Jun 2014 13:03:10 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: Let?s not make the Erlang manual depend on a foreign company just for commenting. I?m not even sure I want comments, I read some of them on Real Haskell and they certainly don't look like they bring something interesting to the table. It reminded me of the comments on the PHP documentation. -- Anthony Ramine Le 1 juin 2014 ? 11:38, Mark Nijhof a ?crit : > Just a thought on commenting, but adding a disqus comment section to each page might be a real quick way to enable that. Just add it to the templates you use for generating the html. Later it should also be rather easy to migrate them somewhere else if needed. > > From mark.nijhof@REDACTED Sun Jun 1 13:58:25 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sun, 1 Jun 2014 13:58:25 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: Moderated of course, and an external dependency as an intermediate solution. It is a tested solution that works with minimal effort. Anyway just an idea On Jun 1, 2014 1:03 PM, "Anthony Ramine" wrote: > Let?s not make the Erlang manual depend on a foreign company just for > commenting. > > I?m not even sure I want comments, I read some of them on Real Haskell and > they certainly don't look like they bring something interesting to the > table. It reminded me of the comments on the PHP documentation. > > -- > Anthony Ramine > > Le 1 juin 2014 ? 11:38, Mark Nijhof a > ?crit : > > > Just a thought on commenting, but adding a disqus comment section to > each page might be a real quick way to enable that. Just add it to the > templates you use for generating the html. Later it should also be rather > easy to migrate them somewhere else if needed. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Sun Jun 1 15:59:03 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Sun, 1 Jun 2014 09:59:03 -0400 (EDT) Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: <1401631143.55221206@apps.rackspace.com> How can I help? Best, Lloyd -----Original Message----- From: "Joe Armstrong" Sent: Sunday, June 1, 2014 5:09am To: "Lloyd Prentice" Cc: "Erlang-Questions Questions" Subject: Re: [erlang-questions] How to return all records in dets On Sat, May 31, 2014 at 8:44 PM, wrote: > Hi Joe, > > I've resorted to approach 0 many times and much appreciate the generous > help I've received from the community. Indeed, response from the author of > my Erlang bible is particularly awesome. I hope one day to be competent > enough to play it forward. > > I also spend a great deal of time in the Erlang man pages. Problem is that > I'm one of those soft-headed liberal arts types. So, I often find the man > pages near incomprehensible (and not only Erlang). Yes, I perhaps should > have taken more math classes to grasp the elegant concision. But my mind > doesn't seem to be wired that way. > > I can't tell you how many times I've looked at the foldl/n docs and tried > to understand what the hell is going on. I get the general drift, but can't > bring it down to useful code. There's just too much inside-baseball. > > As a self-taught-from-books-and-web Erlang aspirant, I find concrete > examples and well-written tutorials most helpful. This gives me leverage to > apply your approach 3. In general, the concepts of Erlang are simple enough > once I grasp them. In fact, I marvel at the pragmatic elegance. Your books > provide particularly lucid explications. But the man pages? My how I wish I > had the time and chops to write a parallel set for noobies. > > Indeed, would it be helpful if I walked through and commented on the man > doc items that give me headaches? > Absolutely - There is a problem here - which I think should be addressed as soon as possible - "It is not easy to common and ask question about man pages" - I'd really like to see commenting in the style of the real world Haskell book. If you're interested take a look at http://book.realworldhaskell.org/read/types-and-functions.html - in particular look at how comments are added to the text. The erlang man pages are generated from XML so a commenting system should be easy to make. I'd like to see questions about the man pages discussed "inside the man pages" if you see what I mean - not "outside the man pages" (ie here) ... Folds are very common there are the "iterators with an accumulator" In an imperative language you might say state = state0 for(i in x){ state = update(state, f(i)) } In erlang this is a fold fold(F, State0, X) F is a function of I and State which returns a new state, and I iterates over the values in X so fold(fun(I, S) -> I + S end, 0, L) is the same as S = 0; for(I in L){ S = S + I } This is a very common programming pattern Cheers /Joe > Many thanks again for your kind help, > > Lloyd > > -----Original Message----- > From: "Joe Armstrong" > Sent: Saturday, May 31, 2014 1:53pm > To: "Lloyd Prentice" > Cc: "Erlang-Questions Questions" > Subject: Re: [erlang-questions] How to return all records in dets > > The thing to Google for is "dets man erlang" - which should get you the man > page > (even better is to store the man pages locally and do "erl -man dets") > > You want to "list" all records (I'm not sure what list means here - it > might mean > "print" or "make a list of"). > > To make a list of all records you could say: > > dets:foldl(fun(X, L) -> [X|L] end, [], Name) > > (Most collections - ie dets, ets, dict, etc. offer some kind of fold > operation that > traverses all objects in the collection) > > To print all records > > dets:traverse(Name, fun(X) -> > io:format("~p~n",[X]), > continue > end) > > No need to worry about match specifications. > > The best place to start is usually by reading the man pages. > > Now that Erlang is is becoming popular you'll find a lot of incorrect > solutions to problems posted on stackoverlow. > > Best approach is > > 0) ask an expert > 1) read the man pages for the module, in question > 2) experiment with the functions in the man pages in the shell > 3) ask/tell this list if the manual pages are ambiguous or > incomprehensible > 4) search Google/stackoverflow > > Cheers > > /Joe > > > > On Fri, May 30, 2014 at 9:56 PM, wrote: > > > Hello, > > > > I'm cross-eyed from looking at match specifications. All I want to do is > > list all records in my small dets table. I once ran across a very neat > > query to accomplish that, but for the life can't Google it up. > > > > Can some kind soul give me a query that works? > > > > Many thanks, > > > > LRP > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > From essen@REDACTED Sun Jun 1 16:04:46 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 01 Jun 2014 16:04:46 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: <538B32FE.1000606@ninenines.eu> I'm all for comments, but I don't see how it would be at all usable using disqus. Take this page for example: http://www.erlang.org/doc/man/erlang.html Where do you put the comments? They're going to be unnoticed, and they're going to cover a wealth of different topics so much that they'll become entirely useless. Make one comment zone per function? Disqus is already painfully slow to load when there's one, so imagine 50 or 100. Joe's solution is nice and tidy on the other hand. But there's one problem though, who's going to moderate? There's no real quick way to that kind of stuff. At least not with this amount of content. On 06/01/2014 11:38 AM, Mark Nijhof wrote: > Just a thought on commenting, but adding a disqus comment section to > each page might be a real quick way to enable that. Just add it to the > templates you use for generating the html. Later it should also be > rather easy to migrate them somewhere else if needed. > > -Mark > > On Jun 1, 2014 11:09 AM, "Joe Armstrong" > wrote: > > > > > On Sat, May 31, 2014 at 8:44 PM, > wrote: > > Hi Joe, > > I've resorted to approach 0 many times and much appreciate the > generous help I've received from the community. Indeed, response > from the author of my Erlang bible is particularly awesome. I > hope one day to be competent enough to play it forward. > > I also spend a great deal of time in the Erlang man pages. > Problem is that I'm one of those soft-headed liberal arts types. > So, I often find the man pages near incomprehensible (and not > only Erlang). Yes, I perhaps should have taken more math classes > to grasp the elegant concision. But my mind doesn't seem to be > wired that way. > > I can't tell you how many times I've looked at the foldl/n docs > and tried to understand what the hell is going on. I get the > general drift, but can't bring it down to useful code. There's > just too much inside-baseball. > > As a self-taught-from-books-and-web Erlang aspirant, I find > concrete examples and well-written tutorials most helpful. This > gives me leverage to apply your approach 3. In general, the > concepts of Erlang are simple enough once I grasp them. In fact, > I marvel at the pragmatic elegance. Your books provide > particularly lucid explications. But the man pages? My how I > wish I had the time and chops to write a parallel set for noobies. > > Indeed, would it be helpful if I walked through and commented on > the man doc items that give me headaches? > > > Absolutely - There is a problem here - which I think should be > addressed as soon as > possible - "It is not easy to common and ask question about man pages" - > I'd really like to see commenting in the style of the real world > Haskell book. > > If you're interested take a look at > http://book.realworldhaskell.org/read/types-and-functions.html - in > particular look at how comments are added to the text. > > The erlang man pages are generated from XML so a commenting system > should be > easy to make. > > I'd like to see questions about the man pages discussed "inside the > man pages" > if you see what I mean - not "outside the man pages" (ie here) > ... > > Folds are very common there are the "iterators with an accumulator" > > In an imperative language you might say > state = state0 > for(i in x){ > state = update(state, f(i)) > } > > In erlang this is a fold > > fold(F, State0, X) > > F is a function of I and State which returns a new state, and I iterates > over the values in X > > so > > fold(fun(I, S) -> I + S end, 0, L) > > is the same as > > S = 0; > for(I in L){ > S = S + I > } > > This is a very common programming pattern > > Cheers > > /Joe > > > > Many thanks again for your kind help, > > Lloyd > > -----Original Message----- > From: "Joe Armstrong" > > Sent: Saturday, May 31, 2014 1:53pm > To: "Lloyd Prentice" > > Cc: "Erlang-Questions Questions" > > Subject: Re: [erlang-questions] How to return all records in dets > > The thing to Google for is "dets man erlang" - which should get > you the man > page > (even better is to store the man pages locally and do "erl -man > dets") > > You want to "list" all records (I'm not sure what list means > here - it > might mean > "print" or "make a list of"). > > To make a list of all records you could say: > > dets:foldl(fun(X, L) -> [X|L] end, [], Name) > > (Most collections - ie dets, ets, dict, etc. offer some kind of fold > operation that > traverses all objects in the collection) > > To print all records > > dets:traverse(Name, fun(X) -> > io:format("~p~n",[X]), > continue > end) > > No need to worry about match specifications. > > The best place to start is usually by reading the man pages. > > Now that Erlang is is becoming popular you'll find a lot of > incorrect > solutions to problems posted on stackoverlow. > > Best approach is > > 0) ask an expert > 1) read the man pages for the module, in question > 2) experiment with the functions in the man pages in the shell > 3) ask/tell this list if the manual pages are ambiguous or > incomprehensible > 4) search Google/stackoverflow > > Cheers > > /Joe > > > > On Fri, May 30, 2014 at 9:56 PM, > wrote: > > > Hello, > > > > I'm cross-eyed from looking at match specifications. All I > want to do is > > list all records in my small dets table. I once ran across a > very neat > > query to accomplish that, but for the life can't Google it up. > > > > Can some kind soul give me a query that works? > > > > Many thanks, > > > > LRP > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From lloyd@REDACTED Sun Jun 1 19:18:30 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Sun, 1 Jun 2014 13:18:30 -0400 (EDT) Subject: [erlang-questions] How to return all records in dets In-Reply-To: <538B32FE.1000606@ninenines.eu> References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> <538B32FE.1000606@ninenines.eu> Message-ID: <1401643110.963516080@apps.rackspace.com> Hi Lo?c, Seems to me that there are four issues here: - Who are the Erlang docs (man pages and/other authoritative guides) intended to serve? As a not-so-noobie-but-still-vastly-ignorant Erlang aspirant, I can say that current man pages, while helpful to a degree, leave much to be desired. - How can Erlang docs provide greater clarity to intended audiences? From my point-of-view they could provide more examples, say three or four across a range of simplest possible application of the function to a golly-gee-wiz-this-function-can-do-this example Don't forget to note why and where this module/function is useful. Great gains would be come, in my view, by backing up man pages with authoritative noobie-friendly tutorials. By authoritative I mean dated, 100% functional, expressing best practices Lo?c, ask me, you have been doing a great job in this regard with Cowboy. - From a technical point-of-view, how can Erlang docs be maintained most conveniently I can't speak to this other than harness the power of the language. I do think there needs to be three tracks: a template or policy statement for consistent, quality docs, man pages, and tutorials - From a community point of view, who does all this? This is the 64-dollar-question that every volunteer organization faces. Part of the problem of mobilizing a volunteer community is cultivating community spirit. That comes down to determining how everyone stands to gain by participating. I think we all know this. But it may require frequent reminders. It's also very important to serve the noobies well. I saw the vibrant forth community die out, in part, because it failed in this. I see Erlang as a humongous toolkit that includes a vast range including use-everyday tools to use-once-in-a-career exotic. So a good place to start is setting priorities and putting out calls of what needs to be done next. Keep the focus small and keep the pressure on. I have no doubt that the committed brilliant folks in the community will respond if they have a clear sense of direction. Who sets the direction? Whoever will step up. My two cents for what it's worth. Thanks to all, Lloyd -----Original Message----- From: "Lo?c Hoguin" Sent: Sunday, June 1, 2014 10:04am To: "Mark Nijhof" , "Joe Armstrong" Cc: "Erlang Users' List" Subject: Re: [erlang-questions] How to return all records in dets I'm all for comments, but I don't see how it would be at all usable using disqus. Take this page for example: http://www.erlang.org/doc/man/erlang.html Where do you put the comments? They're going to be unnoticed, and they're going to cover a wealth of different topics so much that they'll become entirely useless. Make one comment zone per function? Disqus is already painfully slow to load when there's one, so imagine 50 or 100. Joe's solution is nice and tidy on the other hand. But there's one problem though, who's going to moderate? There's no real quick way to that kind of stuff. At least not with this amount of content. On 06/01/2014 11:38 AM, Mark Nijhof wrote: > Just a thought on commenting, but adding a disqus comment section to > each page might be a real quick way to enable that. Just add it to the > templates you use for generating the html. Later it should also be > rather easy to migrate them somewhere else if needed. > > -Mark > > On Jun 1, 2014 11:09 AM, "Joe Armstrong" > wrote: > > > > > On Sat, May 31, 2014 at 8:44 PM, > wrote: > > Hi Joe, > > I've resorted to approach 0 many times and much appreciate the > generous help I've received from the community. Indeed, response > from the author of my Erlang bible is particularly awesome. I > hope one day to be competent enough to play it forward. > > I also spend a great deal of time in the Erlang man pages. > Problem is that I'm one of those soft-headed liberal arts types. > So, I often find the man pages near incomprehensible (and not > only Erlang). Yes, I perhaps should have taken more math classes > to grasp the elegant concision. But my mind doesn't seem to be > wired that way. > > I can't tell you how many times I've looked at the foldl/n docs > and tried to understand what the hell is going on. I get the > general drift, but can't bring it down to useful code. There's > just too much inside-baseball. > > As a self-taught-from-books-and-web Erlang aspirant, I find > concrete examples and well-written tutorials most helpful. This > gives me leverage to apply your approach 3. In general, the > concepts of Erlang are simple enough once I grasp them. In fact, > I marvel at the pragmatic elegance. Your books provide > particularly lucid explications. But the man pages? My how I > wish I had the time and chops to write a parallel set for noobies. > > Indeed, would it be helpful if I walked through and commented on > the man doc items that give me headaches? > > > Absolutely - There is a problem here - which I think should be > addressed as soon as > possible - "It is not easy to common and ask question about man pages" - > I'd really like to see commenting in the style of the real world > Haskell book. > > If you're interested take a look at > http://book.realworldhaskell.org/read/types-and-functions.html - in > particular look at how comments are added to the text. > > The erlang man pages are generated from XML so a commenting system > should be > easy to make. > > I'd like to see questions about the man pages discussed "inside the > man pages" > if you see what I mean - not "outside the man pages" (ie here) > ... > > Folds are very common there are the "iterators with an accumulator" > > In an imperative language you might say > state = state0 > for(i in x){ > state = update(state, f(i)) > } > > In erlang this is a fold > > fold(F, State0, X) > > F is a function of I and State which returns a new state, and I iterates > over the values in X > > so > > fold(fun(I, S) -> I + S end, 0, L) > > is the same as > > S = 0; > for(I in L){ > S = S + I > } > > This is a very common programming pattern > > Cheers > > /Joe > > > > Many thanks again for your kind help, > > Lloyd > > -----Original Message----- > From: "Joe Armstrong" > > Sent: Saturday, May 31, 2014 1:53pm > To: "Lloyd Prentice" > > Cc: "Erlang-Questions Questions" > > Subject: Re: [erlang-questions] How to return all records in dets > > The thing to Google for is "dets man erlang" - which should get > you the man > page > (even better is to store the man pages locally and do "erl -man > dets") > > You want to "list" all records (I'm not sure what list means > here - it > might mean > "print" or "make a list of"). > > To make a list of all records you could say: > > dets:foldl(fun(X, L) -> [X|L] end, [], Name) > > (Most collections - ie dets, ets, dict, etc. offer some kind of fold > operation that > traverses all objects in the collection) > > To print all records > > dets:traverse(Name, fun(X) -> > io:format("~p~n",[X]), > continue > end) > > No need to worry about match specifications. > > The best place to start is usually by reading the man pages. > > Now that Erlang is is becoming popular you'll find a lot of > incorrect > solutions to problems posted on stackoverlow. > > Best approach is > > 0) ask an expert > 1) read the man pages for the module, in question > 2) experiment with the functions in the man pages in the shell > 3) ask/tell this list if the manual pages are ambiguous or > incomprehensible > 4) search Google/stackoverflow > > Cheers > > /Joe > > > > On Fri, May 30, 2014 at 9:56 PM, > wrote: > > > Hello, > > > > I'm cross-eyed from looking at match specifications. All I > want to do is > > list all records in my small dets table. I once ran across a > very neat > > query to accomplish that, but for the life can't Google it up. > > > > Can some kind soul give me a query that works? > > > > Many thanks, > > > > LRP > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Sun Jun 1 19:47:01 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 01 Jun 2014 10:47:01 -0700 Subject: [erlang-questions] [ANN] CloudI 1.3.2 Released! Message-ID: <538B6715.1080006@gmail.com> Download 1.3.2 from http://sourceforge.net/projects/cloudi/files/latest/download (checksums at the bottom of this email) CloudI (http://cloudi.org/) is a "universal integrator" using an Erlang core, with its actor model, to pursue efficiency, fault-tolerance and scalability. The CloudI API provides a minimal interface to communicate among actors that are called services (long-lived processes), so programming language agnostic, database agnostic, and messaging bus agnostic integration can occur. CloudI currently integrates with the programming languages Erlang, C/C++, Java, Python, and Ruby, the databases PostgreSQL, elasticsearch, Cassandra, MySQL, couchdb, memcached, and tokyotyrant, the messaging bus ZeroMQ, websockets, and the internal CloudI service bus. HTTP is supported with both cowboy and elli integration. Thanks for the various feedback/issues/bugs that have been reported. The details for this release are below: May 31, 2014 Version 1.3.2 (beta) released. * Fixes for Erlang/OTP 17.0 compilation * Improved node auto-discovery functionality and configuration * Add cloudi_service_api:nodes_set/2 for dynamically configuring CloudI nodes configuration * EC2 node discovery now works as expected, selecting based on tags and/or security groups * Allow node connections to be hidden for more complex network topologies (see http://cloudi.org/api.html#2_nodes_set) * Add cloudi_service_queue for persistent queuing of service requests with CT tests * Add cloudi_service_filesystem file update notification service requests (see notify_one and notify_all configuration) * The cloudi_service_http_cowboy service has many different additions: * Added websocket_protocol for creating a mapping between a protocol id and the TransId of websocket service requests to avoid contention * Added websocket_subscriptions for adding additional websocket connection subscriptions for receiving service requests, conditional on the connection URL (to simplify messaging to groups of websockets) * websocket_connect and websocket_disconnect can be set to be either async or sync service requests * use_websockets == exclusively for only using websockets * Add service name pattern support to cloudi_service_router (to map from a service name pattern to a new service name destination) * The cloudi_service_db_pgsql now provides either the https://github.com/semiocast/pgsql or https://github.com/wg/epgsql driver along with a separate confguration option for providing common output * Log output now reflects the default (tuple) service configuration format * Various bugfixes, small additions, and documentation improvements Please mention any problems, issues, or ideas! Thanks, Michael SHA256 CHECKSUMS 893bb95012a1bf9772de9ca959462c66e836e1263b85d6340792b3c008bf726b cloudi-1.3.2.tar.bz2 bd73e6859264d75a0e0cd64df8a1bda32a8c5e19863b9091f9c93d64ac9752b1 cloudi-1.3.2.tar.gz From g@REDACTED Sun Jun 1 20:00:01 2014 From: g@REDACTED (Garrett Smith) Date: Sun, 1 Jun 2014 13:00:01 -0500 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1401643110.963516080@apps.rackspace.com> References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> <538B32FE.1000606@ninenines.eu> <1401643110.963516080@apps.rackspace.com> Message-ID: Given the effort of installing a commenting facility, not to mention the gamble that anyone will find this useful, why not submit a pull request for the applicable doc page? I haven't done this, so maybe installing a commenting facility *is* easier. But it seems like one could write a sentence or two to clarify how a module might be used. And add an example or two on how a function might be used. This strike me as being a pretty direct solution to the problem you're raising. Ease of making these changes and then getting them integrated is of course the big question. If it's a substantial barrier, lowering that friction is something probably worth investing in. As to moderation, if the docs were under a separate commit policy (separate repo?) members of the community could pitch in directly, saving the OTP time some hassle. On Sun, Jun 1, 2014 at 12:18 PM, wrote: > Hi Lo?c, > > Seems to me that there are four issues here: > > - Who are the Erlang docs (man pages and/other authoritative guides) intended to serve? > > As a not-so-noobie-but-still-vastly-ignorant Erlang aspirant, I can say that current man pages, while helpful to a degree, leave much to be desired. > > - How can Erlang docs provide greater clarity to intended audiences? > > From my point-of-view they could provide more examples, say three or four across a range of simplest possible application of the function to a golly-gee-wiz-this-function-can-do-this example > > Don't forget to note why and where this module/function is useful. > > Great gains would be come, in my view, by backing up man pages with authoritative noobie-friendly tutorials. By authoritative I mean dated, 100% functional, expressing best practices > > Lo?c, ask me, you have been doing a great job in this regard with Cowboy. > > - From a technical point-of-view, how can Erlang docs be maintained most conveniently > > I can't speak to this other than harness the power of the language. I do think there needs to be three tracks: a template or policy statement for consistent, quality docs, man pages, and tutorials > > - From a community point of view, who does all this? > > This is the 64-dollar-question that every volunteer organization faces. > > Part of the problem of mobilizing a volunteer community is cultivating community spirit. That comes down to determining how everyone stands to gain by participating. I think we all know this. But it may require frequent reminders. > > It's also very important to serve the noobies well. I saw the vibrant forth community die out, in part, because it failed in this. > > I see Erlang as a humongous toolkit that includes a vast range including use-everyday tools to use-once-in-a-career exotic. So a good place to start is setting priorities and putting out calls of what needs to be done next. Keep the focus small and keep the pressure on. I have no doubt that the committed brilliant folks in the community will respond if they have a clear sense of direction. Who sets the direction? Whoever will step up. > > My two cents for what it's worth. > > Thanks to all, > > Lloyd > > -----Original Message----- > From: "Lo?c Hoguin" > Sent: Sunday, June 1, 2014 10:04am > To: "Mark Nijhof" , "Joe Armstrong" > Cc: "Erlang Users' List" > Subject: Re: [erlang-questions] How to return all records in dets > > I'm all for comments, but I don't see how it would be at all usable > using disqus. Take this page for example: > http://www.erlang.org/doc/man/erlang.html > > Where do you put the comments? They're going to be unnoticed, and > they're going to cover a wealth of different topics so much that they'll > become entirely useless. > > Make one comment zone per function? Disqus is already painfully slow to > load when there's one, so imagine 50 or 100. > > Joe's solution is nice and tidy on the other hand. But there's one > problem though, who's going to moderate? > > There's no real quick way to that kind of stuff. At least not with this > amount of content. > > On 06/01/2014 11:38 AM, Mark Nijhof wrote: >> Just a thought on commenting, but adding a disqus comment section to >> each page might be a real quick way to enable that. Just add it to the >> templates you use for generating the html. Later it should also be >> rather easy to migrate them somewhere else if needed. >> >> -Mark >> >> On Jun 1, 2014 11:09 AM, "Joe Armstrong" > > wrote: >> >> >> >> >> On Sat, May 31, 2014 at 8:44 PM, > > wrote: >> >> Hi Joe, >> >> I've resorted to approach 0 many times and much appreciate the >> generous help I've received from the community. Indeed, response >> from the author of my Erlang bible is particularly awesome. I >> hope one day to be competent enough to play it forward. >> >> I also spend a great deal of time in the Erlang man pages. >> Problem is that I'm one of those soft-headed liberal arts types. >> So, I often find the man pages near incomprehensible (and not >> only Erlang). Yes, I perhaps should have taken more math classes >> to grasp the elegant concision. But my mind doesn't seem to be >> wired that way. >> >> I can't tell you how many times I've looked at the foldl/n docs >> and tried to understand what the hell is going on. I get the >> general drift, but can't bring it down to useful code. There's >> just too much inside-baseball. >> >> As a self-taught-from-books-and-web Erlang aspirant, I find >> concrete examples and well-written tutorials most helpful. This >> gives me leverage to apply your approach 3. In general, the >> concepts of Erlang are simple enough once I grasp them. In fact, >> I marvel at the pragmatic elegance. Your books provide >> particularly lucid explications. But the man pages? My how I >> wish I had the time and chops to write a parallel set for noobies. >> >> Indeed, would it be helpful if I walked through and commented on >> the man doc items that give me headaches? >> >> >> Absolutely - There is a problem here - which I think should be >> addressed as soon as >> possible - "It is not easy to common and ask question about man pages" - >> I'd really like to see commenting in the style of the real world >> Haskell book. >> >> If you're interested take a look at >> http://book.realworldhaskell.org/read/types-and-functions.html - in >> particular look at how comments are added to the text. >> >> The erlang man pages are generated from XML so a commenting system >> should be >> easy to make. >> >> I'd like to see questions about the man pages discussed "inside the >> man pages" >> if you see what I mean - not "outside the man pages" (ie here) >> ... >> >> Folds are very common there are the "iterators with an accumulator" >> >> In an imperative language you might say >> state = state0 >> for(i in x){ >> state = update(state, f(i)) >> } >> >> In erlang this is a fold >> >> fold(F, State0, X) >> >> F is a function of I and State which returns a new state, and I iterates >> over the values in X >> >> so >> >> fold(fun(I, S) -> I + S end, 0, L) >> >> is the same as >> >> S = 0; >> for(I in L){ >> S = S + I >> } >> >> This is a very common programming pattern >> >> Cheers >> >> /Joe >> >> >> >> Many thanks again for your kind help, >> >> Lloyd >> >> -----Original Message----- >> From: "Joe Armstrong" > >> Sent: Saturday, May 31, 2014 1:53pm >> To: "Lloyd Prentice" > > >> Cc: "Erlang-Questions Questions" > > >> Subject: Re: [erlang-questions] How to return all records in dets >> >> The thing to Google for is "dets man erlang" - which should get >> you the man >> page >> (even better is to store the man pages locally and do "erl -man >> dets") >> >> You want to "list" all records (I'm not sure what list means >> here - it >> might mean >> "print" or "make a list of"). >> >> To make a list of all records you could say: >> >> dets:foldl(fun(X, L) -> [X|L] end, [], Name) >> >> (Most collections - ie dets, ets, dict, etc. offer some kind of fold >> operation that >> traverses all objects in the collection) >> >> To print all records >> >> dets:traverse(Name, fun(X) -> >> io:format("~p~n",[X]), >> continue >> end) >> >> No need to worry about match specifications. >> >> The best place to start is usually by reading the man pages. >> >> Now that Erlang is is becoming popular you'll find a lot of >> incorrect >> solutions to problems posted on stackoverlow. >> >> Best approach is >> >> 0) ask an expert >> 1) read the man pages for the module, in question >> 2) experiment with the functions in the man pages in the shell >> 3) ask/tell this list if the manual pages are ambiguous or >> incomprehensible >> 4) search Google/stackoverflow >> >> Cheers >> >> /Joe >> >> >> >> On Fri, May 30, 2014 at 9:56 PM, > > wrote: >> >> > Hello, >> > >> > I'm cross-eyed from looking at match specifications. All I >> want to do is >> > list all records in my small dets table. I once ran across a >> very neat >> > query to accomplish that, but for the life can't Google it up. >> > >> > Can some kind soul give me a query that works? >> > >> > Many thanks, >> > >> > LRP >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lloyd@REDACTED Sun Jun 1 22:09:25 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 1 Jun 2014 16:09:25 -0400 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> Message-ID: Thank you, Joe, So lucid. Wish there was a place where we could capture this so it's easy to find. At cost of some programming, perhaps an index page into a set of wikis would be a way of capturing tutorials. Best wishes, Lloyd Sent from my iPad > On Jun 1, 2014, at 5:09 AM, Joe Armstrong wrote: > > > > >> On Sat, May 31, 2014 at 8:44 PM, wrote: >> Hi Joe, >> >> I've resorted to approach 0 many times and much appreciate the generous help I've received from the community. Indeed, response from the author of my Erlang bible is particularly awesome. I hope one day to be competent enough to play it forward. >> >> I also spend a great deal of time in the Erlang man pages. Problem is that I'm one of those soft-headed liberal arts types. So, I often find the man pages near incomprehensible (and not only Erlang). Yes, I perhaps should have taken more math classes to grasp the elegant concision. But my mind doesn't seem to be wired that way. >> >> I can't tell you how many times I've looked at the foldl/n docs and tried to understand what the hell is going on. I get the general drift, but can't bring it down to useful code. There's just too much inside-baseball. >> >> As a self-taught-from-books-and-web Erlang aspirant, I find concrete examples and well-written tutorials most helpful. This gives me leverage to apply your approach 3. In general, the concepts of Erlang are simple enough once I grasp them. In fact, I marvel at the pragmatic elegance. Your books provide particularly lucid explications. But the man pages? My how I wish I had the time and chops to write a parallel set for noobies. >> >> Indeed, would it be helpful if I walked through and commented on the man doc items that give me headaches? > > Absolutely - There is a problem here - which I think should be addressed as soon as > possible - "It is not easy to common and ask question about man pages" - > I'd really like to see commenting in the style of the real world Haskell book. > > If you're interested take a look at http://book.realworldhaskell.org/read/types-and-functions.html - in particular look at how comments are added to the text. > > The erlang man pages are generated from XML so a commenting system should be > easy to make. > > I'd like to see questions about the man pages discussed "inside the man pages" > if you see what I mean - not "outside the man pages" (ie here) > > ... > > Folds are very common there are the "iterators with an accumulator" > > In an imperative language you might say > > state = state0 > for(i in x){ > state = update(state, f(i)) > } > > In erlang this is a fold > > fold(F, State0, X) > > F is a function of I and State which returns a new state, and I iterates > over the values in X > > so > > fold(fun(I, S) -> I + S end, 0, L) > > is the same as > > S = 0; > for(I in L){ > S = S + I > } > > This is a very common programming pattern > > Cheers > > /Joe > > >> >> Many thanks again for your kind help, >> >> Lloyd >> >> -----Original Message----- >> From: "Joe Armstrong" >> Sent: Saturday, May 31, 2014 1:53pm >> To: "Lloyd Prentice" >> Cc: "Erlang-Questions Questions" >> Subject: Re: [erlang-questions] How to return all records in dets >> >> The thing to Google for is "dets man erlang" - which should get you the man >> page >> (even better is to store the man pages locally and do "erl -man dets") >> >> You want to "list" all records (I'm not sure what list means here - it >> might mean >> "print" or "make a list of"). >> >> To make a list of all records you could say: >> >> dets:foldl(fun(X, L) -> [X|L] end, [], Name) >> >> (Most collections - ie dets, ets, dict, etc. offer some kind of fold >> operation that >> traverses all objects in the collection) >> >> To print all records >> >> dets:traverse(Name, fun(X) -> >> io:format("~p~n",[X]), >> continue >> end) >> >> No need to worry about match specifications. >> >> The best place to start is usually by reading the man pages. >> >> Now that Erlang is is becoming popular you'll find a lot of incorrect >> solutions to problems posted on stackoverlow. >> >> Best approach is >> >> 0) ask an expert >> 1) read the man pages for the module, in question >> 2) experiment with the functions in the man pages in the shell >> 3) ask/tell this list if the manual pages are ambiguous or >> incomprehensible >> 4) search Google/stackoverflow >> >> Cheers >> >> /Joe >> >> >> >> On Fri, May 30, 2014 at 9:56 PM, wrote: >> >> > Hello, >> > >> > I'm cross-eyed from looking at match specifications. All I want to do is >> > list all records in my small dets table. I once ran across a very neat >> > query to accomplish that, but for the life can't Google it up. >> > >> > Can some kind soul give me a query that works? >> > >> > Many thanks, >> > >> > LRP >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Sun Jun 1 22:17:30 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 1 Jun 2014 16:17:30 -0400 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> <538B32FE.1000606@ninenines.eu> <1401643110.963516080@apps.rackspace.com> Message-ID: Hi Garrett, Sounds promising. It crossed my mind that with your experience with surveys, we could run an annual survey to determine most-pressing documentation needs; e.g., by library and/or programming technique. Then use the results of the survey to rally/recruit community talent. Second thought, suppose there was an annual college internship program where interns could be teamed with wizard/gurus. How to set it up and manage? Beats me. Just dreaming. Best, L. Sent from my iPad > On Jun 1, 2014, at 2:00 PM, Garrett Smith wrote: > > Given the effort of installing a commenting facility, not to mention > the gamble that anyone will find this useful, why not submit a pull > request for the applicable doc page? > > I haven't done this, so maybe installing a commenting facility *is* easier. > > But it seems like one could write a sentence or two to clarify how a > module might be used. And add an example or two on how a function > might be used. This strike me as being a pretty direct solution to the > problem you're raising. > > Ease of making these changes and then getting them integrated is of > course the big question. If it's a substantial barrier, lowering that > friction is something probably worth investing in. > > As to moderation, if the docs were under a separate commit policy > (separate repo?) members of the community could pitch in directly, > saving the OTP time some hassle. > >> On Sun, Jun 1, 2014 at 12:18 PM, wrote: >> Hi Lo?c, >> >> Seems to me that there are four issues here: >> >> - Who are the Erlang docs (man pages and/other authoritative guides) intended to serve? >> >> As a not-so-noobie-but-still-vastly-ignorant Erlang aspirant, I can say that current man pages, while helpful to a degree, leave much to be desired. >> >> - How can Erlang docs provide greater clarity to intended audiences? >> >> From my point-of-view they could provide more examples, say three or four across a range of simplest possible application of the function to a golly-gee-wiz-this-function-can-do-this example >> >> Don't forget to note why and where this module/function is useful. >> >> Great gains would be come, in my view, by backing up man pages with authoritative noobie-friendly tutorials. By authoritative I mean dated, 100% functional, expressing best practices >> >> Lo?c, ask me, you have been doing a great job in this regard with Cowboy. >> >> - From a technical point-of-view, how can Erlang docs be maintained most conveniently >> >> I can't speak to this other than harness the power of the language. I do think there needs to be three tracks: a template or policy statement for consistent, quality docs, man pages, and tutorials >> >> - From a community point of view, who does all this? >> >> This is the 64-dollar-question that every volunteer organization faces. >> >> Part of the problem of mobilizing a volunteer community is cultivating community spirit. That comes down to determining how everyone stands to gain by participating. I think we all know this. But it may require frequent reminders. >> >> It's also very important to serve the noobies well. I saw the vibrant forth community die out, in part, because it failed in this. >> >> I see Erlang as a humongous toolkit that includes a vast range including use-everyday tools to use-once-in-a-career exotic. So a good place to start is setting priorities and putting out calls of what needs to be done next. Keep the focus small and keep the pressure on. I have no doubt that the committed brilliant folks in the community will respond if they have a clear sense of direction. Who sets the direction? Whoever will step up. >> >> My two cents for what it's worth. >> >> Thanks to all, >> >> Lloyd >> >> -----Original Message----- >> From: "Lo?c Hoguin" >> Sent: Sunday, June 1, 2014 10:04am >> To: "Mark Nijhof" , "Joe Armstrong" >> Cc: "Erlang Users' List" >> Subject: Re: [erlang-questions] How to return all records in dets >> >> I'm all for comments, but I don't see how it would be at all usable >> using disqus. Take this page for example: >> http://www.erlang.org/doc/man/erlang.html >> >> Where do you put the comments? They're going to be unnoticed, and >> they're going to cover a wealth of different topics so much that they'll >> become entirely useless. >> >> Make one comment zone per function? Disqus is already painfully slow to >> load when there's one, so imagine 50 or 100. >> >> Joe's solution is nice and tidy on the other hand. But there's one >> problem though, who's going to moderate? >> >> There's no real quick way to that kind of stuff. At least not with this >> amount of content. >> >>> On 06/01/2014 11:38 AM, Mark Nijhof wrote: >>> Just a thought on commenting, but adding a disqus comment section to >>> each page might be a real quick way to enable that. Just add it to the >>> templates you use for generating the html. Later it should also be >>> rather easy to migrate them somewhere else if needed. >>> >>> -Mark >>> >>> On Jun 1, 2014 11:09 AM, "Joe Armstrong" >> > wrote: >>> >>> >>> >>> >>> On Sat, May 31, 2014 at 8:44 PM, >> > wrote: >>> >>> Hi Joe, >>> >>> I've resorted to approach 0 many times and much appreciate the >>> generous help I've received from the community. Indeed, response >>> from the author of my Erlang bible is particularly awesome. I >>> hope one day to be competent enough to play it forward. >>> >>> I also spend a great deal of time in the Erlang man pages. >>> Problem is that I'm one of those soft-headed liberal arts types. >>> So, I often find the man pages near incomprehensible (and not >>> only Erlang). Yes, I perhaps should have taken more math classes >>> to grasp the elegant concision. But my mind doesn't seem to be >>> wired that way. >>> >>> I can't tell you how many times I've looked at the foldl/n docs >>> and tried to understand what the hell is going on. I get the >>> general drift, but can't bring it down to useful code. There's >>> just too much inside-baseball. >>> >>> As a self-taught-from-books-and-web Erlang aspirant, I find >>> concrete examples and well-written tutorials most helpful. This >>> gives me leverage to apply your approach 3. In general, the >>> concepts of Erlang are simple enough once I grasp them. In fact, >>> I marvel at the pragmatic elegance. Your books provide >>> particularly lucid explications. But the man pages? My how I >>> wish I had the time and chops to write a parallel set for noobies. >>> >>> Indeed, would it be helpful if I walked through and commented on >>> the man doc items that give me headaches? >>> >>> >>> Absolutely - There is a problem here - which I think should be >>> addressed as soon as >>> possible - "It is not easy to common and ask question about man pages" - >>> I'd really like to see commenting in the style of the real world >>> Haskell book. >>> >>> If you're interested take a look at >>> http://book.realworldhaskell.org/read/types-and-functions.html - in >>> particular look at how comments are added to the text. >>> >>> The erlang man pages are generated from XML so a commenting system >>> should be >>> easy to make. >>> >>> I'd like to see questions about the man pages discussed "inside the >>> man pages" >>> if you see what I mean - not "outside the man pages" (ie here) >>> ... >>> >>> Folds are very common there are the "iterators with an accumulator" >>> >>> In an imperative language you might say >>> state = state0 >>> for(i in x){ >>> state = update(state, f(i)) >>> } >>> >>> In erlang this is a fold >>> >>> fold(F, State0, X) >>> >>> F is a function of I and State which returns a new state, and I iterates >>> over the values in X >>> >>> so >>> >>> fold(fun(I, S) -> I + S end, 0, L) >>> >>> is the same as >>> >>> S = 0; >>> for(I in L){ >>> S = S + I >>> } >>> >>> This is a very common programming pattern >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> Many thanks again for your kind help, >>> >>> Lloyd >>> >>> -----Original Message----- >>> From: "Joe Armstrong" > >>> Sent: Saturday, May 31, 2014 1:53pm >>> To: "Lloyd Prentice" >> > >>> Cc: "Erlang-Questions Questions" >> > >>> Subject: Re: [erlang-questions] How to return all records in dets >>> >>> The thing to Google for is "dets man erlang" - which should get >>> you the man >>> page >>> (even better is to store the man pages locally and do "erl -man >>> dets") >>> >>> You want to "list" all records (I'm not sure what list means >>> here - it >>> might mean >>> "print" or "make a list of"). >>> >>> To make a list of all records you could say: >>> >>> dets:foldl(fun(X, L) -> [X|L] end, [], Name) >>> >>> (Most collections - ie dets, ets, dict, etc. offer some kind of fold >>> operation that >>> traverses all objects in the collection) >>> >>> To print all records >>> >>> dets:traverse(Name, fun(X) -> >>> io:format("~p~n",[X]), >>> continue >>> end) >>> >>> No need to worry about match specifications. >>> >>> The best place to start is usually by reading the man pages. >>> >>> Now that Erlang is is becoming popular you'll find a lot of >>> incorrect >>> solutions to problems posted on stackoverlow. >>> >>> Best approach is >>> >>> 0) ask an expert >>> 1) read the man pages for the module, in question >>> 2) experiment with the functions in the man pages in the shell >>> 3) ask/tell this list if the manual pages are ambiguous or >>> incomprehensible >>> 4) search Google/stackoverflow >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> On Fri, May 30, 2014 at 9:56 PM, >> > wrote: >>> >>>> Hello, >>>> >>>> I'm cross-eyed from looking at match specifications. All I >>> want to do is >>>> list all records in my small dets table. I once ran across a >>> very neat >>>> query to accomplish that, but for the life can't Google it up. >>>> >>>> Can some kind soul give me a query that works? >>>> >>>> Many thanks, >>>> >>>> LRP >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From donpedrothird@REDACTED Mon Jun 2 00:06:52 2014 From: donpedrothird@REDACTED (Evgeny M) Date: Sun, 1 Jun 2014 15:06:52 -0700 (PDT) Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1401479806.358332223@apps.rackspace.com> References: <1401479806.358332223@apps.rackspace.com> Message-ID: <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> My 2 cents as a more or less erlang noob on the documentation. Most of the docs on the standard modules is fine if you know basics about folds, maps, common data structures etc. Some of docs, like docs on dets/ets/mnesia selects and matches are vague and need more examples. I for one still not sure why foldl on a table, as Joe Armstrong suggested, is better than match or select. There are other commonly used modules and apps which would benefit from more examples too, the first things that come to my mind are inets and crypto infrastructure with public_key. The docs are not horrible, far from it, but having more examples would be really helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Mon Jun 2 00:17:12 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 1 Jun 2014 18:17:12 -0400 Subject: [erlang-questions] How to access digraph vertices Message-ID: Hello, The documentation for digraphs tells us that vertices can be any Erlang term. How would we retrieve a vertex expressed as a record? E.g., by key. Surely we wouldn't want to use or even know the whole record. Many thanks,, LRP Sent from my iPad From lloyd@REDACTED Mon Jun 2 02:52:05 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 1 Jun 2014 20:52:05 -0400 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: Hi Evgeny, I do agree with you wholeheartedly that a great deal of fine and hard work has gone into developing the Erlang docs as they stand. I'm deeply grateful for this. And I hope that my critique in no way diminishes the accomplishment or the folks who have put so much into it. I see the Erlang docs as a work-in-progress. And, at this point in my understanding of Erlang, I feel that the most constructive contribution I can make is to point out from the noobie perspective how they might be more helpful to a wider audience. How quickly we take for granted what was once a struggle to learn. All the best, Lloyd Sent from my iPad > On Jun 1, 2014, at 6:06 PM, Evgeny M wrote: > > My 2 cents as a more or less erlang noob on the documentation. > Most of the docs on the standard modules is fine if you know basics about folds, maps, common data structures etc. > Some of docs, like docs on dets/ets/mnesia selects and matches are vague and need more examples. I for one still not sure why foldl on a table, as Joe Armstrong suggested, is better than match or select. There are other commonly used modules and apps which would benefit from more examples too, the first things that come to my mind are inets and crypto infrastructure with public_key. > > The docs are not horrible, far from it, but having more examples would be really helpful. From lloyd@REDACTED Mon Jun 2 02:57:26 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 1 Jun 2014 20:57:26 -0400 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: P.S. At this point, as the result of my naive question, I've learned five ways to dump a dets table. What a cornucopia of riches! Thanks to all, Lloyd Sent from my iPad > On Jun 1, 2014, at 6:06 PM, Evgeny M wrote: > > My 2 cents as a more or less erlang noob on the documentation. > Most of the docs on the standard modules is fine if you know basics about folds, maps, common data structures etc. > Some of docs, like docs on dets/ets/mnesia selects and matches are vague and need more examples. I for one still not sure why foldl on a table, as Joe Armstrong suggested, is better than match or select. There are other commonly used modules and apps which would benefit from more examples too, the first things that come to my mind are inets and crypto infrastructure with public_key. > > The docs are not horrible, far from it, but having more examples would be really helpful. From mononcqc@REDACTED Mon Jun 2 08:33:25 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 1 Jun 2014 23:33:25 -0700 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: <20140602063323.GC7746@ferdair.local> On 06/01, Evgeny M wrote: > My 2 cents as a more or less erlang noob on the documentation. > Most of the docs on the standard modules is fine if you know basics about > folds, maps, common data structures etc. "Fine if you know them" tends to be a synonym of a 'reference manual', in that it provides a reference (in case you need help remembering), not tutorial. > Some of docs, like docs on dets/ets/mnesia selects and matches are vague > and need more examples. That's where the Erlang documentation gets divided into a 'user guide' and a 'reference manual'. For example, if you go into the margin on the left, back to the top, you will see a menu like this: User's Guide Reference Manual Release Notes PDF Top The reference manual will contain something minimal like: http://www.erlang.org/doc/man/mnesia.html#select-2 expecting you to know about it, whereas if you go into the user guide, you get an actual tutorial: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap4.html#id74467 This one has a few more examples than the reference manual. > I for one still not sure why foldl on a table, as > Joe Armstrong suggested, is better than match or select. A fold is useful when you want to accumulate or reduce a state. For example, if you were to accumulate the sum of all your red-headed members, you could either use a 'select' pattern and make it return '1' for every member, in which case you would end up with a potentially large list you need to count the length of (or the sum of) to get your result. Using a fold, you iterate over the table and can accumulate the sum as you go, never needing to build the intermediate list. That can help save on memory if your data set is particularly large. Regards, Fred. From ulf@REDACTED Mon Jun 2 08:45:18 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 2 Jun 2014 08:45:18 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <20140602063323.GC7746@ferdair.local> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> <20140602063323.GC7746@ferdair.local> Message-ID: On 02 Jun 2014, at 08:33, Fred Hebert wrote: > Using a fold, you iterate over the table and can accumulate the sum as > you go, never needing to build the intermediate list. That can help save > on memory if your data set is particularly large. Indeed. The fold functions in ets were added exactly because pulling the entire data set onto the heap could have terrible consequences for memory usage - esp. in the old days, when 512 MB was considered ?a lot? of memory. :) Garbage collection generally has difficulty with constantly growing data sets. The GC will trigger when the heap is full, and sweep for garbage. If we?re building a large structure, there will be no garbage. With generational GC, the ?new heap? will be swept first. When that fails, a fullsweep will be tried. When that fails, the heap will be resized. Rinse, repeat, until the whole data structure has been built. Not only is this expensive; the memory required for the operation can well reach 3x the size of the data set being built. At least this used to be the rule of thumb in the good ol? days. It is possible to temporarily set the heap size to something very big, build the structure, and then set it back. But the fold operations can execute without growing the heap. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From erlang@REDACTED Mon Jun 2 09:36:11 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 2 Jun 2014 09:36:11 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: On Mon, Jun 2, 2014 at 12:06 AM, Evgeny M wrote: > My 2 cents as a more or less erlang noob on the documentation. > Most of the docs on the standard modules is fine if you know basics about > folds, maps, common data structures etc. > Some of docs, like docs on dets/ets/mnesia selects and matches are vague > and need more examples. I for one still not sure why foldl on a table, as > Joe Armstrong suggested, is better than match or select. There are other > commonly used modules and apps which would benefit from more examples too, the > first things that come to my mind are inets and crypto infrastructure > with public_key. > > The docs are not horrible, far from it, but having more examples would be > really helpful. > I agree - two thoughts occur to me. Firstly, some kind of "reduced" manual pages might be helpful. Many modules export a heck of a lot of functions, of which possible half a dozen are the most used and most useful. It might be nice to document the "best of" some module. Secondly the "best of" section should have a lot of simple examples. /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Mon Jun 2 09:49:17 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 2 Jun 2014 09:49:17 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: Hi, On Mon, Jun 2, 2014 at 9:36 AM, Joe Armstrong wrote: > On Mon, Jun 2, 2014 at 12:06 AM, Evgeny M wrote: >> >> The docs are not horrible, far from it, but having more examples would be >> really helpful. > > > I agree - two thoughts occur to me. > > Firstly, some kind of "reduced" manual pages might be helpful. > Many modules export a heck of a lot of functions, of which possible half a > dozen are the most used and > most useful. It might be nice to document the "best of" some module. > Secondly the "best of" section should have a lot > of simple examples. Another option would be to group functions in a module (in the docs) by area of usage. This is especially useful for a module like 'erlang' that covers many distinct areas of functionality. regards, Vlad From n.oxyde@REDACTED Mon Jun 2 10:10:21 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Jun 2014 10:10:21 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401561861.18413033@apps.rackspace.com> <538B32FE.1000606@ninenines.eu> <1401643110.963516080@apps.rackspace.com> Message-ID: <60C93E0D-0BA5-48AC-8DF7-0C6EB82D443C@gmail.com> This, that?s all we need. And there is no need for a separate commit policy, make a pull request and members of the community will review it if they want. There is no need for a trimmed-down version of the manual either, anyone is free to add to their favourite module?s documentation a summary of the provided features and what the most common use cases are, with code examples. Regards, -- Anthony Ramine Le 1 juin 2014 ? 20:00, Garrett Smith a ?crit : > Given the effort of installing a commenting facility, not to mention > the gamble that anyone will find this useful, why not submit a pull > request for the applicable doc page? > > I haven't done this, so maybe installing a commenting facility *is* easier. > > But it seems like one could write a sentence or two to clarify how a > module might be used. And add an example or two on how a function > might be used. This strike me as being a pretty direct solution to the > problem you're raising. > > Ease of making these changes and then getting them integrated is of > course the big question. If it's a substantial barrier, lowering that > friction is something probably worth investing in. > > As to moderation, if the docs were under a separate commit policy > (separate repo?) members of the community could pitch in directly, > saving the OTP time some hassle. > > On Sun, Jun 1, 2014 at 12:18 PM, wrote: >> Hi Lo?c, >> >> Seems to me that there are four issues here: >> >> - Who are the Erlang docs (man pages and/other authoritative guides) intended to serve? >> >> As a not-so-noobie-but-still-vastly-ignorant Erlang aspirant, I can say that current man pages, while helpful to a degree, leave much to be desired. >> >> - How can Erlang docs provide greater clarity to intended audiences? >> >> From my point-of-view they could provide more examples, say three or four across a range of simplest possible application of the function to a golly-gee-wiz-this-function-can-do-this example >> >> Don't forget to note why and where this module/function is useful. >> >> Great gains would be come, in my view, by backing up man pages with authoritative noobie-friendly tutorials. By authoritative I mean dated, 100% functional, expressing best practices >> >> Lo?c, ask me, you have been doing a great job in this regard with Cowboy. >> >> - From a technical point-of-view, how can Erlang docs be maintained most conveniently >> >> I can't speak to this other than harness the power of the language. I do think there needs to be three tracks: a template or policy statement for consistent, quality docs, man pages, and tutorials >> >> - From a community point of view, who does all this? >> >> This is the 64-dollar-question that every volunteer organization faces. >> >> Part of the problem of mobilizing a volunteer community is cultivating community spirit. That comes down to determining how everyone stands to gain by participating. I think we all know this. But it may require frequent reminders. >> >> It's also very important to serve the noobies well. I saw the vibrant forth community die out, in part, because it failed in this. >> >> I see Erlang as a humongous toolkit that includes a vast range including use-everyday tools to use-once-in-a-career exotic. So a good place to start is setting priorities and putting out calls of what needs to be done next. Keep the focus small and keep the pressure on. I have no doubt that the committed brilliant folks in the community will respond if they have a clear sense of direction. Who sets the direction? Whoever will step up. >> >> My two cents for what it's worth. >> >> Thanks to all, >> >> Lloyd >> >> -----Original Message----- >> From: "Lo?c Hoguin" >> Sent: Sunday, June 1, 2014 10:04am >> To: "Mark Nijhof" , "Joe Armstrong" >> Cc: "Erlang Users' List" >> Subject: Re: [erlang-questions] How to return all records in dets >> >> I'm all for comments, but I don't see how it would be at all usable >> using disqus. Take this page for example: >> http://www.erlang.org/doc/man/erlang.html >> >> Where do you put the comments? They're going to be unnoticed, and >> they're going to cover a wealth of different topics so much that they'll >> become entirely useless. >> >> Make one comment zone per function? Disqus is already painfully slow to >> load when there's one, so imagine 50 or 100. >> >> Joe's solution is nice and tidy on the other hand. But there's one >> problem though, who's going to moderate? >> >> There's no real quick way to that kind of stuff. At least not with this >> amount of content. >> >> On 06/01/2014 11:38 AM, Mark Nijhof wrote: >>> Just a thought on commenting, but adding a disqus comment section to >>> each page might be a real quick way to enable that. Just add it to the >>> templates you use for generating the html. Later it should also be >>> rather easy to migrate them somewhere else if needed. >>> >>> -Mark >>> >>> On Jun 1, 2014 11:09 AM, "Joe Armstrong" >> > wrote: >>> >>> >>> >>> >>> On Sat, May 31, 2014 at 8:44 PM, >> > wrote: >>> >>> Hi Joe, >>> >>> I've resorted to approach 0 many times and much appreciate the >>> generous help I've received from the community. Indeed, response >>> from the author of my Erlang bible is particularly awesome. I >>> hope one day to be competent enough to play it forward. >>> >>> I also spend a great deal of time in the Erlang man pages. >>> Problem is that I'm one of those soft-headed liberal arts types. >>> So, I often find the man pages near incomprehensible (and not >>> only Erlang). Yes, I perhaps should have taken more math classes >>> to grasp the elegant concision. But my mind doesn't seem to be >>> wired that way. >>> >>> I can't tell you how many times I've looked at the foldl/n docs >>> and tried to understand what the hell is going on. I get the >>> general drift, but can't bring it down to useful code. There's >>> just too much inside-baseball. >>> >>> As a self-taught-from-books-and-web Erlang aspirant, I find >>> concrete examples and well-written tutorials most helpful. This >>> gives me leverage to apply your approach 3. In general, the >>> concepts of Erlang are simple enough once I grasp them. In fact, >>> I marvel at the pragmatic elegance. Your books provide >>> particularly lucid explications. But the man pages? My how I >>> wish I had the time and chops to write a parallel set for noobies. >>> >>> Indeed, would it be helpful if I walked through and commented on >>> the man doc items that give me headaches? >>> >>> >>> Absolutely - There is a problem here - which I think should be >>> addressed as soon as >>> possible - "It is not easy to common and ask question about man pages" - >>> I'd really like to see commenting in the style of the real world >>> Haskell book. >>> >>> If you're interested take a look at >>> http://book.realworldhaskell.org/read/types-and-functions.html - in >>> particular look at how comments are added to the text. >>> >>> The erlang man pages are generated from XML so a commenting system >>> should be >>> easy to make. >>> >>> I'd like to see questions about the man pages discussed "inside the >>> man pages" >>> if you see what I mean - not "outside the man pages" (ie here) >>> ... >>> >>> Folds are very common there are the "iterators with an accumulator" >>> >>> In an imperative language you might say >>> state = state0 >>> for(i in x){ >>> state = update(state, f(i)) >>> } >>> >>> In erlang this is a fold >>> >>> fold(F, State0, X) >>> >>> F is a function of I and State which returns a new state, and I iterates >>> over the values in X >>> >>> so >>> >>> fold(fun(I, S) -> I + S end, 0, L) >>> >>> is the same as >>> >>> S = 0; >>> for(I in L){ >>> S = S + I >>> } >>> >>> This is a very common programming pattern >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> Many thanks again for your kind help, >>> >>> Lloyd >>> >>> -----Original Message----- >>> From: "Joe Armstrong" > >>> Sent: Saturday, May 31, 2014 1:53pm >>> To: "Lloyd Prentice" >> > >>> Cc: "Erlang-Questions Questions" >> > >>> Subject: Re: [erlang-questions] How to return all records in dets >>> >>> The thing to Google for is "dets man erlang" - which should get >>> you the man >>> page >>> (even better is to store the man pages locally and do "erl -man >>> dets") >>> >>> You want to "list" all records (I'm not sure what list means >>> here - it >>> might mean >>> "print" or "make a list of"). >>> >>> To make a list of all records you could say: >>> >>> dets:foldl(fun(X, L) -> [X|L] end, [], Name) >>> >>> (Most collections - ie dets, ets, dict, etc. offer some kind of fold >>> operation that >>> traverses all objects in the collection) >>> >>> To print all records >>> >>> dets:traverse(Name, fun(X) -> >>> io:format("~p~n",[X]), >>> continue >>> end) >>> >>> No need to worry about match specifications. >>> >>> The best place to start is usually by reading the man pages. >>> >>> Now that Erlang is is becoming popular you'll find a lot of >>> incorrect >>> solutions to problems posted on stackoverlow. >>> >>> Best approach is >>> >>> 0) ask an expert >>> 1) read the man pages for the module, in question >>> 2) experiment with the functions in the man pages in the shell >>> 3) ask/tell this list if the manual pages are ambiguous or >>> incomprehensible >>> 4) search Google/stackoverflow >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> On Fri, May 30, 2014 at 9:56 PM, >> > wrote: >>> >>>> Hello, >>>> >>>> I'm cross-eyed from looking at match specifications. All I >>> want to do is >>>> list all records in my small dets table. I once ran across a >>> very neat >>>> query to accomplish that, but for the life can't Google it up. >>>> >>>> Can some kind soul give me a query that works? >>>> >>>> Many thanks, >>>> >>>> LRP >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Mon Jun 2 10:11:58 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 2 Jun 2014 10:11:58 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> Message-ID: <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, There is also the possibility to copy functions from the erlang module to suitable, smaller, modules. Then just link to the new place, and hope that in time users will stop looking for them in the old module. bengt On Mon, 2014-06-02 at 09:49 +0200, Vlad Dumitrescu wrote: > Hi, > > On Mon, Jun 2, 2014 at 9:36 AM, Joe Armstrong wrote: > > On Mon, Jun 2, 2014 at 12:06 AM, Evgeny M wrote: > >> > >> The docs are not horrible, far from it, but having more examples would be > >> really helpful. > > > > > > I agree - two thoughts occur to me. > > > > Firstly, some kind of "reduced" manual pages might be helpful. > > Many modules export a heck of a lot of functions, of which possible half a > > dozen are the most used and > > most useful. It might be nice to document the "best of" some module. > > Secondly the "best of" section should have a lot > > of simple examples. > > Another option would be to group functions in a module (in the docs) > by area of usage. This is especially useful for a module like 'erlang' > that covers many distinct areas of functionality. > > regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Mon Jun 2 11:24:44 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Jun 2014 11:24:44 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> Message-ID: <614D158D-9565-4420-A13F-FD64D7629C36@gmail.com> What would be the point? Moving things around won't help anything. How do you guess that it is in module X if you didn't previously guess that it was in module 'erlang'? -- Anthony Ramine > Le 2 juin 2014 ? 10:11, Bengt Kleberg a ?crit : > > Greetings, > > There is also the possibility to copy functions from the erlang module > to suitable, smaller, modules. Then just link to the new place, and hope > that in time users will stop looking for them in the old module. > > > bengt > >> On Mon, 2014-06-02 at 09:49 +0200, Vlad Dumitrescu wrote: >> Hi, >> >>> On Mon, Jun 2, 2014 at 9:36 AM, Joe Armstrong wrote: >>>> On Mon, Jun 2, 2014 at 12:06 AM, Evgeny M wrote: >>>> >>>> The docs are not horrible, far from it, but having more examples would be >>>> really helpful. >>> >>> >>> I agree - two thoughts occur to me. >>> >>> Firstly, some kind of "reduced" manual pages might be helpful. >>> Many modules export a heck of a lot of functions, of which possible half a >>> dozen are the most used and >>> most useful. It might be nice to document the "best of" some module. >>> Secondly the "best of" section should have a lot >>> of simple examples. >> >> Another option would be to group functions in a module (in the docs) >> by area of usage. This is especially useful for a module like 'erlang' >> that covers many distinct areas of functionality. >> >> regards, >> Vlad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Mon Jun 2 12:30:17 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 2 Jun 2014 12:30:17 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <614D158D-9565-4420-A13F-FD64D7629C36@gmail.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> <614D158D-9565-4420-A13F-FD64D7629C36@gmail.com> Message-ID: <1401705017.5240.11.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, Example: If erlang:disconnect_node/1 is in net_kernel it would be easier to find for those that have already used net_kernel:connect_node/1 and now wants to undo what they have done. bengt On Mon, 2014-06-02 at 11:24 +0200, Anthony Ramine wrote: > What would be the point? Moving things around won't help anything. How do you guess that it is in module X if you didn't previously guess that it was in module 'erlang'? > From n.oxyde@REDACTED Mon Jun 2 13:26:12 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Jun 2014 13:26:12 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <1401705017.5240.11.camel@sekic1152.rnd.ki.sw.ericsson.se> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> <614D158D-9565-4420-A13F-FD64D7629C36@gmail.com> <1401705017.5240.11.camel@sekic1152.rnd.ki.sw.ericsson.se> Message-ID: <884C389D-5DAF-4943-A9B7-469E3125071F@gmail.com> And does one know about module net_kernel? -- Anthony Ramine > Le 2 juin 2014 ? 12:30, Bengt Kleberg a ?crit : > > Greetings, > > Example: If erlang:disconnect_node/1 is in net_kernel it would be easier > to find for those that have already used net_kernel:connect_node/1 and > now wants to undo what they have done. > > > bengt > >> On Mon, 2014-06-02 at 11:24 +0200, Anthony Ramine wrote: >> What would be the point? Moving things around won't help anything. How do you guess that it is in module X if you didn't previously guess that it was in module 'erlang'? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Mon Jun 2 13:31:58 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 2 Jun 2014 13:31:58 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <884C389D-5DAF-4943-A9B7-469E3125071F@gmail.com> References: <1401479806.358332223@apps.rackspace.com> <1cd994d3-572d-46ba-bbb7-4f0d39820e82@googlegroups.com> <1401696718.5240.5.camel@sekic1152.rnd.ki.sw.ericsson.se> <614D158D-9565-4420-A13F-FD64D7629C36@gmail.com> <1401705017.5240.11.camel@sekic1152.rnd.ki.sw.ericsson.se> <884C389D-5DAF-4943-A9B7-469E3125071F@gmail.com> Message-ID: <1401708718.5240.16.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, In the example the net_kernel:connect_node/1 function is still found in the same way as before. It is finding disconnect_node/1 that is helped by a copy to net_kernel. bengt On Mon, 2014-06-02 at 13:26 +0200, Anthony Ramine wrote: > And does one know about module net_kernel? > From aseigo@REDACTED Mon Jun 2 13:45:31 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Mon, 02 Jun 2014 13:45:31 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> Message-ID: <2474806.080TbbrlWx@freedom> On Sunday, June 1, 2014 13:18:30 lloyd@REDACTED wrote: > Great gains would be come, in my view, by backing up man pages with > authoritative noobie-friendly tutorials. By authoritative I mean dated, > 100% functional, expressing best practices as YAEN (yet another erlang newbie ;) this would be really quite valuable. i spent a fair amount of time looking at various sources of examples. tl;dr -> there is actually a fair number of examples lurking out there, but nothing that is stand-alone, authoritative and well structured (as Lloyd describes it, anyways) and such a thing would be pretty fantastic. a reasonably well-maintained git repo with examples would be simply fantastic for people learning the ropes, and making it easy to contribute to would simply be icing on the cake. verbose -> i did find various sources for examples inc: * http://www.erlang.org/examples -> a wiki is not the best medium imho (if only because you can't load them directly into the erlang vm from the command line; there is very little structure to the examples; the documentation page warns they are out of date (scary! :) * http://erlangcentral.org/wiki/index.php?title=Category:CookBook -> fair number of interesting snippets, though not much structure * Learn You Some Erlang (LYSE) the true gold mine imho are the examples that come with LYSE. they were immensely helpful in getting me up and running in minimal time. of course, the examples make sense only when paired with the book itself. there is no indication in the examples archive as to which order the examples are to be read or what each example program demonstrates. the book itself provides that, of course, so this isn't a critical flaw by any means, it just means that these examples are not overly useful on their own. (aside: a 2nd edition of LYSE that folds in the postscript on maps, has a bit more on binary comprehensions along with a general proof-reading sweep would be utterly fantastic. i wonder what would be required to make that happen?) On Sunday, June 1, 2014 13:00:01 Garrett Smith wrote: > As to moderation, if the docs were under a separate commit policy > (separate repo?) members of the community could pitch in directly, > saving the OTP time some hassle. i actually did not even realize that the docs were in the OTP repo. *blush* i didn't see it mentioned on http://www.erlang.org/doc/ and had to dig for a bit before finding them in otp/system/doc/. having docs under system/ instead of a top-level directory is unusual and serves to hide them pretty well. ;) things that occurred to me as "would be helpful..." while navigating through the sources: * move docs to a top-level dir in the OTP repo to make them more discoverable * document how to contribute to them on http://erlang.org/doc/ .. besiddes the whole github push request workflow, there are many non-self-evident details such as how book.xml is the top level file for each doc module * with the OTP git repo cloned, one can not simply `cd system/doc; make` since the make depends on the top-level OTP build system. you have to configure (and autogen, if using a git checkout .. which is pretty much a requirement for push requests) and build from the top-level. `make docs` triggers a build of the actual OTP sources which is pretty irrelevant when i just want to contribute some improved docs and would like to see the results before doing a push request. :/ a pure-erlang system that uses a pre-existing erl in the user's path would be, comparatively, rather nice. * it would be nice if the source tree reflect the generated HTML index a bit more clearly. at http://www.erlang.org/doc/, navigating "System Documentation -> Erlang Reference Manual -> Introduction" gets one to the content found in reference_manual/introduction.xml. this is evident by looking at the URL on the website, but unclear by just looking at the source tree. another example: the system/doc/tutorial dir is not actually a generic tutorial but the tutorial on interoperability. (true story: i actually went into that dir looking for an erlang tutorial :) * navigating the index on the left side of http://www.erlang.org/doc/ is pretty tedious (and lacks a search function). contributing improvements to that is fairly non-trivial due to the tooling for generating documentation. i found myself wishing that a clear, simple, "modern" template system was used for those parts .... * the erlang code in system/doc/top along the templates in system/doc/top/templates is (ironically? :) underdocumented; some documentation on what it does and how/where they are used would be helpful (if only to know that one can safely ignore it when wanting to contribute to the docs ;) -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From zxq9@REDACTED Mon Jun 2 14:19:53 2014 From: zxq9@REDACTED (zxq9) Date: Mon, 02 Jun 2014 21:19:53 +0900 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> Message-ID: <6055181.t5esXroPBy@jalapeno> On Monday 02 June 2014 09:49:17 Vlad Dumitrescu wrote: > Hi, > > On Mon, Jun 2, 2014 at 9:36 AM, Joe Armstrong wrote: > > On Mon, Jun 2, 2014 at 12:06 AM, Evgeny M wrote: > >> The docs are not horrible, far from it, but having more examples would be > >> really helpful. > > > > I agree - two thoughts occur to me. > > > > Firstly, some kind of "reduced" manual pages might be helpful. > > Many modules export a heck of a lot of functions, of which possible half a > > dozen are the most used and > > most useful. It might be nice to document the "best of" some module. > > Secondly the "best of" section should have a lot > > of simple examples. > > Another option would be to group functions in a module (in the docs) > by area of usage. This is especially useful for a module like 'erlang' > that covers many distinct areas of functionality. My feeling is that there are really two issues to address in the docs, one of which isn't being done much service (and when it is, it seems incidental): 1- Erlang the language (quick and easy to understand, provided the reader has his functional bases covered) 2- Erlang the system A lot of Erlang documentation focuses on the language and specific functions in libraries, very little time is spent being explicit about the fact that Erlang is a guest operating system. This is mentioned in a peripheral way, of course, but very rarely is layout out just how Erlang works as a system. I could write a new language that targets the Erlang runtime, for example, and compiles to Erlang bytecode. Let's say its a clone of Clojure we'll call Clerlang. Porting a program between Clojure and Clerlang won't be difficult just because the Java libraries and OTP use different names for similar functions, it will be difficult because writing something that targets the JVM is just like writing anything else that targets a typical machine or VM, whereas writing something that targets the Erlang system must be re-figured to work in a way that plays to the system's advantages. It would be, of course, possible to simply write phrase-for-phrase an idiomatic Clojure program in Clerlang, but this would not be idiomatic use of the Erlang system and would probably perform horribly. Consider, however, that an idiomatic Clerlang program would be nearly impossible to port to Clojure. My point is that the system is what is important, not the details of the language per se, and this separates great Erlang code from mediocre Erlang code, and nearly any non-trivial Erlang code from code in almost any other language I can think of. Docs need to treat the system, not just the language. And this is, from my perspective, what is mostly lacking. -Craig PS: I'm working on an expanded essay about this particular subject and have a mind to force myself into learning the system better by writing some tutorial paths. If anyone happens to think this is a good idea I'd love to work up some material, get it cut to pieces by the experts here, and eventually create an Erlang Tutorial path analogous to the (outstanding) Python Tutorial. It would be less ambitious than the (wonderful) LYSE book, more ambitious than the four-day class already available, and specifically focused on treating the system and only incidentally on treating the language. From n.oxyde@REDACTED Mon Jun 2 14:25:29 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Jun 2014 14:25:29 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: <2474806.080TbbrlWx@freedom> References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> Message-ID: Replied inline. Le 2 juin 2014 ? 13:45, Aaron J. Seigo a ?crit : > a reasonably well-maintained git repo with examples would be simply fantastic > for people learning the ropes, and making it easy to contribute to would > simply be icing on the cake. OTP is a reasonably well-maintained Git repository. It is now using GitHub?s pull requests, which makes it easy to contribute to, at least according to the persons who wanted OTP to depend on GitHub. > * move docs to a top-level dir in the OTP repo to make them more discoverable Great, let?s move things for the sake of moving things. > * document how to contribute to them on http://erlang.org/doc/ .. besiddes the > whole github push request workflow, there are many non-self-evident details > such as how book.xml is the top level file for each doc module http://www.erlang.org/doc/apps/erl_docgen/users_guide.html > * with the OTP git repo cloned, one can not simply `cd system/doc; make` since > the make depends on the top-level OTP build system. you have to configure (and > autogen, if using a git checkout .. which is pretty much a requirement for > push requests) and build from the top-level. `make docs` triggers a build of > the actual OTP sources which is pretty irrelevant when i just want to > contribute some improved docs and would like to see the results before doing a > push request. :/ a pure-erlang system that uses a pre-existing erl in the > user's path would be, comparatively, rather nice. True, `make docs` should work, but not going through autotools and whatnot is asking for problems. Rewriting things to only use Erlang is asking for problems too, why reinvent the wheel? > * navigating the index on the left side of http://www.erlang.org/doc/ is > pretty tedious (and lacks a search function). contributing improvements to > that is fairly non-trivial due to the tooling for generating documentation. i > found myself wishing that a clear, simple, "modern" template system was used > for those parts ?. On http://www.erlang.org/doc.html, we can read: "Online documentation for the latest version of the run-time system as well as all the libraries. Searchable in the right column". If Erlang?s own documentation is not a good place to tell where the searchable documentation is, what is a good place? -- Anthony Ramine From aseigo@REDACTED Mon Jun 2 16:35:33 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Mon, 02 Jun 2014 16:35:33 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <2474806.080TbbrlWx@freedom> Message-ID: <1527311.j7pqQn4Pp5@freedom> On Monday, June 2, 2014 14:25:29 you wrote: > Le 2 juin 2014 ? 13:45, Aaron J. Seigo a ?crit : > > a reasonably well-maintained git repo with examples would be simply > > fantastic for people learning the ropes, and making it easy to contribute > > to would simply be icing on the cake. > > OTP is a reasonably well-maintained Git repository. It is now using GitHub?s > pull requests, which makes it easy to contribute to, at least according to > the persons who wanted OTP to depend on GitHub. great, so there's a destination repo. :) there's some examples in there, even, in the various lib/*/examples/ dirs. some questions: * where should (non-OTP lib using) Erlang examples go? (stdlib/examples?) * should _every_ lib get an examples/ subdir? (i notice some don't, e.g. edoc) * should there be a recommended/standardized manner of documenting the examples? e.g. what each example does? the order to look at the examples in, if any? i notice, for instance that the gs lib, has a relatively large # of examples and most of the files are numbered giving an implied order .. * where would be a reasonable place to publish the extracted set of examples? (it probably doesn't make much sense to ask people to grab the entire OTP git repo and explore around in it to get them when a simple archive could be offered for download...) > > * move docs to a top-level dir in the OTP repo to make them more > > discoverable > Great, let?s move things for the sake of moving things. not for the sake of the moving things: for the sake of making the docs more discoverable. perhaps i'm an idiot, but when i looked in the OTP repo the last place i thought to look was in system/. fortunately find(1) saved me ;) > > * document how to contribute to them on http://erlang.org/doc/ .. besiddes > > the whole github push request workflow, there are many non-self-evident > > details such as how book.xml is the top level file for each doc module > > http://www.erlang.org/doc/apps/erl_docgen/users_guide.html is this linked anywhere in the index tree on the left side of http://www.erlang.org/doc/? (i couldn't find it ... and one place i did look before writing my email was under the Documentation entry .. maybe i just missed it). it would be very nice imho to find a link on the main page along with the "Some hints that may get you started faster" i mentioned book.xml specifically, as it seems to be a convention, and i did not find a single mention of it in system/doc/. where are OTP documentation conventions documented? and of course, the users_guide still misses things like how to contribute new docs to OTP itself ... > > * with the OTP git repo cloned, one can not simply `cd system/doc; make` > > since the make depends on the top-level OTP build system. you have to > > configure (and autogen, if using a git checkout .. which is pretty much a > > requirement for push requests) and build from the top-level. `make docs` > > triggers a build of the actual OTP sources which is pretty irrelevant > > when i just want to contribute some improved docs and would like to see > > the results before doing a push request. :/ a pure-erlang system that > > uses a pre-existing erl in the user's path would be, comparatively, > > rather nice. > > True, `make docs` should work, but not going through autotools and whatnot > is asking for problems. Rewriting things to only use Erlang is asking for > problems too, why reinvent the wheel? if the goal is to make contributing to documentation attractive and easy, asking potential contributors to set up and build the entire OTP repo build is a hurdle. if i want to correct something in the documentation, or add a clarifying phrase / sentence / paragraph, should i really need to not only check out the OTP git repo but also build it? > > * navigating the index on the left side of http://www.erlang.org/doc/ is > > pretty tedious (and lacks a search function). contributing improvements to > > that is fairly non-trivial due to the tooling for generating > > documentation. i found myself wishing that a clear, simple, "modern" > > template system was used for those parts ?. > > On http://www.erlang.org/doc.html, we can read: "Online documentation for > the latest version of the run-time system as well as all the libraries. > Searchable in the right column". If Erlang?s own documentation is not a > good place to tell where the searchable documentation is, what is a good > place? http://www.erlang.org/doc/ that is where one often ends up, and there is no way to trigger the search there. the actual point i was attempting to make was that contributing improvements to http://www.erlang.org/doc/ as generated from otp/system/doc/ is not clear and easy. it should, indeed, be simple to provide a link to the already-provided search capabilities. (that said ... should perhaps the "Erlang/OTP documentation" link on http://www.erlang.org/doc.html link to http://www.erlang.org/erldoc? rather than http://www.erlang.org/doc/? apologies in advance if that's a 'newbie' question and there is an 'obvious' answer why it is the way it is ... :) -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jesper.louis.andersen@REDACTED Mon Jun 2 17:15:02 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 2 Jun 2014 17:15:02 +0200 Subject: [erlang-questions] How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> Message-ID: On Mon, Jun 2, 2014 at 2:25 PM, Anthony Ramine wrote: > OTP is a reasonably well-maintained Git repository. It is now using > GitHub?s pull requests, which makes it easy to contribute to, at least > according to the persons who wanted OTP to depend on GitHub. Also worth mentioning: We have "Users Guide" documentation exactly for the purpose of writing User Guides for various parts of the Erlang system. They are not references, but *guides* which tend to explain the back-story of how to use a given application. References are just that. Quick information for those in the know. Think FreeBSD/OpenBSD man pages in quality. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Mon Jun 2 20:43:56 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Mon, 2 Jun 2014 14:43:56 -0400 Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> Message-ID: <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> Hello, So many thoughtful ideas and comments regarding Erlang docs came out in the thread "How to return all records in dets," I'm taking the liberty of changing the subject line. As I find time over the next week I'll try to extract, summarize, and category the constructive contributions. Meanwhile, three thoughts occur to me: - Why does this topic matter? Because, speaking for myself, as good as they are, my inability to find answers that I needed at one time or another in Erlang docs has cost me countless wasted and frustrating hours. Integrate that experience across the past, current, and future Erlang community and how many hours are we talking about? If each of us did just a bit to work toward making the docs best-of-breed, how much time would we ultimately save individually and collectively? - The responses do suggest that the path toward improving docs will involve grappling with both technical and cultural/organizational/governance issues. - Within the past 12 hours I've unsuccessfully asked two questions of the docs: a) A look at the digraph library left me confused about how to query the graphs, in part out confusion over vertices and labels. This may just be a matter of me not reading carefully enough. b) A look at ordsets gave me no indication of resource costs of adopting ordsets as solution to my project (nor, best I can determine is this information readily available for other data structures.) These two examples suggest that work toward improving docs will require both noobies to point out content lapses and confusing language and wizard/gurus to get the story straight. Best to all, Lloyd Sent from my iPad > On Jun 2, 2014, at 11:15 AM, Jesper Louis Andersen wrote: > > >> On Mon, Jun 2, 2014 at 2:25 PM, Anthony Ramine wrote: >> OTP is a reasonably well-maintained Git repository. It is now using GitHub?s pull requests, which makes it easy to contribute to, at least according to the persons who wanted OTP to depend on GitHub. > > Also worth mentioning: We have "Users Guide" documentation exactly for the purpose of writing User Guides for various parts of the Erlang system. They are not references, but *guides* which tend to explain the back-story of how to use a given application. > > References are just that. Quick information for those in the know. Think FreeBSD/OpenBSD man pages in quality. > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon Jun 2 21:14:01 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 2 Jun 2014 14:14:01 -0500 Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> Message-ID: I'm still not clear why just updating the *existing* docs -- adding examples, clarifying points of confusion, etc. isn't the obvious next step here. So, you find something confusing, unclear, or wrong. After getting help here, set aside some Saturday morning with and dive into the docs source. When you like the result, send a pull request. Maybe pick one of these lapses/gaps in the docs, based on this thread, and just try this? This, btw, is exactly why I never bring up "docs quality" -- ever -- in open source projects. The likelihood that someone will ask *me* to help improve them is somewhere between 99.999% and 100% :) On Mon, Jun 2, 2014 at 1:43 PM, Lloyd R. Prentice wrote: > Hello, > > So many thoughtful ideas and comments regarding Erlang docs came out in the > thread "How to return all records in dets," I'm taking the liberty of > changing the subject line. As I find time over the next week I'll try to > extract, summarize, and category the constructive contributions. > > Meanwhile, three thoughts occur to me: > > - Why does this topic matter? Because, speaking for myself, as good as they > are, my inability to find answers that I needed at one time or another in > Erlang docs has cost me countless wasted and frustrating hours. Integrate > that experience across the past, current, and future Erlang community and > how many hours are we talking about? If each of us did just a bit to work > toward making the docs best-of-breed, how much time would we ultimately save > individually and collectively? > > - The responses do suggest that the path toward improving docs will involve > grappling with both technical and cultural/organizational/governance issues. > > - Within the past 12 hours I've unsuccessfully asked two questions of the > docs: a) A look at the digraph library left me confused about how to query > the graphs, in part out confusion over vertices and labels. This may just be > a matter of me not reading carefully enough. b) A look at ordsets gave me no > indication of resource costs of adopting ordsets as solution to my project > (nor, best I can determine is this information readily available for other > data structures.) > > These two examples suggest that work toward improving docs will require both > noobies to point out content lapses and confusing language and > wizard/gurus to get the story straight. > > Best to all, > > Lloyd > > Sent from my iPad > > On Jun 2, 2014, at 11:15 AM, Jesper Louis Andersen > wrote: > > > On Mon, Jun 2, 2014 at 2:25 PM, Anthony Ramine wrote: >> >> OTP is a reasonably well-maintained Git repository. It is now using >> GitHub?s pull requests, which makes it easy to contribute to, at least >> according to the persons who wanted OTP to depend on GitHub. > > > Also worth mentioning: We have "Users Guide" documentation exactly for the > purpose of writing User Guides for various parts of the Erlang system. They > are not references, but *guides* which tend to explain the back-story of how > to use a given application. > > References are just that. Quick information for those in the know. Think > FreeBSD/OpenBSD man pages in quality. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From lloyd@REDACTED Mon Jun 2 21:40:16 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 2 Jun 2014 15:40:16 -0400 (EDT) Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> Message-ID: <1401738016.30117002@apps.rackspace.com> Hi Garrett, I'll try it. I don't mind doing what I can to improve docs within the limits of my knowledge. It's the least I can do to pay back the tremendous effort that Erlang developers and contributors have invested to date. All the best, L. -----Original Message----- From: "Garrett Smith" Sent: Monday, June 2, 2014 3:14pm To: "Lloyd R. Prentice" Cc: "Jesper Louis Andersen" , "Erlang (E-mail)" Subject: Re: [erlang-questions] Erlang docs was Re: How to return all records in dets I'm still not clear why just updating the *existing* docs -- adding examples, clarifying points of confusion, etc. isn't the obvious next step here. So, you find something confusing, unclear, or wrong. After getting help here, set aside some Saturday morning with and dive into the docs source. When you like the result, send a pull request. Maybe pick one of these lapses/gaps in the docs, based on this thread, and just try this? This, btw, is exactly why I never bring up "docs quality" -- ever -- in open source projects. The likelihood that someone will ask *me* to help improve them is somewhere between 99.999% and 100% :) On Mon, Jun 2, 2014 at 1:43 PM, Lloyd R. Prentice wrote: > Hello, > > So many thoughtful ideas and comments regarding Erlang docs came out in the > thread "How to return all records in dets," I'm taking the liberty of > changing the subject line. As I find time over the next week I'll try to > extract, summarize, and category the constructive contributions. > > Meanwhile, three thoughts occur to me: > > - Why does this topic matter? Because, speaking for myself, as good as they > are, my inability to find answers that I needed at one time or another in > Erlang docs has cost me countless wasted and frustrating hours. Integrate > that experience across the past, current, and future Erlang community and > how many hours are we talking about? If each of us did just a bit to work > toward making the docs best-of-breed, how much time would we ultimately save > individually and collectively? > > - The responses do suggest that the path toward improving docs will involve > grappling with both technical and cultural/organizational/governance issues. > > - Within the past 12 hours I've unsuccessfully asked two questions of the > docs: a) A look at the digraph library left me confused about how to query > the graphs, in part out confusion over vertices and labels. This may just be > a matter of me not reading carefully enough. b) A look at ordsets gave me no > indication of resource costs of adopting ordsets as solution to my project > (nor, best I can determine is this information readily available for other > data structures.) > > These two examples suggest that work toward improving docs will require both > noobies to point out content lapses and confusing language and > wizard/gurus to get the story straight. > > Best to all, > > Lloyd > > Sent from my iPad > > On Jun 2, 2014, at 11:15 AM, Jesper Louis Andersen > wrote: > > > On Mon, Jun 2, 2014 at 2:25 PM, Anthony Ramine wrote: >> >> OTP is a reasonably well-maintained Git repository. It is now using >> GitHub?s pull requests, which makes it easy to contribute to, at least >> according to the persons who wanted OTP to depend on GitHub. > > > Also worth mentioning: We have "Users Guide" documentation exactly for the > purpose of writing User Guides for various parts of the Erlang system. They > are not references, but *guides* which tend to explain the back-story of how > to use a given application. > > References are just that. Quick information for those in the know. Think > FreeBSD/OpenBSD man pages in quality. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseigo@REDACTED Mon Jun 2 21:50:27 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Mon, 02 Jun 2014 21:50:27 +0200 Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: References: <1401479806.358332223@apps.rackspace.com> <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> Message-ID: <34195755.JXr2B0JBBH@freedom> On Monday, June 2, 2014 14:14:01 Garrett Smith wrote: > I'm still not clear why just updating the *existing* docs -- adding fwiw, that's my intention; in fact, it's why i participated in this thread at all. given my current level of erlangery, contributing docs is about the upper extent of my usefulness to erlang right now. it has the added bonus of letting me learn a bit more about how things are put together (explaining is a great way of learning, after all). i've written a fair amount of technical documentation and examples in other free software projects so i have a rough idea of what i'm getting myself into. ;) that said, many of the questions i pose stand as there are a good number of things that could be done to improve not just the content of the docs, but also the workflow around creating and consuming them; as a newcomer i have neither the insight nor the position to propose answers to those question, so i simply ask them hoping someone such as yourself will open up a can of wisdom and provide some guidance. as you noted in your earlier email: "Ease of making these changes and then getting them integrated is of course the big question. If it's a substantial barrier, lowering that friction is something probably worth investing in." -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From n.oxyde@REDACTED Mon Jun 2 21:50:53 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Jun 2014 21:50:53 +0200 Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: <1401738016.30117002@apps.rackspace.com> References: <1401479806.358332223@apps.rackspace.com> <1401643110.963516080@apps.rackspace.com> <2474806.080TbbrlWx@freedom> <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> <1401738016.30117002@apps.rackspace.com> Message-ID: <0D87377C-9E94-4B8E-A183-A93AA6DC6C24@gmail.com> I?m pretty sure documentation patches will be welcomed with enthusiasm. I would suggest visiting the IRC channel on Freenode, as people there will be able to help you in a more timely fashion when you are exploring the OTP repository or get lost in it. -- Anthony Ramine Le 2 juin 2014 ? 21:40, lloyd@REDACTED a ?crit : > I don't mind doing what I can to improve docs within the limits of my knowledge. It's the least I can do to pay back the tremendous effort that Erlang developers and contributors have invested to date. From lloyd@REDACTED Mon Jun 2 22:33:53 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 2 Jun 2014 16:33:53 -0400 (EDT) Subject: [erlang-questions] Erlang docs was Re: How to return all records in dets In-Reply-To: <34195755.JXr2B0JBBH@freedom> References: <1401479806.358332223@apps.rackspace.com> <270FB0D7-C7E5-4646-9322-657185E7B2AF@writersglen.com> <34195755.JXr2B0JBBH@freedom> Message-ID: <1401741233.880328727@apps.rackspace.com> Way to go, Seigo! Looking forward to your contributions. Best, Lloyd -----Original Message----- From: "Aaron J. Seigo" Sent: Monday, June 2, 2014 3:50pm To: erlang-questions@REDACTED Subject: Re: [erlang-questions] Erlang docs was Re: How to return all records in dets _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions On Monday, June 2, 2014 14:14:01 Garrett Smith wrote: > I'm still not clear why just updating the *existing* docs -- adding fwiw, that's my intention; in fact, it's why i participated in this thread at all. given my current level of erlangery, contributing docs is about the upper extent of my usefulness to erlang right now. it has the added bonus of letting me learn a bit more about how things are put together (explaining is a great way of learning, after all). i've written a fair amount of technical documentation and examples in other free software projects so i have a rough idea of what i'm getting myself into. ;) that said, many of the questions i pose stand as there are a good number of things that could be done to improve not just the content of the docs, but also the workflow around creating and consuming them; as a newcomer i have neither the insight nor the position to propose answers to those question, so i simply ask them hoping someone such as yourself will open up a can of wisdom and provide some guidance. as you noted in your earlier email: "Ease of making these changes and then getting them integrated is of course the big question. If it's a substantial barrier, lowering that friction is something probably worth investing in." -- Aaron J. Seigo -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bailey@REDACTED Mon Jun 2 23:28:44 2014 From: andy.bailey@REDACTED (Andy Bailey) Date: Mon, 2 Jun 2014 16:28:44 -0500 Subject: [erlang-questions] Malformed countryName in x509 certs + public_key Message-ID: <20140602212844.GE31112@rackspace.com> Hi All, I'm working on an Erlang project that entails controlling some devices that expose a SOAP api. The device manufacturer made a mistake and shipped the devices with a cert where the countryName field in the cert subject is three characters long. Even with verification disabled via ssl options, we get a crash while parsing the cert (this stack with with R15B01 but I get the same results with 17) {{{badmatch,{error,{asn1,{length,2,<<"USA">>}}}}, [{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,215}]}, {public_key,validate,2,[{file,"public_key.erl"},{line,630}]}, {public_key,path_validation,2,[{file,"public_key.erl"},{line,591}]}, {ssl_handshake,certify,7,[{file,"ssl_handshake.erl"},{line,218}]}, {ssl_connection,certify,2,[{file,"ssl_connection.erl"},{line,514}]}, {ssl_connection,next_state,4,[{file,"ssl_connection.erl"},{line,1929}]},{gen_fsm,handle_msg,7... So presumably the cert runs afoul before the normal verification steps, and disabling verification doesn't help. Normally it wouldn't be a big deal to replace these certs, but there are a bunch of them and the process entails an interruption of service on the device, so I'm hoping to find a workaround. One option would be to modify public_key to accept the three byte value until we can get the certs rotated- I've experimented with modiying PKIX1Explicit88.asn1 and recompiling with asn1ct, but I am totally clueless in this area and suspect I may be on a fools errand :) Anyhow- my purpose in mailing the list was to see if any other erlang users have run into a similar predicament, and to see if you found a good strategy for working around it. Thanks in advance! .andy From ok@REDACTED Tue Jun 3 05:50:40 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 3 Jun 2014 15:50:40 +1200 Subject: [erlang-questions] Conditional configuration? In-Reply-To: References: Message-ID: <14771C48-2983-487F-A624-57292A508560@cs.otago.ac.nz> On 30/05/2014, at 11:09 PM, Roger Lipscombe wrote: > You can provide different config files by using the -config switch. We > use this to have a different configuration for each environment. > Unfortunately, this leads to a lot of duplication in the config files. The question is what the cost of that duplication is. If someone has to *maintain* duplicate files, that's a problem. If the duplicate files are automatically generated from a single master, so that only a single file has to be humanly maintained, that's not much of a problem. Since the configuration files are straightforward data structures, how hard would it be to have a module that generates all the variants? From nx@REDACTED Tue Jun 3 05:55:43 2014 From: nx@REDACTED (nx) Date: Mon, 2 Jun 2014 23:55:43 -0400 Subject: [erlang-questions] Conditional configuration? In-Reply-To: <14771C48-2983-487F-A624-57292A508560@cs.otago.ac.nz> References: <14771C48-2983-487F-A624-57292A508560@cs.otago.ac.nz> Message-ID: Why not store the configuration in the environment? Switching environment config would be as simple as changing the systems environment variables. On Jun 2, 2014 11:51 PM, "Richard A. O'Keefe" wrote: > > On 30/05/2014, at 11:09 PM, Roger Lipscombe wrote: > > > You can provide different config files by using the -config switch. We > > use this to have a different configuration for each environment. > > Unfortunately, this leads to a lot of duplication in the config files. > > The question is what the cost of that duplication is. > If someone has to *maintain* duplicate files, that's > a problem. > > If the duplicate files are automatically generated > from a single master, so that only a single file has > to be humanly maintained, that's not much of a problem. > > Since the configuration files are straightforward > data structures, how hard would it be to have a module > that generates all the variants? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Jun 3 06:14:37 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 3 Jun 2014 16:14:37 +1200 Subject: [erlang-questions] fast tuple sorting In-Reply-To: References: <9D283B66-92FD-4912-A197-05FCF526EE42@gmail.com> Message-ID: One pretty obvious question is "what is the range of the integers"? From aschultz@REDACTED Tue Jun 3 09:54:46 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 3 Jun 2014 07:54:46 +0000 (UTC) Subject: [erlang-questions] Malformed countryName in x509 certs + public_key In-Reply-To: <20140602212844.GE31112@rackspace.com> References: <20140602212844.GE31112@rackspace.com> Message-ID: <1186931372.245852.1401782086354.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hi All, > > I'm working on an Erlang project that entails controlling some > devices that expose a SOAP api. The device manufacturer made a > mistake and shipped the devices with a cert where the countryName > field in the cert subject is three characters long. > > Even with verification disabled via ssl options, we get a crash while > parsing the cert (this stack with with R15B01 but I get the > same results with 17) > > {{{badmatch,{error,{asn1,{length,2,<<"USA">>}}}}, > [{public_key,pkix_decode_cert,2,[{file,"public_key.erl"},{line,215}]}, > {public_key,validate,2,[{file,"public_key.erl"},{line,630}]}, > {public_key,path_validation,2,[{file,"public_key.erl"},{line,591}]}, > {ssl_handshake,certify,7,[{file,"ssl_handshake.erl"},{line,218}]}, > {ssl_connection,certify,2,[{file,"ssl_connection.erl"},{line,514}]}, > {ssl_connection,next_state,4,[{file,"ssl_connection.erl"},{line,1929}]},{gen_fsm,handle_msg,7... > > So presumably the cert runs afoul before the normal verification > steps, and disabling verification doesn't help. > > Normally it wouldn't be a big deal to replace these certs, but there > are a bunch of them and the process entails an interruption of > service on the device, so I'm hoping to find a workaround. > > One option would be to modify public_key to accept the three byte > value until we can get the certs rotated- I've experimented with > modiying PKIX1Explicit88.asn1 and recompiling with asn1ct, but I am > totally clueless in this area and suspect I may be on a fools errand :) The SSL App decodes the certificates as OTPCertificate defined in OTP-PKIX.asn1. Did you try adjusting OTP-X520countryname? It is defined as: OTP-X520countryname ::= CHOICE { printableString PrintableString (SIZE (2)), utf8String UTF8String (SIZE (2)) } Andreas > Anyhow- my purpose in mailing the list was to see if any other erlang > users have run into a similar predicament, and to see if you found a > good strategy for working around it. > > Thanks in advance! > .andy > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From torben.hoffmann@REDACTED Tue Jun 3 08:28:09 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Tue, 03 Jun 2014 08:28:09 +0200 Subject: [erlang-questions] How to access digraph vertices In-Reply-To: References: Message-ID: Hi Lloyd, Lloyd R. Prentice writes: > Hello, > > The documentation for digraphs tells us that vertices can be any Erlang term. > > How would we retrieve a vertex expressed as a record? E.g., by key. Surely we > wouldn't want to use or even know the whole record. > Not quite sure what it is you are trying to do here, maybe an example would help us (or just me) understand what you are up to. Even though vertex() is term() I would not push a record into the vertex. I would push the key in as the vertex() type and let the record be the label of the vertex. But, again, it highly depends on what the use case is... hint, hint!! Might be that digraph is not the right way to solve your problem. Cheers, Torben > Many thanks,, > > LRP > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From dszoboszlay@REDACTED Tue Jun 3 11:09:11 2014 From: dszoboszlay@REDACTED (=?iso-8859-1?Q?D=E1niel_Szoboszlay?=) Date: Tue, 3 Jun 2014 11:09:11 +0200 Subject: [erlang-questions] funs and code loading Message-ID: Hi, There?s some strange behaviour with local funs and code loading in the VM that I don?t understand. If I create a local fun in a process (e.g. something like F = fun () -> ? end and not like F = fun foo:bar/1) the fun will be bound to my process (erlang:fun_info(F, pid) will return the creating process), and also to the current code version of the module where the fun was defined. If I load a new version of the module, the fun will point to old code. If I load an other new version of the module, the fun will no longer has its code in memory. At this point: The process that created the fun is killed (I believe even if it cannot access the fun anymore, but it?s not yet garbage collected). If I sent the fun to an other process, it is killed as well. However, if I stored the fun in an ets table, the table survives the code loading. I can even retrieve the fun in a third process, call erlang:fun_info/2 on the fun there etc. If I try to invoke the fun however I get a badfun error. My question is why?s the difference? This is very confusing: some processes having the fun are killed, some others are not. On the surface the two funs look equal, but are they implemented in a different way somehow? I could imagine that the ?killing fun? stores an actual pointer to the code (on the emulator level) for efficiency reasons, while the ets version stores only the hash of the module or something similar. But how does the fun in the process that retrieved the value from the ets table look like than? And if a process can have a fun that has no corresponding code why are processes killed at all (assuming they are not executing the old code at the moment)? Why aren?t their invokable funs simply replaced with this non-invokable fun? (If I?m not mistaken funs are stored in an off-heap memory area, so you wouldn?t even have to search the process? entire heap to find them.) Could someone explain to me what is the VM doing here and why? Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuelrivas@REDACTED Tue Jun 3 13:29:16 2014 From: samuelrivas@REDACTED (Samuel) Date: Tue, 3 Jun 2014 13:29:16 +0200 Subject: [erlang-questions] PropEr testing of a fixed set of atoms In-Reply-To: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> References: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> Message-ID: Hi, Why are you using proper at all for this task? If you want exhaustive testing, just write a tests that goes over all the alternatives. Using eunit: new_dict_test_() -> DictTypes = [vbisect, dict, orddict], [ ?_assert(valid_empty_dict(T, my_dict_module:new(T))) || T <- DictTypes]. On 1 June 2014 01:03, Jay Nelson wrote: > All the PropEr documentation seems to indicate that only random generators > are possible when testing. Maybe I?m missing something obvious, but I would > like to do a simple exhaustive test on the following example: > > -type epode_dict_type() :: vbisect | dict | orddict. > -spec is_dict(epode_dict_type(), any()) -> boolean(). > > I currently do the following to test it, assuming 6 tries will oversample the set of > three values and nearly always test all three cases: > > -define(TM, my_dict_module). > > check_new_dict() -> > Test_New = ?FORALL(Dict_Type, epode_dict_type(), > valid_empty_dict(Dict_Type, ?TM:new(Dict_Type)), > proper:quickcheck(Test_New, [{num_tests, 6}]). > > valid_empty_dict(Dict_Type, Dict) -> > true = ?TM:is_dict(Dict_Type, Dict), > 0 =:= ?TM:size(Dict). > > > I would like a deterministic generator that would provide a list of all the dictionary > types. I want to be able to update only the epode_dict_type() and have the test > automatically execute for the new types. > > I imagine something like: > > ?FORALL(Dict_Type, proper:enumerate(epode_dict_type()), ?) > > or > > ?LET(Dict_Types, proper:enumerate(epode_dict_type()), > [test(DT) || DT <- Dict_Types]) > > Are there any deterministic generators? > > jay > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Samuel From roger@REDACTED Tue Jun 3 15:29:24 2014 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 3 Jun 2014 14:29:24 +0100 Subject: [erlang-questions] Conditional configuration? In-Reply-To: <14771C48-2983-487F-A624-57292A508560@cs.otago.ac.nz> References: <14771C48-2983-487F-A624-57292A508560@cs.otago.ac.nz> Message-ID: On 3 June 2014 04:50, Richard A. O'Keefe wrote: > > On 30/05/2014, at 11:09 PM, Roger Lipscombe wrote: > >> You can provide different config files by using the -config switch. We >> use this to have a different configuration for each environment. >> Unfortunately, this leads to a lot of duplication in the config files. > > The question is what the cost of that duplication is. > If someone has to *maintain* duplicate files, that's > a problem. Absolutely agree. For *us*, *right now*, the cost is low enough that we're not immediately bothered. I can see it being a problem for others, and becoming a problem for us in future. > Since the configuration files are straightforward > data structures, how hard would it be to have a module > that generates all the variants? At this point, you're basically looking at preprocessing the files, whether you do something in Erlang, or (even) use GNU m4. This is why we're considering using cuttlefish for this. From icfp.publicity@REDACTED Tue Jun 3 15:54:21 2014 From: icfp.publicity@REDACTED (David Van Horn) Date: Tue, 3 Jun 2014 09:54:21 -0400 Subject: [erlang-questions] ICFP 2014 Student Volunteer Programme Message-ID: [With apologies for cross-posting] Please forward this to anyone who may be interested! ICFP Student Volunteer Programme http://icfpconference.org/icfp2014/sv.html We are looking for student volunteers to help with the running of ICFP 2014 in Gothenburg, Sweden. If you are a student (part-time, full-time, undergraduate, masters or PhD), and would like free registration in exchange for helping out, please consider applying! As a student volunteer, you will receive the following: * Free conference registration, including workshops and electronic proceedings * Free lunches and refreshments during breaks. * Free conference banquet ticket and access to student-only social events. * An ICFP 2014 Student Volunteers T-shirt. In return you will be expected to help with the running of the conference. Possible jobs include assisting with technical sessions, workshops, tutorials and panels and helping at the registration desk. Please note that student volunteers are responsible for their own travel arrangements and accommodation. You should be available for at least three full days between 31st of August and the 6th of September 2014 in order to offer 16 hours of volunteering work. Note that we will prioritise students who will be available the full week. Naturally presentations etc. at workshops and technical sessions take precedence. Application Deadline: 15th June 2014 Initial Acceptance and Reserve List announcement: 30th June 2014 For more information, and instructions on how to apply, please see the student volunteer information page at http://icfpconference.org/icfp2014/sv.html. From lloyd@REDACTED Tue Jun 3 16:16:30 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 3 Jun 2014 10:16:30 -0400 (EDT) Subject: [erlang-questions] How to access digraph vertices In-Reply-To: References: Message-ID: <1401804990.449413454@apps.rackspace.com> Hi Toben, Many thanks. Aw, so simple. I should have thought of that. I'm working on a db that has a strong hierarchical structure similar to: books | fiction | non-fiction | genre1 genre2 ... | author1 author2 ... | book1 book2 Queries would look like: 1) List all genres 2) List all authors in genre 3) Select author 3) List all books in genre 4) List all books in genre 5) Select book Many times more reads than writes. As I understand, the whole structure has to be built in RAM. Genres could, conceivably be factored into separate graphs of up to several hundred books and authors/genre. Which leaves the questions: 1) Is a transaction-like technique available to permit write graph structure to disk with losing record writes coming in in the meantime? 2) Any gains or simply querying a flat db? 3) Is there a yet better way? Thanks again, Lloyd -----Original Message----- From: "Torben Hoffmann" Sent: Tuesday, June 3, 2014 2:28am To: "Lloyd R. Prentice" Cc: "Erlang Users' List" Subject: Re: [erlang-questions] How to access digraph vertices Hi Lloyd, Lloyd R. Prentice writes: > Hello, > > The documentation for digraphs tells us that vertices can be any Erlang term. > > How would we retrieve a vertex expressed as a record? E.g., by key. Surely we > wouldn't want to use or even know the whole record. > Not quite sure what it is you are trying to do here, maybe an example would help us (or just me) understand what you are up to. Even though vertex() is term() I would not push a record into the vertex. I would push the key in as the vertex() type and let the record be the label of the vertex. But, again, it highly depends on what the use case is... hint, hint!! Might be that digraph is not the right way to solve your problem. Cheers, Torben > Many thanks,, > > LRP > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Tue Jun 3 16:56:02 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 3 Jun 2014 07:56:02 -0700 Subject: [erlang-questions] funs and code loading In-Reply-To: References: Message-ID: <20140603145601.GF7746@ferdair.local> On 06/03, D?niel Szoboszlay wrote: > My question is why?s the difference? > > [...] > > Could someone explain to me what is the VM doing here and why? > The distinction here comes back to the difference between local calls, and fully qualified function calls, vis. code loading. It's a process I have tried to describe at http://learnyousomeerlang.com/designing-a-concurrent-application#hot-code-loving including this image: http://learnyousomeerlang.com/static/img/hot-code-loading.png The gist of it is that local calls (calling a function without a module) always keeps using the current code used by a process at the time it was being called. Fully qualified calls are calls made through a module (Mod:Fun(Args), apply(Mod, Fun, [Args]), and so on) will always use the latest version of a module that is loaded in the VM. If you load a third version of a module while a process still runs with the first one, that process gets killed by the VM, which assumes it was an orphan process without a supervisor or a way to upgrade itself. If nobody runs the oldest version, it is simply dropped and the newest ones are kept instead. So what you see with anonymous functions here is the same mechanism, just repeated in a different way. An inline anonymous function like fun() -> do_something_local() end or fun my_local_stuff/2 will be declared and running the 'old' version of the code, and pointing to the old version of the code. This, like any other process running or holding old code, will need to be killed if it can't drop that value before a second code reloading is done. A fully qualified fun (fun Mod:Fun/Arity) will however be a fully qualified function that doesn't refer to any specific code version and will be reloadable. This may have an important impact when deciding whether to use spawn(fun() -> my_loop(), log(whatever) end) versus spawn(?MODULE, my_loop, []), for example. Hopefully that helps. Regards, Fred. From jay@REDACTED Tue Jun 3 17:54:43 2014 From: jay@REDACTED (Jay Nelson) Date: Tue, 3 Jun 2014 08:54:43 -0700 Subject: [erlang-questions] PropEr testing of a fixed set of atoms In-Reply-To: References: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> Message-ID: <9A92D1B5-0DC1-4E22-A61F-A7BEABC78E00@duomark.com> On Jun 3, 2014, at 4:29 AM, Samuel wrote: > Hi, > > Why are you using proper at all for this task? If you want exhaustive > testing, just write a tests that goes over all the alternatives. Using > eunit: > > new_dict_test_() -> > DictTypes = [vbisect, dict, orddict], > [ ?_assert(valid_empty_dict(T, my_dict_module:new(T))) || T <- DictTypes]. > Several reasons: 1) I believe unit testing is too brittle and attached to the code written 2) I prefer to use a single technique where comprehensive 3) I want to avoid repeating the list of valid datatype atoms (which occur in -type) 4) I am using PropEr for other property tests as my main tool 5) PropEr already knows about my type declarations Because of my experience on several projects with #1 I?ve stopped using xUnit tools. Several years ago I adopted common_test over eunit. Now I am looking to improve my coverage in a more general fashion and I run PropEr from within common_test with cover to aid in detecting code that my property tests overlook. I also believe thinking in property-based testable terms leads to a better code architecture over unit-testing specific functions. PropEr has built-in generators that already enumerate the datatypes, but select randomly from them when generating test cases. In the case of a fixed, limited set of enumerables, it should be an obvious property to test them all. I just thought I was missing something in the documentation that allowed controlling the randomness without jumping through hoops to create filters and a dictionary of already seen values. jay From dszoboszlay@REDACTED Tue Jun 3 18:23:03 2014 From: dszoboszlay@REDACTED (=?iso-8859-1?Q?D=E1niel_Szoboszlay?=) Date: Tue, 3 Jun 2014 18:23:03 +0200 Subject: [erlang-questions] funs and code loading In-Reply-To: <20140603145601.GF7746@ferdair.local> References: <20140603145601.GF7746@ferdair.local> Message-ID: Hi Fred, I think we are talking about slightly different things here. I understand the concepts of old code and why shall a process executing the first version of the code be terminated when the third version is loaded. But I don?t understand why holding a fun (but not executing the code!) is a reason for killing the process. Especially since I can hide the fun in an ets table and read it back from there after the code is gone. So the emulator doesn?t have a built-in constraint that every fun must point to existing (new or old) code. This is not the same mechanism as executing old code either: executing a fun that points to no code raises a badfun error (which can be catched, if I wish). Regards, Daniel On 2014 Jun 3, at 16:56 , Fred Hebert wrote: > On 06/03, D?niel Szoboszlay wrote: >> My question is why?s the difference? >> >> [...] >> >> Could someone explain to me what is the VM doing here and why? >> > > [?] > So what you see with anonymous functions here is the same mechanism, > just repeated in a different way. > [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Wed Jun 4 02:16:44 2014 From: sdl.web@REDACTED (Leo Liu) Date: Wed, 04 Jun 2014 08:16:44 +0800 Subject: [erlang-questions] unbreak erlang html documentation in git Message-ID: Hi there, For the past weeks, the links in the html documentation (of erlang built from git) point to many dead targets due to version changes. Could someone unbreak them or tell me how to? Thanks. Leo From samuelrivas@REDACTED Wed Jun 4 08:52:27 2014 From: samuelrivas@REDACTED (Samuel) Date: Wed, 4 Jun 2014 08:52:27 +0200 Subject: [erlang-questions] PropEr testing of a fixed set of atoms In-Reply-To: <9A92D1B5-0DC1-4E22-A61F-A7BEABC78E00@duomark.com> References: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> <9A92D1B5-0DC1-4E22-A61F-A7BEABC78E00@duomark.com> Message-ID: Hi, I don't know what is your definition of unit testing, but to me it is not about the tool you use but what you are actually testing. From the example you posted I understand you are writing tests to verify the API of a module somewhat in isolation, which falls into what I understand is unit testing. Regardless of your tool selection, what you want to do falls outside the model of quickchecking using generators, as you don't want to generate random data. You simply want to evaluate a static expression and verify that it returns true (and doesn't crash in the match with true). I understand the ?FORALL notation seems natural when you want to test all the values contained in one type, but that is not what ?FORALL does, it tests a fixed number of samples, 100 by default, not all. For the same reason, you are not using the same technique either. You can, of course, find ways of using proper for this for the sake of running all your tests in proper if that is valuable for you. I would advise to use the right tool for the right job though. Anyway, given that proper already parses your types, it wouldn't be unreasonable for it to provide an api to use that information, so that you could get the DictTypes list without duplicating the types in your code. I don't know if the proper guys are willing to invest on that or accept a contribution that does it. You could also read the type information yourself, as proper does, from the module abstract code. On 3 June 2014 17:54, Jay Nelson wrote: > > On Jun 3, 2014, at 4:29 AM, Samuel wrote: > >> Hi, >> >> Why are you using proper at all for this task? If you want exhaustive >> testing, just write a tests that goes over all the alternatives. Using >> eunit: >> >> new_dict_test_() -> >> DictTypes = [vbisect, dict, orddict], >> [ ?_assert(valid_empty_dict(T, my_dict_module:new(T))) || T <- DictTypes]. >> > > Several reasons: > > 1) I believe unit testing is too brittle and attached to the code written > 2) I prefer to use a single technique where comprehensive > 3) I want to avoid repeating the list of valid datatype atoms (which occur in -type) > 4) I am using PropEr for other property tests as my main tool > 5) PropEr already knows about my type declarations > > > Because of my experience on several projects with #1 I?ve stopped > using xUnit tools. Several years ago I adopted common_test over > eunit. Now I am looking to improve my coverage in a more general > fashion and I run PropEr from within common_test with cover to aid > in detecting code that my property tests overlook. I also believe thinking > in property-based testable terms leads to a better code architecture > over unit-testing specific functions. > > PropEr has built-in generators that already enumerate the datatypes, > but select randomly from them when generating test cases. In the case > of a fixed, limited set of enumerables, it should be an obvious property > to test them all. I just thought I was missing something in the > documentation that allowed controlling the randomness without > jumping through hoops to create filters and a dictionary of already > seen values. > > jay > -- Samuel From jesper.louis.andersen@REDACTED Wed Jun 4 11:14:23 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 4 Jun 2014 11:14:23 +0200 Subject: [erlang-questions] PropEr testing of a fixed set of atoms In-Reply-To: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> References: <0BE16665-C728-43DC-9504-1C6D84144211@duomark.com> Message-ID: On Sun, Jun 1, 2014 at 1:03 AM, Jay Nelson wrote: > I currently do the following to test it, assuming 6 tries will oversample > the set of > three values and nearly always test all three cases: > The key is to use collect/aggregate/classify. You want to print the distribution of your test cases so you have confidence you got all variants covered. If the distributions are skewed, you want to tune your generators so they generate more nasty cases. Coincidentally, this is why automatic derivation of generators isn't that useful in practice. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvg.mailing@REDACTED Wed Jun 4 14:09:19 2014 From: rvg.mailing@REDACTED (Rudolph van Graan) Date: Wed, 04 Jun 2014 13:09:19 +0100 Subject: [erlang-questions] Maps matching syntax - matching on keys that don't exist in a map - Alternative syntax? Message-ID: Hi there, I am getting to grips on how one can use maps, but I keep on hitting the same problem. Imagine I have a map which could contain any of three keys : [a,b,c]). Key a is mandatory, the other two may or may not be there depending on business rules: > convert_map(#{a := ValueA, b := OptionalValueB, c := OptionalValueC}) -> > {ValueA,OptionalValueB, OptionalValueC}. The problem is that this doesn't work if b and c are not present: > (system@REDACTED)31> pend:convert_map(#{ a => 1, b => 2, c => 3}). > {1,2,3} > (system@REDACTED)32> pend:convert_map(#{ a => 1, b => 2}). > ** exception error: no function clause matching pend:convert_map(#{a => 1,b => 2}) (pend.erl, line 105) > (system@REDACTED)33> pend:convert_map(#{ a => 1, c => 3}). > ** exception error: no function clause matching pend:convert_map(#{a => 1,c => 3}) (pend.erl, line 105) So do deal with this, I wrote this code: > convert_map(#{a := A, b := OptionalValueB, c := OptionalValueC}) -> > {A,OptionalValueB,OptionalValueC}; > convert_map(Map = #{a := A}) -> > {A, value_b(Map), value_c(Map)}. > > > value_b(#{ b := OptionalValueB}) -> OptionalValueB; > value_b(#{}) -> undefined. > > value_c(#{ c := OptionalValueC}) -> OptionalValueC; > value_c(#{}) -> undefined. which works: > (system@REDACTED)34> pend:convert_map(#{ a => 1, c => 3}). > {1,undefined,3} > (system@REDACTED)35> pend:convert_map(#{ a => 1, c => 2}). > {1,undefined,2} > (system@REDACTED)36> pend:convert_map(#{ a => 1, b => 2}). > {1,2,undefined} But this feels very clumsy and not Erlang'ish at all. Are there plans for introducing another operator apart from ":=" that will do an optional/default match? Perhaps "~="? Then the code would like this: > convert_map(#{a := A, b ~= OptionalValueB, c ~= OptionalValueC}) -> The same problem will occur when single value access is implemented. I would need a way to extract a key that may or may not be in the map. Any suggestions? Rudolph From Ola.Backstrom@REDACTED Wed Jun 4 14:34:13 2014 From: Ola.Backstrom@REDACTED (=?iso-8859-1?Q?Ola__B=E4ckstr=F6m?=) Date: Wed, 4 Jun 2014 12:34:13 +0000 Subject: [erlang-questions] Maps matching syntax - matching on keys that don't exist in a map - Alternative syntax? In-Reply-To: References: Message-ID: <68757dc3cebd4e55996bdd2ebc666ca1@exsrvfe.ls.local> You can use maps:merge to provide default values. See the example at http://www.erlang.org/doc/man/maps.html#merge-2 /Ola B?ckstr?m _______________________________________________ Switchboard: +46 (0)63-18 34 40 Postal address: Box 153, 840 60 Br?cke, Sweden Visit: Arm?gr?nd 7, ?stersund, Sweden Web: www.loxysoft.se -----Original Message----- From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Rudolph van Graan Sent: den 4 juni 2014 14:09 To: erlang-questions Questions Subject: [erlang-questions] Maps matching syntax - matching on keys that don't exist in a map - Alternative syntax? Hi there, I am getting to grips on how one can use maps, but I keep on hitting the same problem. Imagine I have a map which could contain any of three keys : [a,b,c]). Key a is mandatory, the other two may or may not be there depending on business rules: > convert_map(#{a := ValueA, b := OptionalValueB, c := OptionalValueC}) -> > {ValueA,OptionalValueB, OptionalValueC}. The problem is that this doesn't work if b and c are not present: > (system@REDACTED)31> pend:convert_map(#{ a => 1, b => 2, c => 3}). > {1,2,3} > (system@REDACTED)32> pend:convert_map(#{ a => 1, b => 2}). > ** exception error: no function clause matching pend:convert_map(#{a > => 1,b => 2}) (pend.erl, line 105) (system@REDACTED)33> pend:convert_map(#{ a => 1, c => 3}). > ** exception error: no function clause matching pend:convert_map(#{a > => 1,c => 3}) (pend.erl, line 105) So do deal with this, I wrote this code: > convert_map(#{a := A, b := OptionalValueB, c := OptionalValueC}) -> > {A,OptionalValueB,OptionalValueC}; > convert_map(Map = #{a := A}) -> > {A, value_b(Map), value_c(Map)}. > > > value_b(#{ b := OptionalValueB}) -> OptionalValueB; > value_b(#{}) -> undefined. > > value_c(#{ c := OptionalValueC}) -> OptionalValueC; > value_c(#{}) -> undefined. which works: > (system@REDACTED)34> pend:convert_map(#{ a => 1, c => 3}). > {1,undefined,3} > (system@REDACTED)35> pend:convert_map(#{ a => 1, c => 2}). > {1,undefined,2} > (system@REDACTED)36> pend:convert_map(#{ a => 1, b => 2}). > {1,2,undefined} But this feels very clumsy and not Erlang'ish at all. Are there plans for introducing another operator apart from ":=" that will do an optional/default match? Perhaps "~="? Then the code would like this: > convert_map(#{a := A, b ~= OptionalValueB, c ~= OptionalValueC}) -> The same problem will occur when single value access is implemented. I would need a way to extract a key that may or may not be in the map. Any suggestions? Rudolph _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From co7eb@REDACTED Wed Jun 4 14:48:08 2014 From: co7eb@REDACTED (=?iso-8859-1?Q?Ivan_Carmenates_Garc=EDa?=) Date: Wed, 4 Jun 2014 08:48:08 -0400 Subject: [erlang-questions] CB render a param to the url Message-ID: <000001cf7ff3$40bccfd0$c2366f70$@frcuba.co.cu> Hi David and all, I would like to know if there is a way in CB to pass a parameter to a page url and values to the template at the same time using a redirect or render_other, for example in my case: I have a simple page with a control tab and in the url I specify as a parameter witch tab will be showed when the page loads, ex: //localhost/session?tab=login Then if some errors occurs while entering the login information I have to redirect from the controller who is dealing with the POST login request to the //localhost/session again but passing ?tab=login to open the corresponded tab, ex: //localhost/session?tab=login but at the same time I have to pass values to the django template. I tried this, but it didn?t work! {render_other, [{controller, "index"}, {action, "session?tab=login"}], [{errors, Errors}]}. And this: {render_other, [{controller, "index"}, {action, "session"}, {tab, "login"}], %% or {params, [{tab, "login"}]} and many of its variants [{errors, Errors}]}. I also tried to do something like this in the boss routes file {"/signup", [{controller, "index"}, {action, "session"}, {tab, "login"}]}. So I could simplify the render other {render_other, [{controller, "index"}, {action, "signup"}], [{errors, Errors}]}. Best regards, Ivan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Jun 4 15:46:36 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 4 Jun 2014 15:46:36 +0200 Subject: [erlang-questions] Maps matching syntax - matching on keys that don't exist in a map - Alternative syntax? In-Reply-To: References: Message-ID: On Wed, Jun 4, 2014 at 2:09 PM, Rudolph van Graan wrote: > Any suggestions? You are modelling your data such that illegal data is representable. This is usually a mistake based on the lack of proper sum-types in the language of choice. The sum-types can be emulated in Erlang by use of tuples. Say we have #{ a => x, b => 8 } and #{ a => y, c => 9 }. Here, the 'a' key steers whether or not the 'b' key and the 'c' key are valid. But if you use -spec t() :: {x, integer()} | {y, integer()}. as your representation, then you can match directly on the structure: case Struct of {x, B} -> ...; {y, C} -> ... end, and there is no way we can represent the data #{ a => x, c => 9 } for instance. The resolution is to pick a better representation format of your data. And to aggressively convert badly formed data at the system border. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Wed Jun 4 17:02:28 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 4 Jun 2014 10:02:28 -0500 Subject: [erlang-questions] pkcs-12? Message-ID: I am unable to find any Erlang support for pkcs-12. I am looking to both encode and decode. Any suggestions? Thanks, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Jun 5 09:00:06 2014 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 5 Jun 2014 09:00:06 +0200 Subject: [erlang-questions] sext encoding of maps Message-ID: <253CEBD9-5D1C-4BD4-AD51-457DF1C8C8D0@feuerlabs.com> I made a first stab at encoding maps using sext. I have not yet updated the EQC spec, or added any checks to ensure that the code will compile with a pre-R17 OTP (it won?t). I only gave a fleeting thought to how prefix encoding of maps should work. The good news is that the encoding is backwards compatible! :) That is, I was able to squeeze in maps between tuples and lists, without having to rearrange type tags. Comments and contributions are welcome: https://github.com/uwiger/sext/tree/uw-maps BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From cao.xu@REDACTED Thu Jun 5 11:39:35 2014 From: cao.xu@REDACTED (rytong-caoxu) Date: Thu, 5 Jun 2014 17:39:35 +0800 Subject: [erlang-questions] pkcs-12? In-Reply-To: References: Message-ID: If you don?t care about the performance, you can call openssl-client command line tools from os:cmd() to convert pkcs-12 files to those Erlang support, pkcs-1 for example. ? 2014?6?4????11:02?Daniel Goertzen ??? > I am unable to find any Erlang support for pkcs-12. I am looking to both encode and decode. Any suggestions? > > Thanks, > Dan. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kenji@REDACTED Thu Jun 5 15:15:20 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Thu, 5 Jun 2014 22:15:20 +0900 Subject: [erlang-questions] SSL/TLS MITM CCS Injection case on Erlang ssl module? Message-ID: <20140605131520.GA27711@k2r.org> I'd be glad if Erlang core team could give an idea about how the vulnerability of CVE-2014-0224 would or would not affect Erlang ssl module: http://www.openssl.org/news/secadv_20140605.txt http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html Regards, Kenji Rikitake From peerst@REDACTED Thu Jun 5 15:19:51 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Thu, 5 Jun 2014 15:19:51 +0200 Subject: [erlang-questions] LibreSSL Slides of interest to Erlang users Message-ID: Hi, just stumbled upon these slides: LibreSSL - An OpenSSL replacement. The first 30 days, and where we go from here. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html They seem to have made good progress so far (and OpenSSL seems to be more horrible that I thought so far). The longer term goals are interesting for OTP's use also: Longer Term Goals - Provide a better (replacement, reduced) API - Reduce code base even more. - Split out non-crypto things from libcrypto - Split libcrypto from libssl. Since OTP seems to only use libcrypto, having a separate sane version of it looks like a good thing. Cheers, -- Peer From sverker.eriksson@REDACTED Thu Jun 5 16:36:19 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 5 Jun 2014 16:36:19 +0200 Subject: [erlang-questions] blowfish CFB mode in Crypto application In-Reply-To: <5388299A.7080609@palmoid.com> References: <5388299A.7080609@palmoid.com> Message-ID: <53908063.10508@erix.ericsson.se> On 05/30/2014 08:47 AM, Igor Nesterov wrote: > Hi, > > I'm using block_encrypt function from crypto application with blowfish > cipher in CFB mode and find that block_encrypt doesn't allow to > continue sequential encryption in this mode. Underlying > BF_cfb64_encrypt function changes parameters iv and num, so they can > be passed to the next call.And bf_cfb64_crypt from C part of crypto > application doesn't pass those parameters back to erlang side, so it's > impossible to obtain new parameters for the new call. Is there another > solution exists? Or it's better to make patch? There is an interface for streaming encrypt/decrypt: crypto:stream_init/2/3 crypto:stream_encrypt/2 crypto:stream_decrypt/2 A patch that adds blowfish mode to this interface is the solution I think. /Sverker, Erlang/OTP From sverker.eriksson@REDACTED Thu Jun 5 17:15:52 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 5 Jun 2014 17:15:52 +0200 Subject: [erlang-questions] crypto:block_decrypt doesn't return ivec In-Reply-To: References: Message-ID: <539089A8.7010706@ericsson.com> On 05/09/2014 04:48 PM, Max Lapshin wrote: > I'm implementing Apple HLS SAMPLE-AES decryption and according to their > spec, it is required to decrypt different blocks independently. > > But specs are written for fun, so it is required to take ivec from decrypt > process and use it in next decrypt. > > crypto:block_decrypt(aes_cbc128,....) returns only decrypted text and > looses ivec: > > ret_ptr = enif_make_new_binary(env, data_bin.size, &ret); > memcpy(ivec, ivec_bin.data, 16); /* writable copy */ > AES_cbc_encrypt(data_bin.data, ret_ptr, data_bin.size, &aes_key, ivec, > i); > CONSUME_REDS(env,data_bin); > return ret; > > > modified ivec is lost. So I cannot reuse it and I need to cut all parts for > decrypting, glue them together and then split back. > > Why modified ivec is ignored? Is it possible to modify api in some way that > it would be possible to fix it and return ivec also? > > There is an api for this that could be amended with more cipher modes: crypto:stream_init/2/3 crypto:stream_encrypt/2 crypto:stream_decrypt/2 /Sverker, Erlang/OTP From g@REDACTED Thu Jun 5 20:49:25 2014 From: g@REDACTED (Guilherme Andrade) Date: Thu, 05 Jun 2014 19:49:25 +0100 Subject: [erlang-questions] SSL/TLS MITM CCS Injection case on Erlang ssl module? In-Reply-To: <20140605131520.GA27711@k2r.org> References: <20140605131520.GA27711@k2r.org> Message-ID: <5390BBB5.6050505@gandrade.net> AFAIK, all the handshake logic is implemented in Erlang; quoting from memory based on some previous thread (probably around the time of heartbleed), OpenSSL is used only for the heavy arithmetic. If in fact true, this would discard automatically a part of those CVEs. But I'd rather wait for a more informed opinion on this. Cheers, On 05-06-2014 14:15, Kenji Rikitake wrote: > I'd be glad if Erlang core team could give an idea about how the > vulnerability of CVE-2014-0224 would or would not affect Erlang ssl > module: > > http://www.openssl.org/news/secadv_20140605.txt > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html > > Regards, > Kenji Rikitake > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme Andrade PGP fingerprint: 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kenneth.lundin@REDACTED Thu Jun 5 21:33:54 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 5 Jun 2014 21:33:54 +0200 Subject: [erlang-questions] SSL/TLS MITM CCS Injection case on Erlang ssl module? In-Reply-To: <5390BBB5.6050505@gandrade.net> References: <20140605131520.GA27711@k2r.org> <5390BBB5.6050505@gandrade.net> Message-ID: The SSL/TLS protocol is implemented in Erlang , only the crypto routines (libcrypto) from OpenSSL are used. So it seems that these CVEs are not relevant for Erlang. /Kenneth Erlang/OTP, Ericsson On Thu, Jun 5, 2014 at 8:49 PM, Guilherme Andrade wrote: > AFAIK, all the handshake logic is implemented in Erlang; quoting from > memory based on some previous thread (probably around the time of > heartbleed), OpenSSL is used only for the heavy arithmetic. If in fact > true, this would discard automatically a part of those CVEs. But I'd > rather wait for a more informed opinion on this. > > Cheers, > > > On 05-06-2014 14:15, Kenji Rikitake wrote: > > I'd be glad if Erlang core team could give an idea about how the > > vulnerability of CVE-2014-0224 would or would not affect Erlang ssl > > module: > > > > http://www.openssl.org/news/secadv_20140605.txt > > > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html > > > > Regards, > > Kenji Rikitake > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- > Guilherme Andrade > > PGP fingerprint: 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Fri Jun 6 11:14:34 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 6 Jun 2014 09:14:34 +0000 (UTC) Subject: [erlang-questions] SSL/TLS MITM CCS Injection case on Erlang ssl module? In-Reply-To: <20140605131520.GA27711@k2r.org> References: <20140605131520.GA27711@k2r.org> Message-ID: <78834196.256793.1402046074661.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > I'd be glad if Erlang core team could give an idea about how the > vulnerability of CVE-2014-0224 would or would not affect Erlang ssl > module: > > http://www.openssl.org/news/secadv_20140605.txt > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html My take on this: Short version ============= I believe that Erlang SSL does not handle out of sequence CCS (Change-Cipher-Spec) messages correctly, whether that can be exploited or not is unclear. Long version ============ >From reading the source, I would say that the SSL application will accept CCS messages that are out of sequence. tls_connection:next_state is processing the packets. Normal handshake records are processed through the tls_connection FSM, but a CCS message is processed immediately, outside of the FSM in any state. One of the problems OpenSSL has with this, are that invalid pointers might be exploited. Luckily this is not going to be an issue for Erlang, ssl might crash, but it will not reveal sensitive data. The other issue as described by OpenSSL: > An attacker using a carefully crafted handshake can force the use of weak > keying material in OpenSSL SSL/TLS clients and servers. This can be exploited > by a Man-in-the-middle (MITM) attack where the attacker can decrypt and > modify traffic from the attacked client and server. Now this might be a problem for Erlang. A CCS will activate the pending connection state. ssl_record initializes the pending states with values that are partly valid. The bulk_cipher_algo and the secrets are not initialized, so I'm not sure if it would be possible to craft the handshake sequence in a way to have valid, but weak values in there. Regards Andreas > > Regards, > Kenji Rikitake > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From dan353hehe@REDACTED Fri Jun 6 19:09:48 2014 From: dan353hehe@REDACTED (Daniel Barney) Date: Fri, 6 Jun 2014 11:09:48 -0600 Subject: [erlang-questions] eaddrinuse even though I am using {reuseaddr, true} Message-ID: My application establishes a LOT of outbound connections on an internal network, and then closes them really quickly. I recently started running my erlang applications on SmartOs, an os based on illumos/solaris, and noticed something strange. Every now and then when establishing the outbound connection I get an error {error,eaddrinuse}. I used to get this when running on Ubuntu, so I added {reuseaddr,true} which solved the issue. And now that I switched over to using SmartOS the issue has popped back up. Has anyone seen this kind of difference between the VM running between linuix/unix? And does anyone know where I could start looking to debug this? Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.maushake@REDACTED Fri Jun 6 19:27:11 2014 From: joerg.maushake@REDACTED (=?UTF-8?Q?=22J=C3=B6rg_Maushake=22?=) Date: Fri, 6 Jun 2014 19:27:11 +0200 Subject: [erlang-questions] eaddrinuse even though I am using {reuseaddr, true} In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lloyd@REDACTED Fri Jun 6 20:20:14 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Fri, 6 Jun 2014 14:20:14 -0400 (EDT) Subject: [erlang-questions] Problems loading LeoFS Message-ID: <1402078814.057229878@apps.rackspace.com> Hello, This is one of those Mickey-the-Dunce questions that no doubt everyone knows the answer except yours truly. But, I'd like to load LeoFS on a spare server. Following the instructions here: http://leo-project.net/leofs/docs/getting_started.html I set out to do so. libatomic_ops-7.2d compiled fine, as did otp_src_R16B03-1. But the last step of LeoFS failed: ==> leo_mcerl (compile) make[1]: Entering directory `/home/lloyd/libatomic_ops-7.2/otp_src_R16B03-1/leofs/deps/leo_mcerl/c_src/libcutil/build' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory `/home/lloyd/libatomic_ops-7.2/otp_src_R16B03-1/leofs/deps/leo_mcerl/c_src/libcutil/build' ERROR: Command [compile] failed! make: *** [compile] Error 1 I checked Google for Debian + libcutil, but got this: Did you mean: Debian + libcurl Then, confused somewhat by the fact that LeoFS docs doesn't specify directories, it occurred to me that I had been compiling these three packages one atop the other: lloyd@REDACTED:~/libatomic_ops-7.2/otp_src_R16B03-1/leofs$ Maybe that's the problem. So I deleted all work, and started over, but compiling each package at my home root directory: lloyd@REDACTED:~/ Now I got a different error: lloyd@REDACTED:~/leofs$ make && make release /usr/bin/env: escript: No such file or directory make: *** [deps] Error 127 So now I'm wondering: 1) Which approach is correct--- compile one atop the other or each from home root? 2) Am I doing something else wrong? 3) Or are there some lapses in the LeoFS docs? 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 max.lapshin@REDACTED Fri Jun 6 20:34:07 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 6 Jun 2014 22:34:07 +0400 Subject: [erlang-questions] Problems loading LeoFS In-Reply-To: <1402078814.057229878@apps.rackspace.com> References: <1402078814.057229878@apps.rackspace.com> Message-ID: What for is the libcutil in LeoFS? -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeljalvarezmiguel@REDACTED Fri Jun 6 22:31:49 2014 From: angeljalvarezmiguel@REDACTED (Angel Alvarez (GMAIL)) Date: Fri, 6 Jun 2014 22:31:49 +0200 Subject: [erlang-questions] Supervisor tree width? In-Reply-To: <0908DD8B-C362-4E7A-B954-0552FF9B6719@gmail.com> References: <0908DD8B-C362-4E7A-B954-0552FF9B6719@gmail.com> Message-ID: Sorry I came across this, and I need to ask, I'm planning to have several thousand children (FSM machines) under the same supervisor. There is one FSM per client and they don't talk to each other so they are unrelated in this regard .. I thought "simple_one_one" is designed to cope with this, is it the right thing to do? or I'm missing something out? Thanks in advance! Angel Alvarez (GMAIL) angeljalvarezmiguel@REDACTED El 30/05/2014, a las 15:02, Dmitry Kolesnikov escribi?: > I?ll be trivial to say that design of supervisor tree is an application specific. > > One lesson learned is that supervision it?s about the guarantees. Take a look into Fred?s post > http://ferd.ca/it-s-about-the-guarantees.html > > Personally, I?am splitting an application to smaller functional units with own supervisors per unit. > If an unit design needs 15 children then I see no issue to have them. > However, if 15 children do not have any relations each other then I am combining them to guaranty deterministic application state after failure. > > Best Regards, > Dmitry > > On 30 May 2014, at 14:28, Roger Lipscombe wrote: > >> I'm concerned that the top-level supervisor in one of our applications >> has too many children. It has about 15 children, which are only >> vaguely related to each other. >> >> What's a good rule-of-thumb for whether a supervisor tree is too wide? >> Or too deep? Or am I thinking on the wrong level here? >> >> Thanks, >> Roger. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From yousuke.hara@REDACTED Sat Jun 7 01:15:49 2014 From: yousuke.hara@REDACTED (Yosuke Hara) Date: Sat, 7 Jun 2014 08:15:49 +0900 Subject: [erlang-questions] Problems loading LeoFS In-Reply-To: References: <1402078814.057229878@apps.rackspace.com> Message-ID: <30108866-10E1-439F-B9D8-EDD010E57B45@gmail.com> Hi, Actually, we does not write about required libraries on "Getting Started". I'll fix it correctly soon. Would you see LeoFS installation page? URL of the page is as follows: http://leo-project.net/leofs/docs/install.html#install-required-libraries-using-apt-get-ubuntu-server-12-04-lts Thank you. Yosuke Hara Leo Project: http://leo-project.net/leofs > On Jun 7, 2014, at 3:34 AM, Max Lapshin wrote: > > What for is the libcutil in LeoFS? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Sat Jun 7 04:00:01 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Fri, 6 Jun 2014 22:00:01 -0400 Subject: [erlang-questions] Problems loading LeoFS In-Reply-To: <30108866-10E1-439F-B9D8-EDD010E57B45@gmail.com> References: <1402078814.057229878@apps.rackspace.com> <30108866-10E1-439F-B9D8-EDD010E57B45@gmail.com> Message-ID: <9834F0BB-E9FC-4C9F-A888-BCF47BEBE9D2@writersglen.com> Hi Yosuke, Thank you for responding to my question. I did indeed miss the section on required libraries. I'll fix that tomorrow. As noted in my question, my other confusion had to do with which directory I should have been in at each step. Each step is simply prefaced with $. Perhaps this is something most folks would know, but I'm not that experienced. LeoFS looks like a terrific program. I'm looking forward to understanding it better and, perhaps employing it in a project I'm working on. Many thanks again for your help and your outstanding work with LeoFS. All the best, Lloyd Sent from my iPad > On Jun 6, 2014, at 7:15 PM, Yosuke Hara wrote: > > Hi, > Actually, we does not write about required libraries on "Getting Started". > I'll fix it correctly soon. > > Would you see LeoFS installation page? > URL of the page is as follows: > > http://leo-project.net/leofs/docs/install.html#install-required-libraries-using-apt-get-ubuntu-server-12-04-lts > > Thank you. > > Yosuke Hara > Leo Project: http://leo-project.net/leofs > >> On Jun 7, 2014, at 3:34 AM, Max Lapshin wrote: >> >> What for is the libcutil in LeoFS? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Sat Jun 7 00:49:06 2014 From: tom@REDACTED (Tom van Neerijnen) Date: Fri, 6 Jun 2014 23:49:06 +0100 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel Message-ID: Hi all Does anyone have an example of an Erlang port forwarding SSH server? My aim is to give it a ssh -R 1234:localhost:5678 and have the erlang server forward connections on 1234 to localhost:5678. I've started ssh:daemon as described in the docs and have an Erlang shell on the server end of my ssh connection, so that at least is working, but I can't seem to get ssh_connection:direct_tcpip called. I guessed that I needed to add a "direct-tcpip" subsystem but this is ignored when I ssh in. Anyone got any pointers to get me started? -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Jun 7 10:39:01 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 7 Jun 2014 10:39:01 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: What is the end point? How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk through back streets of s?der to get there fj?llgatan etc. Best to tweet a reply hash tags #euc and #erlang -Joe On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund wrote: > > Hello! > > The evening before the EUC (Wednesday), we invite participants from abroad > to a city-walk through central Stockholm (showing the castle, the old town > etc) and a beer/meal together at a pub. If you care to join us, please > send an e-mail to Henry and me. > > When and where? We'll meet up at the central station at 18:00, about 15-20 > meters from the main entrance (ground level) there is a "large hole" in > the floor (about 8 meters in diameter), with an iron fence around it. > > Best regards, > > Niclas Eklund @ Erlang/OTP > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Sat Jun 7 12:19:49 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 7 Jun 2014 12:19:49 +0200 Subject: [erlang-questions] SSL/TLS MITM CCS Injection case on Erlang ssl module? In-Reply-To: <78834196.256793.1402046074661.JavaMail.zimbra@tpip.net> References: <20140605131520.GA27711@k2r.org> <78834196.256793.1402046074661.JavaMail.zimbra@tpip.net> Message-ID: Hi! We are currently focusing on gracefulness an running Codenomicon Defensics tests.If we find any problems they will be fixed promptly. In the upcoming release we have for instance added a format functions for state data so that secrets should not be visible in crash-reports. Even if this is not as bad as heart-bleed. See also comments below. 2014-06-06 11:14 GMT+02:00 Andreas Schultz : > Hi, > > ----- Original Message ----- > > I'd be glad if Erlang core team could give an idea about how the > > vulnerability of CVE-2014-0224 would or would not affect Erlang ssl > > module: > > > > http://www.openssl.org/news/secadv_20140605.txt > > > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html > > My take on this: > > Short version > ============= > > I believe that Erlang SSL does not handle out of sequence CCS > (Change-Cipher-Spec) > messages correctly, whether that can be exploited or not is unclear. > > Long version > ============ > > From reading the source, I would say that the SSL application will accept > CCS messages that are out of sequence. > > tls_connection:next_state is processing the packets. Normal handshake > records > are processed through the tls_connection FSM, but a CCS message is > processed > immediately, outside of the FSM in any state. > Yes this is done as data received after the CSS shall be decoded using the new connection state, however we are state aware, and I will add a state check and a flag to check that the next messages is finished (or protocol_next_negotion and finished), we should not take any unnecessary risks with security. > One of the problems OpenSSL has with this, are that invalid pointers might > be > exploited. Luckily this is not going to be an issue for Erlang, ssl might > crash, > but it will not reveal sensitive data. > > That is one of the upsides having the code in Erlang instead of C/C++ :) > The other issue as described by OpenSSL: > > > An attacker using a carefully crafted handshake can force the use of weak > > keying material in OpenSSL SSL/TLS clients and servers. This can be > exploited > > by a Man-in-the-middle (MITM) attack where the attacker can decrypt and > > modify traffic from the attacked client and server. > > Now this might be a problem for Erlang. A CCS will activate the pending > connection > state. ssl_record initializes the pending states with values that are > partly valid. > The bulk_cipher_algo and the secrets are not initialized, so I'm not sure > if it > would be possible to craft the handshake sequence in a way to have valid, > but weak > values in there. > > Does this not require that you can tamper both with the client and the server? Regards Ingela Erlang/OTP Team - Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Sat Jun 7 14:58:28 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 7 Jun 2014 14:58:28 +0200 Subject: [erlang-questions] pkcs-12? In-Reply-To: References: Message-ID: Hi! 2014-06-04 17:02 GMT+02:00 Daniel Goertzen : > I am unable to find any Erlang support for pkcs-12. I am looking to both > encode and decode. Any suggestions? > > Last time I tried to implement it, the Erlang ASN-1 application did not support all needed constructs. I know we have plans to change that but I can not say anything about when that will happen. Regards Ingela Erlang/OTP team - Ericsson AB > Thanks, > Dan. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sat Jun 7 17:01:17 2014 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Sat, 7 Jun 2014 17:01:17 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: Joe, are you answering a mail from 2009 ? 2014-06-07 10:39 GMT+02:00 Joe Armstrong : > What is the end point? > > How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk > through back streets of s?der to get there fj?llgatan etc. > > Best to tweet a reply hash tags #euc and #erlang > > -Joe > > > On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund > wrote: > >> >> Hello! >> >> The evening before the EUC (Wednesday), we invite participants from abroad >> to a city-walk through central Stockholm (showing the castle, the old town >> etc) and a beer/meal together at a pub. If you care to join us, please >> send an e-mail to Henry and me. >> >> When and where? We'll meet up at the central station at 18:00, about 15-20 >> meters from the main entrance (ground level) there is a "large hole" in >> the floor (about 8 meters in diameter), with an iron fence around it. >> >> Best regards, >> >> Niclas Eklund @ Erlang/OTP >> >> ________________________________________________________________ >> erlang-questions mailing list. See http://www.erlang.org/faq.html >> erlang-questions (at) erlang.org >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Jun 7 18:20:32 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 7 Jun 2014 18:20:32 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: It seems like I am - I searched for "euc walk" (which I thought was being arranged) cam up with this, then clicked on reply - but I didn't read the date. My bad. Anybody know if there is a pre-conf booze up? If not I can just tweet a pub address and time Cheers /Joe On Sat, Jun 7, 2014 at 5:01 PM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > Joe, are you answering a mail from 2009 ? > > > 2014-06-07 10:39 GMT+02:00 Joe Armstrong : > >> What is the end point? >> >> How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk >> through back streets of s?der to get there fj?llgatan etc. >> >> Best to tweet a reply hash tags #euc and #erlang >> >> -Joe >> >> >> On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund >> wrote: >> >>> >>> Hello! >>> >>> The evening before the EUC (Wednesday), we invite participants from >>> abroad >>> to a city-walk through central Stockholm (showing the castle, the old >>> town >>> etc) and a beer/meal together at a pub. If you care to join us, please >>> send an e-mail to Henry and me. >>> >>> When and where? We'll meet up at the central station at 18:00, about >>> 15-20 >>> meters from the main entrance (ground level) there is a "large hole" in >>> the floor (about 8 meters in diameter), with an iron fence around it. >>> >>> Best regards, >>> >>> Niclas Eklund @ Erlang/OTP >>> >>> ________________________________________________________________ >>> erlang-questions mailing list. See http://www.erlang.org/faq.html >>> erlang-questions (at) erlang.org >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Sat Jun 7 19:00:39 2014 From: g@REDACTED (Guilherme Andrade) Date: Sat, 07 Jun 2014 18:00:39 +0100 Subject: [erlang-questions] Supervisor tree width? In-Reply-To: References: <0908DD8B-C362-4E7A-B954-0552FF9B6719@gmail.com> Message-ID: <53934537.2010209@gandrade.net> I'd say there shouldn't be any issue; supervisors are capable of handling hundreds of thousand of children. Unless it makes sense to further subgroup those workers and/or there are requirements along such lines (concerning process deaths, restarts and whatnot), I see no reason for not having a single supervisor for them all. Cheers, On 06-06-2014 21:31, Angel Alvarez (GMAIL) wrote: > Sorry I came across this, and I need to ask, > > > I'm planning to have several thousand children (FSM machines) under the same supervisor. > > There is one FSM per client and they don't talk to each other so they are unrelated in this regard .. > > I thought "simple_one_one" is designed to cope with this, is it the right thing to do? or I'm missing something out? > > > Thanks in advance! > > Angel Alvarez (GMAIL) > angeljalvarezmiguel@REDACTED > > > > El 30/05/2014, a las 15:02, Dmitry Kolesnikov escribi?: > >> I?ll be trivial to say that design of supervisor tree is an application specific. >> >> One lesson learned is that supervision it?s about the guarantees. Take a look into Fred?s post >> http://ferd.ca/it-s-about-the-guarantees.html >> >> Personally, I?am splitting an application to smaller functional units with own supervisors per unit. >> If an unit design needs 15 children then I see no issue to have them. >> However, if 15 children do not have any relations each other then I am combining them to guaranty deterministic application state after failure. >> >> Best Regards, >> Dmitry >> >> On 30 May 2014, at 14:28, Roger Lipscombe wrote: >> >>> I'm concerned that the top-level supervisor in one of our applications >>> has too many children. It has about 15 children, which are only >>> vaguely related to each other. >>> >>> What's a good rule-of-thumb for whether a supervisor tree is too wide? >>> Or too deep? Or am I thinking on the wrong level here? >>> >>> Thanks, >>> Roger. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme Andrade PGP fingerprint: 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From g@REDACTED Sat Jun 7 19:35:04 2014 From: g@REDACTED (Garrett Smith) Date: Sat, 7 Jun 2014 19:35:04 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: I looked at the word "Wednesday" for like two minutes. Down at my calendar. Back to the word "Wednesday". To my watch. To the screen. On Sat, Jun 7, 2014 at 6:20 PM, Joe Armstrong wrote: > It seems like I am - I searched for "euc walk" (which I thought was being > arranged) > cam up with this, then clicked on reply - but I didn't read the date. My > bad. > > Anybody know if there is a pre-conf booze up? If not I can just tweet > a pub address and time > > Cheers > > /Joe > > > On Sat, Jun 7, 2014 at 5:01 PM, Bj?rn-Egil Dahlberg > wrote: >> >> Joe, are you answering a mail from 2009 ? >> >> >> 2014-06-07 10:39 GMT+02:00 Joe Armstrong : >>> >>> What is the end point? >>> >>> How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk >>> through back streets of s?der to get there fj?llgatan etc. >>> >>> Best to tweet a reply hash tags #euc and #erlang >>> >>> -Joe >>> >>> >>> On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund >>> wrote: >>>> >>>> >>>> Hello! >>>> >>>> The evening before the EUC (Wednesday), we invite participants from >>>> abroad >>>> to a city-walk through central Stockholm (showing the castle, the old >>>> town >>>> etc) and a beer/meal together at a pub. If you care to join us, please >>>> send an e-mail to Henry and me. >>>> >>>> When and where? We'll meet up at the central station at 18:00, about >>>> 15-20 >>>> meters from the main entrance (ground level) there is a "large hole" in >>>> the floor (about 8 meters in diameter), with an iron fence around it. >>>> >>>> Best regards, >>>> >>>> Niclas Eklund @ Erlang/OTP >>>> >>>> ________________________________________________________________ >>>> erlang-questions mailing list. See http://www.erlang.org/faq.html >>>> erlang-questions (at) erlang.org >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mark.nijhof@REDACTED Sat Jun 7 19:42:25 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 7 Jun 2014 19:42:25 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: Joe is a long way from inbox zero ;-) On Jun 7, 2014 5:01 PM, "Bj?rn-Egil Dahlberg" wrote: > Joe, are you answering a mail from 2009 ? > > > 2014-06-07 10:39 GMT+02:00 Joe Armstrong : > >> What is the end point? >> >> How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk >> through back streets of s?der to get there fj?llgatan etc. >> >> Best to tweet a reply hash tags #euc and #erlang >> >> -Joe >> >> >> On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund >> wrote: >> >>> >>> Hello! >>> >>> The evening before the EUC (Wednesday), we invite participants from >>> abroad >>> to a city-walk through central Stockholm (showing the castle, the old >>> town >>> etc) and a beer/meal together at a pub. If you care to join us, please >>> send an e-mail to Henry and me. >>> >>> When and where? We'll meet up at the central station at 18:00, about >>> 15-20 >>> meters from the main entrance (ground level) there is a "large hole" in >>> the floor (about 8 meters in diameter), with an iron fence around it. >>> >>> Best regards, >>> >>> Niclas Eklund @ Erlang/OTP >>> >>> ________________________________________________________________ >>> erlang-questions mailing list. See http://www.erlang.org/faq.html >>> erlang-questions (at) erlang.org >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeljalvarezmiguel@REDACTED Mon Jun 9 13:05:36 2014 From: angeljalvarezmiguel@REDACTED (Angel Alvarez (GMAIL)) Date: Mon, 9 Jun 2014 13:05:36 +0200 Subject: [erlang-questions] Supervisor tree width? In-Reply-To: References: <0908DD8B-C362-4E7A-B954-0552FF9B6719@gmail.com> Message-ID: Thanks all for your responses. @Ingela, good point, hopefully I will be starting all the children dynamically at different times.. I have a bunch of packet decoders asking the supervisor to spawn a new child if needed (and they remembers the pid to some extend). Also I have a gen_server caching all the children {id, Pid} to avoid having to ask the supervisor the whole children list on every request. I hope this will prevent me from hitting a hot spot on the supervisor for now. Regards, Angel Alvarez angeljalvarezmiguel at gmail.com El 08/06/2014, a las 11:38, Ingela Andin escribi?: > > Hi! > > 2014-06-06 22:31 GMT+02:00 Angel Alvarez (GMAIL) : > Sorry I came across this, and I need to ask, > > > I'm planning to have several thousand children (FSM machines under the same supervisor. > > There is one FSM per client and they don't talk to each other so they are unrelated in this regard .. > > I thought "simple_one_one" is designed to cope with this, is it the right thing to do? or I'm missing something out? > > > > I think you are on the right track. However supervisors can need some further development in some places, and it can be > desirable to start the processes without "init_ack-synchronisation" and then use gen_server/fsm:enter_loop. (The ssl application does this). > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Thanks in advance! > > Angel Alvarez (GMAIL) > angeljalvarezmiguel@REDACTED > > > > El 30/05/2014, a las 15:02, Dmitry Kolesnikov escribi?: > > > I?ll be trivial to say that design of supervisor tree is an application specific. > > > > One lesson learned is that supervision it?s about the guarantees. Take a look into Fred?s post > > http://ferd.ca/it-s-about-the-guarantees.html > > > > Personally, I?am splitting an application to smaller functional units with own supervisors per unit. > > If an unit design needs 15 children then I see no issue to have them. > > However, if 15 children do not have any relations each other then I am combining them to guaranty deterministic application state after failure. > > > > Best Regards, > > Dmitry > > > > On 30 May 2014, at 14:28, Roger Lipscombe wrote: > > > >> I'm concerned that the top-level supervisor in one of our applications > >> has too many children. It has about 15 children, which are only > >> vaguely related to each other. > >> > >> What's a good rule-of-thumb for whether a supervisor tree is too wide? > >> Or too deep? Or am I thinking on the wrong level here? > >> > >> Thanks, > >> Roger. > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bosky101@REDACTED Mon Jun 9 14:44:56 2014 From: bosky101@REDACTED (Bhasker Kode) Date: Mon, 9 Jun 2014 18:14:56 +0530 Subject: [erlang-questions] pkcs-12? In-Reply-To: References: Message-ID: I also recently searched for the same, but will end up calling os:cmd/1 ~B On Sat, Jun 7, 2014 at 6:28 PM, Ingela Andin wrote: > Hi! > > 2014-06-04 17:02 GMT+02:00 Daniel Goertzen : > > I am unable to find any Erlang support for pkcs-12. I am looking to both >> encode and decode. Any suggestions? >> >> > Last time I tried to implement it, the Erlang ASN-1 application did not > support all needed constructs. I know we have plans to change that but I > can not say anything about when that will happen. > > Regards Ingela Erlang/OTP team - Ericsson AB > > >> Thanks, >> Dan. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Mon Jun 9 15:42:33 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 9 Jun 2014 08:42:33 -0500 Subject: [erlang-questions] pkcs-12? In-Reply-To: References: Message-ID: Thanks everyone, I guess it is os:cmd/1 for me too then. And its good to know its on the Erlang team's radar. On Mon, Jun 9, 2014 at 7:44 AM, Bhasker Kode wrote: > I also recently searched for the same, but will end up calling os:cmd/1 > > ~B > > > On Sat, Jun 7, 2014 at 6:28 PM, Ingela Andin > wrote: > >> Hi! >> >> 2014-06-04 17:02 GMT+02:00 Daniel Goertzen : >> >> I am unable to find any Erlang support for pkcs-12. I am looking to both >>> encode and decode. Any suggestions? >>> >>> >> Last time I tried to implement it, the Erlang ASN-1 application did not >> support all needed constructs. I know we have plans to change that but I >> can not say anything about when that will happen. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> Thanks, >>> Dan. >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeljalvarezmiguel@REDACTED Mon Jun 9 16:52:00 2014 From: angeljalvarezmiguel@REDACTED (Angel Alvarez (GMAIL)) Date: Mon, 9 Jun 2014 16:52:00 +0200 Subject: [erlang-questions] City-walk In-Reply-To: References: Message-ID: <524F2BE5-CD8A-4225-B8E4-8508E41C6F36@gmail.com> LOL! When I first came to erlang, everything was like alien technology, It wasn't that the Erlang part was hard to understand but also the ton of computer science, I realized I have been missing out? So I resorted to import all erlang-questions archives almost from 1998 (1998 -> 2009). Kmail was stuck for many hours... Then I started reading.. playing catch up, trying to coming back to the future.. These days I'm usually lagging behind about 50 messages and I miss things out by roughly a month , yet I feel much more relieved when I recall these days.. Regards, Angel Alvarez (GMAIL) angeljalvarezmiguel@REDACTED El 07/06/2014, a las 19:42, Mark Nijhof escribi?: > Joe is a long way from inbox zero ;-) > > On Jun 7, 2014 5:01 PM, "Bj?rn-Egil Dahlberg" wrote: > Joe, are you answering a mail from 2009 ? > > > 2014-06-07 10:39 GMT+02:00 Joe Armstrong : > What is the end point? > > How about Bishops Arms 105 Folkugagatan 7.30 ish - there a nice walk through back streets of s?der to get there fj?llgatan etc. > > Best to tweet a reply hash tags #euc and #erlang > > -Joe > > > On Fri, Nov 6, 2009 at 4:42 PM, Niclas Eklund wrote: > > Hello! > > The evening before the EUC (Wednesday), we invite participants from abroad > to a city-walk through central Stockholm (showing the castle, the old town > etc) and a beer/meal together at a pub. If you care to join us, please > send an e-mail to Henry and me. > > When and where? We'll meet up at the central station at 18:00, about 15-20 > meters from the main entrance (ground level) there is a "large hole" in > the floor (about 8 meters in diameter), with an iron fence around it. > > Best regards, > > Niclas Eklund @ Erlang/OTP > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ishwar@REDACTED Mon Jun 9 16:54:49 2014 From: ishwar@REDACTED (ishwar@REDACTED) Date: Mon, 9 Jun 2014 10:54:49 -0400 (EDT) Subject: [erlang-questions] Off topic Message-ID: How do I unsubscribe to this list? -ishwar From g@REDACTED Mon Jun 9 16:57:36 2014 From: g@REDACTED (Guilherme Andrade) Date: Mon, 09 Jun 2014 15:57:36 +0100 Subject: [erlang-questions] Off topic In-Reply-To: References: Message-ID: <5395CB60.6070000@gandrade.net> http://erlang.org/mailman/listinfo/erlang-questions#subscribers On 09-06-2014 15:54, ishwar@REDACTED wrote: > > How do I unsubscribe to this list? > > -ishwar > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme Andrade PGP fingerprint: 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From sean@REDACTED Mon Jun 9 18:00:01 2014 From: sean@REDACTED (Functional Jobs) Date: Mon, 9 Jun 2014 12:00:01 -0400 Subject: [erlang-questions] New Functional Programming Job Opportunities Message-ID: <5395da063c9e5@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Sr. Software Engineer at Clutch Analytics http://functionaljobs.com/jobs/8720-sr-software-engineer-at-clutch-analytics Cheers, Sean Murphy FunctionalJobs.com From benhsu@REDACTED Tue Jun 10 01:41:44 2014 From: benhsu@REDACTED (Ben Hsu) Date: Mon, 9 Jun 2014 19:41:44 -0400 Subject: [erlang-questions] Manning OTP questions Message-ID: Hello! I am reading the Manning OTP book ( http://www.manning.com/logan/ , https://github.com/erlware/Erlang-and-OTP-in-Action-Source ), and I have three questions: In chapter 3, which is about the RPC server, I'm not sure how OTP hooks up with gen_tcp. I see that tr_server.erl calls gen_tcp:listen, but I don't see how TCP requests are passed to handle_call or handle_cast. I'm also not clear on how TCP requests are transformed into Erlang function arguments. In chapter 6, which is about making a network cache, I'm not sure how the timeout works. I see that sc_element:handle_call gets the Starttime and Leasetime from the State variable, and computes a time left. I'm not sure how the time left variable is used to expire the cache. I thought there will be a line of code where we check if Timeleft < 0, but I can't find any such line. Is this handled inside OTP? Thank you. I am very excited to be learning OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Tue Jun 10 08:24:40 2014 From: alex@REDACTED (Alex Wilson) Date: Tue, 10 Jun 2014 16:24:40 +1000 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel In-Reply-To: References: Message-ID: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> There's no public API in the SSH app for this at the moment. However, if you're willing to use private API, you can do something like this: {ok, Ssh} = ssh:connect(Host, Port, [...]), RemoteHost = "thing-on-other-side.of.tunnel.com", RemotePort = 80, HostBin = list_to_binary(RemoteHost), HostLen = byte_size(HostBin), % the "originating" host, meant to be the thing connecting to the -R/-L forwarder % in this case we just generate a random one OrigHost = <<"localhost">>, OrigHostLen = byte_size(OrigHost), OrigPort = crypto:rand_uniform(10000,65000), Msg = <>, {open, Chan} = ssh_connection_handler:open_channel(Ssh, "direct-tcpip", Msg, ?DEFAULT_WINDOW_SIZE, ?DEFAULT_PACKET_SIZE, ?DEFAULT_TIMEOUT), % then after you've got the channel, use it like any other: _ = ssh_connection:send(Ssh, Chan, <<"some data to send here">>), receive {ssh_cm, Ssh, {data, Chan, _, IncomingBinary}} -> ... {ssh_cm, Ssh, {closed, Chan}} -> ... end etc Note that ssh_connection_handler:open_channel/6 changed names between R15B and R16B, it used to be ssh_connection_manager:open_channel/6 and returned {ok, Chan} on success instead of {open, Chan}. Being private API, it might change again at any time! :) This should probably have a public API though, it's a pretty useful operation. On 7 Jun 2014, at 8:49 am, Tom van Neerijnen wrote: > Hi all > > Does anyone have an example of an Erlang port forwarding SSH server? > My aim is to give it a ssh -R 1234:localhost:5678 and have the erlang server forward connections on 1234 to localhost:5678. > > I've started ssh:daemon as described in the docs and have an Erlang shell on the server end of my ssh connection, so that at least is working, but I can't seem to get ssh_connection:direct_tcpip called. > I guessed that I needed to add a "direct-tcpip" subsystem but this is ignored when I ssh in. > Anyone got any pointers to get me started? > > -- > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From alex@REDACTED Tue Jun 10 08:59:22 2014 From: alex@REDACTED (Alex Wilson) Date: Tue, 10 Jun 2014 16:59:22 +1000 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel In-Reply-To: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> References: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> Message-ID: <16D3F030-D760-47EE-837F-1A66642730D7@cooperi.net> The code is making a liar out of me. :) There is better private API for this now that is marked as "Potential API currently unsupported and not tested" (aka, might become public at some point), in the form of ssh_connection:direct_tcpip/6. There is also ssh_connection:tcpip_forward/3 which you might find interesting as well. Looks like these have been available since R13B in some form, I missed them completely. So rather than encoding the binary yourself and calling ssh_connection_handler:open_channel/6, it would be better to do {open, Chan} = ssh_connection:direct_tcpip(Ssh, "thing-on-other-side.of.tunnel.com", 80, "localhost", crypto:rand_uniform(10000,65000), 1000), My apologies for misleading anyone. On 10 Jun 2014, at 4:24 pm, Alex Wilson wrote: > There's no public API in the SSH app for this at the moment. > > However, if you're willing to use private API, you can do something like this: > > {ok, Ssh} = ssh:connect(Host, Port, [...]), > > RemoteHost = "thing-on-other-side.of.tunnel.com", > RemotePort = 80, > HostBin = list_to_binary(RemoteHost), HostLen = byte_size(HostBin), > > % the "originating" host, meant to be the thing connecting to the -R/-L forwarder > % in this case we just generate a random one > OrigHost = <<"localhost">>, OrigHostLen = byte_size(OrigHost), > OrigPort = crypto:rand_uniform(10000,65000), > > Msg = < OrigHost/binary, OrigPort:32/big>>, > > {open, Chan} = ssh_connection_handler:open_channel(Ssh, "direct-tcpip", > Msg, ?DEFAULT_WINDOW_SIZE, ?DEFAULT_PACKET_SIZE, > ?DEFAULT_TIMEOUT), > > % then after you've got the channel, use it like any other: > _ = ssh_connection:send(Ssh, Chan, <<"some data to send here">>), > receive > {ssh_cm, Ssh, {data, Chan, _, IncomingBinary}} -> ... > {ssh_cm, Ssh, {closed, Chan}} -> ... > end > > etc > > Note that ssh_connection_handler:open_channel/6 changed names between R15B and R16B, it used to be ssh_connection_manager:open_channel/6 and returned {ok, Chan} on success instead of {open, Chan}. Being private API, it might change again at any time! :) > > This should probably have a public API though, it's a pretty useful operation. > > > > On 7 Jun 2014, at 8:49 am, Tom van Neerijnen wrote: > >> Hi all >> >> Does anyone have an example of an Erlang port forwarding SSH server? >> My aim is to give it a ssh -R 1234:localhost:5678 and have the erlang server forward connections on 1234 to localhost:5678. >> >> I've started ssh:daemon as described in the docs and have an Erlang shell on the server end of my ssh connection, so that at least is working, but I can't seem to get ssh_connection:direct_tcpip called. >> I guessed that I needed to add a "direct-tcpip" subsystem but this is ignored when I ssh in. >> Anyone got any pointers to get me started? >> >> -- >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tom@REDACTED Tue Jun 10 09:51:18 2014 From: tom@REDACTED (Tom van Neerijnen) Date: Tue, 10 Jun 2014 08:51:18 +0100 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel In-Reply-To: <16D3F030-D760-47EE-837F-1A66642730D7@cooperi.net> References: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> <16D3F030-D760-47EE-837F-1A66642730D7@cooperi.net> Message-ID: Thanks anyway but I think your solution is the wrong way around. I'm specifically writing a SSH server, not a SSH client, and my admittedly naive understanding of your example (I've been erlanging for all of a few weeks) and ssh_connection:direct_tcpip is that this would work if I were writing a client but not for a server. I may be misunderstanding tho so bear with me while I explain and if I am indeed wrong please let me know where I would hook ssh_connection:direct_tcpip up to a running ssh:daemon. I've tracked down the reason it's not working for me to ssh_connection:handle_msg(#ssh_msg_global_request{name = Type, want_reply = WantReply, data = Data}, Connection, _). A request for tcpip-forward obviously has want_reply set to true but the function in this case always returns a ssh_msg_request_failure. I'm going to have a crack at having it look up from available subsystems (or what ever port forwarding is, I'll give the RFC a better read to understand it) in a similar way to Python's Twisted Conch. If I'm missing something obvious please let me know, otherwise if I get it working I'll submit a pull request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Tue Jun 10 10:06:25 2014 From: tom@REDACTED (Tom van Neerijnen) Date: Tue, 10 Jun 2014 09:06:25 +0100 Subject: [erlang-questions] Manning OTP questions In-Reply-To: References: Message-ID: First Chapter 3: TCP requests aren't passed to handle_call or handle_cast by gen_tcp, they're passed by the tr_server:do_rcp function. When gen_tcp:listen is called it's passed {active, true} as an option. This tells gen_tcp to send events as messages to the process that started it, in this case the tr_server process. Any messages sent to a gen_server not using gen_cast or gen_call arrive in the handle_info functions which is why you see the handle_info({tcp, Socket, RawData}, State) function. It is that function that calls do_rpc which in turn calls gen_cast and gets your data to your handle_cast functions. I suggest reading http://erlang.org/doc/man/gen_tcp.html, it explains this quite well. Chapter 6: the returns from your callback functions (the ones that look like {noreply, State, Timeout}) return the timeout. Once the gen_server process reaches that timeout the timeout callback is fired which stops the process. Process holding data for that key stops =:= key expired, no explicit expiry is necessary which is why you don't see code for it. Again, give http://www.erlang.org/doc/man/gen_server.html a good read, it's all explained in there. On Tue, Jun 10, 2014 at 12:41 AM, Ben Hsu wrote: > Hello! > > I am reading the Manning OTP book ( http://www.manning.com/logan/ , > https://github.com/erlware/Erlang-and-OTP-in-Action-Source ), and I have > three questions: > > In chapter 3, which is about the RPC server, I'm not sure how OTP hooks up > with gen_tcp. I see that tr_server.erl calls gen_tcp:listen, but I don't > see how TCP requests are passed to handle_call or handle_cast. I'm also not > clear on how TCP requests are transformed into Erlang function arguments. > > In chapter 6, which is about making a network cache, I'm not sure how the > timeout works. I see that sc_element:handle_call gets the Starttime and > Leasetime from the State variable, and computes a time left. I'm not sure > how the time left variable is used to expire the cache. I thought there > will be a line of code where we check if Timeleft < 0, but I can't find any > such line. Is this handled inside OTP? > > Thank you. I am very excited to be learning OTP > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Thomas van Neerijnen http://tomvn.com +4477 1709 7670 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Tue Jun 10 11:54:01 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 10 Jun 2014 09:54:01 +0000 (UTC) Subject: [erlang-questions] file:file_info/1 broken on R17 In-Reply-To: <1651476655.6093.1402393923906.JavaMail.zimbra@tpip.net> Message-ID: <52529427.6099.1402394041373.JavaMail.zimbra@tpip.net> Hi, file:file_info/1 is marked obsolete, but it is still there and should probably not be broken, right? It get this when using it on a non-existing file: root@REDACTED:/usr/src/erlang/xray_node# erl Erlang/OTP 17 [erts-6.0.1] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false] Eshell V6.0.1 (abort with ^G) 1> file:file_info("test"). ** exception error: undefined function erlang:nif_error/1 in function file:file_info/1 (file.erl, line 128) file:read_file_info works as expected... Andreas -- -- Dipl. Inform. Andreas Schultz From essen@REDACTED Tue Jun 10 12:38:10 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 10 Jun 2014 12:38:10 +0200 Subject: [erlang-questions] [ANN] Cowboy and Ranch 0.10 Message-ID: <5396E012.4070900@ninenines.eu> Hello! I just pushed Cowboy 0.10 and Ranch 0.10. https://github.com/extend/cowboy https://github.com/extend/ranch The Cowboy changelog can be found here: https://github.com/extend/cowboy/blob/master/CHANGELOG.md This release sees the addition of functions for reading multipart! (And there are also functions for creating multipart bodies in the cowlib library if you need them.) The old multipart interface got removed. The other big change is a rework of the body reading interface, again. Users have reported having timeout issues sometimes so the new interface allows you to configure read length/timeout so you can control the rate of transfer *per body function call*. The functions init_stream, stream_body and skip_body have been deprecated and will be removed in 1.0 (alongside one clause of the body/2 and body_qs/2 functions). Current code *should* be compatible but you are really encouraged to test and remove dead code introduced by this change. The changes in Ranch are mostly small so I won't bore you with the details. The next step will be to release 1.0 sometimes this summer. Work on 2.0 will start immediately after that but 2.0 is planned to be released after Erlang 18.0 is out. We'll have a new version bump for every Erlang version basically. More details later. Hope you enjoy this release, and that I didn't break your code (too much)! Enjoy. -- Lo?c Hoguin http://ninenines.eu From alex@REDACTED Tue Jun 10 16:22:42 2014 From: alex@REDACTED (Alex Wilson) Date: Wed, 11 Jun 2014 00:22:42 +1000 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel In-Reply-To: References: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> <16D3F030-D760-47EE-837F-1A66642730D7@cooperi.net> Message-ID: <1F1B6CE7-34CB-4AA7-A40A-DED4F375B32A@cooperi.net> Ah, sorry, you are correct. direct-tcpip is the wrong way around for what you want, it's used for the equivalent of ssh -L, client-listens-server-connects forwarding. The tcpip-forward + forwarded-tcpip channel setup is used for -R, server-listens-client-connects. The client sends tcpip-forward to ask the server to listen on a port, then the server accepts a TCP connection on that port, and then sends a request over SSH to open a forwarded-tcpip channel back to the client, which the client should then accept. Then all the data from the TCP connection is forwarded to that channel and vice versa (see http://www.ietf.org/rfc/rfc4254.txt) While there is some code that appears to handle these messages in the SSH daemon at the moment, it doesn't look like it's really functional for this kind of remote forwarding tunnel. The daemon looks like it will accept any tcpip-forward request, but it never opens a port or anything and there is no way to generate the forwarded-tcpip channel open requests going back to the client at the moment. I also can see no implementation of server-side handling of direct-tcpip -- I don't want to jump to conclusions, but it looks like maybe this was written in just to prevent crashes with these messages and nothing more -- you should probably take it as a blank slate, not as something to just be fixed up a little to get it going. Also, I'm pretty sure a subsystem callback module won't work for this, as it's not a subsystem request and it doesn't open a channel -- tcpip-forward is just a global request on its own, then later a channel can be created by the daemon sending open with forwarded-tcpip. So no subsystem will get started (never calls ssh_connection:start_subsytem). I think you'll have to modify the code in ssh_connection and ssh_connection_handler to correctly deal with these messages and provide some sort of interface to set policy / implement the port listening in order to use them. Implementing direct-tcpip would probably be simpler (as there's no real state to deal with), but of course it won't get you what you want if you need the -R functionality. On 10 Jun 2014, at 5:51 pm, Tom van Neerijnen wrote: > Thanks anyway but I think your solution is the wrong way around. > I'm specifically writing a SSH server, not a SSH client, and my admittedly naive understanding of your example (I've been erlanging for all of a few weeks) and ssh_connection:direct_tcpip is that this would work if I were writing a client but not for a server. > I may be misunderstanding tho so bear with me while I explain and if I am indeed wrong please let me know where I would hook ssh_connection:direct_tcpip up to a running ssh:daemon. > > I've tracked down the reason it's not working for me to ssh_connection:handle_msg(#ssh_msg_global_request{name = Type, want_reply = WantReply, data = Data}, Connection, _). > A request for tcpip-forward obviously has want_reply set to true but the function in this case always returns a ssh_msg_request_failure. > I'm going to have a crack at having it look up from available subsystems (or what ever port forwarding is, I'll give the RFC a better read to understand it) in a similar way to Python's Twisted Conch. > > If I'm missing something obvious please let me know, otherwise if I get it working I'll submit a pull request. From essen@REDACTED Tue Jun 10 17:45:06 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 10 Jun 2014 17:45:06 +0200 Subject: [erlang-questions] file:file_info/1 broken on R17 In-Reply-To: <52529427.6099.1402394041373.JavaMail.zimbra@tpip.net> References: <52529427.6099.1402394041373.JavaMail.zimbra@tpip.net> Message-ID: <53972802.6010407@ninenines.eu> On 06/10/2014 11:54 AM, Andreas Schultz wrote: > Hi, > > file:file_info/1 is marked obsolete, but it is still there and > should probably not be broken, right? > > It get this when using it on a non-existing file: > > root@REDACTED:/usr/src/erlang/xray_node# erl > Erlang/OTP 17 [erts-6.0.1] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false] > > Eshell V6.0.1 (abort with ^G) > 1> file:file_info("test"). > ** exception error: undefined function erlang:nif_error/1 > in function file:file_info/1 (file.erl, line 128) > > file:read_file_info works as expected... I reported that on erlang-bugs at the end of October 2013. Must not be very high priority. :-) -- Lo?c Hoguin http://ninenines.eu From serge@REDACTED Tue Jun 10 21:35:21 2014 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 10 Jun 2014 15:35:21 -0400 Subject: [erlang-questions] code_server and ERL_LIBS: bug or feature? Message-ID: When trying to start a node with the "-mode embedded" command-line option I noticed that ERL_LIBS environment variable setting gets ignored. Has this always been this way or it is a recent change? Is this the desired behavior? The culprit is in the code_server:add_loader_path/2 function. Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From z@REDACTED Tue Jun 10 22:40:22 2014 From: z@REDACTED (Danil Zagoskin) Date: Wed, 11 Jun 2014 00:40:22 +0400 Subject: [erlang-questions] Is lhttpc project alive? Message-ID: Hi! The project https://github.com/esl/lhttpc seems to be abandoned (many open issues including 17.0 compatibility, almost no activity since January 2013). There are some forks: some do simple fixes and some (rymir, jbothma) do heavy refactoring. Is any of forks the new default? Is https://github.com/ferd/dlhttpc production-ready drop-in replacement? I've found a bug in original lhttpc causing manager (and thus all new requests) to block but I don't know where to report it. -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Jun 11 01:20:02 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 10 Jun 2014 19:20:02 -0400 Subject: [erlang-questions] Is lhttpc project alive? In-Reply-To: References: Message-ID: <20140610232001.GC864@ferdmbp.local> Hi, I'm in charge of dlhttpc, and also wrote a fork of lhttpc. These are stable projects that only cared about getting basic GET/POST requests working, with specific pools when what you need is really intensive low-latency requests to a limited set of hosts. My variations of lhttpc/dlhttpc have been in use in large-ish high performance clusters where multiple thousands of requests would be sent per second to a known set of endpoints, and that's what they'll be best used for. Their pooling mechanisms might not be adequate for more general use, but would be able to act as a replacement with a limited amount of changes if you're doing what it was built for. Regards, Fred. On 06/11, Danil Zagoskin wrote: > Hi! > > The project https://github.com/esl/lhttpc seems to be abandoned (many open > issues including 17.0 compatibility, almost no activity since January 2013). > > There are some forks: some do simple fixes and some (rymir, jbothma) do > heavy refactoring. > > Is any of forks the new default? > > Is https://github.com/ferd/dlhttpc production-ready drop-in replacement? > > > I've found a bug in original lhttpc causing manager (and thus all new > requests) to block but I don't know where to report it. > > > -- > Danil Zagoskin | z@REDACTED > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From roger@REDACTED Wed Jun 11 09:17:33 2014 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 11 Jun 2014 08:17:33 +0100 Subject: [erlang-questions] Atomically replace named process? Message-ID: I've got a gen_server with a particular name. I've got a bunch of other processes calling and casting to it, by name. Can I spin up another gen_server, and have the name transferred without anyone noticing? That is: can I redirect the calls and casts to the new process without interruption? -- Roger. From sedrik@REDACTED Wed Jun 11 09:25:15 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Wed, 11 Jun 2014 09:25:15 +0200 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: Message-ID: Doing a code uppgrade would be my approach if you really need it to be uninterrupted. You could unregister and register the new one but that will lead to race conditions and would not be a recommended approach. On Wed, Jun 11, 2014 at 9:17 AM, Roger Lipscombe wrote: > I've got a gen_server with a particular name. I've got a bunch of > other processes calling and casting to it, by name. > > Can I spin up another gen_server, and have the name transferred > without anyone noticing? That is: can I redirect the calls and casts > to the new process without interruption? > > -- > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Jun 11 09:49:40 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 11 Jun 2014 10:49:40 +0300 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: Message-ID: <1C8D6F0B-3952-4FD0-9B1B-721B75E416D1@gmail.com> Hello, yes, but ... Only one process can be registered to name. You can kill old process and start new process with same name. The transition period would not be transparent for client. They would exit with no_proc. However, properly defined supervision strategy would recover errors during transition period. On another hand, hot code / application upgrades might help you to deploy a new version of gen_server in transparent mode. - Dmitry On 11 Jun 2014, at 10:17, Roger Lipscombe wrote: > I've got a gen_server with a particular name. I've got a bunch of > other processes calling and casting to it, by name. > > Can I spin up another gen_server, and have the name transferred > without anyone noticing? That is: can I redirect the calls and casts > to the new process without interruption? > > -- > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From Tobias.Schlager@REDACTED Wed Jun 11 10:23:51 2014 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Wed, 11 Jun 2014 08:23:51 +0000 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: Message-ID: <12F2115FD1CCEE4294943B2608A18FA3011E70A62D@MAIL01.win.lbaum.eu> Hi, I know this not exactly what you're asking for, but you could use a (registered) process group as a middleman and add you gen_server's into that as needed. Regards Tobias ________________________________________ Von: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED]" im Auftrag von "Roger Lipscombe [roger@REDACTED] Gesendet: Mittwoch, 11. Juni 2014 09:17 An: erlang-questions@REDACTED Betreff: [erlang-questions] Atomically replace named process? I've got a gen_server with a particular name. I've got a bunch of other processes calling and casting to it, by name. Can I spin up another gen_server, and have the name transferred without anyone noticing? That is: can I redirect the calls and casts to the new process without interruption? -- Roger. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Wed Jun 11 10:36:15 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 11 Jun 2014 01:36:15 -0700 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: Message-ID: <539814FF.8090204@gmail.com> If you need redundant process names, you should probably look at pg2 (http://www.erlang.org/doc/man/pg2.html) or cpg (https://github.com/okeuday/cpg/). On 06/11/2014 12:17 AM, Roger Lipscombe wrote: > I've got a gen_server with a particular name. I've got a bunch of > other processes calling and casting to it, by name. > > Can I spin up another gen_server, and have the name transferred > without anyone noticing? That is: can I redirect the calls and casts > to the new process without interruption? > From z@REDACTED Wed Jun 11 13:23:55 2014 From: z@REDACTED (Danil Zagoskin) Date: Wed, 11 Jun 2014 15:23:55 +0400 Subject: [erlang-questions] Is lhttpc project alive? In-Reply-To: <20140610232001.GC864@ferdmbp.local> References: <20140610232001.GC864@ferdmbp.local> Message-ID: Hi Fred! Thank you for dlhttpc and dispcount! Unfortunately, table-per-endpoint does not fit our needs, but the code seems to run well with small number of endpoints, as you said. On Wed, Jun 11, 2014 at 3:20 AM, Fred Hebert wrote: > Hi, I'm in charge of dlhttpc, and also wrote a fork of lhttpc. These are > stable projects that only cared about getting basic GET/POST requests > working, with specific pools when what you need is really intensive > low-latency requests to a limited set of hosts. > > My variations of lhttpc/dlhttpc have been in use in large-ish high > performance clusters where multiple thousands of requests would be sent > per second to a known set of endpoints, and that's what they'll be best > used for. > > Their pooling mechanisms might not be adequate for more general use, but > would be able to act as a replacement with a limited amount of changes > if you're doing what it was built for. > > Regards, > Fred. > > On 06/11, Danil Zagoskin wrote: > > Hi! > > > > The project https://github.com/esl/lhttpc seems to be abandoned (many > open > > issues including 17.0 compatibility, almost no activity since January > 2013). > > > > There are some forks: some do simple fixes and some (rymir, jbothma) do > > heavy refactoring. > > > > Is any of forks the new default? > > > > Is https://github.com/ferd/dlhttpc production-ready drop-in replacement? > > > > > > I've found a bug in original lhttpc causing manager (and thus all new > > requests) to block but I don't know where to report it. > > > > > > -- > > Danil Zagoskin | z@REDACTED > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From co7eb@REDACTED Wed Jun 11 17:42:26 2014 From: co7eb@REDACTED (=?iso-8859-1?Q?Ivan_Carmenates_Garc=EDa?=) Date: Wed, 11 Jun 2014 11:42:26 -0400 Subject: [erlang-questions] Which technology I should choose? Message-ID: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Hi all, I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. I hope someone can help me to decide. I will appreciate all kind of suggestions. Best regards, Ivan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roe.adrian@REDACTED Wed Jun 11 17:54:59 2014 From: roe.adrian@REDACTED (Adrian Roe) Date: Wed, 11 Jun 2014 16:54:59 +0100 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: We've used both mochiweb / webmachine and cowboy extensively in production (cowboy probably being my preferred solution in general, webmachine having strong REST credentials) so I would definitely explore both of those for your use case. Both are well documented with active communities. I have no experience of yaws so can't really comment on pros and cons in comparison. Adrian Dr Adrian Roe Director Sent from my iPhone > On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a wrote: > > Hi all, > > I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. > > My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. > > What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. > > I hope someone can help me to decide. > I will appreciate all kind of suggestions. > > Best regards, > Ivan. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.sylvester@REDACTED Wed Jun 11 17:58:48 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Wed, 11 Jun 2014 16:58:48 +0100 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: <51B2BD08-F215-47C9-9CF4-2B3401C6C6EA@gmail.com> I find Cowboy provides a lot of flexibility, but WebMachine provides a ?quick to market? solution. WebMachine also helps you build cleaner code. Mochiweb is useful, but since WebMachine is built on it, I?d say it?s WebMachine hands down. Lee On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a wrote: > Hi all, > > I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. > > My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. > > What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. > > I hope someone can help me to decide. > I will appreciate all kind of suggestions. > > Best regards, > Ivan. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Jun 11 18:21:00 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 11 Jun 2014 18:21:00 +0200 Subject: [erlang-questions] Which technology I should choose? Message-ID: Cowboy has had Webmachine based REST for more than 2 years now. Am I missing something obvious that Webmachine has or are people simply not aware of the implementation in Cowboy? If there is something that can be improved I'd like to hear about it. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Lee Sylvester Sent:Wed, 11 Jun 2014 17:58:48 +0200 To:Ivan Carmenates Garc?a Cc:erlang-questions@REDACTED Subject:Re: [erlang-questions] Which technology I should choose? >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Jun 11 19:22:16 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 11 Jun 2014 13:22:16 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: Since I help maintain Yaws, if there are issues preventing you from using it, I'd like to hear about them. I wrote an article years ago about REST with Yaws that you might find useful: http://www.infoq.com/articles/vinoski-erlang-rest Yaws has supported WebSocket for a long time now as well. I also have a fork of Webmachine that runs on Yaws if you're interested in that. --steve On Wed, Jun 11, 2014 at 11:42 AM, Ivan Carmenates Garc?a wrote: > Hi all, > > > > I?ve been wondering if I could ask for an advice from the community to > help me choose a good tec for a project I am developing. > > > > My primordial priority is not to be productive, I like pure Erlang as it > is, no dummy frameworks for productivity, I?m looking for something clean > and powerful at the same time, I already choose Extjs 4.2 for the view, > because the project is about accounting and statistics, and the graphics > and visual that extjs gives is a very nice and interesting fact. I have a > weak choice for yaws for the server at the time. > > > > What I would like to know is if there is another web server better than > yaws to combine it with extjs, the idea is to export an API REST or another > kind of API that allows a good communication with extjs using json, also > that supports for web-socket or any real-time server push technology, that > is primordial since I need a real-time app, ex: Chicago Boss have a very > interesting mechanism to do that, since it use a long-polling strategy, > that is very interesting, the only problem and almost impossible to deal > with CB is the errors formatting and definition. A good documentation is > required too. > > > > I hope someone can help me to decide. > > I will appreciate all kind of suggestions. > > > > Best regards, > > Ivan. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hi@REDACTED Wed Jun 11 18:00:49 2014 From: hi@REDACTED (Vladimir Galunshchikov) Date: Wed, 11 Jun 2014 20:00:49 +0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: <53987D31.1020209@portfelio.org> Hi, Ivan. Try N2O https://github.com/5HT/n2o Example app: https://github.com/kakaranet/games/ From sergej.jurecko@REDACTED Wed Jun 11 20:19:07 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Wed, 11 Jun 2014 20:19:07 +0200 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: Message-ID: <1944EFDA-7AE0-48C4-A927-D098E0CB2A1D@gmail.com> If you are registering the process manually this method will work. The problem you might run into is the old process dying just before someone is calling it. You would have to cycle off the process by calling unregister manually and wait for some time to handle calls that are still using the old PID. If your gen_server init looks like this: init() -> case catch register(name) of ok -> {ok,#state{}}; _ -> {stop,normal} end. Then call, getpid functions: call(Msg) -> gen_server:call(getpid(),Msg). % The returned PID may get unregistered before it is used. % This is why the gen_server must unregister and wait for a timeout before dying. getpid() -> case whereis(name) of undefined -> case gen_server:start(?.) of {error,normal} -> % some other process won the race to register itself. whereis(name); {ok,Pid} -> % this start call won the race Pid end; Pid -> Pid end. On 11 Jun 2014, at 09:17, Roger Lipscombe wrote: > I've got a gen_server with a particular name. I've got a bunch of > other processes calling and casting to it, by name. > > Can I spin up another gen_server, and have the name transferred > without anyone noticing? That is: can I redirect the calls and casts > to the new process without interruption? > > -- > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paulo.ferraz.oliveira@REDACTED Wed Jun 11 20:20:15 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Wed, 11 Jun 2014 19:20:15 +0100 Subject: [erlang-questions] Is lhttpc project alive? In-Reply-To: References: Message-ID: Hi, Danil. Do you have more information on "I've found a bug in original lhttpc causing manager (and thus all new requests) to block but I don't know where to report it." that you can share? I've been using lhttpc lately and may profit from a resolution to your problem, seeing that I too seem get to a situation where new requests are "blocked" but haven't had time to run after that "bug". Thanks. Cheers. - Paulo F. Oliveira On 10 June 2014 21:40, Danil Zagoskin wrote: > Hi! > > The project https://github.com/esl/lhttpc seems to be abandoned (many > open issues including 17.0 compatibility, almost no activity since January > 2013). > > There are some forks: some do simple fixes and some (rymir, jbothma) do > heavy refactoring. > > Is any of forks the new default? > > Is https://github.com/ferd/dlhttpc production-ready drop-in replacement? > > > I've found a bug in original lhttpc causing manager (and thus all new > requests) to block but I don't know where to report it. > > > -- > Danil Zagoskin | z@REDACTED > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Wed Jun 11 20:59:55 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 11 Jun 2014 13:59:55 -0500 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: Cowboy supports REST, Websockets and can you can trivially implement Server Sent Events (see http://dev.af83.com/2012/01/06/erlang-server-sent-events-made-for-each-other.html ) On Wed, Jun 11, 2014 at 10:42 AM, Ivan Carmenates Garc?a wrote: > Hi all, > > > > I?ve been wondering if I could ask for an advice from the community to > help me choose a good tec for a project I am developing. > > > > My primordial priority is not to be productive, I like pure Erlang as it > is, no dummy frameworks for productivity, I?m looking for something clean > and powerful at the same time, I already choose Extjs 4.2 for the view, > because the project is about accounting and statistics, and the graphics > and visual that extjs gives is a very nice and interesting fact. I have a > weak choice for yaws for the server at the time. > > > > What I would like to know is if there is another web server better than > yaws to combine it with extjs, the idea is to export an API REST or another > kind of API that allows a good communication with extjs using json, also > that supports for web-socket or any real-time server push technology, that > is primordial since I need a real-time app, ex: Chicago Boss have a very > interesting mechanism to do that, since it use a long-polling strategy, > that is very interesting, the only problem and almost impossible to deal > with CB is the errors formatting and definition. A good documentation is > required too. > > > > I hope someone can help me to decide. > > I will appreciate all kind of suggestions. > > > > Best regards, > > Ivan. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Wed Jun 11 22:22:59 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 11 Jun 2014 23:22:59 +0300 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: I use yaws for REST services without any problems in production for 1 year. It just works. Service implementations are very clean and compact on it. Karolis On Wed, Jun 11, 2014 at 8:22 PM, Steve Vinoski wrote: > Since I help maintain Yaws, if there are issues preventing you from using > it, I'd like to hear about them. I wrote an article years ago about REST > with Yaws that you might find useful: > > http://www.infoq.com/articles/vinoski-erlang-rest > > Yaws has supported WebSocket for a long time now as well. > > I also have a fork of Webmachine that runs on Yaws if you're interested in > that. > > --steve > > > > On Wed, Jun 11, 2014 at 11:42 AM, Ivan Carmenates Garc?a > wrote: >> >> Hi all, >> >> >> >> I?ve been wondering if I could ask for an advice from the community to >> help me choose a good tec for a project I am developing. >> >> >> >> My primordial priority is not to be productive, I like pure Erlang as it >> is, no dummy frameworks for productivity, I?m looking for something clean >> and powerful at the same time, I already choose Extjs 4.2 for the view, >> because the project is about accounting and statistics, and the graphics and >> visual that extjs gives is a very nice and interesting fact. I have a weak >> choice for yaws for the server at the time. >> >> >> >> What I would like to know is if there is another web server better than >> yaws to combine it with extjs, the idea is to export an API REST or another >> kind of API that allows a good communication with extjs using json, also >> that supports for web-socket or any real-time server push technology, that >> is primordial since I need a real-time app, ex: Chicago Boss have a very >> interesting mechanism to do that, since it use a long-polling strategy, that >> is very interesting, the only problem and almost impossible to deal with CB >> is the errors formatting and definition. A good documentation is required >> too. >> >> >> >> I hope someone can help me to decide. >> >> I will appreciate all kind of suggestions. >> >> >> >> Best regards, >> >> Ivan. >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From co7eb@REDACTED Thu Jun 12 00:30:19 2014 From: co7eb@REDACTED (=?utf-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Wed, 11 Jun 2014 18:30:19 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: References: Message-ID: <000001cf85c4$bbe3dab0$33ab9010$@frcuba.co.cu> Regards all, So Cowboy also support Webmachine? Or only its REST based capabilities, and the WebSockets and server send event behavior could be interesting. The problem here is that I need many capabilities, REST, WebSocket, Server Push, a clean code, and easily integration with extjs. I already explored CB, and it is really a shame that it handles errors so bad, has many other non-liked things, like static models and the concept of model at all, an ORM is always a dirty and easy solution, but have many other nice things. I will see above all tec you tell me about and try to choose the best that fits with my use case, Thanks to all. Best regards, Ivan. De: Lo?c Hoguin [mailto:essen@REDACTED] Enviado el: mi?rcoles, 11 de junio de 2014 12:21 p.m. Para: Lee Sylvester CC: Ivan Carmenates Garc?a; erlang-questions@REDACTED Asunto: Re: [erlang-questions] Which technology I should choose? Cowboy has had Webmachine based REST for more than 2 years now. Am I missing something obvious that Webmachine has or are people simply not aware of the implementation in Cowboy? If there is something that can be improved I'd like to hear about it. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Lee Sylvester Sent:Wed, 11 Jun 2014 17:58:48 +0200 To:Ivan Carmenates Garc?a Cc:erlang-questions@REDACTED Subject:Re: [erlang-questions] Which technology I should choose? I find Cowboy provides a lot of flexibility, but WebMachine provides a ?quick to market? solution. WebMachine also helps you build cleaner code. Mochiweb is useful, but since WebMachine is built on it, I?d say it?s WebMachine hands down. Lee On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a wrote: Hi all, I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. I hope someone can help me to decide. I will appreciate all kind of suggestions. Best regards, Ivan. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jun 12 00:43:54 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 12 Jun 2014 00:43:54 +0200 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf85c4$bbe3dab0$33ab9010$@frcuba.co.cu> References: <000001cf85c4$bbe3dab0$33ab9010$@frcuba.co.cu> Message-ID: On Thu, Jun 12, 2014 at 12:30 AM, Ivan Carmenates Garc?a wrote: > So Cowboy also support Webmachine The cowboy_rest module is roughly a reimplementation of webmachine. Running the HTTP protocol as an FSM is a nice way to handle code. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim@REDACTED Thu Jun 12 00:57:57 2014 From: maxim@REDACTED (Maxim Sokhatsky) Date: Thu, 12 Jun 2014 01:57:57 +0300 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu> Message-ID: I would recommend you to search "erlang binary websockets".Just try it. 5HT From: co7eb@REDACTED To: erlang-questions@REDACTED Date: Wed, 11 Jun 2014 11:42:26 -0400 Subject: [erlang-questions] Which technology I should choose? Hi all, I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. I hope someone can help me to decide.I will appreciate all kind of suggestions. Best regards,Ivan. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim@REDACTED Thu Jun 12 01:08:17 2014 From: maxim@REDACTED (Maxim Sokhatsky) Date: Thu, 12 Jun 2014 02:08:17 +0300 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: References: <000001cf858b$c03b64e0$40b22ea0$@frcuba.co.cu>, , Message-ID: Cleaner than That: http://synrc.com/apps/n2o/doc/web/architecture.htm#htoc11 ? :-) 5HT > I use yaws for REST services without any problems in production for 1 > year. It just works. Service implementations are very clean and > compact on it. >? > Karolis From lee.sylvester@REDACTED Thu Jun 12 01:23:23 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Thu, 12 Jun 2014 00:23:23 +0100 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: References: Message-ID: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> Hey Lo?c, I meant nothing by it. I had to build a Socket.IO compatible server recently, and Cowboy was my first choice. I simply find WebMachine gets the job done when that job is a super simple task and I need full REST without thinking too hard about it. Lee On 11 Jun 2014, at 17:21, Lo?c Hoguin wrote: > Cowboy has had Webmachine based REST for more than 2 years now. Am I missing something obvious that Webmachine has or are people simply not aware of the implementation in Cowboy? If there is something that can be improved I'd like to hear about it. > > -- > Lo?c Hoguin > http://ninenines.eu > > -------- Original Message -------- > From:Lee Sylvester > Sent:Wed, 11 Jun 2014 17:58:48 +0200 > To:Ivan Carmenates Garc?a > Cc:erlang-questions@REDACTED > Subject:Re: [erlang-questions] Which technology I should choose? > > I find Cowboy provides a lot of flexibility, but WebMachine provides a ?quick to market? solution. WebMachine also helps you build cleaner code. Mochiweb is useful, but since WebMachine is built on it, I?d say it?s WebMachine hands down. > > Lee > > > On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a wrote: > >> Hi all, >> >> I?ve been wondering if I could ask for an advice from the community to help me choose a good tec for a project I am developing. >> >> My primordial priority is not to be productive, I like pure Erlang as it is, no dummy frameworks for productivity, I?m looking for something clean and powerful at the same time, I already choose Extjs 4.2 for the view, because the project is about accounting and statistics, and the graphics and visual that extjs gives is a very nice and interesting fact. I have a weak choice for yaws for the server at the time. >> >> What I would like to know is if there is another web server better than yaws to combine it with extjs, the idea is to export an API REST or another kind of API that allows a good communication with extjs using json, also that supports for web-socket or any real-time server push technology, that is primordial since I need a real-time app, ex: Chicago Boss have a very interesting mechanism to do that, since it use a long-polling strategy, that is very interesting, the only problem and almost impossible to deal with CB is the errors formatting and definition. A good documentation is required too. >> >> I hope someone can help me to decide. >> I will appreciate all kind of suggestions. >> >> Best regards, >> Ivan. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim@REDACTED Thu Jun 12 01:27:58 2014 From: maxim@REDACTED (Maxim Sokhatsky) Date: Thu, 12 Jun 2014 02:27:58 +0300 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> References: , <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> Message-ID: You should know about this if you want to go really simple?http://synrc.github.io/rest/ :-) 5HT > I meant nothing by it. I had to build a Socket.IO compatible server > recently, and Cowboy was my first choice. I simply find WebMachine > gets the job done when that job is a super simple task and I need full > REST without thinking too hard about it. > > Lee From ahe.sanath@REDACTED Thu Jun 12 05:08:34 2014 From: ahe.sanath@REDACTED (Sanath Prasanna) Date: Thu, 12 Jun 2014 08:38:34 +0530 Subject: [erlang-questions] Diameter Encoding Problem Message-ID: Hi, Pls help to resolve below error. =ERROR REPORT==== 12-Jun-2014::08:22:05 === * why: {diameter_codec,encode,* * {{encode_failure,undef,'CCR',* * [{diameter_gen_base_rfc6733,avp_header,['Session-Id'],[]},* {rfc4006_cc_Gy,e,2, [{file, "i:diameter-1.0/include/diameter_gen.hrl"}, {line,105}]}, {lists,flatmap,2,[{file,"lists.erl"},{line,1184}]}, {rfc4006_cc_Gy,encode_avps,2, [{file, "i:diameter-1.0/include/diameter_gen.hrl"}, Sample Code Below: client:start(). client:create_session(No). create_session(No) -> SId = diameter:session_id(?L(?SVC_NAME)), CCR = #rfc4006_cc_Gy_CCR{ 'Session-Id' = SId, 'Origin-Host' = ?ORIGIN_HOST, 'Origin-Realm' = ?ORIGIN_REALM, 'Destination-Realm' = ?DEST_REALM, 'Auth-Application-Id' = 4, 'Service-Context-Id' = ?CONTEXT_ID, 'CC-Request-Type' = 4, 'CC-Request-Number' = 0, %%'Event-Timestamp' = [ erlang:localtime()], 'Subscription-Id' = [#'rfc4006_cc_Gy_Subscription-Id' { 'Subscription-Id-Type' = 0, 'Subscription-Id-Data' = No}], 'Requested-Service-Unit' = [0], 'Requested-Action' = 0}, io:fwrite("connect ~p~n",[{CCR}]), diameter:call(?SVC_NAME, ?APP_ALIAS, CCR, []). Br, Sanath -------------- next part -------------- An HTML attachment was scrubbed... URL: From z@REDACTED Thu Jun 12 06:23:07 2014 From: z@REDACTED (Danil Zagoskin) Date: Thu, 12 Jun 2014 08:23:07 +0400 Subject: [erlang-questions] Is lhttpc project alive? In-Reply-To: References: Message-ID: Hi Paulo! Yes, the bug is quite simple but annoying. First, how lhttpc works: * before each request the client makes call to lhttpc_manager to check if there is a free socket for an endpoint: https://github.com/esl/lhttpc/blob/master/src/lhttpc_manager.erl#L199 * lhttpc_manager holds all sockets which aren't in use * it handles 'closed' messages from sockets: https://github.com/esl/lhttpc/blob/master/src/lhttpc_manager.erl#L340 * the function remove_sockets calls 'close' on socket one more time: https://github.com/esl/lhttpc/blob/master/src/lhttpc_manager.erl#L419 * actual call to corresponding handling module is at https://github.com/esl/lhttpc/blob/master/src/lhttpc_sock.erl#L176 The problem is in ssl:close ? it may block for many seconds, causing lhttpc_manager not to serve client requests and thus preventing all new requests from running. Some requests will fail with 'timeout' which seems like bad service on the other side. Currently we use such simple hack to workaround the problem: * replace ssl:close(Socket) on lhttpc_sock.erl#L176 with proc_lib:spawn_link(ssl, close, [Socket]) This may lead to other problems (no control of spawned processes) and does not solve the problem completely (there are some minor blockings on setopt), but works as quick fix. On Wed, Jun 11, 2014 at 10:20 PM, Paulo F. Oliveira < paulo.ferraz.oliveira@REDACTED> wrote: > Hi, Danil. > > Do you have more information on "I've found a bug in original lhttpc > causing manager (and thus all new requests) to block but I don't know where > to report it." that you can share? I've been using lhttpc lately and may > profit from a resolution to your problem, seeing that I too seem get to a > situation where new requests are "blocked" but haven't had time to run > after that "bug". > > Thanks. > > Cheers. > > - Paulo F. Oliveira > > > On 10 June 2014 21:40, Danil Zagoskin wrote: > >> Hi! >> >> The project https://github.com/esl/lhttpc seems to be abandoned (many >> open issues including 17.0 compatibility, almost no activity since January >> 2013). >> >> There are some forks: some do simple fixes and some (rymir, jbothma) do >> heavy refactoring. >> >> Is any of forks the new default? >> >> Is https://github.com/ferd/dlhttpc production-ready drop-in replacement? >> >> >> I've found a bug in original lhttpc causing manager (and thus all new >> requests) to block but I don't know where to report it. >> >> >> -- >> Danil Zagoskin | z@REDACTED >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu Jun 12 07:20:51 2014 From: mrtndimitrov@REDACTED (Martin Koroudjiev) Date: Thu, 12 Jun 2014 08:20:51 +0300 Subject: [erlang-questions] Problems with dynamically compiled eunit test Message-ID: <539938B3.90903@gmail.com> Hello, I've used eunit framework many times before with no problems but now I try to compile dynamically a test module and to run the tests. I get this error: undefined *unexpected termination of test process* ::{undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]}, {eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]}, {eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]}, {eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line,530}]}, {eunit_data,group,1,[{file,[...]},{line,...}]}, {eunit_data,next,1,[{file,...},{...}]}, {eunit_data,iter_next,1,[{...}|...]}, {eunit_proc,get_next_item,1,[...]}]} ======================================================= Failed: 0. Skipped: 0. Passed: 0. One or more tests were cancelled. =ERROR REPORT==== 12-Jun-2014::08:10:16 === Error in process <0.185.0> on node 'dilbert@REDACTED' with exit value: {undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]},{eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]},{eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]},{eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line... error The test module is the fib example from the doc page: -module(my_test). -include_lib("eunit/include/eunit.hrl"). -export([fib/1]). fib(0) -> 1; fib(1) -> 1; fib(N) when N > 1 -> fib(N-1) + fib(N-2). fib_test_() -> [?_assert(fib(0) =:= 1), ?_assert(fib(1) =:= 1), ?_assert(fib(2) =:= 2), ?_assert(fib(3) =:= 3), ?_assert(fib(4) =:= 5), ?_assert(fib(5) =:= 8), ?_assertException(error, function_clause, fib(-1)), ?_assert(fib(31) =:= 2178309) ]. Does anyone know what can be wrong? Thanks in advance for your time. Regards, Martin From essen@REDACTED Thu Jun 12 09:56:33 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Jun 2014 09:56:33 +0200 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> Message-ID: <53995D31.7020102@ninenines.eu> No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. (If you haven't guessed from this post, yes, WebMachine was a big inspiration for many things in Cowboy.) On 06/12/2014 01:23 AM, Lee Sylvester wrote: > Hey Lo?c, > > I meant nothing by it. I had to build a Socket.IO compatible server > recently, and Cowboy was my first choice. I simply find WebMachine gets > the job done when that job is a super simple task and I need full REST > without thinking too hard about it. > > Lee > > > On 11 Jun 2014, at 17:21, Lo?c Hoguin > wrote: > >> Cowboy has had Webmachine based REST for more than 2 years now. Am I >> missing something obvious that Webmachine has or are people simply not >> aware of the implementation in Cowboy? If there is something that can >> be improved I'd like to hear about it. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> -------- Original Message -------- >> From:Lee Sylvester > > >> Sent:Wed, 11 Jun 2014 17:58:48 +0200 >> To:Ivan Carmenates Garc?a > >> Cc:erlang-questions@REDACTED >> Subject:Re: [erlang-questions] Which technology I should choose? >> >> I find Cowboy provides a lot of flexibility, but WebMachine provides a >> ?quick to market? solution. WebMachine also helps you build cleaner >> code. Mochiweb is useful, but since WebMachine is built on it, I?d >> say it?s WebMachine hands down. >> >> Lee >> >> >> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a > > wrote: >> >>> Hi all, >>> I?ve been wondering if I could ask for an advice from the community >>> to help me choose a good tec for a project I am developing. >>> My primordial priority is not to be productive, I like pure Erlang as >>> it is, no dummy frameworks for productivity, I?m looking for >>> something clean and powerful at the same time, I already choose Extjs >>> 4.2 for the view, because the project is about accounting and >>> statistics, and the graphics and visual that extjs gives is a very >>> nice and interesting fact. I have a weak choice for yaws for the >>> server at the time. >>> What I would like to know is if there is another web server better >>> than yaws to combine it with extjs, the idea is to export an API REST >>> or another kind of API that allows a good communication with extjs >>> using json, also that supports for web-socket or any real-time server >>> push technology, that is primordial since I need a real-time app, ex: >>> Chicago Boss have a very interesting mechanism to do that, since it >>> use a long-polling strategy, that is very interesting, the only >>> problem and almost impossible to deal with CB is the errors >>> formatting and definition. A good documentation is required too. >>> I hope someone can help me to decide. >>> I will appreciate all kind of suggestions. >>> Best regards, >>> Ivan. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > -- Lo?c Hoguin http://ninenines.eu From lenartlad@REDACTED Thu Jun 12 10:42:27 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Thu, 12 Jun 2014 10:42:27 +0200 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: <1944EFDA-7AE0-48C4-A927-D098E0CB2A1D@gmail.com> References: <1944EFDA-7AE0-48C4-A927-D098E0CB2A1D@gmail.com> Message-ID: <539967F3.9070001@volny.cz> Hello. I think the second whereis might also return undefined at times, at least in theory. Therefore I think it would be better (safer) to call get_pid() recursively instead. Like this: > getpid() -> > case whereis(name) of > undefined -> > case gen_server:start(?.) of > {error,normal} -> > getpid(); % <-- changed > {ok,Pid} -> > % this start call won the race > Pid > end; > Pid -> > Pid > end. HTH, Ladislav Lenart On 11.6.2014 20:19, Sergej Jurecko wrote: > If you are registering the process manually this method will work. > > The problem you might run into is the old process dying just before someone is calling it. You would have to cycle off the process by calling unregister manually and wait for some time to handle calls that are still using the old PID. > > If your gen_server init looks like this: > > init() -> > case catch register(name) of > ok -> > {ok,#state{}}; > _ -> > {stop,normal} > end. > > Then call, getpid functions: > > call(Msg) -> > gen_server:call(getpid(),Msg). > > % The returned PID may get unregistered before it is used. > % This is why the gen_server must unregister and wait for a timeout before dying. > getpid() -> > case whereis(name) of > undefined -> > case gen_server:start(?.) of > {error,normal} -> > % some other process won the race to register itself. > whereis(name); > {ok,Pid} -> > % this start call won the race > Pid > end; > Pid -> > Pid > end. > > > On 11 Jun 2014, at 09:17, Roger Lipscombe wrote: > >> I've got a gen_server with a particular name. I've got a bunch of >> other processes calling and casting to it, by name. >> >> Can I spin up another gen_server, and have the name transferred >> without anyone noticing? That is: can I redirect the calls and casts >> to the new process without interruption? >> >> -- >> Roger. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From erlang@REDACTED Thu Jun 12 10:46:36 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 12 Jun 2014 10:46:36 +0200 Subject: [erlang-questions] How would you implement a blob store Message-ID: Hello I want some opinions on how to implement a blob store. I want a simple key-value store. To fix our ideas - The values are variable size binaries (max 56 KB) - The keys are SHA1 hashes of the values - I want to store max 1M blobs - Efficiency is not a concern (though it would be a deciding factor given two equally beautiful solutions) The *simplest* way I can think of is to use the file store a blob with (hex) hash "a2e34a32..." gets stored in 2-level directory structure in a file called a2/e3/a2e34a32 Even this might have problems - for example is file:write_file/2 atomic? What happens if two process try to write the same file at the same time with the same content? (and I know "at the same time" is meaningless, but it's shorter to say than ' if one processes has made a write_file request and a second process makes a write_file request before the first request issued by the first process has completed ...) The next simplest way I can think of is to make a single huge blob store file (max 56GB) and use an ets table to map hashes to addresses in the file - if this is a good idea or not would depend upon how well the host OS handles sparse files and so on. The third alternative would be to use a raw disk partition(very non portable etc.) The fourth alternative would be to use a library like bitcask The fifth alternative would be use use some other library. My instinct points me to the *simplest* way (above) or bitcask. Now I know that Richard will reply "do them all and measure" - but possibly somebody somebody has done this before - so I can benefit from their wisdom. All ideas are welcome Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Jun 12 10:57:41 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 12 Jun 2014 10:57:41 +0200 Subject: [erlang-questions] How would you implement a blob store In-Reply-To: References: Message-ID: On Thu, Jun 12, 2014 at 10:46 AM, Joe Armstrong wrote: > Hello > > I want some opinions on how to implement a blob store. > > I want a simple key-value store. > > > To fix our ideas > > - The values are variable size binaries (max 56 KB) > - The keys are SHA1 hashes of the values > - I want to store max 1M blobs > - Efficiency is not a concern (though it would be a deciding factor > given two > equally beautiful solutions) > > The *simplest* way I can think of is to use the file store > a blob with (hex) hash "a2e34a32..." gets stored in 2-level directory > structure > in a file called a2/e3/a2e34a32 > > Even this might have problems - for example is file:write_file/2 atomic? > What happens if two process try to write the same file at the same time > with the same > content? (and I know "at the same time" is meaningless, but it's shorter > to say than > ' if one processes has made a write_file request and a second process > makes a write_file > request before the first request issued by the first process has completed > ...) > not sure to see the problem here, if you use an hash then you can check if you're already writing it or not on the file system by testing if it's exist on it. The problem is to make sure that the write won't have any read at the same time that could happen on the filesystem which imply to upload the file to a temporary file and rename it at the end. Or such things. > > The next simplest way I can think of is to make a single huge blob store > file > (max 56GB) and use an ets table to map hashes to addresses in the file - > if this is a good idea or not would depend upon how well the host OS > handles sparse files > and so on. > > > The third alternative would be to use a raw disk partition(very non > portable etc.) > > The fourth alternative would be to use a library like bitcask > or any other key/value api, which was is doing leofs if i remember well. you can store {keys, offset start, size} / chunks in the k/v to point on large file. You will probably need to split the file. > > The fifth alternative would be use use some other library. > we are releasing coffer next week which is providing such features: http://refuge.io/learnmore/platform.html#blob-server The blob server can fullly be used as a library. It abstract blobs upload to different storages services or the filesystem. Current code online is not the one that will be released but can be useful. Hope it helps, - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Thu Jun 12 10:58:57 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 12 Jun 2014 11:58:57 +0300 Subject: [erlang-questions] How would you implement a blob store In-Reply-To: References: Message-ID: <5A573092-9FD7-42A4-B378-F3682EDCAF46@gmail.com> Hello, I see here two approaches (both used by me for blob store). a) use sharded dets. e.g. first byte of your key defines the dets partition. I?ve build a simple library https://github.com/fogfish/d3 to use pid for dets operation. Therefore, you can use gproc or similar to bind your partition identity with dets shard. You can spawn all partition within supervisor using, etc. One of advantage of this option, it is built from erlang native libraries. b) use eleveldb. https://github.com/basho/eleveldb This is very easy to use. I?ve migrated some of my dets based implementation to leveldb. It might not be suitable if you need to port the solution to some other platform. I?ve tried to build this library on Intel CPU only (dunno if it works on ARM, PowerPC, etc) Best Regards, Dmitry On 12 Jun 2014, at 11:46, Joe Armstrong wrote: > Hello > > I want some opinions on how to implement a blob store. > > I want a simple key-value store. > > > To fix our ideas > > - The values are variable size binaries (max 56 KB) > - The keys are SHA1 hashes of the values > - I want to store max 1M blobs > - Efficiency is not a concern (though it would be a deciding factor given two > equally beautiful solutions) > > The *simplest* way I can think of is to use the file store > a blob with (hex) hash "a2e34a32..." gets stored in 2-level directory structure > in a file called a2/e3/a2e34a32 > > Even this might have problems - for example is file:write_file/2 atomic? > What happens if two process try to write the same file at the same time with the same > content? (and I know "at the same time" is meaningless, but it's shorter to say than > ' if one processes has made a write_file request and a second process makes a write_file > request before the first request issued by the first process has completed ...) > > The next simplest way I can think of is to make a single huge blob store file > (max 56GB) and use an ets table to map hashes to addresses in the file - > if this is a good idea or not would depend upon how well the host OS handles sparse files > and so on. > > The third alternative would be to use a raw disk partition(very non portable etc.) > > The fourth alternative would be to use a library like bitcask > > The fifth alternative would be use use some other library. > > > My instinct points me to the *simplest* way (above) or bitcask. > > Now I know that Richard will reply "do them all and measure" - but possibly somebody somebody has done this before - so I can benefit from their wisdom. > > All ideas are welcome > > Cheers > > /Joe > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ingela.andin@REDACTED Thu Jun 12 11:18:47 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 12 Jun 2014 11:18:47 +0200 Subject: [erlang-questions] ssh direct-tcpip port forwarded tunnel In-Reply-To: <1F1B6CE7-34CB-4AA7-A40A-DED4F375B32A@cooperi.net> References: <8512DDCA-8396-4F69-A630-F52DA385F01B@cooperi.net> <16D3F030-D760-47EE-837F-1A66642730D7@cooperi.net> <1F1B6CE7-34CB-4AA7-A40A-DED4F375B32A@cooperi.net> Message-ID: Hi! [...] While there is some code that appears to handle these messages in the SSH > daemon at the moment, it doesn't look like it's really functional for this > kind of remote forwarding tunnel. The daemon looks like it will accept any > tcpip-forward request, but it never opens a port or anything and there is > no way to generate the forwarded-tcpip channel open requests going back to > the client at the moment. I also can see no implementation of server-side > handling of direct-tcpip -- I don't want to jump to conclusions, but it > looks like maybe this was written in just to prevent crashes with these > messages and nothing more -- you should probably take it as a blank slate, > not as something to just be fixed up a little to get it going. > On 10 Jun 2014, at 5:51 pm, Tom van Neerijnen wrote: > > This code was part of the original ssh contribution, that was undocumented and had no testcases (there is a reason we have higher demands on contributions nowdays). We have spent a lot of time improving ssh and writing test cases and documentation for ssh, but there are still quite a few things to do to have full RFC support. It would surprise me a lot if the forwarded-tcpip code would work out of the box, there is a reason it is not documented and it is that we do not have any test for it and hence it probably does not work. It would be nice if it worked but as always a question of priorities. Maybe a good candidate for a user contribution! Regards Ingela Erlang/OTP Team - Ericsson AB [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Thu Jun 12 12:14:13 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 12 Jun 2014 13:14:13 +0300 Subject: [erlang-questions] fast tuple sorting In-Reply-To: References: <9D283B66-92FD-4912-A197-05FCF526EE42@gmail.com> Message-ID: <28F63F4E-AF7C-4769-B175-C4564B303AB0@gmail.com> Hello, Thank you very much for your advises. Let?s re-start the discussion on this thread. I was unavailable recently but problem is still exists. So, let me depict the task and my temporary solution for it but I?d like to obtain an opinion on other possible solutions. There is a flow of request to the system. Each request is set of integer on interval [0, 2^32]. The set cardinality varies from 100 to 300 elements. Some of those integers has a special meaning, they are associated with list of tuples in format {integer(), float()}. The length of tuple lists over 200 elements and there are finite number of those key integers, about ~6M. The system filters ?key integers? from incoming request. For each "key integer" it retrieves a list of tuples associated with it and returns this list to client. The list of tuples has to be sorted by first element. It is very typical scenario that resulting list is 30k - 50k tuples. As I said previously, the timing criteria is hard 6ms to sort the list of tuples. Profiling says that sorting is bottleneck. What comes to implementation? The associated lists are stored within ets bag. Each ets:lookup operation return me a sub-list of tuples. What I need is to sort them. I?ve tries some of your advices: * gb_trees / rbtrees the build time goes over 100ms * ordered ets was fast enough to build but build + read + delete cycle does not fit to the budget * binomial heap was fast to append but slow to read (normal heap suffered from building) I am afraid that problem is bond to data copy. The best possible option I came out is * sort tuple lists before they written to ets bag * use merge sort to build resulting list. this options has nearly same performance as using ordered ets but it is not capable to sort 30k items in given time frame, it takes about 15ms. Fortunately, I was able to temporary reduce the list size to 6 - 8k result elements. The merge sort producing the output with 6 - 7ms. However, I am still seeking for full solution. Best Regards, Dmitry On 30 May 2014, at 22:14, Max Lapshin wrote: > Dmitry, maybe you can tell a bit about your task? > > What are these tuples? Where do you get them from? > From freza@REDACTED Thu Jun 12 13:26:55 2014 From: freza@REDACTED (Jachym Holecek) Date: Thu, 12 Jun 2014 07:26:55 -0400 Subject: [erlang-questions] fast tuple sorting In-Reply-To: <28F63F4E-AF7C-4769-B175-C4564B303AB0@gmail.com> References: <9D283B66-92FD-4912-A197-05FCF526EE42@gmail.com> <28F63F4E-AF7C-4769-B175-C4564B303AB0@gmail.com> Message-ID: <20140612112654.GA100@circlewave.net> # Dmitry Kolesnikov 2014-06-12: > [...] > > There is a flow of request to the system. Each request is set of integer > on interval [0, 2^32]. The set cardinality varies from 100 to 300 elements. > Some of those integers has a special meaning, they are associated with list > of tuples in format {integer(), float()}. The length of tuple lists over > 200 elements and there are finite number of those key integers, about ~6M. > The system filters ?key integers? from incoming request. For each "key > integer" it retrieves a list of tuples associated with it and returns > this list to client. The list of tuples has to be sorted by first element. > It is very typical scenario that resulting list is 30k - 50k tuples. > As I said previously, the timing criteria is hard 6ms to sort the list of > tuples. > > Profiling says that sorting is bottleneck. > > [...] > > I am afraid that problem is bond to data copy. > > The best possible option I came out is > * sort tuple lists before they written to ets bag > * use merge sort to build resulting list. Yes, absolutely -- you don't won't to burn cycles doing the same computations over and over and over again. :-) Presumably the first element in your {Integer, Float} tuples fits a fixed width (32bit or 64bit), in which case you can encode the whole list as a packed binary: <>, this will avoid all the ETS copying which is probably hurting you quite a bit. You'll need a custom merge sort to work with that, but that's okay and you should be able to spread the whole sorting business across multiple cores (this, and the ordering requirement implied below, would require slightly more detailed look then I'm prepared to give it right now, but I trust it will prove straightforward). This is also a good place to cheat with impunity and accelerate things with a simple NIF if necessary. You mention fairly huge lists of results, so hopefully you're not actually building them in memory, then encoding to ouput format and sending back in bulk; but rather encoding and sending out result chunks as they become available. If the protocol you're using doesn't allow for such mode of operation that's a flaw that should be fed back into the design process if at all possible. Just to be a bit clearer on previous point, this is the signalling sequence you probably want: Cli Srv -+-----------+- | | +-----------> lookup_initiate(Ref, [Integer]). | | <-----------+ report_results(Ref, 1, [{Integer, Float}]). | | ... | | <-----------+ report_results(Ref, N, [{Integer, Float}]). | | <-----------+ lookup_terminated(Ref). That reduces resources used by the server during lookup; whilst also fooling with client's perception of operation latency in a good way. Hope these ideas are pertinent and not duplicate, I wasn't following this thread very closely. BR, -- Jachym From bob@REDACTED Thu Jun 12 16:06:18 2014 From: bob@REDACTED (Bob Ippolito) Date: Thu, 12 Jun 2014 09:06:18 -0500 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: <539814FF.8090204@gmail.com> References: <539814FF.8090204@gmail.com> Message-ID: Using gproc (or even just ets) is also a solution. Whether you need the names to be redundant or not, using ets instead of the process registry will allow you to replace them atomically. On Wednesday, June 11, 2014, Michael Truog wrote: > If you need redundant process names, you should probably look at pg2 ( > http://www.erlang.org/doc/man/pg2.html) or cpg ( > https://github.com/okeuday/cpg/). > > On 06/11/2014 12:17 AM, Roger Lipscombe wrote: > >> I've got a gen_server with a particular name. I've got a bunch of >> other processes calling and casting to it, by name. >> >> Can I spin up another gen_server, and have the name transferred >> without anyone noticing? That is: can I redirect the calls and casts >> to the new process without interruption? >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jun 12 16:54:37 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 12 Jun 2014 16:54:37 +0200 Subject: [erlang-questions] Beginners tutorials Message-ID: Re: Garrett's great talk at EUC2014 The point has been made many times before that "There are no easy Erlang getting started guides" So I thought I'd take a look at Node.js. The node js home page (node.js) starts with a simple example var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); To run the server, put the code into a file example.js and execute it with the node program from the command line: % node example.js Server running at http://127.0.0.1:1337/ It's pretty easy to knock up an almost identical example in Erlang - using any of the well-known web servers in the background, unfortunately this has not been done, or if it has been done it's not easy to find the examples (or if there are examples I can't find them) I was vaguely thinking of making some examples that are more-or-less isomorphic to the node.js examples and then applying small transformation steps to turn then from idiomatic node.js code to idiomatic Erlang code. Although I could find a simple hello world example in node.js I could not find a tutorial that started with a simple example and then built on it in very small steps adding routing, authentication, database access and so on. Does anybody know of some examples of node.js that could be used for this. Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jun 12 17:10:46 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Jun 2014 17:10:46 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: <5399C2F6.5000101@ninenines.eu> The simple nodejs example works because it's a nodejs example and not a Javascript example. Someone who doesn't know Javascript (pretty much equivalent to someone who doesn't know programming at all) won't understand it. In particular it has a number of objects in it, and these are not what you start learning a language with. Most people who look at Erlang necessarily have to learn a number of things that people who look at nodejs don't. You can't dumb it down as much as nodejs can. The other issue would be that teaching someone to do that in Erlang would be counter-productive. Do you really want to teach people to do that and then tell them they're doing it wrong? I think the bigger difference here is that nodejs uses a scripting language vs Erlang's compiled/run in a VM language. There's simply more to do and learn before you can start something. You have to compile the file. You have to start the VM with the proper paths set. And so on. Since you have to do all that, why not explain it properly from the beginning? That's why the Cowboy guide starts with building a release. It takes about five minutes to go from nothing to your first release running a hello world application. Of course that's not as fast as nodejs, but we simply can't go that fast anyway. We're not a scripting language. Still I think that's a pretty quick way to start. The chapter is here if you want to take a look and provide feedback: http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ On 06/12/2014 04:54 PM, Joe Armstrong wrote: > Re: Garrett's great talk at EUC2014 > > The point has been made many times before that > "There are no easy Erlang getting started guides" > > So I thought I'd take a look at Node.js. > > The node js home page (node.js) starts with a simple example > > > > var http = require('http'); > http.createServer(function (req, res) { > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end('Hello World\n'); > }).listen(1337, '127.0.0.1'); > console.log('Server running at http://127.0.0.1:1337/'); > > To run the server, put the code into a file example.js and execute it > with the node program from the command line: > > % node example.js > Server running at http://127.0.0.1:1337/ > > > It's pretty easy to knock up an almost identical example in Erlang - > using any of the well-known web > servers in the background, unfortunately this has not been done, or if > it has been done > it's not easy to find the examples (or if there are examples I can't > find them) > > I was vaguely thinking of making some examples that are more-or-less > isomorphic to the > node.js examples and then applying small transformation steps to turn > then from idiomatic node.js code to idiomatic Erlang code. > > Although I could find a simple hello world example in node.js I could > not find a tutorial that > started with a simple example and then built on it in very small steps > adding routing, authentication, > database access and so on. > > Does anybody know of some examples of node.js that could be used for this. > Cheers > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From lee.sylvester@REDACTED Thu Jun 12 17:14:00 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Thu, 12 Jun 2014 16:14:00 +0100 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <53995D31.7020102@ninenines.eu> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> Message-ID: <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> I actually think Cowboy has the most potential. Mostly because Cowboy receives the most frequent updates. However, I also love WebMachine and it?s cleanliness. It would be good to have a secondary layer for Cowboy one of these days, that helps scaffold complex but typical web server requirements. I?ve been thinking quite a bit about it. Lee On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. > > (If you haven't guessed from this post, yes, WebMachine was a big inspiration for many things in Cowboy.) > > On 06/12/2014 01:23 AM, Lee Sylvester wrote: >> Hey Lo?c, >> >> I meant nothing by it. I had to build a Socket.IO compatible server >> recently, and Cowboy was my first choice. I simply find WebMachine gets >> the job done when that job is a super simple task and I need full REST >> without thinking too hard about it. >> >> Lee >> >> >> On 11 Jun 2014, at 17:21, Lo?c Hoguin > > wrote: >> >>> Cowboy has had Webmachine based REST for more than 2 years now. Am I >>> missing something obvious that Webmachine has or are people simply not >>> aware of the implementation in Cowboy? If there is something that can >>> be improved I'd like to hear about it. >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >>> >>> -------- Original Message -------- >>> From:Lee Sylvester >> > >>> Sent:Wed, 11 Jun 2014 17:58:48 +0200 >>> To:Ivan Carmenates Garc?a > >>> Cc:erlang-questions@REDACTED >>> Subject:Re: [erlang-questions] Which technology I should choose? >>> >>> I find Cowboy provides a lot of flexibility, but WebMachine provides a >>> ?quick to market? solution. WebMachine also helps you build cleaner >>> code. Mochiweb is useful, but since WebMachine is built on it, I?d >>> say it?s WebMachine hands down. >>> >>> Lee >>> >>> >>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a >> > wrote: >>> >>>> Hi all, >>>> I?ve been wondering if I could ask for an advice from the community >>>> to help me choose a good tec for a project I am developing. >>>> My primordial priority is not to be productive, I like pure Erlang as >>>> it is, no dummy frameworks for productivity, I?m looking for >>>> something clean and powerful at the same time, I already choose Extjs >>>> 4.2 for the view, because the project is about accounting and >>>> statistics, and the graphics and visual that extjs gives is a very >>>> nice and interesting fact. I have a weak choice for yaws for the >>>> server at the time. >>>> What I would like to know is if there is another web server better >>>> than yaws to combine it with extjs, the idea is to export an API REST >>>> or another kind of API that allows a good communication with extjs >>>> using json, also that supports for web-socket or any real-time server >>>> push technology, that is primordial since I need a real-time app, ex: >>>> Chicago Boss have a very interesting mechanism to do that, since it >>>> use a long-polling strategy, that is very interesting, the only >>>> problem and almost impossible to deal with CB is the errors >>>> formatting and definition. A good documentation is required too. >>>> I hope someone can help me to decide. >>>> I will appreciate all kind of suggestions. >>>> Best regards, >>>> Ivan. >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> > > -- > Lo?c Hoguin > http://ninenines.eu From essen@REDACTED Thu Jun 12 17:15:53 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 12 Jun 2014 17:15:53 +0200 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> Message-ID: <5399C429.6070300@ninenines.eu> But what's this cleanliness you speak of? Can you provide some examples? On 06/12/2014 05:14 PM, Lee Sylvester wrote: > I actually think Cowboy has the most potential. Mostly because Cowboy receives the most frequent updates. However, I also love WebMachine and it?s cleanliness. It would be good to have a secondary layer for Cowboy one of these days, that helps scaffold complex but typical web server requirements. I?ve been thinking quite a bit about it. > > Lee > > > > On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > >> No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. >> >> (If you haven't guessed from this post, yes, WebMachine was a big inspiration for many things in Cowboy.) >> >> On 06/12/2014 01:23 AM, Lee Sylvester wrote: >>> Hey Lo?c, >>> >>> I meant nothing by it. I had to build a Socket.IO compatible server >>> recently, and Cowboy was my first choice. I simply find WebMachine gets >>> the job done when that job is a super simple task and I need full REST >>> without thinking too hard about it. >>> >>> Lee >>> >>> >>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >> > wrote: >>> >>>> Cowboy has had Webmachine based REST for more than 2 years now. Am I >>>> missing something obvious that Webmachine has or are people simply not >>>> aware of the implementation in Cowboy? If there is something that can >>>> be improved I'd like to hear about it. >>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> >>>> -------- Original Message -------- >>>> From:Lee Sylvester >>> > >>>> Sent:Wed, 11 Jun 2014 17:58:48 +0200 >>>> To:Ivan Carmenates Garc?a > >>>> Cc:erlang-questions@REDACTED >>>> Subject:Re: [erlang-questions] Which technology I should choose? >>>> >>>> I find Cowboy provides a lot of flexibility, but WebMachine provides a >>>> ?quick to market? solution. WebMachine also helps you build cleaner >>>> code. Mochiweb is useful, but since WebMachine is built on it, I?d >>>> say it?s WebMachine hands down. >>>> >>>> Lee >>>> >>>> >>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a >>> > wrote: >>>> >>>>> Hi all, >>>>> I?ve been wondering if I could ask for an advice from the community >>>>> to help me choose a good tec for a project I am developing. >>>>> My primordial priority is not to be productive, I like pure Erlang as >>>>> it is, no dummy frameworks for productivity, I?m looking for >>>>> something clean and powerful at the same time, I already choose Extjs >>>>> 4.2 for the view, because the project is about accounting and >>>>> statistics, and the graphics and visual that extjs gives is a very >>>>> nice and interesting fact. I have a weak choice for yaws for the >>>>> server at the time. >>>>> What I would like to know is if there is another web server better >>>>> than yaws to combine it with extjs, the idea is to export an API REST >>>>> or another kind of API that allows a good communication with extjs >>>>> using json, also that supports for web-socket or any real-time server >>>>> push technology, that is primordial since I need a real-time app, ex: >>>>> Chicago Boss have a very interesting mechanism to do that, since it >>>>> use a long-polling strategy, that is very interesting, the only >>>>> problem and almost impossible to deal with CB is the errors >>>>> formatting and definition. A good documentation is required too. >>>>> I hope someone can help me to decide. >>>>> I will appreciate all kind of suggestions. >>>>> Best regards, >>>>> Ivan. >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu > -- Lo?c Hoguin http://ninenines.eu From maxim@REDACTED Thu Jun 12 17:19:18 2014 From: maxim@REDACTED (Maxim Sokhatsky) Date: Thu, 12 Jun 2014 18:19:18 +0300 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: Try this time following: $ git clone?https://github.com/5HT/n2o $ cd n2o/samples $ make && make console Prerequisites: ? ? ? ? Mac: brew install erlang rebar ? ? ? ? Linux: sudo apt-get install erlang rebar inotify-tools ? ? ? ? BSD: use gmake instead of make 5HT From lee.sylvester@REDACTED Thu Jun 12 17:19:18 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Thu, 12 Jun 2014 16:19:18 +0100 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <5399C429.6070300@ninenines.eu> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> <5399C429.6070300@ninenines.eu> Message-ID: <268F1854-1B95-4852-9A78-D21F15F2B151@gmail.com> By cleanliness, I simply mean the variety of hooks at my disposal. It means I can compartmentalise in a very uniform way. I?m not familiar enough with Cowboy to do that. I blame the docs. In my opinion, neither Cowboy nor WebMachine have great (exhaustive) docs. However, that said, the reason I can do what I do in WebMachine is because I have to. At least Cowboy let?s me do what I want with the few hooks I know about. Yes, I can read the source, but I don?t have time :-) Lee On 12 Jun 2014, at 16:15, Lo?c Hoguin wrote: > But what's this cleanliness you speak of? Can you provide some examples? > > On 06/12/2014 05:14 PM, Lee Sylvester wrote: >> I actually think Cowboy has the most potential. Mostly because Cowboy receives the most frequent updates. However, I also love WebMachine and it?s cleanliness. It would be good to have a secondary layer for Cowboy one of these days, that helps scaffold complex but typical web server requirements. I?ve been thinking quite a bit about it. >> >> Lee >> >> >> >> On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: >> >>> No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. >>> >>> (If you haven't guessed from this post, yes, WebMachine was a big inspiration for many things in Cowboy.) >>> >>> On 06/12/2014 01:23 AM, Lee Sylvester wrote: >>>> Hey Lo?c, >>>> >>>> I meant nothing by it. I had to build a Socket.IO compatible server >>>> recently, and Cowboy was my first choice. I simply find WebMachine gets >>>> the job done when that job is a super simple task and I need full REST >>>> without thinking too hard about it. >>>> >>>> Lee >>>> >>>> >>>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >>> > wrote: >>>> >>>>> Cowboy has had Webmachine based REST for more than 2 years now. Am I >>>>> missing something obvious that Webmachine has or are people simply not >>>>> aware of the implementation in Cowboy? If there is something that can >>>>> be improved I'd like to hear about it. >>>>> >>>>> -- >>>>> Lo?c Hoguin >>>>> http://ninenines.eu >>>>> >>>>> -------- Original Message -------- >>>>> From:Lee Sylvester >>>> > >>>>> Sent:Wed, 11 Jun 2014 17:58:48 +0200 >>>>> To:Ivan Carmenates Garc?a > >>>>> Cc:erlang-questions@REDACTED >>>>> Subject:Re: [erlang-questions] Which technology I should choose? >>>>> >>>>> I find Cowboy provides a lot of flexibility, but WebMachine provides a >>>>> ?quick to market? solution. WebMachine also helps you build cleaner >>>>> code. Mochiweb is useful, but since WebMachine is built on it, I?d >>>>> say it?s WebMachine hands down. >>>>> >>>>> Lee >>>>> >>>>> >>>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a >>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> I?ve been wondering if I could ask for an advice from the community >>>>>> to help me choose a good tec for a project I am developing. >>>>>> My primordial priority is not to be productive, I like pure Erlang as >>>>>> it is, no dummy frameworks for productivity, I?m looking for >>>>>> something clean and powerful at the same time, I already choose Extjs >>>>>> 4.2 for the view, because the project is about accounting and >>>>>> statistics, and the graphics and visual that extjs gives is a very >>>>>> nice and interesting fact. I have a weak choice for yaws for the >>>>>> server at the time. >>>>>> What I would like to know is if there is another web server better >>>>>> than yaws to combine it with extjs, the idea is to export an API REST >>>>>> or another kind of API that allows a good communication with extjs >>>>>> using json, also that supports for web-socket or any real-time server >>>>>> push technology, that is primordial since I need a real-time app, ex: >>>>>> Chicago Boss have a very interesting mechanism to do that, since it >>>>>> use a long-polling strategy, that is very interesting, the only >>>>>> problem and almost impossible to deal with CB is the errors >>>>>> formatting and definition. A good documentation is required too. >>>>>> I hope someone can help me to decide. >>>>>> I will appreciate all kind of suggestions. >>>>>> Best regards, >>>>>> Ivan. >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >> > > -- > Lo?c Hoguin > http://ninenines.eu From m3oucat@REDACTED Thu Jun 12 16:47:07 2014 From: m3oucat@REDACTED (ami) Date: Thu, 12 Jun 2014 17:47:07 +0300 Subject: [erlang-questions] How does a match context of an erlang bitstring work? Message-ID: Hi all I'd read [efficiency guide][1] and [erlang-questions mailing list archive][2] & all of the available books in erlang. But I haven't found the precise description of efficient binaries pattern matching. Though, I haven't read sources yet :) But I hope that people, who already have read them, would read this post. Here are my questions. 1. How many match contexts does an erlang binary have? a) if we match parts of a binary sequentially and just once A = <<1,2,3,4>>. <> = A. Do we have just one binary match context(moving from the beginning of A to the end), or four? b) if we match parts of a binary sequentially from the beginning to the end for the first time and(sequentially again) from the beginning to the end for the second time B = <<1,2,3,4>>. <> = B. <> = B. Do we have just a single match context, which is moving from the beginning of B to the end of B and then moving again from the beginning of B to the end of B, or we have 2 match contexts, one is moving from the beginning of B to the end of B, and another - again from the beginning of B to the end of B (as first can't move to the beginning again) or we have 8 match contexts? 2. According to [documentation][3], if I write: my_binary_to_list(<>) -> [H|my_binary_to_list(T)]; my_binary_to_list(<<>>) -> []. there will be only 1 match context for the whole recursion tree, even though, this function isn't tail-recursive. a) Did I get it right, that there would be only 1 match context in this case? b) Did I get right, that if I match an erlang binary sequentially(from the beginning to the end), it doesn't matter which recursion type(tail or body) has to be used?(from the binary-matching efficiency point of view) c) What if I'm going to process erlang binary NOT sequentially, say, I'm travelling through a binary - first I match first byte, then 1000th, then 5th, then 10001th, then 10th... In this case, d1) If I used body-recursion, how many matching contexts for this binary would I have - one or >1? d2) if I used tail-recursion, how many matching contexts for this binary would I have - one or >1? 3. If I pass a large binary(say 1 megabyte) via tail recursion, Will all the 1 megabyte data be copied? Or only a some kind of pointer to the beginning of this binary is being passed between calls? 4. Does it matter which binary I'm matching - big or small - a match context will be created for binary of any size or only for large ones? [1]: http://www.erlang.org/doc/efficiency_guide/users_guide.html [2]: http://erlang.org/pipermail/erlang-questions/ [3]: http://www.erlang.org/doc/efficiency_guide/binaryhandling.html#id65745 Thanks a lot in advance & kind regards, Alex From mallen@REDACTED Thu Jun 12 17:45:03 2014 From: mallen@REDACTED (Mark Allen) Date: Thu, 12 Jun 2014 10:45:03 -0500 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: I started http://introducingerlang.com right after EF2014 in San Francisco. It's intended to be a really short and simple introduction to Erlang for people who know how to program in other languages but don't know Erlang. I have a mostly documented OTP application (uses Gordon Guthrie's "literate Erlang" markup) with a supervisor, gen_server and application modules here: https://github.com/introducingerlang/todolist/tree/master/src_md I would welcome any help finishing the documentation of the modules in that repo or extending/correcting/fixing the web content that's already there. I can add you directly to the github organization. Thanks, Mark From: Joe Armstrong > Date: Thursday, June 12, 2014 9:54 AM To: Erlang > Subject: [erlang-questions] Beginners tutorials Re: Garrett's great talk at EUC2014 The point has been made many times before that "There are no easy Erlang getting started guides" So I thought I'd take a look at Node.js. The node js home page (node.js) starts with a simple example var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); To run the server, put the code into a file example.js and execute it with the node program from the command line: % node example.js Server running at http://127.0.0.1:1337/ It's pretty easy to knock up an almost identical example in Erlang - using any of the well-known web servers in the background, unfortunately this has not been done, or if it has been done it's not easy to find the examples (or if there are examples I can't find them) I was vaguely thinking of making some examples that are more-or-less isomorphic to the node.js examples and then applying small transformation steps to turn then from idiomatic node.js code to idiomatic Erlang code. Although I could find a simple hello world example in node.js I could not find a tutorial that started with a simple example and then built on it in very small steps adding routing, authentication, database access and so on. Does anybody know of some examples of node.js that could be used for this. Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Jun 12 17:47:15 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Thu, 12 Jun 2014 11:47:15 -0400 (EDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: <5399C2F6.5000101@ninenines.eu> References: <5399C2F6.5000101@ninenines.eu> Message-ID: <1402588035.811615800@apps.rackspace.com> Hello, As a not-so-noobie clawing my way up the Erlang learning curve, I concur with Lo?c. One of the biggest challenges I had as I set out to learn Erlang without mentoring was making sense of Erlang source code that I found on the web. Here were these weird modules that seemed to relate to one another, but where do I enter the tangle of code to trace the logic of the program? I was studiously working through Programming Erlang and the other major works of the Erlang canon and learning much about Erlang syntax, but simply couldn't grasp the high-level logic of source I found on the web. Consequently, there was no way I could even think about writing a useful Erlang program. It wasn't until I finally grasped the structure of OTP applications that it began to come together--- took months and months to reach that point. That still left the mysterious and scary process of creating Erlang releases. But, at least, I could sort of follow and admire the works of various Erlang gurus. I venture that there is direct correlation between early success and noobie loyalty. Fortunately I'm a stubborn cus so I stuck it out through the hours and hours of frustration. How many Erlang tire kickers drop out along the way? Lo?c's guide to building an Erlang release was a powerful epiphany. At last I felt maybe I could build something in Erlang of use to myself and maybe the world. Jesse Gumm and I are working on the definitive Nitrogen text. In it, we have a chapter called Erlang from the Top Down. The whole premise of the book is to build success upon early success, learning Erlang as you go. Early days yet, but it's looking promising. All the best, Lloyd -----Original Message----- From: "Lo?c Hoguin" Sent: Thursday, June 12, 2014 11:10am To: "Joe Armstrong" , "Erlang" Subject: Re: [erlang-questions] Beginners tutorials The simple nodejs example works because it's a nodejs example and not a Javascript example. Someone who doesn't know Javascript (pretty much equivalent to someone who doesn't know programming at all) won't understand it. In particular it has a number of objects in it, and these are not what you start learning a language with. Most people who look at Erlang necessarily have to learn a number of things that people who look at nodejs don't. You can't dumb it down as much as nodejs can. The other issue would be that teaching someone to do that in Erlang would be counter-productive. Do you really want to teach people to do that and then tell them they're doing it wrong? I think the bigger difference here is that nodejs uses a scripting language vs Erlang's compiled/run in a VM language. There's simply more to do and learn before you can start something. You have to compile the file. You have to start the VM with the proper paths set. And so on. Since you have to do all that, why not explain it properly from the beginning? That's why the Cowboy guide starts with building a release. It takes about five minutes to go from nothing to your first release running a hello world application. Of course that's not as fast as nodejs, but we simply can't go that fast anyway. We're not a scripting language. Still I think that's a pretty quick way to start. The chapter is here if you want to take a look and provide feedback: http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ On 06/12/2014 04:54 PM, Joe Armstrong wrote: > Re: Garrett's great talk at EUC2014 > > The point has been made many times before that > "There are no easy Erlang getting started guides" > > So I thought I'd take a look at Node.js. > > The node js home page (node.js) starts with a simple example > > > > var http = require('http'); > http.createServer(function (req, res) { > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end('Hello World\n'); > }).listen(1337, '127.0.0.1'); > console.log('Server running at http://127.0.0.1:1337/'); > > To run the server, put the code into a file example.js and execute it > with the node program from the command line: > > % node example.js > Server running at http://127.0.0.1:1337/ > > > It's pretty easy to knock up an almost identical example in Erlang - > using any of the well-known web > servers in the background, unfortunately this has not been done, or if > it has been done > it's not easy to find the examples (or if there are examples I can't > find them) > > I was vaguely thinking of making some examples that are more-or-less > isomorphic to the > node.js examples and then applying small transformation steps to turn > then from idiomatic node.js code to idiomatic Erlang code. > > Although I could find a simple hello world example in node.js I could > not find a tutorial that > started with a simple example and then built on it in very small steps > adding routing, authentication, > database access and so on. > > Does anybody know of some examples of node.js that could be used for this. > Cheers > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Jun 12 17:48:52 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 12 Jun 2014 11:48:52 -0400 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <5399C2F6.5000101@ninenines.eu> References: <5399C2F6.5000101@ninenines.eu> Message-ID: <5399CBE4.2080603@meetinghouse.net> Doesn't it kind of depend on what the goal of a tutorial is? If all one is trying to do is teach straight coding in Erlang, the big conceptual issue is getting one's head around a functional language. For that, there's: http://www.erlang.org/static/getting_started_quickly.html and http://learnyousomeerlang.com/content But, really, if all one is trying to do is get from "hello world" to stand-alone code modules, that kind of misses the point of Erlang (at least IMHO). It's not like one is progressing from short, simple programs, to very large complicated ones - the whole point of Erlang is to develop systems of actors - where the conceptual issues have a lot more to do with how to structure large collections of interacting units. Now if one is trying to do a ground up tutorial for Erlang, and OTP, as a platform - that immediately leads to three questions: - what is the audience trying to learn? - what is the reader's state of knowledge about such things as distributed system concepts and architectures, run-time environments, platforms, and so forth? - where to start? - and maybe, whether to proceed with a bottom-up incremental approach to system building, or a top-down architectural approach In fact, if anything, rather than a bottom-up tutorial, what might be really useful is a top-down tutorial - more along the lines of learning Linux for the first time. Rather than starting with echo "Hello World!" a tutorial is more along the lines of: - insert liveCD into slot, and boot - log in - list some files - create a file, display it, examine its properties, - examine directory structures and file types (including device types) - examine the processes running, manipulate them - examine environment variables, paths, etc. - create and manipulate some shells - download, unpack, and install some packages - and so forth For Erlang, the equivalent might start with: - install Erlang - start a node - use the various run-time tools to start examining what's running - write, compile, load, run a simple 2-actor ping-pong application; examine it's behavior with the various run-time tools - start up another node - modify ping-pong to run across nodes; examine its run-time behavior - play with some of the packaging/installation/distribution tools - from there, I think we're getting into areas that are more complex than it makes sense to address in a tutorial - more like the ground that "Erlang and OTP in Action" covers pretty well Just my two cents, Miles Fidelman Lo?c Hoguin wrote: > The simple nodejs example works because it's a nodejs example and not > a Javascript example. Someone who doesn't know Javascript (pretty much > equivalent to someone who doesn't know programming at all) won't > understand it. In particular it has a number of objects in it, and > these are not what you start learning a language with. > > Most people who look at Erlang necessarily have to learn a number of > things that people who look at nodejs don't. You can't dumb it down as > much as nodejs can. > > The other issue would be that teaching someone to do that in Erlang > would be counter-productive. Do you really want to teach people to do > that and then tell them they're doing it wrong? I think the bigger > difference here is that nodejs uses a scripting language vs Erlang's > compiled/run in a VM language. There's simply more to do and learn > before you can start something. You have to compile the file. You have > to start the VM with the proper paths set. And so on. Since you have > to do all that, why not explain it properly from the beginning? > > That's why the Cowboy guide starts with building a release. It takes > about five minutes to go from nothing to your first release running a > hello world application. Of course that's not as fast as nodejs, but > we simply can't go that fast anyway. We're not a scripting language. > Still I think that's a pretty quick way to start. > > The chapter is here if you want to take a look and provide feedback: > http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ > > On 06/12/2014 04:54 PM, Joe Armstrong wrote: >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it >> with the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - >> using any of the well-known web >> servers in the background, unfortunately this has not been done, or if >> it has been done >> it's not easy to find the examples (or if there are examples I can't >> find them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn >> then from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could >> not find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for >> this. >> Cheers >> >> /Joe >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mjtruog@REDACTED Thu Jun 12 18:00:28 2014 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 12 Jun 2014 09:00:28 -0700 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: References: <539814FF.8090204@gmail.com> Message-ID: <5399CE9C.8050507@gmail.com> Yes, gproc and ets could be used if you are only using a single Erlang node. On 06/12/2014 07:06 AM, Bob Ippolito wrote: > Using gproc (or even just ets) is also a solution. Whether you need the names to be redundant or not, using ets instead of the process registry will allow you to replace them atomically. > > On Wednesday, June 11, 2014, Michael Truog > wrote: > > If you need redundant process names, you should probably look at pg2 (http://www.erlang.org/doc/man/pg2.html) or cpg (https://github.com/okeuday/cpg/). > > On 06/11/2014 12:17 AM, Roger Lipscombe wrote: > > I've got a gen_server with a particular name. I've got a bunch of > other processes calling and casting to it, by name. > > Can I spin up another gen_server, and have the name transferred > without anyone noticing? That is: can I redirect the calls and casts > to the new process without interruption? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico.carrone@REDACTED Thu Jun 12 18:15:25 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Thu, 12 Jun 2014 13:15:25 -0300 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <5399C2F6.5000101@ninenines.eu> References: <5399C2F6.5000101@ninenines.eu> Message-ID: On Thu, Jun 12, 2014 at 12:10 PM, Lo?c Hoguin wrote: > >The simple nodejs example works because it's a nodejs example and not a > Javascript example. Someone who >doesn't know Javascript (pretty much > equivalent to someone who doesn't know programming at all) won't > >understand it. In particular it has a number of objects in it, and these > are not what you start learning a language >with. > I think most devs from other languages understand pretty quickly that nodejs example even if they don't know javascript. I think with Erlang the issue is that, like you said Loic, you have to learn quite a few new things. I don't think that is bad. While learning Erlang I have learnt a LOT of things that are really useful not only for developing in Erlang. However we have to accept that so that we can try to do the best for newcomers. > >Most people who look at Erlang necessarily have to learn a number of > things that people who look at nodejs don't. >You can't dumb it down as > much as nodejs can. > For the last eight or nine years I have worked with C, C++, Java, Python, Ruby and Javascript. Even if the languages were different, it was not difficult to move from one to the other. Sure, I had to learn some new stuff, specially how to do things on that particular language/community. With Erlang I had to learn a lot more than a new syntax. It was a huge list of new and beautiful concepts. Even if we "can't dumb" things as much as nodejs tutorial can, we have to do our best. I think cowboy/cowboy guide/cowboy examples (even if some are outdated) are a great step into dumbing it down as much as we can. However I think we can do even better. I am not saying that Loic, Joe, francesco, Fred, J Louis, etc have not done enough! When I say "we" I am talking specially about newcomers. In my case, I think that there are a lot of great books (specially learn you some erlang, programming erlang and erlang programming) about Erlang that explain all the concepts and parts of the language. However I think there should be a good series of posts, or even a book, more like Hands on Nodejs. A good tutorial/book where you start creating a system, instead of learning about message passing and erlang basic types. Instead of explaining every detail before using new concepts, instead of going from little things to a big system, you use them and then you explain them in some detail. I think this is the best way to learn and get people excited in the process. That's why a few days ago I started writing a series of posts (and hopefully a small book) with a few teammates from my company, Inaka, about how to create a comment system (like http://disqus.com/) and a really simple messaging system to be used by iOS, Android or web clients (I am building one in Erlang for http://whisper.sh/ so I will use what I learnt) from scratch. Instead of learning about all the Erlang basic types, message passing, etc, you start creating a HTTP/Rest application with cowboy and you learn things when you need to use them. Hopefully we will have the first post finished in the next days thanks to Inaka that is giving me some hours for doing it. Apart from the posts/mini book I am working on a web like http://superherojs.com/ but for Erlang. I think this could be great for newcomers. I am adding the links to this Readme: https://github.com/pyotrgalois/spawnedshelter/blob/master/README.md. In the following weeks I will do the frontend work. I already have a friend who is drawing a few things for the web :). Regards, Federico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Jun 12 18:19:32 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Thu, 12 Jun 2014 12:19:32 -0400 (EDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: <5399CBE4.2080603@meetinghouse.net> References: <5399C2F6.5000101@ninenines.eu> <5399CBE4.2080603@meetinghouse.net> Message-ID: <1402589972.449530811@apps.rackspace.com> Hello, > Now if one is trying to do a ground up tutorial for Erlang, and OTP, as > a platform - that immediately leads to three questions: > - what is the audience trying to learn? > - what is the reader's state of knowledge about such things as > distributed system concepts and architectures, run-time environments, > platforms, and so forth? > - where to start? Spot on! No laws of the universe dictate against more than one tutorial. Love your idea of two-note ping-pong plus dissect with tools. Getting my head around OTP concepts was my first major learning barrier; understanding how to architect ambitious Erlang systems is the issue I'm wrestling with now. All the best, Lloyd -----Original Message----- From: "Miles Fidelman" Sent: Thursday, June 12, 2014 11:48am To: "Erlang" Subject: Re: [erlang-questions] Beginners tutorials Doesn't it kind of depend on what the goal of a tutorial is? If all one is trying to do is teach straight coding in Erlang, the big conceptual issue is getting one's head around a functional language. For that, there's: http://www.erlang.org/static/getting_started_quickly.html and http://learnyousomeerlang.com/content But, really, if all one is trying to do is get from "hello world" to stand-alone code modules, that kind of misses the point of Erlang (at least IMHO). It's not like one is progressing from short, simple programs, to very large complicated ones - the whole point of Erlang is to develop systems of actors - where the conceptual issues have a lot more to do with how to structure large collections of interacting units. Now if one is trying to do a ground up tutorial for Erlang, and OTP, as a platform - that immediately leads to three questions: - what is the audience trying to learn? - what is the reader's state of knowledge about such things as distributed system concepts and architectures, run-time environments, platforms, and so forth? - where to start? - and maybe, whether to proceed with a bottom-up incremental approach to system building, or a top-down architectural approach In fact, if anything, rather than a bottom-up tutorial, what might be really useful is a top-down tutorial - more along the lines of learning Linux for the first time. Rather than starting with echo "Hello World!" a tutorial is more along the lines of: - insert liveCD into slot, and boot - log in - list some files - create a file, display it, examine its properties, - examine directory structures and file types (including device types) - examine the processes running, manipulate them - examine environment variables, paths, etc. - create and manipulate some shells - download, unpack, and install some packages - and so forth For Erlang, the equivalent might start with: - install Erlang - start a node - use the various run-time tools to start examining what's running - write, compile, load, run a simple 2-actor ping-pong application; examine it's behavior with the various run-time tools - start up another node - modify ping-pong to run across nodes; examine its run-time behavior - play with some of the packaging/installation/distribution tools - from there, I think we're getting into areas that are more complex than it makes sense to address in a tutorial - more like the ground that "Erlang and OTP in Action" covers pretty well Just my two cents, Miles Fidelman Lo?c Hoguin wrote: > The simple nodejs example works because it's a nodejs example and not > a Javascript example. Someone who doesn't know Javascript (pretty much > equivalent to someone who doesn't know programming at all) won't > understand it. In particular it has a number of objects in it, and > these are not what you start learning a language with. > > Most people who look at Erlang necessarily have to learn a number of > things that people who look at nodejs don't. You can't dumb it down as > much as nodejs can. > > The other issue would be that teaching someone to do that in Erlang > would be counter-productive. Do you really want to teach people to do > that and then tell them they're doing it wrong? I think the bigger > difference here is that nodejs uses a scripting language vs Erlang's > compiled/run in a VM language. There's simply more to do and learn > before you can start something. You have to compile the file. You have > to start the VM with the proper paths set. And so on. Since you have > to do all that, why not explain it properly from the beginning? > > That's why the Cowboy guide starts with building a release. It takes > about five minutes to go from nothing to your first release running a > hello world application. Of course that's not as fast as nodejs, but > we simply can't go that fast anyway. We're not a scripting language. > Still I think that's a pretty quick way to start. > > The chapter is here if you want to take a look and provide feedback: > http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ > > On 06/12/2014 04:54 PM, Joe Armstrong wrote: >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it >> with the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - >> using any of the well-known web >> servers in the background, unfortunately this has not been done, or if >> it has been done >> it's not easy to find the examples (or if there are examples I can't >> find them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn >> then from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could >> not find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for >> this. >> Cheers >> >> /Joe >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From co7eb@REDACTED Thu Jun 12 18:38:16 2014 From: co7eb@REDACTED (=?UTF-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Thu, 12 Jun 2014 12:38:16 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <5399C429.6070300@ninenines.eu> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> <5399C429.6070300@ninenines.eu> Message-ID: <002a01cf865c$ba378e30$2ea6aa90$@frcuba.co.cu> Yes, I mean no embedded code like apache/php and yaws/erlang, a good and separate logic, like using model, view, controller, an example could be in the standard web design, using html, css and javascript, the html file only content the struct, css file with the style, and the combination of two is referring in the html file id classes in css file, not embedding css code in the html, for the javascript part even more careful, using add listener events in the js file over registering events or embedding js code in the html. Something like that, I really disgust embedded code I rather a thousand of times to build a well-defined and separated logic. Regards, Ivan. -----Mensaje original----- De: Lo?c Hoguin [mailto:essen@REDACTED] Enviado el: jueves, 12 de junio de 2014 11:16 a.m. Para: Lee Sylvester CC: Ivan Carmenates Garc?a; erlang-questions@REDACTED Asunto: Re: [erlang-questions] Which technology I should choose? But what's this cleanliness you speak of? Can you provide some examples? On 06/12/2014 05:14 PM, Lee Sylvester wrote: > I actually think Cowboy has the most potential. Mostly because Cowboy receives the most frequent updates. However, I also love WebMachine and it?s cleanliness. It would be good to have a secondary layer for Cowboy one of these days, that helps scaffold complex but typical web server requirements. I?ve been thinking quite a bit about it. > > Lee > > > > On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > >> No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. >> >> (If you haven't guessed from this post, yes, WebMachine was a big >> inspiration for many things in Cowboy.) >> >> On 06/12/2014 01:23 AM, Lee Sylvester wrote: >>> Hey Lo?c, >>> >>> I meant nothing by it. I had to build a Socket.IO compatible server >>> recently, and Cowboy was my first choice. I simply find WebMachine >>> gets the job done when that job is a super simple task and I need >>> full REST without thinking too hard about it. >>> >>> Lee >>> >>> >>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >> > wrote: >>> >>>> Cowboy has had Webmachine based REST for more than 2 years now. Am >>>> I missing something obvious that Webmachine has or are people >>>> simply not aware of the implementation in Cowboy? If there is >>>> something that can be improved I'd like to hear about it. >>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> >>>> -------- Original Message -------- >>>> From:Lee Sylvester >>> > Sent:Wed, 11 Jun 2014 17:58:48 >>>> +0200 To:Ivan Carmenates Garc?a >>> > Cc:erlang-questions@REDACTED >>>> >>>> Subject:Re: [erlang-questions] Which technology I should choose? >>>> >>>> I find Cowboy provides a lot of flexibility, but WebMachine >>>> provides a ?quick to market? solution. WebMachine also helps you >>>> build cleaner code. Mochiweb is useful, but since WebMachine is >>>> built on it, I?d say it?s WebMachine hands down. >>>> >>>> Lee >>>> >>>> >>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a >>>> > wrote: >>>> >>>>> Hi all, >>>>> I?ve been wondering if I could ask for an advice from the >>>>> community to help me choose a good tec for a project I am developing. >>>>> My primordial priority is not to be productive, I like pure Erlang >>>>> as it is, no dummy frameworks for productivity, I?m looking for >>>>> something clean and powerful at the same time, I already choose >>>>> Extjs >>>>> 4.2 for the view, because the project is about accounting and >>>>> statistics, and the graphics and visual that extjs gives is a very >>>>> nice and interesting fact. I have a weak choice for yaws for the >>>>> server at the time. >>>>> What I would like to know is if there is another web server better >>>>> than yaws to combine it with extjs, the idea is to export an API >>>>> REST or another kind of API that allows a good communication with >>>>> extjs using json, also that supports for web-socket or any >>>>> real-time server push technology, that is primordial since I need a real-time app, ex: >>>>> Chicago Boss have a very interesting mechanism to do that, since >>>>> it use a long-polling strategy, that is very interesting, the only >>>>> problem and almost impossible to deal with CB is the errors >>>>> formatting and definition. A good documentation is required too. >>>>> I hope someone can help me to decide. >>>>> I will appreciate all kind of suggestions. >>>>> Best regards, >>>>> Ivan. >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu > -- Lo?c Hoguin http://ninenines.eu From vinoski@REDACTED Thu Jun 12 18:45:39 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 12 Jun 2014 12:45:39 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <002a01cf865c$ba378e30$2ea6aa90$@frcuba.co.cu> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> <5399C429.6070300@ninenines.eu> <002a01cf865c$ba378e30$2ea6aa90$@frcuba.co.cu> Message-ID: There is no requirement in Yaws that you use embedded code. It's there if you want to use it in your app, as are a variety of other features, but nothing forces you to use it if you don't want to. --steve On Thu, Jun 12, 2014 at 12:38 PM, Ivan Carmenates Garc?a wrote: > Yes, I mean no embedded code like apache/php and yaws/erlang, a good and > separate logic, like using model, view, controller, > an example could be in the standard web design, using html, css and > javascript, the html file only content the struct, css file with the > style, and the combination of two is referring in the html file id classes > in css file, not embedding css code in the html, for the javascript part > even more careful, using add listener events in the js file over > registering events or embedding js code in the html. Something like that, I > really disgust embedded code I rather a thousand of times to build a > well-defined and separated logic. > > Regards, > Ivan. > > > > -----Mensaje original----- > De: Lo?c Hoguin [mailto:essen@REDACTED] > Enviado el: jueves, 12 de junio de 2014 11:16 a.m. > Para: Lee Sylvester > CC: Ivan Carmenates Garc?a; erlang-questions@REDACTED > Asunto: Re: [erlang-questions] Which technology I should choose? > > But what's this cleanliness you speak of? Can you provide some examples? > > On 06/12/2014 05:14 PM, Lee Sylvester wrote: > > I actually think Cowboy has the most potential. Mostly because Cowboy > receives the most frequent updates. However, I also love WebMachine and > it?s cleanliness. It would be good to have a secondary layer for Cowboy > one of these days, that helps scaffold complex but typical web server > requirements. I?ve been thinking quite a bit about it. > > > > Lee > > > > > > > > On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > > > >> No offense taken or anything. Just the way you say it makes it sound > like you didn't know about cowboy_rest. cowboy_rest implements the same > state machine as WebMachine, and the Cowboy router implements a similar > routing mechanism to WebMachine, so using Cowboy or WebMachine should be > equivalent for REST tasks, simple or not. It's the same callbacks and > concepts etc. > >> > >> (If you haven't guessed from this post, yes, WebMachine was a big > >> inspiration for many things in Cowboy.) > >> > >> On 06/12/2014 01:23 AM, Lee Sylvester wrote: > >>> Hey Lo?c, > >>> > >>> I meant nothing by it. I had to build a Socket.IO compatible server > >>> recently, and Cowboy was my first choice. I simply find WebMachine > >>> gets the job done when that job is a super simple task and I need > >>> full REST without thinking too hard about it. > >>> > >>> Lee > >>> > >>> > >>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >>> > wrote: > >>> > >>>> Cowboy has had Webmachine based REST for more than 2 years now. Am > >>>> I missing something obvious that Webmachine has or are people > >>>> simply not aware of the implementation in Cowboy? If there is > >>>> something that can be improved I'd like to hear about it. > >>>> > >>>> -- > >>>> Lo?c Hoguin > >>>> http://ninenines.eu > >>>> > >>>> -------- Original Message -------- > >>>> From:Lee Sylvester >>>> > Sent:Wed, 11 Jun 2014 17:58:48 > >>>> +0200 To:Ivan Carmenates Garc?a >>>> > Cc:erlang-questions@REDACTED > >>>> > >>>> Subject:Re: [erlang-questions] Which technology I should choose? > >>>> > >>>> I find Cowboy provides a lot of flexibility, but WebMachine > >>>> provides a ?quick to market? solution. WebMachine also helps you > >>>> build cleaner code. Mochiweb is useful, but since WebMachine is > >>>> built on it, I?d say it?s WebMachine hands down. > >>>> > >>>> Lee > >>>> > >>>> > >>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a > >>>> > wrote: > >>>> > >>>>> Hi all, > >>>>> I?ve been wondering if I could ask for an advice from the > >>>>> community to help me choose a good tec for a project I am developing. > >>>>> My primordial priority is not to be productive, I like pure Erlang > >>>>> as it is, no dummy frameworks for productivity, I?m looking for > >>>>> something clean and powerful at the same time, I already choose > >>>>> Extjs > >>>>> 4.2 for the view, because the project is about accounting and > >>>>> statistics, and the graphics and visual that extjs gives is a very > >>>>> nice and interesting fact. I have a weak choice for yaws for the > >>>>> server at the time. > >>>>> What I would like to know is if there is another web server better > >>>>> than yaws to combine it with extjs, the idea is to export an API > >>>>> REST or another kind of API that allows a good communication with > >>>>> extjs using json, also that supports for web-socket or any > >>>>> real-time server push technology, that is primordial since I need a > real-time app, ex: > >>>>> Chicago Boss have a very interesting mechanism to do that, since > >>>>> it use a long-polling strategy, that is very interesting, the only > >>>>> problem and almost impossible to deal with CB is the errors > >>>>> formatting and definition. A good documentation is required too. > >>>>> I hope someone can help me to decide. > >>>>> I will appreciate all kind of suggestions. > >>>>> Best regards, > >>>>> Ivan. > >>>>> _______________________________________________ > >>>>> erlang-questions mailing list > >>>>> erlang-questions@REDACTED > >>>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>> > >> > >> -- > >> Lo?c Hoguin > >> http://ninenines.eu > > > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From co7eb@REDACTED Thu Jun 12 19:38:45 2014 From: co7eb@REDACTED (=?UTF-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Thu, 12 Jun 2014 13:38:45 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> <5399C429.6070300@ninenines.eu> <002a01cf865c$ba378e30$2ea6aa90$@frcuba.co.cu> Message-ID: <002e01cf8665$2afa0140$80ee03c0$@frcuba.co.cu> Yes, that is a release, that why I choose yaws from the beginning, because despite of that fact it is so kind of free, but yet I needed to investigate more tecs to select the better one. Regards, Ivan. De: vinoski@REDACTED [mailto:vinoski@REDACTED] En nombre de Steve Vinoski Enviado el: jueves, 12 de junio de 2014 12:46 p.m. Para: Ivan Carmenates Garc?a CC: Lo?c Hoguin; Lee Sylvester; erlang-questions Asunto: Re: [erlang-questions] Which technology I should choose? There is no requirement in Yaws that you use embedded code. It's there if you want to use it in your app, as are a variety of other features, but nothing forces you to use it if you don't want to. --steve On Thu, Jun 12, 2014 at 12:38 PM, Ivan Carmenates Garc?a wrote: Yes, I mean no embedded code like apache/php and yaws/erlang, a good and separate logic, like using model, view, controller, an example could be in the standard web design, using html, css and javascript, the html file only content the struct, css file with the style, and the combination of two is referring in the html file id classes in css file, not embedding css code in the html, for the javascript part even more careful, using add listener events in the js file over registering events or embedding js code in the html. Something like that, I really disgust embedded code I rather a thousand of times to build a well-defined and separated logic. Regards, Ivan. -----Mensaje original----- De: Lo?c Hoguin [mailto:essen@REDACTED] Enviado el: jueves, 12 de junio de 2014 11:16 a.m. Para: Lee Sylvester CC: Ivan Carmenates Garc?a; erlang-questions@REDACTED Asunto: Re: [erlang-questions] Which technology I should choose? But what's this cleanliness you speak of? Can you provide some examples? On 06/12/2014 05:14 PM, Lee Sylvester wrote: > I actually think Cowboy has the most potential. Mostly because Cowboy receives the most frequent updates. However, I also love WebMachine and it?s cleanliness. It would be good to have a secondary layer for Cowboy one of these days, that helps scaffold complex but typical web server requirements. I?ve been thinking quite a bit about it. > > Lee > > > > On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > >> No offense taken or anything. Just the way you say it makes it sound like you didn't know about cowboy_rest. cowboy_rest implements the same state machine as WebMachine, and the Cowboy router implements a similar routing mechanism to WebMachine, so using Cowboy or WebMachine should be equivalent for REST tasks, simple or not. It's the same callbacks and concepts etc. >> >> (If you haven't guessed from this post, yes, WebMachine was a big >> inspiration for many things in Cowboy.) >> >> On 06/12/2014 01:23 AM, Lee Sylvester wrote: >>> Hey Lo?c, >>> >>> I meant nothing by it. I had to build a Socket.IO compatible server >>> recently, and Cowboy was my first choice. I simply find WebMachine >>> gets the job done when that job is a super simple task and I need >>> full REST without thinking too hard about it. >>> >>> Lee >>> >>> >>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >> > wrote: >>> >>>> Cowboy has had Webmachine based REST for more than 2 years now. Am >>>> I missing something obvious that Webmachine has or are people >>>> simply not aware of the implementation in Cowboy? If there is >>>> something that can be improved I'd like to hear about it. >>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> >>>> -------- Original Message -------- >>>> From:Lee Sylvester >>> > Sent:Wed, 11 Jun 2014 17:58:48 >>>> +0200 To:Ivan Carmenates Garc?a >>> > Cc:erlang-questions@REDACTED >>>> >>>> Subject:Re: [erlang-questions] Which technology I should choose? >>>> >>>> I find Cowboy provides a lot of flexibility, but WebMachine >>>> provides a ?quick to market? solution. WebMachine also helps you >>>> build cleaner code. Mochiweb is useful, but since WebMachine is >>>> built on it, I?d say it?s WebMachine hands down. >>>> >>>> Lee >>>> >>>> >>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a >>>> > wrote: >>>> >>>>> Hi all, >>>>> I?ve been wondering if I could ask for an advice from the >>>>> community to help me choose a good tec for a project I am developing. >>>>> My primordial priority is not to be productive, I like pure Erlang >>>>> as it is, no dummy frameworks for productivity, I?m looking for >>>>> something clean and powerful at the same time, I already choose >>>>> Extjs >>>>> 4.2 for the view, because the project is about accounting and >>>>> statistics, and the graphics and visual that extjs gives is a very >>>>> nice and interesting fact. I have a weak choice for yaws for the >>>>> server at the time. >>>>> What I would like to know is if there is another web server better >>>>> than yaws to combine it with extjs, the idea is to export an API >>>>> REST or another kind of API that allows a good communication with >>>>> extjs using json, also that supports for web-socket or any >>>>> real-time server push technology, that is primordial since I need a real-time app, ex: >>>>> Chicago Boss have a very interesting mechanism to do that, since >>>>> it use a long-polling strategy, that is very interesting, the only >>>>> problem and almost impossible to deal with CB is the errors >>>>> formatting and definition. A good documentation is required too. >>>>> I hope someone can help me to decide. >>>>> I will appreciate all kind of suggestions. >>>>> Best regards, >>>>> Ivan. >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu > -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jun 12 19:56:10 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 12 Jun 2014 19:56:10 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <5399C2F6.5000101@ninenines.eu> References: <5399C2F6.5000101@ninenines.eu> Message-ID: On Thu, Jun 12, 2014 at 5:10 PM, Lo?c Hoguin wrote: > The simple nodejs example works because it's a nodejs example and not a > Javascript example. Someone who doesn't know Javascript (pretty much > equivalent to someone who doesn't know programming at all) won't understand > it. In particular it has a number of objects in it, and these are not what > you start learning a language with. > > No but the example is the *first* thing you see on the nodejs.org website and node.js is far more popular than Erlang. The first example just says "type this stuff in" and "give this command" - it's not *teaching* JS nor Node.js for that matter - that comes later. > Most people who look at Erlang necessarily have to learn a number of > things that people who look at nodejs don't. You can't dumb it down as much > as nodejs can. > I have no intention of dumbing down anything - what I want is a simple example that folks can type in and run. They don't need to understand it yet. I tried the node example and it worked and I still don't understand how it works. I'd have to read and understand all the code to do this - but this can come later ... > > The other issue would be that teaching someone to do that in Erlang would > be counter-productive. Do you really want to teach people to do that and > then tell them they're doing it wrong? Yes - I do want this. This is how education works. You start with the simple story and then tell people why it is wrong. Take physics, for example. Start with Newtonian mechanics, then relativistic, then quantum relativistic, ... Start by telling people functions in Erlang are pure, then tell them about ets and get/put I would also not start with examples that are wrong - it's easy to find examples that are correct. > I think the bigger difference here is that nodejs uses a scripting > language vs Erlang's compiled/run in a VM language. The examples could easily start with escript. Compiling should not change semantics only performance (which again is not the whole truth, but good enough to get started) > There's simply more to do and learn before you can start something. I can start things with a one liner > You have to compile the file. Not if it's an escript > You have to start the VM with the proper paths set. Like Java and Node > And so on. Since you have to do all that, why not explain it properly from > the beginning? > Simple examples should work out-of-the-box. And simple examples should be explained properly. > > That's why the Cowboy guide starts with building a release. I've run cowboy thousands of times (I use it a lot) and have *never* built a release. The only time I build a release is in products and this is the last thing I do, not the first. > It takes about five minutes to go from nothing to your first release > running a hello world application. A release might take five minutes - but you don't need a release to run hello world. Example: Type this in a file called hello.es #!/usr/bin/env escript main(_) -> io:format("Hello world~n"). Then give this commands $ escript ./hello.es I timed this it and it took me 17 seconds. If you have correctly installed Erlang this should work first time. How about a cowboy example in an escript that you can type in and run in less than one minute? - This might get you a large number of new users. > Of course that's not as fast as nodejs, but we simply can't go that fast > anyway. No we should go 10 times faster :-) > We're not a scripting language. escript is. Add: -mode(compile). To an escript and it *is* compiled > Still I think that's a pretty quick way to start. > > The chapter is here if you want to take a look and provide feedback: > http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ > > I think this would be excellent as an "Advanced usage" section. Your first paragraph says: Setting up a working Erlang application is a little more complex than for most other languages. The reason is that Erlang is designed to build systems and not just simple applications. I disagree - Erlang was designed for building systems AND simple applications. Also "most other languages" are complex to set up. (Actually the fast majority of things I write ARE simple, without releases and all that stuff. Releases are only for production quality run-forever stuff) (aside - setting up a working C application - ie one that runs forever and restarts after errors is *incredibly* difficult - so I'm not sure what your point of reference is here) In Garrett's talk at EUC and in Katie Miller's keynote, both speakers emphasised the importance of Erlang being not perceived as being complex and difficult to get started with. This is why I don't like first sentence in the "Getting started" guide. If I'd said that in the first line of my Erlang book my editor would have asked me if I actually wanted anybody to read the book. I'd have said "Getting started with cowboy is really really easy, just put this in a file ... and type this. ..." Once you've got started you can gradually introduce more complex ideas. And yes - I do use cowboy - but I don't build it in a release, and it can be booted from an escript and we can make examples that show this. Cheers /Joe > > On 06/12/2014 04:54 PM, Joe Armstrong wrote: > >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it >> with the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - >> using any of the well-known web >> servers in the background, unfortunately this has not been done, or if >> it has been done >> it's not easy to find the examples (or if there are examples I can't >> find them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn >> then from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could >> not find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for this. >> Cheers >> >> /Joe >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Jun 12 20:03:35 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 12 Jun 2014 14:03:35 -0400 Subject: [erlang-questions] Which technology I should choose? In-Reply-To: <002e01cf8665$2afa0140$80ee03c0$@frcuba.co.cu> References: <9F25B0C9-9443-4819-A1CE-06DA8D14FDEC@gmail.com> <53995D31.7020102@ninenines.eu> <8961A515-6DDD-4360-8097-FFAC7798B325@gmail.com> <5399C429.6070300@ninenines.eu> <002a01cf865c$ba378e30$2ea6aa90$@frcuba.co.cu> <002e01cf8665$2afa0140$80ee03c0$@frcuba.co.cu> Message-ID: Like I said in the beginning of this thread, if you're having problems with Yaws, I'd like to hear about them. I'm one of the 3 active developers/maintainers of Yaws. There's also the erlyaws mailing list if you need help or advice from other users: https://lists.sourceforge.net/lists/listinfo/erlyaws-list --steve On Thu, Jun 12, 2014 at 1:38 PM, Ivan Carmenates Garc?a wrote: > Yes, that is a release, that why I choose yaws from the beginning, because > despite of that fact it is so kind of free, but yet I needed to investigate > more tecs to select the better one. > > > > Regards, > > Ivan. > > > > > > > > *De:* vinoski@REDACTED [mailto:vinoski@REDACTED] *En nombre de *Steve > Vinoski > *Enviado el:* jueves, 12 de junio de 2014 12:46 p.m. > *Para:* Ivan Carmenates Garc?a > *CC:* Lo?c Hoguin; Lee Sylvester; erlang-questions > > *Asunto:* Re: [erlang-questions] Which technology I should choose? > > > > There is no requirement in Yaws that you use embedded code. It's there if > you want to use it in your app, as are a variety of other features, but > nothing forces you to use it if you don't want to. > > > > --steve > > > > On Thu, Jun 12, 2014 at 12:38 PM, Ivan Carmenates Garc?a < > co7eb@REDACTED> wrote: > > Yes, I mean no embedded code like apache/php and yaws/erlang, a good and > separate logic, like using model, view, controller, > an example could be in the standard web design, using html, css and > javascript, the html file only content the struct, css file with the > style, and the combination of two is referring in the html file id classes > in css file, not embedding css code in the html, for the javascript part > even more careful, using add listener events in the js file over > registering events or embedding js code in the html. Something like that, I > really disgust embedded code I rather a thousand of times to build a > well-defined and separated logic. > > Regards, > Ivan. > > > > -----Mensaje original----- > > De: Lo?c Hoguin [mailto:essen@REDACTED] > > Enviado el: jueves, 12 de junio de 2014 11:16 a.m. > > Para: Lee Sylvester > CC: Ivan Carmenates Garc?a; erlang-questions@REDACTED > > Asunto: Re: [erlang-questions] Which technology I should choose? > > > But what's this cleanliness you speak of? Can you provide some examples? > > On 06/12/2014 05:14 PM, Lee Sylvester wrote: > > I actually think Cowboy has the most potential. Mostly because Cowboy > receives the most frequent updates. However, I also love WebMachine and > it?s cleanliness. It would be good to have a secondary layer for Cowboy > one of these days, that helps scaffold complex but typical web server > requirements. I?ve been thinking quite a bit about it. > > > > Lee > > > > > > > > On 12 Jun 2014, at 08:56, Lo?c Hoguin wrote: > > > >> No offense taken or anything. Just the way you say it makes it sound > like you didn't know about cowboy_rest. cowboy_rest implements the same > state machine as WebMachine, and the Cowboy router implements a similar > routing mechanism to WebMachine, so using Cowboy or WebMachine should be > equivalent for REST tasks, simple or not. It's the same callbacks and > concepts etc. > >> > >> (If you haven't guessed from this post, yes, WebMachine was a big > >> inspiration for many things in Cowboy.) > >> > >> On 06/12/2014 01:23 AM, Lee Sylvester wrote: > >>> Hey Lo?c, > >>> > >>> I meant nothing by it. I had to build a Socket.IO compatible server > >>> recently, and Cowboy was my first choice. I simply find WebMachine > >>> gets the job done when that job is a super simple task and I need > >>> full REST without thinking too hard about it. > >>> > >>> Lee > >>> > >>> > >>> On 11 Jun 2014, at 17:21, Lo?c Hoguin >>> > wrote: > >>> > >>>> Cowboy has had Webmachine based REST for more than 2 years now. Am > >>>> I missing something obvious that Webmachine has or are people > >>>> simply not aware of the implementation in Cowboy? If there is > >>>> something that can be improved I'd like to hear about it. > >>>> > >>>> -- > >>>> Lo?c Hoguin > >>>> http://ninenines.eu > >>>> > >>>> -------- Original Message -------- > >>>> From:Lee Sylvester >>>> > Sent:Wed, 11 Jun 2014 17:58:48 > >>>> +0200 To:Ivan Carmenates Garc?a >>>> > Cc:erlang-questions@REDACTED > >>>> > >>>> Subject:Re: [erlang-questions] Which technology I should choose? > >>>> > >>>> I find Cowboy provides a lot of flexibility, but WebMachine > >>>> provides a ?quick to market? solution. WebMachine also helps you > >>>> build cleaner code. Mochiweb is useful, but since WebMachine is > >>>> built on it, I?d say it?s WebMachine hands down. > >>>> > >>>> Lee > >>>> > >>>> > >>>> On 11 Jun 2014, at 16:42, Ivan Carmenates Garc?a > >>>> > wrote: > >>>> > >>>>> Hi all, > >>>>> I?ve been wondering if I could ask for an advice from the > >>>>> community to help me choose a good tec for a project I am developing. > >>>>> My primordial priority is not to be productive, I like pure Erlang > >>>>> as it is, no dummy frameworks for productivity, I?m looking for > >>>>> something clean and powerful at the same time, I already choose > >>>>> Extjs > >>>>> 4.2 for the view, because the project is about accounting and > >>>>> statistics, and the graphics and visual that extjs gives is a very > >>>>> nice and interesting fact. I have a weak choice for yaws for the > >>>>> server at the time. > >>>>> What I would like to know is if there is another web server better > >>>>> than yaws to combine it with extjs, the idea is to export an API > >>>>> REST or another kind of API that allows a good communication with > >>>>> extjs using json, also that supports for web-socket or any > >>>>> real-time server push technology, that is primordial since I need a > real-time app, ex: > >>>>> Chicago Boss have a very interesting mechanism to do that, since > >>>>> it use a long-polling strategy, that is very interesting, the only > >>>>> problem and almost impossible to deal with CB is the errors > >>>>> formatting and definition. A good documentation is required too. > >>>>> I hope someone can help me to decide. > >>>>> I will appreciate all kind of suggestions. > >>>>> Best regards, > >>>>> Ivan. > >>>>> _______________________________________________ > >>>>> erlang-questions mailing list > >>>>> erlang-questions@REDACTED > >>>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>> > >> > >> -- > >> Lo?c Hoguin > >> http://ninenines.eu > > > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jun 12 22:29:44 2014 From: erlang@REDACTED (rambocoder) Date: Thu, 12 Jun 2014 16:29:44 -0400 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: Joe, When I first heard about node, this book provided a gentle introduction by developing a web based calculator: http://www.packtpub.com/toc/node-web-development-table-contents The book is based on Node 0.4, so none of the examples will work out of the box with current node. The book started with canonical "Hello World" example, then it progressed by introducing a package manager and a section on how to make the "Hello World" app run as a daemon and have it autostart on a Linux server (similar to your http://www.sics.se/~joe/tutorials/web_server/web_server.html). I really liked the book's guide on "daemonizing" the basic node server (init.d script + forever) because it was such an easy win and within minutes I had the example running on my Linode. http://www.railstutorial.org/book/beginning a Ruby on Rails tutorial that does something similar by not just introducing ROR in the first chapter, but also getting me started with rvm, gem, git workflow and the free Heroku tier, so by the end of the chapter you have a basic hello world ROR application running on Heroku. After the "Hello World" example, the Node Web Development book shows how to render a basic table of contents web page with several calculator URLs. Each calculator URL is another example of generating HTML this time with a form and some injected values using string replace, no template language yet. Then the book proceeds to show how to do routing of URLs and parsing query strings, how to handle POST parameters and return results of calculations using just node, no 3rd party libraries. Once the basic calculator is developed, the author asks: "What complete web server features are missing?" and introduces Connect middleware. Logic code of the calculator remains intact, but web server startup and routing code get's rewritten to use Connect in addition to adding Connect's static content handling and Connect's logger. Once Connect based calculator is running, he introduces Express web framework and EJS templating engine, changing string based HTML generation into an EJS templates, rewriting routing into parametrized Express based routing and he adds Error pages. Before Cowboy, Misultin was all the rage, it provided short and sweet examples of simple applications in one Erlang file https://code.google.com/p/misultin/wiki/ExamplesPage and before Misultin, Mochiweb was the go to web server for one pager examples, such as http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1 and in Kevin Smith's screencasts http://pragprog.com/screencasts/v-kserl/source_code Episode 6, Adding REST using Mochiweb Cowboy "Hello World" can also be presented as 1 file, check out Elixir's Plug Hello World example, https://github.com/elixir-lang/plug/blob/master/README.md#hello-world I think it would be awesome to have an erlang tutorial that would teach how to build a web app while doing a compare and contrast to nodejs code. Cheers, rambocoder On Thu, Jun 12, 2014 at 10:54 AM, Joe Armstrong wrote: > Re: Garrett's great talk at EUC2014 > > The point has been made many times before that > "There are no easy Erlang getting started guides" > > So I thought I'd take a look at Node.js. > > The node js home page (node.js) starts with a simple example > > > > var http = require('http'); > http.createServer(function (req, res) { > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end('Hello World\n'); > }).listen(1337, '127.0.0.1'); > console.log('Server running at http://127.0.0.1:1337/'); > > To run the server, put the code into a file example.js and execute it with > the node program from the command line: > > % node example.js > Server running at http://127.0.0.1:1337/ > > > It's pretty easy to knock up an almost identical example in Erlang - using > any of the well-known web > servers in the background, unfortunately this has not been done, or if it > has been done > it's not easy to find the examples (or if there are examples I can't find > them) > > I was vaguely thinking of making some examples that are more-or-less > isomorphic to the > node.js examples and then applying small transformation steps to turn then > from idiomatic node.js code to idiomatic Erlang code. > > Although I could find a simple hello world example in node.js I could not > find a tutorial that > started with a simple example and then built on it in very small steps > adding routing, authentication, > database access and so on. > > Does anybody know of some examples of node.js that could be used for this. > > Cheers > > /Joe > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jun 12 23:08:33 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 12 Jun 2014 23:08:33 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: On Thu, Jun 12, 2014 at 10:29 PM, rambocoder wrote: > Joe, > > When I first heard about node, this book provided a gentle introduction by > developing a web based calculator: > > http://www.packtpub.com/toc/node-web-development-table-contents > > The book is based on Node 0.4, so none of the examples will work out of > the box with current node. > > The book started with canonical "Hello World" example, then it progressed > by introducing a package manager and a section on how to make the "Hello > World" app run as a daemon and have it autostart on a Linux server (similar > to your http://www.sics.se/~joe/tutorials/web_server/web_server.html). I > really liked the book's guide on "daemonizing" the basic node server > (init.d script + forever) because it was such an easy win and within > minutes I had the example running on my Linode. > http://www.railstutorial.org/book/beginning a Ruby on Rails tutorial that > does something similar by not just introducing ROR in the first chapter, > but also getting me started with rvm, gem, git workflow and the free Heroku > tier, so by the end of the chapter you have a basic hello world ROR > application running on Heroku. > > After the "Hello World" example, the Node Web Development book shows how > to render a basic table of contents web page with several calculator URLs. > Each calculator URL is another example of generating HTML this time with a > form and some injected values using string replace, no template language > yet. > > Then the book proceeds to show how to do routing of URLs and parsing query > strings, how to handle POST parameters and return results of calculations > using just node, no 3rd party libraries. > > Once the basic calculator is developed, the author asks: "What complete > web server features are missing?" and introduces Connect middleware. Logic > code of the calculator remains intact, but web server startup and routing > code get's rewritten to use Connect in addition to adding Connect's static > content handling and Connect's logger. Once Connect based calculator is > running, he introduces Express web framework and EJS templating engine, > changing string based HTML generation into an EJS templates, rewriting > routing into parametrized Express based routing and he adds Error pages. > > Before Cowboy, Misultin was all the rage, it provided short and sweet > examples of simple applications in one Erlang file > https://code.google.com/p/misultin/wiki/ExamplesPage and before Misultin, > Mochiweb was the go to web server for one pager examples, such as > http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1 > and in Kevin Smith's screencasts > http://pragprog.com/screencasts/v-kserl/source_code Episode 6, Adding > REST using Mochiweb > > Cowboy "Hello World" can also be presented as 1 file, check out Elixir's > Plug Hello World example, > https://github.com/elixir-lang/plug/blob/master/README.md#hello-world > *very* interesting - uses cowboy :-) Now why can't we do that? - this code is also superficially similar to the node version not a bad thing I think. > > I think it would be awesome to have an erlang tutorial that would teach > how to build a web app while doing a compare and contrast to nodejs code. > Absolutely - I'd like to learn node *properly* - run to completion in a callback is the very "interesting" idea (pre 1957 if the wikipedia is correct). (Time sharing was invented while people were waiting for jobs to complete :-) /Joe > > Cheers, > > rambocoder > > > > On Thu, Jun 12, 2014 at 10:54 AM, Joe Armstrong wrote: > >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it >> with the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - >> using any of the well-known web >> servers in the background, unfortunately this has not been done, or if it >> has been done >> it's not easy to find the examples (or if there are examples I can't find >> them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn >> then from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could not >> find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for this. >> >> Cheers >> >> /Joe >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahe.sanath@REDACTED Fri Jun 13 02:41:22 2014 From: ahe.sanath@REDACTED (Sanath Prasanna) Date: Fri, 13 Jun 2014 06:11:22 +0530 Subject: [erlang-questions] Fwd: Diameter Encoding Problem In-Reply-To: References: Message-ID: Any help ? ---------- Forwarded message ---------- From: Sanath Prasanna Date: Thu, Jun 12, 2014 at 8:38 AM Subject: Diameter Encoding Problem To: erlang-questions Hi, Pls help to resolve below error. =ERROR REPORT==== 12-Jun-2014::08:22:05 === * why: {diameter_codec,encode,* * {{encode_failure,undef,'CCR',* * [{diameter_gen_base_rfc6733,avp_header,['Session-Id'],[]},* {rfc4006_cc_Gy,e,2, [{file, "i:diameter-1.0/include/diameter_gen.hrl"}, {line,105}]}, {lists,flatmap,2,[{file,"lists.erl"},{line,1184}]}, {rfc4006_cc_Gy,encode_avps,2, [{file, "i:diameter-1.0/include/diameter_gen.hrl"}, Sample Code Below: client:start(). client:create_session(No). create_session(No) -> SId = diameter:session_id(?L(?SVC_NAME)), CCR = #rfc4006_cc_Gy_CCR{ 'Session-Id' = SId, 'Origin-Host' = ?ORIGIN_HOST, 'Origin-Realm' = ?ORIGIN_REALM, 'Destination-Realm' = ?DEST_REALM, 'Auth-Application-Id' = 4, 'Service-Context-Id' = ?CONTEXT_ID, 'CC-Request-Type' = 4, 'CC-Request-Number' = 0, %%'Event-Timestamp' = [ erlang:localtime()], 'Subscription-Id' = [#'rfc4006_cc_Gy_Subscription-Id' { 'Subscription-Id-Type' = 0, 'Subscription-Id-Data' = No}], 'Requested-Service-Unit' = [0], 'Requested-Action' = 0}, io:fwrite("connect ~p~n",[{CCR}]), diameter:call(?SVC_NAME, ?APP_ALIAS, CCR, []). Br, Sanath -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelr1@REDACTED Fri Jun 13 02:58:21 2014 From: joelr1@REDACTED (Joel Reymont) Date: Fri, 13 Jun 2014 08:58:21 +0800 Subject: [erlang-questions] ejabberd expert Message-ID: Folks, I'm looking for an ejabberd expert, ideally in California. Would you get in touch if you are one and let me know your hourly rate? I'm looking for experience with writing ejabberd modules. Thanks, Joel -- firmware & device drivers http://wagerlabs.com/about From roger@REDACTED Fri Jun 13 09:13:11 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 13 Jun 2014 08:13:11 +0100 Subject: [erlang-questions] Atomically replace named process? In-Reply-To: <5399CE9C.8050507@gmail.com> References: <539814FF.8090204@gmail.com> <5399CE9C.8050507@gmail.com> Message-ID: These are all really useful things, thanks. As it happens, however, my problem was with a live system, so code changes to the existing clients or original gen_server wasn't possible -- I couldn't persuade the gen_server to suspend (because of a full message queue), so code swapping was difficult. I _almost_ got it working (in test), but in the end, we decided to snaffle the message queue (by using process_info/2), throw it to disk (using disk_log), restart the node and deal with the old messages using some escript. On 12 June 2014 17:00, Michael Truog wrote: > Yes, gproc and ets could be used if you are only using a single Erlang node. > > > On 06/12/2014 07:06 AM, Bob Ippolito wrote: > > Using gproc (or even just ets) is also a solution. Whether you need the > names to be redundant or not, using ets instead of the process registry will > allow you to replace them atomically. > > On Wednesday, June 11, 2014, Michael Truog wrote: >> >> If you need redundant process names, you should probably look at pg2 >> (http://www.erlang.org/doc/man/pg2.html) or cpg >> (https://github.com/okeuday/cpg/). >> >> On 06/11/2014 12:17 AM, Roger Lipscombe wrote: >>> >>> I've got a gen_server with a particular name. I've got a bunch of >>> other processes calling and casting to it, by name. >>> >>> Can I spin up another gen_server, and have the name transferred >>> without anyone noticing? That is: can I redirect the calls and casts >>> to the new process without interruption? >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From roger@REDACTED Fri Jun 13 09:26:59 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 13 Jun 2014 08:26:59 +0100 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: On 12 June 2014 22:08, Joe Armstrong wrote: > On Thu, Jun 12, 2014 at 10:29 PM, rambocoder wrote: >> Cowboy "Hello World" can also be presented as 1 file, check out Elixir's >> Plug Hello World example, >> https://github.com/elixir-lang/plug/blob/master/README.md#hello-world > > > *very* interesting - uses cowboy :-) > > Now why can't we do that? - this code is also superficially similar to the > node version > not a bad thing I think. The immediate problem is that cowboy uses Erlang modules to inplement handlers, and those are hard (impossible?) to do in escript. Any more than that, and you've basically got the cowboy hello world example. The problem with kids these days is that if it's not a web app, they're not interested. So, the step from io:format("Hello World~n") to even a simple web server _is_ a step; it's not a gentle slope. What other examples could we come up with that bridge that gap? -- Roger. From erlangsiri@REDACTED Fri Jun 13 09:58:34 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 13 Jun 2014 09:58:34 +0200 Subject: [erlang-questions] code_server and ERL_LIBS: bug or feature? In-Reply-To: References: Message-ID: Hi Serge, the embedded mode has always been this way, and I think it is the desired behaviour. In embedded mode, all code is loaded during system start-up according to the boot script (where all required paths are specified). There is no dynamic code loading in this mode. In some (debugging) cases you might want to load code which is not part of your release (i.e. not specified in the boot script). This is still possible, but then you need to explicitly add the paths using code:add_path and friends. Regards /siri 2014-06-10 21:35 GMT+02:00 Serge Aleynikov : > When trying to start a node with the "-mode embedded" command-line option > I noticed that ERL_LIBS environment variable setting gets ignored. Has > this always been this way or it is a recent change? Is this the desired > behavior? > > The culprit is in the code_server:add_loader_path/2 function. > > Serge > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Fri Jun 13 11:05:15 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 13 Jun 2014 11:05:15 +0200 Subject: [erlang-questions] How does a match context of an erlang bitstring work? In-Reply-To: References: Message-ID: On Thu, Jun 12, 2014 at 4:47 PM, ami wrote: > Hi all > > I'd read [efficiency guide][1] and [erlang-questions mailing list archive][2] & > all of the available books in erlang. But I haven't found the precise description of efficient > binaries pattern matching. Though, I haven't read sources yet :) But I hope > that people, who already have read them, would read this post. Here are my questions. > > > 1. How many match contexts does an erlang binary have? > In general, a match context is created for every "<<" and destroyed at ">>". The exception is if the last thing matched is a binary, in which case the match context can be retained in certain cases (delayed sub-binary creation). For example: <<..., T/binary>> = Var, <<...>> = T > a) if we match parts of a binary sequentially and just once > > A = <<1,2,3,4>>. > <> = A. > > Do we have just one binary match context(moving from the beginning of A to the end), or four? One. > b) if we match parts of a binary sequentially from the beginning to the end for the first time > and(sequentially again) from the beginning to the end for the second time > > B = <<1,2,3,4>>. > <> = B. > <> = B. > > Do we have just a single match context, which is moving from the beginning of B to the end > of B and then moving again from the beginning of B to the end of B, No. > or > > we have 2 match contexts, one is moving from the beginning of B to the end of B, > and another - again from the beginning of B to the end of B (as first can't move > to the beginning again) Yes. > or we have 8 match contexts? No. > > 2. According to [documentation][3], if I write: > > my_binary_to_list(<>) -> > [H|my_binary_to_list(T)]; > my_binary_to_list(<<>>) -> []. > > there will be only 1 match context for the whole recursion tree, even though, this > function isn't tail-recursive. > > a) Did I get it right, that there would be only 1 match context in this case? > Yes. > b) Did I get right, that if I match an erlang binary sequentially(from the beginning to > the end), it doesn't matter which recursion type(tail or body) has to be used?(from the binary-matching efficiency point of view) Yes. > > c) What if I'm going to process erlang binary NOT sequentially, say, I'm travelling through > a binary - first I match first byte, then 1000th, then 5th, then 10001th, then 10th... > > In this case, > > d1) If I used body-recursion, how many matching contexts for this binary would I have - > one or >1? > > d2) if I used tail-recursion, how many matching contexts for this binary would I have - > one or >1? It depends on your code. Potentially one match context could be enough. Use the bin_opt_info option to find out. > > 3. If I pass a large binary(say 1 megabyte) via tail recursion, Will all the 1 megabyte data be copied? Or only a some kind of pointer to the beginning of this binary is being passed between calls? Only a pointer. It doesn't matter whether you use tail-recursion or not. In general, binaries are not copied, especially not big binaries. (Binaries no more than 64 bytes in size may be stored on the process heap and they will be copied when sent to another process or stored in ETS tables.) > 4. Does it matter which binary I'm matching - big or small - a match context will be created for binary of any size or only for large ones? It doesn't matter. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mrtndimitrov@REDACTED Fri Jun 13 12:30:28 2014 From: mrtndimitrov@REDACTED (Martin Koroudjiev) Date: Fri, 13 Jun 2014 13:30:28 +0300 Subject: [erlang-questions] Problems with dynamically compiled eunit test In-Reply-To: <539938B3.90903@gmail.com> References: <539938B3.90903@gmail.com> Message-ID: <539AD2C4.3040105@gmail.com> Just for the record. It turned out I had a module in the code path called eunit_test. There is a module called the same in eunit lib. Martin On 6/12/2014 8:20 AM, Martin Koroudjiev wrote: > Hello, > > I've used eunit framework many times before with no problems but now I > try to compile dynamically a test module and to run the tests. I get > this error: > > undefined > *unexpected termination of test process* > ::{undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]}, > {eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]}, > {eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]}, > {eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line,530}]}, > {eunit_data,group,1,[{file,[...]},{line,...}]}, > {eunit_data,next,1,[{file,...},{...}]}, > {eunit_data,iter_next,1,[{...}|...]}, > {eunit_proc,get_next_item,1,[...]}]} > > ======================================================= > Failed: 0. Skipped: 0. Passed: 0. > One or more tests were cancelled. > > =ERROR REPORT==== 12-Jun-2014::08:10:16 === > Error in process <0.185.0> on node 'dilbert@REDACTED' with exit value: > {undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]},{eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]},{eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]},{eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line... > > > error > > The test module is the fib example from the doc page: > > -module(my_test). > > -include_lib("eunit/include/eunit.hrl"). > > -export([fib/1]). > > fib(0) -> 1; > fib(1) -> 1; > fib(N) when N > 1 -> fib(N-1) + fib(N-2). > > fib_test_() -> > [?_assert(fib(0) =:= 1), > ?_assert(fib(1) =:= 1), > ?_assert(fib(2) =:= 2), > ?_assert(fib(3) =:= 3), > ?_assert(fib(4) =:= 5), > ?_assert(fib(5) =:= 8), > ?_assertException(error, function_clause, fib(-1)), > ?_assert(fib(31) =:= 2178309) > ]. > > Does anyone know what can be wrong? Thanks in advance for your time. > > Regards, > Martin From stamarit@REDACTED Fri Jun 13 13:57:14 2014 From: stamarit@REDACTED (Salvador Tamarit) Date: Fri, 13 Jun 2014 13:57:14 +0200 Subject: [erlang-questions] Call for bugs Message-ID: Hi all, we are working in an alternative debugger for Erlang based on the concept of declarative debugging. We have found some difficulties finding interesting buggy programs to test our tool, so we think that maybe you all can help us in this. We will need examples of buggy functions or modules or, if it exits, a place where there is a collection of them. Also any bug that you remember that was difficult to solve in order to try to reproduce it again in a new program. We are more interested in bugs that Dialyzer can't find, because the intention of the tool is to help to find bugs after running Dialyzer. Thanks in advance for your collaboration. Salvador Tamarit -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Fri Jun 13 16:02:42 2014 From: shayan@REDACTED (Shayan Pooya) Date: Fri, 13 Jun 2014 10:02:42 -0400 Subject: [erlang-questions] Call for bugs In-Reply-To: References: Message-ID: Hello, I occasionally see some errors that I am a little surprised that dialyzer did not catch. For example these commits are fixing some issues that could have been caught by type analysis but dialyzer did not catch them: 1. https://github.com/discoproject/disco/commit/78e388020 2. https://github.com/discoproject/disco/commit/57953a9d29420 3. https://github.com/discoproject/disco/commit/8550179b5efb44 4. https://github.com/discoproject/disco/commit/1b7bfc4161f37 On Fri, Jun 13, 2014 at 7:57 AM, Salvador Tamarit < stamarit@REDACTED> wrote: > Hi all, > > we are working in an alternative debugger for Erlang based on the concept > of declarative debugging. We have found some difficulties finding > interesting buggy programs to test our tool, so we think that maybe you all > can help us in this. We will need examples of buggy functions or modules > or, if it exits, a place where there is a collection of them. Also any bug > that you remember that was difficult to solve in order to try to reproduce > it again in a new program. We are more interested in bugs that Dialyzer > can't find, because the intention of the tool is to help to find bugs after > running Dialyzer. > > Thanks in advance for your collaboration. > Salvador Tamarit > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Jun 13 17:00:44 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Jun 2014 17:00:44 +0200 Subject: [erlang-questions] Call for bugs In-Reply-To: References: Message-ID: <24FF92F8-6270-46CB-99D8-EC27E957A6AA@gmail.com> http://erlang.org/pipermail/erlang-bugs/2014-May/004408.html https://github.com/nox/otp/commit/a10a7979887403ea61c30155cef18aa7324420a6 -- Anthony Ramine Le 13 juin 2014 ? 13:57, Salvador Tamarit a ?crit : > Hi all, > > we are working in an alternative debugger for Erlang based on the concept of declarative debugging. We have found some difficulties finding interesting buggy programs to test our tool, so we think that maybe you all can help us in this. We will need examples of buggy functions or modules or, if it exits, a place where there is a collection of them. Also any bug that you remember that was difficult to solve in order to try to reproduce it again in a new program. We are more interested in bugs that Dialyzer can't find, because the intention of the tool is to help to find bugs after running Dialyzer. > > Thanks in advance for your collaboration. > Salvador Tamarit > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paulo.ferraz.oliveira@REDACTED Fri Jun 13 14:39:15 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Fri, 13 Jun 2014 13:39:15 +0100 Subject: [erlang-questions] Problems with dynamically compiled eunit test In-Reply-To: <539AD2C4.3040105@gmail.com> References: <539938B3.90903@gmail.com> <539AD2C4.3040105@gmail.com> Message-ID: Something similar happened to me recently, while using Cowboy as a dependency. I had the following in rebar.config: {erl_opts, [{src_dirs, ["src", "test", ... which made both my application's and all my dependencies' "src" and "test" folder be compiled leading to a "module already present/compiled"-like exception. I changed rebar.config to: {erl_opts, [{src_dirs, ["src", "../myapp/test", ... which, probably not being the best solution, at least solved my problem. Cheers. - Paulo F. Oliveira On 13 June 2014 11:30, Martin Koroudjiev wrote: > Just for the record. > > It turned out I had a module in the code path called eunit_test. There > is a module called the same in eunit lib. > > Martin > > On 6/12/2014 8:20 AM, Martin Koroudjiev wrote: > > Hello, > > > > I've used eunit framework many times before with no problems but now I > > try to compile dynamically a test module and to run the tests. I get > > this error: > > > > undefined > > *unexpected termination of test process* > > ::{undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]}, > > {eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]}, > > {eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]}, > > {eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line,530}]}, > > {eunit_data,group,1,[{file,[...]},{line,...}]}, > > {eunit_data,next,1,[{file,...},{...}]}, > > {eunit_data,iter_next,1,[{...}|...]}, > > {eunit_proc,get_next_item,1,[...]}]} > > > > ======================================================= > > Failed: 0. Skipped: 0. Passed: 0. > > One or more tests were cancelled. > > > > =ERROR REPORT==== 12-Jun-2014::08:10:16 === > > Error in process <0.185.0> on node 'dilbert@REDACTED' with exit value: > > > {undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]},{eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]},{eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]},{eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line... > > > > > > error > > > > The test module is the fib example from the doc page: > > > > -module(my_test). > > > > -include_lib("eunit/include/eunit.hrl"). > > > > -export([fib/1]). > > > > fib(0) -> 1; > > fib(1) -> 1; > > fib(N) when N > 1 -> fib(N-1) + fib(N-2). > > > > fib_test_() -> > > [?_assert(fib(0) =:= 1), > > ?_assert(fib(1) =:= 1), > > ?_assert(fib(2) =:= 2), > > ?_assert(fib(3) =:= 3), > > ?_assert(fib(4) =:= 5), > > ?_assert(fib(5) =:= 8), > > ?_assertException(error, function_clause, fib(-1)), > > ?_assert(fib(31) =:= 2178309) > > ]. > > > > Does anyone know what can be wrong? Thanks in advance for your time. > > > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon@REDACTED Fri Jun 13 17:58:02 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Fri, 13 Jun 2014 16:58:02 +0100 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: I have taken a bit more radical approach. People traditionally comparing Erlang to other languages - and Erlang loses because of its weak spot - it has a prolog syntax in a world dominated by c-like syntaxes. I decided to compare Erlang/OTP with other ways of building multi-machine clusters. Here's my hell world attempt: http://erlangotp.com Thoughts comments, welcome Gordon On 12/06/2014, Mark Allen wrote: > I started http://introducingerlang.com right after EF2014 in San Francisco. > It's intended to be a really short and simple introduction to Erlang for > people who know how to program in other languages but don't know Erlang. I > have a mostly documented OTP application (uses Gordon Guthrie's "literate > Erlang" markup) with a supervisor, gen_server and application modules here: > > https://github.com/introducingerlang/todolist/tree/master/src_md > > I would welcome any help finishing the documentation of the modules in that > repo or extending/correcting/fixing the web content that's already there. I > can add you directly to the github organization. > > Thanks, > > Mark > > From: Joe Armstrong > > Date: Thursday, June 12, 2014 9:54 AM > To: Erlang > > > Subject: [erlang-questions] Beginners tutorials > > Re: Garrett's great talk at EUC2014 > > The point has been made many times before that > "There are no easy Erlang getting started guides" > > So I thought I'd take a look at Node.js. > > The node js home page (node.js) starts with a simple example > > > > var http = require('http'); > http.createServer(function (req, res) { > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end('Hello World\n'); > }).listen(1337, '127.0.0.1'); > console.log('Server running at http://127.0.0.1:1337/'); > > To run the server, put the code into a file example.js and execute it with > the node program from the command line: > > % node example.js > Server running at http://127.0.0.1:1337/ > > > It's pretty easy to knock up an almost identical example in Erlang - using > any of the well-known web > servers in the background, unfortunately this has not been done, or if it > has been done > it's not easy to find the examples (or if there are examples I can't find > them) > > I was vaguely thinking of making some examples that are more-or-less > isomorphic to the > node.js examples and then applying small transformation steps to turn then > from idiomatic node.js code to idiomatic Erlang code. > > Although I could find a simple hello world example in node.js I could not > find a tutorial that > started with a simple example and then built on it in very small steps > adding routing, authentication, > database access and so on. > > Does anybody know of some examples of node.js that could be used for this. > > Cheers > > /Joe > > -- Gordon Guthrie CEO hypernumbers http://hypernumbers.com t: hypernumbers +44 7776 251669 From lloyd@REDACTED Fri Jun 13 18:20:56 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Fri, 13 Jun 2014 12:20:56 -0400 (EDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: <1402676456.792632261@apps.rackspace.com> Outstanding! Lloyd -----Original Message----- From: "Gordon Guthrie" Sent: Friday, June 13, 2014 11:58am To: "Mark Allen" Cc: "Erlang" Subject: Re: [erlang-questions] Beginners tutorials I have taken a bit more radical approach. People traditionally comparing Erlang to other languages - and Erlang loses because of its weak spot - it has a prolog syntax in a world dominated by c-like syntaxes. I decided to compare Erlang/OTP with other ways of building multi-machine clusters. Here's my hell world attempt: http://erlangotp.com Thoughts comments, welcome Gordon On 12/06/2014, Mark Allen wrote: > I started http://introducingerlang.com right after EF2014 in San Francisco. > It's intended to be a really short and simple introduction to Erlang for > people who know how to program in other languages but don't know Erlang. I > have a mostly documented OTP application (uses Gordon Guthrie's "literate > Erlang" markup) with a supervisor, gen_server and application modules here: > > https://github.com/introducingerlang/todolist/tree/master/src_md > > I would welcome any help finishing the documentation of the modules in that > repo or extending/correcting/fixing the web content that's already there. I > can add you directly to the github organization. > > Thanks, > > Mark > > From: Joe Armstrong > > Date: Thursday, June 12, 2014 9:54 AM > To: Erlang > > > Subject: [erlang-questions] Beginners tutorials > > Re: Garrett's great talk at EUC2014 > > The point has been made many times before that > "There are no easy Erlang getting started guides" > > So I thought I'd take a look at Node.js. > > The node js home page (node.js) starts with a simple example > > > > var http = require('http'); > http.createServer(function (req, res) { > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end('Hello World\n'); > }).listen(1337, '127.0.0.1'); > console.log('Server running at http://127.0.0.1:1337/'); > > To run the server, put the code into a file example.js and execute it with > the node program from the command line: > > % node example.js > Server running at http://127.0.0.1:1337/ > > > It's pretty easy to knock up an almost identical example in Erlang - using > any of the well-known web > servers in the background, unfortunately this has not been done, or if it > has been done > it's not easy to find the examples (or if there are examples I can't find > them) > > I was vaguely thinking of making some examples that are more-or-less > isomorphic to the > node.js examples and then applying small transformation steps to turn then > from idiomatic node.js code to idiomatic Erlang code. > > Although I could find a simple hello world example in node.js I could not > find a tutorial that > started with a simple example and then built on it in very small steps > adding routing, authentication, > database access and so on. > > Does anybody know of some examples of node.js that could be used for this. > > Cheers > > /Joe > > -- Gordon Guthrie CEO hypernumbers http://hypernumbers.com t: hypernumbers +44 7776 251669 _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From tty.erlang@REDACTED Fri Jun 13 19:47:34 2014 From: tty.erlang@REDACTED (T Ty) Date: Fri, 13 Jun 2014 18:47:34 +0100 Subject: [erlang-questions] Problems with dynamically compiled eunit test In-Reply-To: <539AD2C4.3040105@gmail.com> References: <539938B3.90903@gmail.com> <539AD2C4.3040105@gmail.com> Message-ID: Glad you found the issue. My fav one is having a module called c.erl / c.beam. erts *does not* like that one at all! On Fri, Jun 13, 2014 at 11:30 AM, Martin Koroudjiev wrote: > Just for the record. > > It turned out I had a module in the code path called eunit_test. There > is a module called the same in eunit lib. > > Martin > > On 6/12/2014 8:20 AM, Martin Koroudjiev wrote: > > Hello, > > > > I've used eunit framework many times before with no problems but now I > > try to compile dynamically a test module and to run the tests. I get > > this error: > > > > undefined > > *unexpected termination of test process* > > ::{undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]}, > > {eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]}, > > {eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]}, > > {eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line,530}]}, > > {eunit_data,group,1,[{file,[...]},{line,...}]}, > > {eunit_data,next,1,[{file,...},{...}]}, > > {eunit_data,iter_next,1,[{...}|...]}, > > {eunit_proc,get_next_item,1,[...]}]} > > > > ======================================================= > > Failed: 0. Skipped: 0. Passed: 0. > > One or more tests were cancelled. > > > > =ERROR REPORT==== 12-Jun-2014::08:10:16 === > > Error in process <0.185.0> on node 'dilbert@REDACTED' with exit value: > > > {undef,[{eunit_test,mf_wrapper,[my_test,fib_test_],[]},{eunit_data,parse,1,[{file,"eunit_data.erl"},{line,245}]},{eunit_data,next,1,[{file,"eunit_data.erl"},{line,170}]},{eunit_data,lookahead,1,[{file,"eunit_data.erl"},{line... > > > > > > error > > > > The test module is the fib example from the doc page: > > > > -module(my_test). > > > > -include_lib("eunit/include/eunit.hrl"). > > > > -export([fib/1]). > > > > fib(0) -> 1; > > fib(1) -> 1; > > fib(N) when N > 1 -> fib(N-1) + fib(N-2). > > > > fib_test_() -> > > [?_assert(fib(0) =:= 1), > > ?_assert(fib(1) =:= 1), > > ?_assert(fib(2) =:= 2), > > ?_assert(fib(3) =:= 3), > > ?_assert(fib(4) =:= 5), > > ?_assert(fib(5) =:= 8), > > ?_assertException(error, function_clause, fib(-1)), > > ?_assert(fib(31) =:= 2178309) > > ]. > > > > Does anyone know what can be wrong? Thanks in advance for your time. > > > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Jun 13 20:35:36 2014 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 13 Jun 2014 20:35:36 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: Great stuff - will tweet On Fri, Jun 13, 2014 at 5:58 PM, Gordon Guthrie wrote: > I have taken a bit more radical approach. > > People traditionally comparing Erlang to other languages - and Erlang > loses because of its weak spot - it has a prolog syntax in a world > dominated by c-like syntaxes. > > I decided to compare Erlang/OTP with other ways of building > multi-machine clusters. > > Here's my hell world attempt: > http://erlangotp.com > > Thoughts comments, welcome > > Gordon > > On 12/06/2014, Mark Allen wrote: > > I started http://introducingerlang.com right after EF2014 in San > Francisco. > > It's intended to be a really short and simple introduction to Erlang for > > people who know how to program in other languages but don't know Erlang. > I > > have a mostly documented OTP application (uses Gordon Guthrie's "literate > > Erlang" markup) with a supervisor, gen_server and application modules > here: > > > > https://github.com/introducingerlang/todolist/tree/master/src_md > > > > I would welcome any help finishing the documentation of the modules in > that > > repo or extending/correcting/fixing the web content that's already > there. I > > can add you directly to the github organization. > > > > Thanks, > > > > Mark > > > > From: Joe Armstrong > > > Date: Thursday, June 12, 2014 9:54 AM > > To: Erlang > > > > > Subject: [erlang-questions] Beginners tutorials > > > > Re: Garrett's great talk at EUC2014 > > > > The point has been made many times before that > > "There are no easy Erlang getting started guides" > > > > So I thought I'd take a look at Node.js. > > > > The node js home page (node.js) starts with a simple example > > > > > > > > var http = require('http'); > > http.createServer(function (req, res) { > > res.writeHead(200, {'Content-Type': 'text/plain'}); > > res.end('Hello World\n'); > > }).listen(1337, '127.0.0.1'); > > console.log('Server running at http://127.0.0.1:1337/'); > > > > To run the server, put the code into a file example.js and execute it > with > > the node program from the command line: > > > > % node example.js > > Server running at http://127.0.0.1:1337/ > > > > > > It's pretty easy to knock up an almost identical example in Erlang - > using > > any of the well-known web > > servers in the background, unfortunately this has not been done, or if it > > has been done > > it's not easy to find the examples (or if there are examples I can't find > > them) > > > > I was vaguely thinking of making some examples that are more-or-less > > isomorphic to the > > node.js examples and then applying small transformation steps to turn > then > > from idiomatic node.js code to idiomatic Erlang code. > > > > Although I could find a simple hello world example in node.js I could not > > find a tutorial that > > started with a simple example and then built on it in very small steps > > adding routing, authentication, > > database access and so on. > > > > Does anybody know of some examples of node.js that could be used for > this. > > > > Cheers > > > > /Joe > > > > > > > -- > Gordon Guthrie > CEO hypernumbers > > http://hypernumbers.com > t: hypernumbers > +44 7776 251669 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Fri Jun 13 20:59:53 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Fri, 13 Jun 2014 20:59:53 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: That is awesome! On Jun 13, 2014 5:58 PM, "Gordon Guthrie" wrote: > I have taken a bit more radical approach. > > People traditionally comparing Erlang to other languages - and Erlang > loses because of its weak spot - it has a prolog syntax in a world > dominated by c-like syntaxes. > > I decided to compare Erlang/OTP with other ways of building > multi-machine clusters. > > Here's my hell world attempt: > http://erlangotp.com > > Thoughts comments, welcome > > Gordon > > On 12/06/2014, Mark Allen wrote: > > I started http://introducingerlang.com right after EF2014 in San > Francisco. > > It's intended to be a really short and simple introduction to Erlang for > > people who know how to program in other languages but don't know Erlang. > I > > have a mostly documented OTP application (uses Gordon Guthrie's "literate > > Erlang" markup) with a supervisor, gen_server and application modules > here: > > > > https://github.com/introducingerlang/todolist/tree/master/src_md > > > > I would welcome any help finishing the documentation of the modules in > that > > repo or extending/correcting/fixing the web content that's already > there. I > > can add you directly to the github organization. > > > > Thanks, > > > > Mark > > > > From: Joe Armstrong > > > Date: Thursday, June 12, 2014 9:54 AM > > To: Erlang > > > > > Subject: [erlang-questions] Beginners tutorials > > > > Re: Garrett's great talk at EUC2014 > > > > The point has been made many times before that > > "There are no easy Erlang getting started guides" > > > > So I thought I'd take a look at Node.js. > > > > The node js home page (node.js) starts with a simple example > > > > > > > > var http = require('http'); > > http.createServer(function (req, res) { > > res.writeHead(200, {'Content-Type': 'text/plain'}); > > res.end('Hello World\n'); > > }).listen(1337, '127.0.0.1'); > > console.log('Server running at http://127.0.0.1:1337/'); > > > > To run the server, put the code into a file example.js and execute it > with > > the node program from the command line: > > > > % node example.js > > Server running at http://127.0.0.1:1337/ > > > > > > It's pretty easy to knock up an almost identical example in Erlang - > using > > any of the well-known web > > servers in the background, unfortunately this has not been done, or if it > > has been done > > it's not easy to find the examples (or if there are examples I can't find > > them) > > > > I was vaguely thinking of making some examples that are more-or-less > > isomorphic to the > > node.js examples and then applying small transformation steps to turn > then > > from idiomatic node.js code to idiomatic Erlang code. > > > > Although I could find a simple hello world example in node.js I could not > > find a tutorial that > > started with a simple example and then built on it in very small steps > > adding routing, authentication, > > database access and so on. > > > > Does anybody know of some examples of node.js that could be used for > this. > > > > Cheers > > > > /Joe > > > > > > > -- > Gordon Guthrie > CEO hypernumbers > > http://hypernumbers.com > t: hypernumbers > +44 7776 251669 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay@REDACTED Fri Jun 13 21:03:57 2014 From: jay@REDACTED (Jay Nelson) Date: Fri, 13 Jun 2014 13:03:57 -0600 Subject: [erlang-questions] How would you implement a blob store Message-ID: <0D72FBF4-B665-4A3D-A78B-40E01E3150CD@duomark.com> Joe wrote: > I want some opinions on how to implement a blob store. > I want a simple key-value store. > The *simplest* way I can think of is to use the file store > a blob with (hex) hash "a2e34a32..." gets stored in 2-level directory > structure in a file called a2/e3/a2e34a32 > Even this might have problems - for example is file:write_file/2 atomic? This is typically done by writing to a scratch area with a unique id, then moving the file on top of the existing or non-existing file with the destination key path. Move is typically atomic. > ? > The next simplest way I can think of is to make a single huge blob store > file (max 56GB) and use an ets table to map hashes to addresses in the file - > if this is a good idea or not would depend upon how well the host OS > handles sparse files and so on. The old-fashioned fixed-record length approach to data base implementation. ?????? You might want to look at https://github.com/krestenkrab/vbisect which is an implementation of a binary dictionary with variable-length binary keys and variable-length binary values. I am working on making the dictionary easily interchangeable with other erlang dictionaries and adding common_test + PropEr testing to validate the implementation in the ?cleanup? branch. I have future plans for principled blob/object mapping to enable pluggable storage in https://github.com/jaynel/vbisect. It is easily compatible with both rebar and erlang.mk (especially since it is just a single .erl file). The nice thing about a vbisect dictionary is that it is a single erlang binary and uses binary pattern-matching internally to find values. It contains a sorted tree of the keys and can find keys at the rate of > 25K/sec on my Early 2011 MacBook Pro quad core i7. Because the dictionaries are single binaries they can be shared by multicore, messaged easily to other processes on the same node, are true persistent data structures, and are easily read and written from files (even from within a larger file containing a collection of them). They do have the drawback of expensive modification, which could become large with large dictionaries. We have not tried to optimize modification yet, but I?m sure there are some ways to make it efficient using sub-binaries and pattern-matching carefully as it currently does. Kresten designed vbisect as an internal data structure to use inside Hanoi DB which is his erlang-only eleveldb replacement (https://krestenkrab/hanoidb) which might work as a solution as well. Leveraging Dmitry?s suggestion of partitioning the keyspace and using a separate vbisect dictionary for each allows for better distribution, concurrency and faster lookup, as well as smaller dictionaries to avoid the modification cost. Fiddling with a vbisect is probably the simplest solution since it looks like a binary blob and all the source is just a few hundred lines in a single file. jay From richard.youngkin@REDACTED Fri Jun 13 21:31:37 2014 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Fri, 13 Jun 2014 13:31:37 -0600 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: Ditto, I've been trying to put something along these lines together - now I don't have to. Thanks! P.S. this is a great thread, lot's of new information here for a newbie like me. Thanks to Joe Armstrong for starting it! On Fri, Jun 13, 2014 at 12:59 PM, Mark Nijhof < mark.nijhof@REDACTED> wrote: > That is awesome! > On Jun 13, 2014 5:58 PM, "Gordon Guthrie" wrote: > >> I have taken a bit more radical approach. >> >> People traditionally comparing Erlang to other languages - and Erlang >> loses because of its weak spot - it has a prolog syntax in a world >> dominated by c-like syntaxes. >> >> I decided to compare Erlang/OTP with other ways of building >> multi-machine clusters. >> >> Here's my hell world attempt: >> http://erlangotp.com >> >> Thoughts comments, welcome >> >> Gordon >> >> On 12/06/2014, Mark Allen wrote: >> > I started http://introducingerlang.com right after EF2014 in San >> Francisco. >> > It's intended to be a really short and simple introduction to Erlang for >> > people who know how to program in other languages but don't know >> Erlang. I >> > have a mostly documented OTP application (uses Gordon Guthrie's >> "literate >> > Erlang" markup) with a supervisor, gen_server and application modules >> here: >> > >> > https://github.com/introducingerlang/todolist/tree/master/src_md >> > >> > I would welcome any help finishing the documentation of the modules in >> that >> > repo or extending/correcting/fixing the web content that's already >> there. I >> > can add you directly to the github organization. >> > >> > Thanks, >> > >> > Mark >> > >> > From: Joe Armstrong > >> > Date: Thursday, June 12, 2014 9:54 AM >> > To: Erlang >> > > >> > Subject: [erlang-questions] Beginners tutorials >> > >> > Re: Garrett's great talk at EUC2014 >> > >> > The point has been made many times before that >> > "There are no easy Erlang getting started guides" >> > >> > So I thought I'd take a look at Node.js. >> > >> > The node js home page (node.js) starts with a simple example >> > >> > >> > >> > var http = require('http'); >> > http.createServer(function (req, res) { >> > res.writeHead(200, {'Content-Type': 'text/plain'}); >> > res.end('Hello World\n'); >> > }).listen(1337, '127.0.0.1'); >> > console.log('Server running at http://127.0.0.1:1337/'); >> > >> > To run the server, put the code into a file example.js and execute it >> with >> > the node program from the command line: >> > >> > % node example.js >> > Server running at http://127.0.0.1:1337/ >> > >> > >> > It's pretty easy to knock up an almost identical example in Erlang - >> using >> > any of the well-known web >> > servers in the background, unfortunately this has not been done, or if >> it >> > has been done >> > it's not easy to find the examples (or if there are examples I can't >> find >> > them) >> > >> > I was vaguely thinking of making some examples that are more-or-less >> > isomorphic to the >> > node.js examples and then applying small transformation steps to turn >> then >> > from idiomatic node.js code to idiomatic Erlang code. >> > >> > Although I could find a simple hello world example in node.js I could >> not >> > find a tutorial that >> > started with a simple example and then built on it in very small steps >> > adding routing, authentication, >> > database access and so on. >> > >> > Does anybody know of some examples of node.js that could be used for >> this. >> > >> > Cheers >> > >> > /Joe >> > >> > >> >> >> -- >> Gordon Guthrie >> CEO hypernumbers >> >> http://hypernumbers.com >> t: hypernumbers >> +44 7776 251669 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Jun 13 23:07:40 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Jun 2014 23:07:40 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: References: Message-ID: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> Hello, I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? Regards, -- Anthony Ramine Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > I have taken a bit more radical approach. > > People traditionally comparing Erlang to other languages - and Erlang > loses because of its weak spot - it has a prolog syntax in a world > dominated by c-like syntaxes. > > I decided to compare Erlang/OTP with other ways of building > multi-machine clusters. > > Here's my hell world attempt: > http://erlangotp.com > > Thoughts comments, welcome > > Gordon > > On 12/06/2014, Mark Allen wrote: >> I started http://introducingerlang.com right after EF2014 in San Francisco. >> It's intended to be a really short and simple introduction to Erlang for >> people who know how to program in other languages but don't know Erlang. I >> have a mostly documented OTP application (uses Gordon Guthrie's "literate >> Erlang" markup) with a supervisor, gen_server and application modules here: >> >> https://github.com/introducingerlang/todolist/tree/master/src_md >> >> I would welcome any help finishing the documentation of the modules in that >> repo or extending/correcting/fixing the web content that's already there. I >> can add you directly to the github organization. >> >> Thanks, >> >> Mark >> >> From: Joe Armstrong > >> Date: Thursday, June 12, 2014 9:54 AM >> To: Erlang >> > >> Subject: [erlang-questions] Beginners tutorials >> >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it with >> the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - using >> any of the well-known web >> servers in the background, unfortunately this has not been done, or if it >> has been done >> it's not easy to find the examples (or if there are examples I can't find >> them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn then >> from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could not >> find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for this. >> >> Cheers >> >> /Joe >> >> > > > -- > Gordon Guthrie > CEO hypernumbers > > http://hypernumbers.com > t: hypernumbers > +44 7776 251669 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Fri Jun 13 23:10:48 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 13 Jun 2014 23:10:48 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> Message-ID: Cool? Erlang? On Jun 13, 2014 11:08 PM, "Anthony Ramine" wrote: > Hello, > > I hope to not sound rude, but I can?t imagine any executive in their right > mind choosing Erlang with such an overly colloquial website ridden with > spelling mistakes. For starters, such a person will look up ? Cluster > System ?, to no avail. Why invent new terms? Why try too hard to be cool? > > Regards, > > -- > Anthony Ramine > > Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > > > I have taken a bit more radical approach. > > > > People traditionally comparing Erlang to other languages - and Erlang > > loses because of its weak spot - it has a prolog syntax in a world > > dominated by c-like syntaxes. > > > > I decided to compare Erlang/OTP with other ways of building > > multi-machine clusters. > > > > Here's my hell world attempt: > > http://erlangotp.com > > > > Thoughts comments, welcome > > > > Gordon > > > > On 12/06/2014, Mark Allen wrote: > >> I started http://introducingerlang.com right after EF2014 in San > Francisco. > >> It's intended to be a really short and simple introduction to Erlang for > >> people who know how to program in other languages but don't know > Erlang. I > >> have a mostly documented OTP application (uses Gordon Guthrie's > "literate > >> Erlang" markup) with a supervisor, gen_server and application modules > here: > >> > >> https://github.com/introducingerlang/todolist/tree/master/src_md > >> > >> I would welcome any help finishing the documentation of the modules in > that > >> repo or extending/correcting/fixing the web content that's already > there. I > >> can add you directly to the github organization. > >> > >> Thanks, > >> > >> Mark > >> > >> From: Joe Armstrong > > >> Date: Thursday, June 12, 2014 9:54 AM > >> To: Erlang > >> > > >> Subject: [erlang-questions] Beginners tutorials > >> > >> Re: Garrett's great talk at EUC2014 > >> > >> The point has been made many times before that > >> "There are no easy Erlang getting started guides" > >> > >> So I thought I'd take a look at Node.js. > >> > >> The node js home page (node.js) starts with a simple example > >> > >> > >> > >> var http = require('http'); > >> http.createServer(function (req, res) { > >> res.writeHead(200, {'Content-Type': 'text/plain'}); > >> res.end('Hello World\n'); > >> }).listen(1337, '127.0.0.1'); > >> console.log('Server running at http://127.0.0.1:1337/'); > >> > >> To run the server, put the code into a file example.js and execute it > with > >> the node program from the command line: > >> > >> % node example.js > >> Server running at http://127.0.0.1:1337/ > >> > >> > >> It's pretty easy to knock up an almost identical example in Erlang - > using > >> any of the well-known web > >> servers in the background, unfortunately this has not been done, or if > it > >> has been done > >> it's not easy to find the examples (or if there are examples I can't > find > >> them) > >> > >> I was vaguely thinking of making some examples that are more-or-less > >> isomorphic to the > >> node.js examples and then applying small transformation steps to turn > then > >> from idiomatic node.js code to idiomatic Erlang code. > >> > >> Although I could find a simple hello world example in node.js I could > not > >> find a tutorial that > >> started with a simple example and then built on it in very small steps > >> adding routing, authentication, > >> database access and so on. > >> > >> Does anybody know of some examples of node.js that could be used for > this. > >> > >> Cheers > >> > >> /Joe > >> > >> > > > > > > -- > > Gordon Guthrie > > CEO hypernumbers > > > > http://hypernumbers.com > > t: hypernumbers > > +44 7776 251669 > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Fri Jun 13 23:28:05 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Fri, 13 Jun 2014 17:28:05 -0400 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> Message-ID: <539B6CE5.9010204@meetinghouse.net> Anthony Ramine wrote: > Hello, > > I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? > > Regards, > Well, not to be rude - but what company in its right mind lets an executive make platform decisions (unless, of course we're talking a CTO - in which case what CTO in their right mind makes techno-business decisions based on a web site)? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lloyd@REDACTED Sat Jun 14 00:02:02 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Fri, 13 Jun 2014 18:02:02 -0400 (EDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> Message-ID: <1402696922.99018464@apps.rackspace.com> Sigh. Isn't there a more constructive way of pointing out spelling errors? This thread has clearly brought out the wide interest in and perceived need for introductory Erlang tutorials. Gordon Guthrie has put substantial creativity and some amount of work into his submission. Pure volunteer effort. Unless I've missed something, it's the only concrete submission so far. Why disparage it? Why discourage the next submission tickling someone's brain for fear that it will be dissed on erlang-questions? The target audiences for Erlang tutorials ranges far beyond executives. There's room for many styles and approaches ranging from whimsical to rigorous academic to to bottom-line justification aimed at audiences ranging from students to young engineers to start-up entrepreneurs to grey-beard IT execs and more. There are many learning styles and many ways of teaching. So my take, the more the merrier. Please, Anthony, it's your turn now to show us what you can do and how it can make a difference. All the best, Lloyd -----Original Message----- From: "Anthony Ramine" Sent: Friday, June 13, 2014 5:07pm To: "Gordon Guthrie" Cc: "Erlang" Subject: Re: [erlang-questions] Beginners tutorials Hello, I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? Regards, -- Anthony Ramine Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > I have taken a bit more radical approach. > > People traditionally comparing Erlang to other languages - and Erlang > loses because of its weak spot - it has a prolog syntax in a world > dominated by c-like syntaxes. > > I decided to compare Erlang/OTP with other ways of building > multi-machine clusters. > > Here's my hell world attempt: > http://erlangotp.com > > Thoughts comments, welcome > > Gordon > > On 12/06/2014, Mark Allen wrote: >> I started http://introducingerlang.com right after EF2014 in San Francisco. >> It's intended to be a really short and simple introduction to Erlang for >> people who know how to program in other languages but don't know Erlang. I >> have a mostly documented OTP application (uses Gordon Guthrie's "literate >> Erlang" markup) with a supervisor, gen_server and application modules here: >> >> https://github.com/introducingerlang/todolist/tree/master/src_md >> >> I would welcome any help finishing the documentation of the modules in that >> repo or extending/correcting/fixing the web content that's already there. I >> can add you directly to the github organization. >> >> Thanks, >> >> Mark >> >> From: Joe Armstrong > >> Date: Thursday, June 12, 2014 9:54 AM >> To: Erlang >> > >> Subject: [erlang-questions] Beginners tutorials >> >> Re: Garrett's great talk at EUC2014 >> >> The point has been made many times before that >> "There are no easy Erlang getting started guides" >> >> So I thought I'd take a look at Node.js. >> >> The node js home page (node.js) starts with a simple example >> >> >> >> var http = require('http'); >> http.createServer(function (req, res) { >> res.writeHead(200, {'Content-Type': 'text/plain'}); >> res.end('Hello World\n'); >> }).listen(1337, '127.0.0.1'); >> console.log('Server running at http://127.0.0.1:1337/'); >> >> To run the server, put the code into a file example.js and execute it with >> the node program from the command line: >> >> % node example.js >> Server running at http://127.0.0.1:1337/ >> >> >> It's pretty easy to knock up an almost identical example in Erlang - using >> any of the well-known web >> servers in the background, unfortunately this has not been done, or if it >> has been done >> it's not easy to find the examples (or if there are examples I can't find >> them) >> >> I was vaguely thinking of making some examples that are more-or-less >> isomorphic to the >> node.js examples and then applying small transformation steps to turn then >> from idiomatic node.js code to idiomatic Erlang code. >> >> Although I could find a simple hello world example in node.js I could not >> find a tutorial that >> started with a simple example and then built on it in very small steps >> adding routing, authentication, >> database access and so on. >> >> Does anybody know of some examples of node.js that could be used for this. >> >> Cheers >> >> /Joe >> >> > > > -- > Gordon Guthrie > CEO hypernumbers > > http://hypernumbers.com > t: hypernumbers > +44 7776 251669 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Sat Jun 14 00:34:12 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 13 Jun 2014 18:34:12 -0400 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <1402696922.99018464@apps.rackspace.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> <1402696922.99018464@apps.rackspace.com> Message-ID: On Fri, Jun 13, 2014 at 6:02 PM, wrote: > Sigh. > > Isn't there a more constructive way of pointing out spelling errors? > I see nothing wrong with Anthony's message. He's rightfully concerned with how the site appeals to people outside the community, and I agree with his concerns. > Please, Anthony, it's your turn now to show us what you can do and how it > can make a difference. Umm, maybe you didn't hear that Anthony was voted "Erlang User of the Year" earlier this week by the Erlang community. He's put more effort into improving Erlang than most, and there are a number of things in the system that work correctly for all of us due to his diligence and contributions. So, he's already shown us what he can do and how he can make a difference. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Jun 14 00:41:01 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Jun 2014 00:41:01 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <1402696922.99018464@apps.rackspace.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> <1402696922.99018464@apps.rackspace.com> Message-ID: <01273FC7-A1A6-422F-82A5-F595F5491338@gmail.com> Hello, I don?t think I have a problem with neither volunteer effort nor jokes. I have a problem when new terms are invented with vague definitions, when things are released too early before any editing, when authors make too many jokes and otherwise address me as if I were somewhat slow. About typos, I suggest Gordon to ask for reviews from people before he releases tutorials and whatnot, people on IRC are generally happy to help with such things. Better than ending on HN?s first page in that state, no? Otherwise, I am currently in the process of making erlc?s output better, akin to Clang?s, with nicer error messages for the beginners and experienced developers. Anyone is free to join #erlang on the Freenode network if they wish to help. I?ve been saying this for a year now, because there was other, more interesting, things to implement. That and procrastination. Regards, -- Anthony Ramine Le 14 juin 2014 ? 00:02, lloyd@REDACTED a ?crit : > Sigh. > > Isn't there a more constructive way of pointing out spelling errors? > > This thread has clearly brought out the wide interest in and perceived need for introductory Erlang tutorials. Gordon Guthrie has put substantial creativity and some amount of work into his submission. Pure volunteer effort. Unless I've missed something, it's the only concrete submission so far. > > Why disparage it? Why discourage the next submission tickling someone's brain for fear that it will be dissed on erlang-questions? > > The target audiences for Erlang tutorials ranges far beyond executives. There's room for many styles and approaches ranging from whimsical to rigorous academic to to bottom-line justification aimed at audiences ranging from students to young engineers to start-up entrepreneurs to grey-beard IT execs and more. There are many learning styles and many ways of teaching. > > So my take, the more the merrier. > > Please, Anthony, it's your turn now to show us what you can do and how it can make a difference. > > All the best, > > Lloyd > > -----Original Message----- > From: "Anthony Ramine" > Sent: Friday, June 13, 2014 5:07pm > To: "Gordon Guthrie" > Cc: "Erlang" > Subject: Re: [erlang-questions] Beginners tutorials > > Hello, > > I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? > > Regards, > > -- > Anthony Ramine > > Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > >> I have taken a bit more radical approach. >> >> People traditionally comparing Erlang to other languages - and Erlang >> loses because of its weak spot - it has a prolog syntax in a world >> dominated by c-like syntaxes. >> >> I decided to compare Erlang/OTP with other ways of building >> multi-machine clusters. >> >> Here's my hell world attempt: >> http://erlangotp.com >> >> Thoughts comments, welcome >> >> Gordon >> >> On 12/06/2014, Mark Allen wrote: >>> I started http://introducingerlang.com right after EF2014 in San Francisco. >>> It's intended to be a really short and simple introduction to Erlang for >>> people who know how to program in other languages but don't know Erlang. I >>> have a mostly documented OTP application (uses Gordon Guthrie's "literate >>> Erlang" markup) with a supervisor, gen_server and application modules here: >>> >>> https://github.com/introducingerlang/todolist/tree/master/src_md >>> >>> I would welcome any help finishing the documentation of the modules in that >>> repo or extending/correcting/fixing the web content that's already there. I >>> can add you directly to the github organization. >>> >>> Thanks, >>> >>> Mark >>> >>> From: Joe Armstrong > >>> Date: Thursday, June 12, 2014 9:54 AM >>> To: Erlang >>> > >>> Subject: [erlang-questions] Beginners tutorials >>> >>> Re: Garrett's great talk at EUC2014 >>> >>> The point has been made many times before that >>> "There are no easy Erlang getting started guides" >>> >>> So I thought I'd take a look at Node.js. >>> >>> The node js home page (node.js) starts with a simple example >>> >>> >>> >>> var http = require('http'); >>> http.createServer(function (req, res) { >>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>> res.end('Hello World\n'); >>> }).listen(1337, '127.0.0.1'); >>> console.log('Server running at http://127.0.0.1:1337/'); >>> >>> To run the server, put the code into a file example.js and execute it with >>> the node program from the command line: >>> >>> % node example.js >>> Server running at http://127.0.0.1:1337/ >>> >>> >>> It's pretty easy to knock up an almost identical example in Erlang - using >>> any of the well-known web >>> servers in the background, unfortunately this has not been done, or if it >>> has been done >>> it's not easy to find the examples (or if there are examples I can't find >>> them) >>> >>> I was vaguely thinking of making some examples that are more-or-less >>> isomorphic to the >>> node.js examples and then applying small transformation steps to turn then >>> from idiomatic node.js code to idiomatic Erlang code. >>> >>> Although I could find a simple hello world example in node.js I could not >>> find a tutorial that >>> started with a simple example and then built on it in very small steps >>> adding routing, authentication, >>> database access and so on. >>> >>> Does anybody know of some examples of node.js that could be used for this. >>> >>> Cheers >>> >>> /Joe >>> >>> >> >> >> -- >> Gordon Guthrie >> CEO hypernumbers >> >> http://hypernumbers.com >> t: hypernumbers >> +44 7776 251669 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From lloyd@REDACTED Sat Jun 14 01:20:36 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Fri, 13 Jun 2014 19:20:36 -0400 (EDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: <01273FC7-A1A6-422F-82A5-F595F5491338@gmail.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> <1402696922.99018464@apps.rackspace.com> <01273FC7-A1A6-422F-82A5-F595F5491338@gmail.com> Message-ID: <1402701636.43395032@apps.rackspace.com> My apologies, Anthony, if I sounded too harsh. I've felt Steve Vinoski's lash and appreciate his tribute to you. I certainly agree that spelling and careful editing are an essential part of the publication process. And your point re: outside review is well taken. But, with all respect, I contend that constructive encouragement is a more effective way to promote vital community involvement than harsh rebuke. But maybe you and Steve are touching on an essential issue: Just exactly who with what experience and qualifications would the Erlang community like to attract and invite into the fold? Clarity on this question should inform any and all documentation including beginner tutorials. If only staid, respectable engineers and corporate executives are invited, then I don't fit. I'm a novelist/small press publisher --- army of one --- looking to master Erlang sufficiently well to build tools that I need in my business. I've been programming for many years, indeed owned a software development shop for more than two decades. I don't doubt that as a programmer my best day is miles behind your worst. For that reason, I don't consider myself a professional programmer. That said, I found Gordon's site both interesting and informative. I learned a great deal that I had no idea was going on in the Erlang world even though I do make efforts to keep up. But that highlights a second point: We do, I'd venture, agree that there is a very fine line between interesting, accessible discourse and talking down to your audience. Problem is, what's interesting and accessible to me as a semi-technically literate reader may well be disrespectful to you as an experienced Erlang wizard. As they say, horses for courses; different strokes for different folks. One thing I can't sufficiently emphasize, however, is how much I appreciate Erlang and the community that has worked so hard to make it the fine set of tools that we have today. I feel like I owe a tremendous debt. But given my vast ignorance, the only thing I have at present to contribute is the noobie perspective and the ability to ask stupid questions. And that is my sole motive for speaking out on this thread. All the best, Lloyd -----Original Message----- From: "Anthony Ramine" Sent: Friday, June 13, 2014 6:41pm To: lloyd@REDACTED Cc: "Gordon Guthrie" , "Erlang" Subject: Re: [erlang-questions] Beginners tutorials Hello, I don?t think I have a problem with neither volunteer effort nor jokes. I have a problem when new terms are invented with vague definitions, when things are released too early before any editing, when authors make too many jokes and otherwise address me as if I were somewhat slow. About typos, I suggest Gordon to ask for reviews from people before he releases tutorials and whatnot, people on IRC are generally happy to help with such things. Better than ending on HN?s first page in that state, no? Otherwise, I am currently in the process of making erlc?s output better, akin to Clang?s, with nicer error messages for the beginners and experienced developers. Anyone is free to join #erlang on the Freenode network if they wish to help. I?ve been saying this for a year now, because there was other, more interesting, things to implement. That and procrastination. Regards, -- Anthony Ramine Le 14 juin 2014 ? 00:02, lloyd@REDACTED a ?crit : > Sigh. > > Isn't there a more constructive way of pointing out spelling errors? > > This thread has clearly brought out the wide interest in and perceived need for introductory Erlang tutorials. Gordon Guthrie has put substantial creativity and some amount of work into his submission. Pure volunteer effort. Unless I've missed something, it's the only concrete submission so far. > > Why disparage it? Why discourage the next submission tickling someone's brain for fear that it will be dissed on erlang-questions? > > The target audiences for Erlang tutorials ranges far beyond executives. There's room for many styles and approaches ranging from whimsical to rigorous academic to to bottom-line justification aimed at audiences ranging from students to young engineers to start-up entrepreneurs to grey-beard IT execs and more. There are many learning styles and many ways of teaching. > > So my take, the more the merrier. > > Please, Anthony, it's your turn now to show us what you can do and how it can make a difference. > > All the best, > > Lloyd > > -----Original Message----- > From: "Anthony Ramine" > Sent: Friday, June 13, 2014 5:07pm > To: "Gordon Guthrie" > Cc: "Erlang" > Subject: Re: [erlang-questions] Beginners tutorials > > Hello, > > I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? > > Regards, > > -- > Anthony Ramine > > Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > >> I have taken a bit more radical approach. >> >> People traditionally comparing Erlang to other languages - and Erlang >> loses because of its weak spot - it has a prolog syntax in a world >> dominated by c-like syntaxes. >> >> I decided to compare Erlang/OTP with other ways of building >> multi-machine clusters. >> >> Here's my hell world attempt: >> http://erlangotp.com >> >> Thoughts comments, welcome >> >> Gordon >> >> On 12/06/2014, Mark Allen wrote: >>> I started http://introducingerlang.com right after EF2014 in San Francisco. >>> It's intended to be a really short and simple introduction to Erlang for >>> people who know how to program in other languages but don't know Erlang. I >>> have a mostly documented OTP application (uses Gordon Guthrie's "literate >>> Erlang" markup) with a supervisor, gen_server and application modules here: >>> >>> https://github.com/introducingerlang/todolist/tree/master/src_md >>> >>> I would welcome any help finishing the documentation of the modules in that >>> repo or extending/correcting/fixing the web content that's already there. I >>> can add you directly to the github organization. >>> >>> Thanks, >>> >>> Mark >>> >>> From: Joe Armstrong > >>> Date: Thursday, June 12, 2014 9:54 AM >>> To: Erlang >>> > >>> Subject: [erlang-questions] Beginners tutorials >>> >>> Re: Garrett's great talk at EUC2014 >>> >>> The point has been made many times before that >>> "There are no easy Erlang getting started guides" >>> >>> So I thought I'd take a look at Node.js. >>> >>> The node js home page (node.js) starts with a simple example >>> >>> >>> >>> var http = require('http'); >>> http.createServer(function (req, res) { >>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>> res.end('Hello World\n'); >>> }).listen(1337, '127.0.0.1'); >>> console.log('Server running at http://127.0.0.1:1337/'); >>> >>> To run the server, put the code into a file example.js and execute it with >>> the node program from the command line: >>> >>> % node example.js >>> Server running at http://127.0.0.1:1337/ >>> >>> >>> It's pretty easy to knock up an almost identical example in Erlang - using >>> any of the well-known web >>> servers in the background, unfortunately this has not been done, or if it >>> has been done >>> it's not easy to find the examples (or if there are examples I can't find >>> them) >>> >>> I was vaguely thinking of making some examples that are more-or-less >>> isomorphic to the >>> node.js examples and then applying small transformation steps to turn then >>> from idiomatic node.js code to idiomatic Erlang code. >>> >>> Although I could find a simple hello world example in node.js I could not >>> find a tutorial that >>> started with a simple example and then built on it in very small steps >>> adding routing, authentication, >>> database access and so on. >>> >>> Does anybody know of some examples of node.js that could be used for this. >>> >>> Cheers >>> >>> /Joe >>> >>> >> >> >> -- >> Gordon Guthrie >> CEO hypernumbers >> >> http://hypernumbers.com >> t: hypernumbers >> +44 7776 251669 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From zxq9@REDACTED Sat Jun 14 01:38:00 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 14 Jun 2014 08:38 +0900 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <539B6CE5.9010204@meetinghouse.net> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> <539B6CE5.9010204@meetinghouse.net> Message-ID: <12420387.frnj11spC4@jalapeno> On Friday 13 June 2014 17:28:05 Miles Fidelman wrote: > Anthony Ramine wrote: > > Hello, > > > > I hope to not sound rude, but I can?t imagine any executive in their right > > mind choosing Erlang with such an overly colloquial website ridden with > > spelling mistakes. For starters, such a person will look up ? Cluster > > System ?, to no avail. Why invent new terms? Why try too hard to be cool? > > > > Regards, > > Well, not to be rude - but what company in its right mind lets an > executive make platform decisions (unless, of course we're talking a > CTO - in which case what CTO in their right mind makes techno-business > decisions based on a web site)? > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra The quote in Miles' signature is as relevant as it is true. From n.oxyde@REDACTED Sat Jun 14 01:56:34 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Jun 2014 01:56:34 +0200 Subject: [erlang-questions] Beginners tutorials In-Reply-To: <1402701636.43395032@apps.rackspace.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> <1402696922.99018464@apps.rackspace.com> <01273FC7-A1A6-422F-82A5-F595F5491338@gmail.com> <1402701636.43395032@apps.rackspace.com> Message-ID: <594BF027-E19C-4C27-9E48-3B0630A3D592@gmail.com> Replied inline. Le 14 juin 2014 ? 01:20, lloyd@REDACTED a ?crit : > My apologies, Anthony, if I sounded too harsh. I've felt Steve Vinoski's lash and appreciate his tribute to you. No offense taken at all. > I certainly agree that spelling and careful editing are an essential part of the publication process. And your point re: outside review is well taken. > > But, with all respect, I contend that constructive encouragement is a more effective way to promote vital community involvement than harsh rebuke. I could point out all the typos, or aspell could do it. The jokes are a matter of taste. To me their generous use makes the whole thing sound a bit too amateurish. I don?t even feel concerned by some of them, like the bloodier steak, is that a regional thing? Is it beef? I usually prefer veal. > But maybe you and Steve are touching on an essential issue: > > Just exactly who with what experience and qualifications would the Erlang community like to attract and invite into the fold? > > Clarity on this question should inform any and all documentation including beginner tutorials. > > If only staid, respectable engineers and corporate executives are invited, then I don't fit. > > I'm a novelist/small press publisher --- army of one --- looking to master Erlang sufficiently well to build tools that I need in my business. I've been programming for many years, indeed owned a software development shop for more than two decades. I don't doubt that as a programmer my best day is miles behind your worst. For that reason, I don't consider myself a professional programmer. I am a hobbyist who doesn?t use the language professionally. My bad days are as bad as yours and my good days just come from reading the OTP code on my free time. Nice to know someone is using Erlang in press publishing. > That said, I found Gordon's site both interesting and informative. I learned a great deal that I had no idea was going on in the Erlang world even though I do make efforts to keep up. > > But that highlights a second point: We do, I'd venture, agree that there is a very fine line between interesting, accessible discourse and talking down to your audience. Problem is, what's interesting and accessible to me as a semi-technically literate reader may well be disrespectful to you as an experienced Erlang wizard. As they say, horses for courses; different strokes for different folks. I don?t mind trying to reach beginners with layman terms, though maybe people could try to do that in the documentation directly, so that people can comment in a better fashion. Layman terms aren?t disrespectful at all, they just need to be correctly used. > One thing I can't sufficiently emphasize, however, is how much I appreciate Erlang and the community that has worked so hard to make it the fine set of tools that we have today. I feel like I owe a tremendous debt. But given my vast ignorance, the only thing I have at present to contribute is the noobie perspective and the ability to ask stupid questions. Ignorance just begs to be eradicated and questions to be answered. Erlang gives you the advantage of being boring and unsurprising to read, if you wish to know more about how OTP behaviours and friends work, it?s just a matter of reading their code of a key set of modules and trying to reach a person willing to help, did I mention IRC? > And that is my sole motive for speaking out on this thread. Nothing wrong with that. From bchesneau@REDACTED Sat Jun 14 08:31:59 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Jun 2014 08:31:59 +0200 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? Message-ID: what is the solution used by erlang to handle multlle processes to accept. Does it use a signaling system to prevent n processes to accept a connection at the same time (which trigger an eagain later) ? - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Sat Jun 14 09:44:20 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sat, 14 Jun 2014 00:44:20 -0700 (PDT) Subject: [erlang-questions] Beginners tutorials In-Reply-To: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> References: <63E2043D-2323-444A-B134-E6FAC2EC65F9@gmail.com> Message-ID: <1402731860.33439.YahooMailNeo@web163604.mail.gq1.yahoo.com> Clusters are hardly an unknown term, though personally I mentally associate the term with DIY HPC.?Greg Pfister's In Search of Clusters was pretty good. Computer cluster - Wikipedia, the free encyclopedia Computer cluster - Wikipedia, the free encyclopedia A computer cluster consists of a set of loosely connected or tightly connected computers that work together so that in many respects they can be viewed as a single ... View on en.wikipedia.org Preview by Yahoo PS. Gordon, I liked the site, it's a nice read for someone who wants to get the flavor of the language rather than a tutorial. Loved the last paragraph "Muslims say that all human things are flawed, and only God is perfect. The great Muslim caligraphers would make a deliberate mistake in their work so God wouldn't think them too proud. Getting the final semicolon wrong in Erlang (which we all do) is the Erlang developer's acknowlegement of their own human frailty." On Friday, June 13, 2014 11:08 PM, Anthony Ramine wrote: > > >Hello, > >I hope to not sound rude, but I can?t imagine any executive in their right mind choosing Erlang with such an overly colloquial website ridden with spelling mistakes. For starters, such a person will look up ? Cluster System ?, to no avail. Why invent new terms? Why try too hard to be cool? > >Regards, > >-- >Anthony Ramine > >Le 13 juin 2014 ? 17:58, Gordon Guthrie a ?crit : > >> I have taken a bit more radical approach. >> >> People traditionally comparing Erlang to other languages - and Erlang >> loses because of its weak spot - it has a prolog syntax in a world >> dominated by c-like syntaxes. >> >> I decided to compare Erlang/OTP with other ways of building >> multi-machine clusters. >> >> Here's my hell world attempt: >> http://erlangotp.com >> >> Thoughts comments, welcome >> >> Gordon >> >> On 12/06/2014, Mark Allen wrote: >>> I started http://introducingerlang.com right after EF2014 in San Francisco. >>> It's intended to be a really short and simple introduction to Erlang for >>> people who know how to program in other languages but don't know Erlang. I >>> have a mostly documented OTP application (uses Gordon Guthrie's "literate >>> Erlang" markup) with a supervisor, gen_server and application modules here: >>> >>> https://github.com/introducingerlang/todolist/tree/master/src_md >>> >>> I would welcome any help finishing the documentation of the modules in that >>> repo or extending/correcting/fixing the web content that's already there. I >>> can add you directly to the github organization. >>> >>> Thanks, >>> >>> Mark >>> >>> From: Joe Armstrong > >>> Date: Thursday, June 12, 2014 9:54 AM >>> To: Erlang >>> > >>> Subject: [erlang-questions] Beginners tutorials >>> >>> Re: Garrett's great talk at EUC2014 >>> >>> The point has been made many times before that >>> "There are no easy Erlang getting started guides" >>> >>> So I thought I'd take a look at Node.js. >>> >>> The node js home page (node.js) starts with a simple example >>> >>> >>> >>> var http = require('http'); >>> http.createServer(function (req, res) { >>>? res.writeHead(200, {'Content-Type': 'text/plain'}); >>>? res.end('Hello World\n'); >>> }).listen(1337, '127.0.0.1'); >>> console.log('Server running at http://127.0.0.1:1337/'); >>> >>> To run the server, put the code into a file example.js and execute it with >>> the node program from the command line: >>> >>> % node example.js >>> Server running at http://127.0.0.1:1337/ >>> >>> >>> It's pretty easy to knock up an almost identical example in Erlang - using >>> any of the well-known web >>> servers in the background, unfortunately this has not been done, or if it >>> has been done >>> it's not easy to find the examples (or if there are examples I can't find >>> them) >>> >>> I was vaguely thinking of making some examples that are more-or-less >>> isomorphic to the >>> node.js examples and then applying small transformation steps to turn then >>> from idiomatic node.js code to idiomatic Erlang code. >>> >>> Although I could find a simple hello world example in node.js I could not >>> find a tutorial that >>> started with a simple example and then built on it in very small steps >>> adding routing, authentication, >>> database access and so on. >>> >>> Does anybody know of some examples of node.js that could be used for this. >>> >>> Cheers >>> >>> /Joe >>> >>> >> >> >> -- >> Gordon Guthrie >> CEO hypernumbers >> >> http://hypernumbers.com >> t: hypernumbers >> +44 7776 251669 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jun 14 09:59:34 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 14 Jun 2014 11:59:34 +0400 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: References: Message-ID: Driver remembers what processes have asked to notify them about new connection. When new client comes, driver looks for next waiting process, send message to it and removes his record from list of waiting processes. So, nothing magic. Driver is single threaded, but it is scheduled independently from other processes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Jun 14 10:25:41 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Jun 2014 10:25:41 +0200 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: References: Message-ID: On Sat, Jun 14, 2014 at 9:59 AM, Max Lapshin wrote: > Driver remembers what processes have asked to notify them about new > connection. > > When new client comes, driver looks for next waiting process, send message > to it and removes his record from list of waiting processes. > > So, nothing magic. Driver is single threaded, but it is scheduled > independently from other processes. > So afaik accepting is only done in one thread right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Jun 14 10:30:06 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Jun 2014 10:30:06 +0200 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: References: Message-ID: On Sat, Jun 14, 2014 at 10:25 AM, Benoit Chesneau wrote: > > > > On Sat, Jun 14, 2014 at 9:59 AM, Max Lapshin > wrote: > >> Driver remembers what processes have asked to notify them about new >> connection. >> >> When new client comes, driver looks for next waiting process, send >> message to it and removes his record from list of waiting processes. >> >> So, nothing magic. Driver is single threaded, but it is scheduled >> independently from other processes. >> > > So afaik accepting is only done in one thread right? > hrmm or does it notify them about a read event and let them accept? -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jun 14 12:44:36 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 14 Jun 2014 14:44:36 +0400 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: References: Message-ID: Driver is awakened on READ_READY event on listener socket, then it calls accept() which returns immediately without blocking, new Port is made out of this socket and sent to next listener. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sat Jun 14 13:04:00 2014 From: tony@REDACTED (Tony Rogvall) Date: Sat, 14 Jun 2014 13:04:00 +0200 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: References: Message-ID: <249757AC-01C4-402C-98BC-64B3DDEF0808@rogvall.se> It is one queue per listen socket, using poll/select. The gen_tcp accept is executed directly in the callers scheduler/thread if the socket accept returns ok. Otherwise the listen socket is "selected" and an input ready callback will run socket accept from a scheduler/thread when the event is triggered. So the answer is no. The queued accepts are executed as result of the (listen) port being scheduled. The listen port actually creates new port / socket and pass that to the process that called gen_tcp accept in the first place. While browsing the code, needed to updated myself with the latest progress, in order to reply to this question, I notice that all accepts are executed from the queue regardless how long the queue is. Could this not lead to very interesting behavior in extreme cases ? (I need to do some fun experiments) /Tony On 14 jun 2014, at 10:30, Benoit Chesneau wrote: > > > > On Sat, Jun 14, 2014 at 10:25 AM, Benoit Chesneau wrote: > > > > On Sat, Jun 14, 2014 at 9:59 AM, Max Lapshin wrote: > Driver remembers what processes have asked to notify them about new connection. > > When new client comes, driver looks for next waiting process, send message to it and removes his record from list of waiting processes. > > So, nothing magic. Driver is single threaded, but it is scheduled independently from other processes. > > So afaik accepting is only done in one thread right? > > hrmm or does it notify them about a read event and let them accept? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From benhsu@REDACTED Sat Jun 14 20:08:52 2014 From: benhsu@REDACTED (Ben Hsu) Date: Sat, 14 Jun 2014 14:08:52 -0400 Subject: [erlang-questions] OTP error: bad_return Message-ID: Hello, I am trying to put my application under an OTP supervisor, and I'm seeing an error message I don't understand when I start my application using "application:start(app_name)". The error says "bad_return", and I'm not sure if it means the tuple I'm returning from init/1 is bad, or if my code is bad. My supervisor code, which I took verbatim from the OTP book, looks like this: start_link() -> supervisor:start_link({local, ?SERVER}, ?MODULE, []). init([]) -> Server = {stats_gatherer, {stats_gatherer, start_link, []}, permanent, 2000, worker, [stats_gatherer]}, Children = [Server], RestartStrategy = {one_for_one, 0, 1}, {ok, RestartStrategy, Children}. I tried running stats_gatherer:start_link() from the Erlang shell, and it worked. The error message is below. I would be grateful for any insight. 1> application:start(stats_app). {error, {{error, {bad_return, {stats_sup,init, {ok,{one_for_one,0,1}, [{stats_gatherer, {stats_gatherer,start_link,[]}, permanent,2000,worker, [stats_gatherer]}]}}}}, {stats_app,start,[normal,[]]}}} =INFO REPORT==== 14-Jun-2014::14:03:19 === application: stats_app exited: {{error, {bad_return, {stats_sup,init, {ok,{one_for_one,0,1}, [{stats_gatherer, {stats_gatherer,start_link,[]}, permanent,2000,worker, [stats_gatherer]}]}}}}, {stats_app,start,[normal,[]]}} type: temporary -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Jun 14 21:05:33 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 14 Jun 2014 21:05:33 +0200 Subject: [erlang-questions] how erlang handle multiple processes accepting on a socket? In-Reply-To: <249757AC-01C4-402C-98BC-64B3DDEF0808@rogvall.se> References: <249757AC-01C4-402C-98BC-64B3DDEF0808@rogvall.se> Message-ID: On Sat, Jun 14, 2014 at 1:04 PM, Tony Rogvall wrote: > It is one queue per listen socket, using poll/select. > > The gen_tcp accept is executed directly in the callers scheduler/thread > if the socket accept returns ok. > Otherwise the listen socket is "selected" and an input ready callback will > run socket accept from a scheduler/thread when the event is triggered. > > So the answer is no. The queued accepts are executed as result of > the (listen) port being scheduled. The listen port actually creates > new port / socket and pass that to the process that called gen_tcp accept > in the first place. > > While browsing the code, needed to updated myself with the latest > progress, > in order to reply to this question, I notice that all accepts are executed > from the queue regardless how long the queue is. Could this not > lead to very interesting behavior in extreme cases ? > (I need to do some fun experiments) > > /Tony > > make sens thanks for the answer! Also thanks to Max :) - benoit > On 14 jun 2014, at 10:30, Benoit Chesneau wrote: > > > > > On Sat, Jun 14, 2014 at 10:25 AM, Benoit Chesneau > wrote: > >> >> >> >> On Sat, Jun 14, 2014 at 9:59 AM, Max Lapshin >> wrote: >> >>> Driver remembers what processes have asked to notify them about new >>> connection. >>> >>> When new client comes, driver looks for next waiting process, send >>> message to it and removes his record from list of waiting processes. >>> >>> So, nothing magic. Driver is single threaded, but it is scheduled >>> independently from other processes. >>> >> >> So afaik accepting is only done in one thread right? >> > > hrmm or does it notify them about a read event and let them accept? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Sat Jun 14 21:07:29 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sat, 14 Jun 2014 20:07:29 +0100 Subject: [erlang-questions] OTP error: bad_return In-Reply-To: References: Message-ID: It is the return value which is not what the supervisor expects. It should be {ok, {RestartStrategy, ChildList}}, you are sending {ok, RestartStrategy, ChildList} F > On 14 Jun 2014, at 19:08, Ben Hsu wrote: > > > Hello, > > I am trying to put my application under an OTP supervisor, and I'm seeing an error message I don't understand when I start my application using "application:start(app_name)". > > The error says "bad_return", and I'm not sure if it means the tuple I'm returning from init/1 is bad, or if my code is bad. > > My supervisor code, which I took verbatim from the OTP book, looks like this: > > start_link() -> > supervisor:start_link({local, ?SERVER}, ?MODULE, []). > > init([]) -> > Server = {stats_gatherer, {stats_gatherer, start_link, []}, > permanent, 2000, worker, [stats_gatherer]}, > Children = [Server], > RestartStrategy = {one_for_one, 0, 1}, > {ok, RestartStrategy, Children}. > > > I tried running stats_gatherer:start_link() from the Erlang shell, and it worked. > > The error message is below. I would be grateful for any insight. > > 1> application:start(stats_app). > {error, > {{error, > {bad_return, > {stats_sup,init, > {ok,{one_for_one,0,1}, > [{stats_gatherer, > {stats_gatherer,start_link,[]}, > permanent,2000,worker, > [stats_gatherer]}]}}}}, > {stats_app,start,[normal,[]]}}} > > =INFO REPORT==== 14-Jun-2014::14:03:19 === > application: stats_app > exited: {{error, > {bad_return, > {stats_sup,init, > {ok,{one_for_one,0,1}, > [{stats_gatherer, > {stats_gatherer,start_link,[]}, > permanent,2000,worker, > [stats_gatherer]}]}}}}, > {stats_app,start,[normal,[]]}} > type: temporary > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Mon Jun 16 09:51:22 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 09:51:22 +0200 Subject: [erlang-questions] Erlang for youngsters Message-ID: Hi, The wonderful thread on "Beginners tutorials" (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started after the EUC last week has touched something in me and I want to get some feedback on my ideas. I think that Joe's original suggestion in the "Beginners tutorials" thread can do something with regards to easing people into Erlang, but it cannot be the only thing. I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a number of things we, as a community, can do better. One thing that stood out in relation to this thread was HardToLearn. HardToLearn influences a lot of things, but it also drives the worry FindingDevelopers, which bad for the career prospects for all of us. See Garrett's talk (when online) and you will understand. Why is Erlang HardToLearn? One can point to documentation and say it is not optimal. One can ask for books on Erlang Concurrency Patterns as Joe did. But I feel there is a more fundamental problem that we need to address: how to think like an Erlanger. Erlang is a concurrent functional language with a unique failure model. More than 2 nines of the people being taught anything on programming will be exposed to procedural or object oriented languages with exceptions and be told that threads are hard (they are 'cause they will make you loose your hair). I think that a learning resource focused on teaching people the Erlang model from the ground up would be a great improvement. A clear narrative around how do we solve a problem the Erlang way. Teaching the basic constructs is not the problem. My initial target for such a learning resources would be young people in the higher grades of elementary school, say 12-15 years. Why? Because I want to influence them before their minds are totally corrupted by other programming models. I don't think we would have to dumb anything down in particular for this group - we just have to find a cool example and organise the learning around how to become so good that one can solve such a problem. Some sort of game will probably be the best candidate, say, some sort of Transport Tycoon clone?!?! And now for the controversial part of my idea: this should probably be done using Elixir plus something for the GUI. Yes, I said the other E word, so I'm ready to be stoned ;-) [1] Why Elixir? Programming Elixir requires the same understanding of the Erlang concurrency model in order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame and misses the boat totally. So using Elixir would allow us to expose people to the Erlang model, which I think is the main point. The more people that uses the BEAM, the better for the FindingDevelopers problem. What is better about Elixir from a learning standpoint is, in my highly subjective opinion, that you can get started quite easily with the mix tool. Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old son to have a look in the "Introducing Elixir" book and his initial reaction was "That's easy to read, it looks like lua." Minimising the amount of surprise is a good thing! Given that I think games are awesome for teaching there needs to be some sort of GUI element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it is functional, but other suggestions are most welcome. Am I on the right track to anything with this? Is there a need for such a learning resource? Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? Cheers, Torben [1] https://www.youtube.com/watch?v=SYkbqzWVHZI -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From g@REDACTED Mon Jun 16 09:59:19 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 16 Jun 2014 09:59:19 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann wrote: > See Garrett's talk (when online) and you will understand. The slide content Torben is referring to is here: http://www.gar1t.com/presentations/2014-06-10-euc/ To skip to the "Results" section: http://www.gar1t.com/presentations/2014-06-10-euc/#slide-63 This is pretty useless without someone saying stuff in front of, but I'll be preparing an essay on this topic shortly to provide a bit more context. Garrett From s.j.thompson@REDACTED Mon Jun 16 10:44:24 2014 From: s.j.thompson@REDACTED (Simon Thompson) Date: Mon, 16 Jun 2014 09:44:24 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <64D2B9BE-9FE1-40E0-BF39-CF83AB8DF15B@kent.ac.uk> Garrett - hat's great to hear, as I wasn't able to get to your talk last week. Kind regards Simon On 16 Jun 2014, at 08:59, Garrett Smith wrote: > This is pretty useless without someone saying stuff in front of, but > I'll be preparing an essay on this topic shortly to provide a bit more > context. > > Garrett Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson@REDACTED | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From g@REDACTED Mon Jun 16 10:50:39 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 16 Jun 2014 10:50:39 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann wrote: -snip- > I think that a learning resource focused on teaching people the Erlang model from the > ground up would be a great improvement. A clear narrative around how do we solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > > My initial target for such a learning resources would be young people in the higher > grades of elementary school, say 12-15 years. Why? Because I want to influence them > before their minds are totally corrupted by other programming models. > > I don't think we would have to dumb anything down in particular for this group - we > just have to find a cool example and organise the learning around how to become so > good that one can solve such a problem. > Some sort of game will probably be the best candidate, say, some sort of Transport > Tycoon clone?!?! I don't have enough experience teaching programming to this age group to provide anything more than a hunch. But I suspect that the Erlang way, which is hard enough for very seasoned programmers to grok, might be a bit ambitious for these young learners. I'm speaking in particular about the model that emerges when you isolate processes. It changes everything: your approach to building software (move from state oriented to activity oriented), error handling (move from defensive measures to assertive/let-it-crash), program structure (from monolith to system), and so on. The benefits of this shift are hard to get across, in my experience anyway. I wish it wasn't, or I wish I was better at communicating. I think maybe just teaching a new language might be enough ambition for this group. I don't mean to throw cold water on this. Just thinking out loud. > And now for the controversial part of my idea: this should probably be done using > Elixir plus something for the GUI. > Yes, I said the other E word, so I'm ready to be stoned ;-) [1] > > Why Elixir? > > Programming Elixir requires the same understanding of the Erlang concurrency model in > order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame > and misses the boat totally. > > So using Elixir would allow us to expose people to the Erlang model, which I think is > the main point. The more people that uses the BEAM, the better for the > FindingDevelopers problem. > > What is better about Elixir from a learning standpoint is, in my highly subjective > opinion, that you can get started quite easily with the mix tool. > > Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old > son to have a look in the "Introducing Elixir" book and his initial reaction was > "That's easy to read, it looks like lua." Minimising the amount of surprise is a good > thing! All of these points are true -- Elixir has a huge advantage here. Which is why I'm afraid you must be stoned. > Given that I think games are awesome for teaching there needs to be some sort of GUI > element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it > is functional, but other suggestions are most welcome. All I can say for sure is that if you can create a simple developer experience around building anything related to *Minecraft* you have a chance at capturing the minds of an entire generation of programmers. > Am I on the right track to anything with this? > Is there a need for such a learning resource? > Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? What does the 12 year old say? From tty.erlang@REDACTED Mon Jun 16 10:57:19 2014 From: tty.erlang@REDACTED (T Ty) Date: Mon, 16 Jun 2014 09:57:19 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: I have always contended that we should start teaching Erlang by teaching OTP and going back to processes as needed later. Yes this might be akin to teaching a script to solve a problem instead of the why however quick easy success builds confidence. Just my 2 cents On Mon, Jun 16, 2014 at 9:50 AM, Garrett Smith wrote: > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > > > I think that a learning resource focused on teaching people the Erlang > model from the > > ground up would be a great improvement. A clear narrative around how do > we solve a > > problem the Erlang way. Teaching the basic constructs is not the problem. > > > > My initial target for such a learning resources would be young people in > the higher > > grades of elementary school, say 12-15 years. Why? Because I want to > influence them > > before their minds are totally corrupted by other programming models. > > > > I don't think we would have to dumb anything down in particular for this > group - we > > just have to find a cool example and organise the learning around how to > become so > > good that one can solve such a problem. > > Some sort of game will probably be the best candidate, say, some sort of > Transport > > Tycoon clone?!?! > > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > > I think maybe just teaching a new language might be enough ambition > for this group. I don't mean to throw cold water on this. Just > thinking out loud. > > > And now for the controversial part of my idea: this should probably be > done using > > Elixir plus something for the GUI. > > Yes, I said the other E word, so I'm ready to be stoned ;-) [1] > > > > Why Elixir? > > > > Programming Elixir requires the same understanding of the Erlang > concurrency model in > > order to program well. Otherwise you are just doing Ruby-on-BEAM, which > is kinda lame > > and misses the boat totally. > > > > So using Elixir would allow us to expose people to the Erlang model, > which I think is > > the main point. The more people that uses the BEAM, the better for the > > FindingDevelopers problem. > > > > What is better about Elixir from a learning standpoint is, in my highly > subjective > > opinion, that you can get started quite easily with the mix tool. > > > > Furthermore, the Elixir syntax is more familiar to youngsters. I asked > my 12 year old > > son to have a look in the "Introducing Elixir" book and his initial > reaction was > > "That's easy to read, it looks like lua." Minimising the amount of > surprise is a good > > thing! > > All of these points are true -- Elixir has a huge advantage here. > Which is why I'm afraid you must be stoned. > > > Given that I think games are awesome for teaching there needs to be some > sort of GUI > > element at some point and here I'm leaning towards Elm ( > http://elm-lang.org) since it > > is functional, but other suggestions are most welcome. > > All I can say for sure is that if you can create a simple developer > experience around building anything related to *Minecraft* you have a > chance at capturing the minds of an entire generation of programmers. > > > Am I on the right track to anything with this? > > Is there a need for such a learning resource? > > Is Concurrent, Functional Programming relevant enough to warrant putting > some energy into? > > What does the 12 year old say? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Mon Jun 16 11:01:11 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Mon, 16 Jun 2014 11:01:11 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: On Mon, Jun 16, 2014 at 10:50 AM, Garrett Smith wrote: > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > > > I think that a learning resource focused on teaching people the Erlang > model from the > > ground up would be a great improvement. A clear narrative around how do > we solve a > > problem the Erlang way. Teaching the basic constructs is not the problem. > > > > My initial target for such a learning resources would be young people in > the higher > > grades of elementary school, say 12-15 years. Why? Because I want to > influence them > > before their minds are totally corrupted by other programming models. > > > > I don't think we would have to dumb anything down in particular for this > group - we > > just have to find a cool example and organise the learning around how to > become so > > good that one can solve such a problem. > > Some sort of game will probably be the best candidate, say, some sort of > Transport > > Tycoon clone?!?! > > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > Interesting, I am planning on giving a programming course at my kids school and was planning on using Erlang as well. I was thinking that because they don't have proper experience with other less tradition languages like the common OO languages that they might not face the same problems we do when adapting this new paradigm. The Erlang language itself is rather simple and straightforward so I don't think that is a problem in its own. Infect using something like Elixir might even add too many variance to the whole thing (I wasn't planning on using that). You can gradually build up towards the different patterns in Erlang, and once they get that they will thank you for the rest of the programming live. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > > I think maybe just teaching a new language might be enough ambition > for this group. I don't mean to throw cold water on this. Just > thinking out loud. > > > And now for the controversial part of my idea: this should probably be > done using > > Elixir plus something for the GUI. > > Yes, I said the other E word, so I'm ready to be stoned ;-) [1] > > > > Why Elixir? > > > > Programming Elixir requires the same understanding of the Erlang > concurrency model in > > order to program well. Otherwise you are just doing Ruby-on-BEAM, which > is kinda lame > > and misses the boat totally. > > > > So using Elixir would allow us to expose people to the Erlang model, > which I think is > > the main point. The more people that uses the BEAM, the better for the > > FindingDevelopers problem. > > > > What is better about Elixir from a learning standpoint is, in my highly > subjective > > opinion, that you can get started quite easily with the mix tool. > > > > Furthermore, the Elixir syntax is more familiar to youngsters. I asked > my 12 year old > > son to have a look in the "Introducing Elixir" book and his initial > reaction was > > "That's easy to read, it looks like lua." Minimising the amount of > surprise is a good > > thing! > > All of these points are true -- Elixir has a huge advantage here. > Which is why I'm afraid you must be stoned. > > > Given that I think games are awesome for teaching there needs to be some > sort of GUI > > element at some point and here I'm leaning towards Elm ( > http://elm-lang.org) since it > > is functional, but other suggestions are most welcome. > > All I can say for sure is that if you can create a simple developer > experience around building anything related to *Minecraft* you have a > chance at capturing the minds of an entire generation of programmers. > > +1 on minecraft, something I was thinking about is an web app that lets students communicate with each other. Like facebook but for the class. Not a game but it enhances the group feeling of the class, and might even be useful for the school as well. A game is going to take a lot of extra stuff to make really engaging. > > Am I on the right track to anything with this? > > Is there a need for such a learning resource? > > Is Concurrent, Functional Programming relevant enough to warrant putting > some energy into? > > What does the 12 year old say? > Please keep us (me) updated on this! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Jun 16 11:08:24 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 16 Jun 2014 11:08:24 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: On 16 Jun 2014, at 10:50, Garrett Smith wrote: > But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. It doesn?t have to be. Two data points: - I once knew a woman who taught logic programming at a South American university. She said that they had successfully taught it to 7 year-olds, and that it was in some ways easier as they had fewer preconceived ideas about what programming was supposed to be. - Frank Huch talked at the 2007 Erlang Workshop in Freiburg about using Erlang to teach programming to high school girls. With no prior exposure to programming, the girls were writing a distributed chat program after one week of study. They had no problem understanding recursion. When I came across Erlang, I was in a bit of a vacuum - couped up as I was in a house in pre-WWW Alaska. I spent 2-3 months trying to ?unlearn? C++ and accept the concurrency-oriented paradigm as at least equally powerful as OO. Thinking back, I can be fascinated by how stuck I was in the OO paradigm, and how extremely well I?ve been able to unlearn it by now. ;-) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From g@REDACTED Mon Jun 16 11:09:23 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 16 Jun 2014 11:09:23 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: On Mon, Jun 16, 2014 at 11:01 AM, Mark Nijhof wrote: > > Interesting, I am planning on giving a programming course at my kids school > and was planning on using Erlang as well. This is where the real feedback will come from -- trying stuff. I think all of these approaches and strategies could pay off, but running experiments will tell. I am very interested to hear about how your work unfolds. > I was thinking that because they > don't have proper experience with other less tradition languages like the > common OO languages that they might not face the same problems we do when > adapting this new paradigm. The Erlang language itself is rather simple and > straightforward so I don't think that is a problem in its own. Infect using > something like Elixir might even add too many variance to the whole thing (I > wasn't planning on using that). You can gradually build up towards the > different patterns in Erlang, and once they get that they will thank you for > the rest of the programming live. It's a lot of work, but boy wouldn't it be *extremely* interesting to use both languages, but on different students, and see what they think? Garrett From mfidelman@REDACTED Mon Jun 16 11:31:37 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 16 Jun 2014 05:31:37 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <539EB979.40605@meetinghouse.net> Garrett Smith wrote: > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> >> I don't think we would have to dumb anything down in particular for this group - we >> just have to find a cool example and organise the learning around how to become so >> good that one can solve such a problem. >> Some sort of game will probably be the best candidate, say, some sort of Transport >> Tycoon clone?!?! > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > > I'm with the folks who suggest that this group has fewer pre-conceptions to unlearn. It strikes me that the actor model is far more natural for certain classes of problems - network code, simulation, and gaming come to mind. It's simply conceptually easier to think in terms of LOTS of independent processes. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From n.oxyde@REDACTED Mon Jun 16 12:20:45 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Jun 2014 12:20:45 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition? -- Anthony Ramine Le 16 juin 2014 ? 09:51, Torben Hoffmann a ?crit : > Why is Erlang HardToLearn? From torben.hoffmann@REDACTED Mon Jun 16 12:20:45 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 12:20:45 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: Garrett Smith writes: > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> >> I don't think we would have to dumb anything down in particular for this group - we >> just have to find a cool example and organise the learning around how to become so >> good that one can solve such a problem. >> Some sort of game will probably be the best candidate, say, some sort of Transport >> Tycoon clone?!?! > > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > Interesting. I have no data or experiments to back this yet, but I think that if you have not been exposed to the "traditional" way of programming you will have a easier time learning a concurrent, functional programming model. Some people insist on telling people that recursion is hard before they teach them about it - weirdly enough those people find recursion hard. This is why I want to target untainted minds. Before they are corrupted by other models. Once you have a particular model in your head you tend to use that as a reference point for everything you learn after that. I grew up on Basic and then Pascal, before trying to learn C during my sabbatical year before university. I started to cry 25 pages into Kernighan and Richie, returned it to the library and hope for a miracle. The miracle arrived: my first language (amongst a dozen or so) at university was Standard ML. That was easy to learn and taught me how to think. Explaining let-it-crash to people that are used to dealing with defensive code is very, very hard - I have the scars to prove it. Being a bit of a mathematician I'm lazy, so I am trying to find a way to avoid this problem!! > I think maybe just teaching a new language might be enough ambition > for this group. I don't mean to throw cold water on this. Just > thinking out loud. > I want the cold wash down! If not, I would not have asked for feedback. The more we know about the pitfalls the easier it would be to fix the problem. >> And now for the controversial part of my idea: this should probably be done using >> Elixir plus something for the GUI. >> Yes, I said the other E word, so I'm ready to be stoned ;-) [1] >> >> Why Elixir? >> >> Programming Elixir requires the same understanding of the Erlang concurrency model in >> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame >> and misses the boat totally. >> >> So using Elixir would allow us to expose people to the Erlang model, which I think is >> the main point. The more people that uses the BEAM, the better for the >> FindingDevelopers problem. >> >> What is better about Elixir from a learning standpoint is, in my highly subjective >> opinion, that you can get started quite easily with the mix tool. >> >> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old >> son to have a look in the "Introducing Elixir" book and his initial reaction was >> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good >> thing! > > All of these points are true -- Elixir has a huge advantage here. > Which is why I'm afraid you must be stoned. > You just wrote Elixir... >> Given that I think games are awesome for teaching there needs to be some sort of GUI >> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it >> is functional, but other suggestions are most welcome. > > All I can say for sure is that if you can create a simple developer > experience around building anything related to *Minecraft* you have a > chance at capturing the minds of an entire generation of programmers. > >> Am I on the right track to anything with this? >> Is there a need for such a learning resource? >> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? > > What does the 12 year old say? He just wants to learn how to program mods for Mindcraft, but he finds Java very hard to get into. He has code Lua for the ComputerCraft mod in Minecraft, so he likes that approach to programming. The main problem he has is how to think about solving a problem, so we have started with learn.code.org and now we need to find the next step on the latter. But I think your point about Minecraft is spot on. I have one data point to back that! The problem with Minecraft is that it requires 3D graphics - even if it is just horrible to look at and that is, regardless of language, somewhat hard to teach people. If there was a simple library out there with an API one could control from Erlang then it would be interesting to see how far one could take it. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From snaky@REDACTED Mon Jun 16 12:50:29 2014 From: snaky@REDACTED (Yuri Lukyanov) Date: Mon, 16 Jun 2014 14:50:29 +0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: I'm not a teacher at all and I don't pretend to be objective here. But my and my colleagues' experiences with Erlang tell me that Erlang is simple to learn. Most of us came to the current company with _zero_ experience in Erlang or any other functional programming experiences. I personally was a complete PHP guy. My first impression on Erlang was "it's very different and hard to learn". But in two weeks we was able to read and understand Erlang code and write simple stuff. My point is that Erlang is not hard-to-learn, but rather hard-to-realize-it-is-easy-to-learn. It's easier than one can imagine. Perhaps, that could be a statement to spread out. Just thinking aloud. On Mon, Jun 16, 2014 at 11:51 AM, Torben Hoffmann wrote: > Hi, > > The wonderful thread on "Beginners tutorials" > (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started > after the EUC last week has touched something in me and I want to get some feedback > on my ideas. > > I think that Joe's original suggestion in the "Beginners tutorials" thread can do > something with regards to easing people into Erlang, but it cannot be the only thing. > > I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use > Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a > number of things we, as a community, can do better. > > One thing that stood out in relation to this thread was HardToLearn. > > HardToLearn influences a lot of things, but it also drives the worry > FindingDevelopers, which bad for the career prospects for all of us. > See Garrett's talk (when online) and you will understand. > > Why is Erlang HardToLearn? > > One can point to documentation and say it is not optimal. > One can ask for books on Erlang Concurrency Patterns as Joe did. > > But I feel there is a more fundamental problem that we need to address: > how to think like an Erlanger. > > Erlang is a concurrent functional language with a unique failure model. > More than 2 nines of the people being taught anything on programming will be exposed > to procedural or object oriented languages with exceptions and be told that threads > are hard (they are 'cause they will make you loose your hair). > > I think that a learning resource focused on teaching people the Erlang model from the > ground up would be a great improvement. A clear narrative around how do we solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > > My initial target for such a learning resources would be young people in the higher > grades of elementary school, say 12-15 years. Why? Because I want to influence them > before their minds are totally corrupted by other programming models. > > I don't think we would have to dumb anything down in particular for this group - we > just have to find a cool example and organise the learning around how to become so > good that one can solve such a problem. > Some sort of game will probably be the best candidate, say, some sort of Transport > Tycoon clone?!?! > > And now for the controversial part of my idea: this should probably be done using > Elixir plus something for the GUI. > Yes, I said the other E word, so I'm ready to be stoned ;-) [1] > > Why Elixir? > > Programming Elixir requires the same understanding of the Erlang concurrency model in > order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame > and misses the boat totally. > > So using Elixir would allow us to expose people to the Erlang model, which I think is > the main point. The more people that uses the BEAM, the better for the > FindingDevelopers problem. > > What is better about Elixir from a learning standpoint is, in my highly subjective > opinion, that you can get started quite easily with the mix tool. > > Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old > son to have a look in the "Introducing Elixir" book and his initial reaction was > "That's easy to read, it looks like lua." Minimising the amount of surprise is a good > thing! > > Given that I think games are awesome for teaching there needs to be some sort of GUI > element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it > is functional, but other suggestions are most welcome. > > Am I on the right track to anything with this? > Is there a need for such a learning resource? > Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? > > Cheers, > Torben > > [1] https://www.youtube.com/watch?v=SYkbqzWVHZI > -- > Torben Hoffmann > CTO > Erlang Solutions Ltd. > Tel: +45 25 14 05 38 > http://www.erlang-solutions.com > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Mon Jun 16 12:55:12 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 16 Jun 2014 12:55:12 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <539ECD10.5090903@ninenines.eu> I don't think the problem is so much that these things are hard to learn, but rather that you *have* to learn them. OO was hard to learn. Pointers took me a while also. In comparison Erlang was very fast to get started with as I started writing parsers for binary files immediately, then later on making it parallel and eventually learnt OTP and did other small things with the language. At the time there was basically no resources. LYSE had about 5 chapters so I didn't really use it. A few blog posts here and there helped a little, but it was mostly Joe's book. Today we have tons of resources. I do not think the docs problem shown by Garrett is the reason why Erlang is hard to learn. I think it's just correlation. (Of course some of the OTP docs are terrible, like sofs and bits of the common_test guide, but the docs on erlang.org are impressive; only they do not help the Erlang beginner, this is covered by Joe's book, LYSE and others.) If there is causation then a link to the free version of LYSE from the erlang.org docs page should be plenty enough to fix it. What I think is that people say Erlang is hard to learn because they expect to go from 0 knowledge to be able to use it for their job in a few hours. This is plain crazy, nobody learnt OO in a day, and nobody can learn concurrent/fault tolerant in a day. And it's even harder if your mind is stuck on a particular paradigm. Learning takes time. In today's impatient world this is seen as a weakness, but those who do take the time to learn Erlang get an exponential reward for their troubles. This is unfortunately hard to demonstrate to people who want everything immediately without the effort. But to kids who have never done programming before? They'll learn Erlang as easily as anything else. When you first start programming even "hello world" is a magical moment. When you've programmed for years it's a very boring moment and you want to skip ahead, which is impossible if you have to learn a new paradigm entirely. Kids do not have that problem. So stop worrying and teach them Erlang. On 06/16/2014 12:20 PM, Anthony Ramine wrote: > Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition? > -- Lo?c Hoguin http://ninenines.eu From ferenc.holzhauser@REDACTED Mon Jun 16 12:55:46 2014 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 16 Jun 2014 12:55:46 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <539EB979.40605@meetinghouse.net> References: <539EB979.40605@meetinghouse.net> Message-ID: The most important thing here I believe is to have a nice collection of simple tasks/problems that are appealing to the target audience and best (easiest/nicest) solved in Erlang. That's a bit of a challenge considering that Erlang is created to solve problems that are rather "industrial" and most people "from outside" can't really relate to. If the audience is not comfortable with understanding the problem itself then it is tricky to make them understand/like the solution too. This we can see with many new people getting into Erlang: The problems they are given are new and difficult to understand. So they often just go off and eagerly try to solve all sort of issues they are familiar with (even when they are not relevant in the particular case) before even trying to understand what the real challenge is. Then they start complaining that Erlang is not very good for some/many of those issues they are busy with. And other way around: people coming to Erlang with the right understanding of the problem area it is made for find it amazingly simple to learn. Coming from the wrong (or right ?) background my imagination fails to come up with these appealing challenges for the youngster target group, but I'm sure many of you can do much better. Ferenc On 16 June 2014 11:31, Miles Fidelman wrote: > Garrett Smith wrote: > >> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >> wrote: >> >> -snip- >> >> I think that a learning resource focused on teaching people the Erlang >>> model from the >>> ground up would be a great improvement. A clear narrative around how do >>> we solve a >>> problem the Erlang way. Teaching the basic constructs is not the problem. >>> >>> My initial target for such a learning resources would be young people in >>> the higher >>> grades of elementary school, say 12-15 years. Why? Because I want to >>> influence them >>> before their minds are totally corrupted by other programming models. >>> >>> I don't think we would have to dumb anything down in particular for this >>> group - we >>> just have to find a cool example and organise the learning around how to >>> become so >>> good that one can solve such a problem. >>> Some sort of game will probably be the best candidate, say, some sort of >>> Transport >>> Tycoon clone?!?! >>> >> I don't have enough experience teaching programming to this age group >> to provide anything more than a hunch. But I suspect that the Erlang >> way, which is hard enough for very seasoned programmers to grok, might >> be a bit ambitious for these young learners. >> >> I'm speaking in particular about the model that emerges when you >> isolate processes. It changes everything: your approach to building >> software (move from state oriented to activity oriented), error >> handling (move from defensive measures to assertive/let-it-crash), >> program structure (from monolith to system), and so on. The benefits >> of this shift are hard to get across, in my experience anyway. I wish >> it wasn't, or I wish I was better at communicating. >> >> >> > I'm with the folks who suggest that this group has fewer pre-conceptions > to unlearn. > > It strikes me that the actor model is far more natural for certain classes > of problems - network code, simulation, and gaming come to mind. It's > simply conceptually easier to think in terms of LOTS of independent > processes. > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Mon Jun 16 13:36:16 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Mon, 16 Jun 2014 07:36:16 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: > > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. Amen! The least relevant part of teaching kids programming is the syntax, or the choice of language - they don't, and won't, give a s**t about it. As a simple thought experiment, just look at how you raised your kids in a multi-lingual environment (yes my American brethren, this is hard. Pretend :-) ) Notice how they - fluidly - bounce across languages, massacring every grammar rule ever, but quite happily making sure that you understand that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio odio la piselli, i don't wanna, where is my red truck?" Mind you, they will pick up the rules over time, but the key here is the importance of the problem at hand ("How To Avoid Eating Peas") - the more immediately relevant it is to the young 'uns, the more rapidly they will pick up the tools, the specifics of the language be damned. Cheers On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < ferenc.holzhauser@REDACTED> wrote: > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. That's a bit of a challenge considering > that Erlang is created to solve problems that are rather "industrial" and > most people "from outside" can't really relate to. If the audience is not > comfortable with understanding the problem itself then it is tricky to make > them understand/like the solution too. > > This we can see with many new people getting into Erlang: The problems > they are given are new and difficult to understand. So they often just go > off and eagerly try to solve all sort of issues they are familiar with > (even when they are not relevant in the particular case) before even trying > to understand what the real challenge is. Then they start complaining that > Erlang is not very good for some/many of those issues they are busy with. > > And other way around: people coming to Erlang with the right understanding > of the problem area it is made for find it amazingly simple to learn. > > Coming from the wrong (or right ?) background my imagination fails to come > up with these appealing challenges for the youngster target group, but I'm > sure many of you can do much better. > > Ferenc > > > On 16 June 2014 11:31, Miles Fidelman wrote: > >> Garrett Smith wrote: >> >>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>> wrote: >>> >>> -snip- >>> >>> I think that a learning resource focused on teaching people the Erlang >>>> model from the >>>> ground up would be a great improvement. A clear narrative around how do >>>> we solve a >>>> problem the Erlang way. Teaching the basic constructs is not the >>>> problem. >>>> >>>> My initial target for such a learning resources would be young people >>>> in the higher >>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>> influence them >>>> before their minds are totally corrupted by other programming models. >>>> >>>> I don't think we would have to dumb anything down in particular for >>>> this group - we >>>> just have to find a cool example and organise the learning around how >>>> to become so >>>> good that one can solve such a problem. >>>> Some sort of game will probably be the best candidate, say, some sort >>>> of Transport >>>> Tycoon clone?!?! >>>> >>> I don't have enough experience teaching programming to this age group >>> to provide anything more than a hunch. But I suspect that the Erlang >>> way, which is hard enough for very seasoned programmers to grok, might >>> be a bit ambitious for these young learners. >>> >>> I'm speaking in particular about the model that emerges when you >>> isolate processes. It changes everything: your approach to building >>> software (move from state oriented to activity oriented), error >>> handling (move from defensive measures to assertive/let-it-crash), >>> program structure (from monolith to system), and so on. The benefits >>> of this shift are hard to get across, in my experience anyway. I wish >>> it wasn't, or I wish I was better at communicating. >>> >>> >>> >> I'm with the folks who suggest that this group has fewer pre-conceptions >> to unlearn. >> >> It strikes me that the actor model is far more natural for certain >> classes of problems - network code, simulation, and gaming come to mind. >> It's simply conceptually easier to think in terms of LOTS of independent >> processes. >> >> Miles Fidelman >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- * Mahesh Paolini-Subramanya That tall bald Indian guy..* * Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Mon Jun 16 13:55:37 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Mon, 16 Jun 2014 13:55:37 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: +1 on this, this rings very true to home. But I also believe that it needs to return results quickly. I.e. building a game is great, but if they have to "code" for days before they see something happen then they loose interest (assumption). So preparing "building blocks" might be a good approach and have them first implement higher level stuff and then step by step dig deeper and implement the building blocks you prepared. An other exercise I planned is to program a drone (not sure about the language there yet) to fly an obstacle course. So they see it is not just something that happens on their iPads ;) -Mark On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < mahesh@REDACTED> wrote: > The most important thing here I believe is to have a nice collection of >> simple tasks/problems that are appealing to the target audience and best >> (easiest/nicest) solved in Erlang. > > Amen! > The least relevant part of teaching kids programming is the syntax, or the > choice of language - they don't, and won't, give a s**t about it. > As a simple thought experiment, just look at how you raised your kids in a > multi-lingual environment (yes my American brethren, this is hard. Pretend > :-) ) Notice how they - fluidly - bounce across languages, massacring > every grammar rule ever, but quite happily making sure that you understand > that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio > odio la piselli, i don't wanna, where is my red truck?" > Mind you, they will pick up the rules over time, but the key here is the > importance of the problem at hand ("How To Avoid Eating Peas") - the more > immediately relevant it is to the young 'uns, the more rapidly they will > pick up the tools, the specifics of the language be damned. > > Cheers > > On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < > ferenc.holzhauser@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >> simple tasks/problems that are appealing to the target audience and best >> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >> that Erlang is created to solve problems that are rather "industrial" and >> most people "from outside" can't really relate to. If the audience is not >> comfortable with understanding the problem itself then it is tricky to make >> them understand/like the solution too. >> >> This we can see with many new people getting into Erlang: The problems >> they are given are new and difficult to understand. So they often just go >> off and eagerly try to solve all sort of issues they are familiar with >> (even when they are not relevant in the particular case) before even trying >> to understand what the real challenge is. Then they start complaining that >> Erlang is not very good for some/many of those issues they are busy with. >> >> And other way around: people coming to Erlang with the right >> understanding of the problem area it is made for find it amazingly simple >> to learn. >> >> Coming from the wrong (or right ?) background my imagination fails to >> come up with these appealing challenges for the youngster target group, but >> I'm sure many of you can do much better. >> >> Ferenc >> >> >> On 16 June 2014 11:31, Miles Fidelman wrote: >> >>> Garrett Smith wrote: >>> >>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>> wrote: >>>> >>>> -snip- >>>> >>>> I think that a learning resource focused on teaching people the Erlang >>>>> model from the >>>>> ground up would be a great improvement. A clear narrative around how >>>>> do we solve a >>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>> problem. >>>>> >>>>> My initial target for such a learning resources would be young people >>>>> in the higher >>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>> influence them >>>>> before their minds are totally corrupted by other programming models. >>>>> >>>>> I don't think we would have to dumb anything down in particular for >>>>> this group - we >>>>> just have to find a cool example and organise the learning around how >>>>> to become so >>>>> good that one can solve such a problem. >>>>> Some sort of game will probably be the best candidate, say, some sort >>>>> of Transport >>>>> Tycoon clone?!?! >>>>> >>>> I don't have enough experience teaching programming to this age group >>>> to provide anything more than a hunch. But I suspect that the Erlang >>>> way, which is hard enough for very seasoned programmers to grok, might >>>> be a bit ambitious for these young learners. >>>> >>>> I'm speaking in particular about the model that emerges when you >>>> isolate processes. It changes everything: your approach to building >>>> software (move from state oriented to activity oriented), error >>>> handling (move from defensive measures to assertive/let-it-crash), >>>> program structure (from monolith to system), and so on. The benefits >>>> of this shift are hard to get across, in my experience anyway. I wish >>>> it wasn't, or I wish I was better at communicating. >>>> >>>> >>>> >>> I'm with the folks who suggest that this group has fewer pre-conceptions >>> to unlearn. >>> >>> It strikes me that the actor model is far more natural for certain >>> classes of problems - network code, simulation, and gaming come to mind. >>> It's simply conceptually easier to think in terms of LOTS of independent >>> processes. >>> >>> Miles Fidelman >>> >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. .... Yogi Berra >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > > * Mahesh Paolini-Subramanya > That > tall bald Indian guy..* > * Google+ > | Blog | Twitter > | LinkedIn > * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Jun 16 14:03:05 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 16 Jun 2014 13:03:05 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: <539EDCF9.5090104@llaisdy.com> I don't know how graphic and snazzy things have to be for this age group ("kids these days, etc."). Sending messages from one node to another can be quite cool and easy, and very erlangy. Extra cool when the other node is someone else's computer in the classroom. For something like that, *not* having fancy graphics might even add to the effect. Ivan On 16/06/2014 12:55, Mark Nijhof wrote: > +1 on this, this rings very true to home. But I also believe that it > needs to return results quickly. I.e. building a game is great, but if > they have to "code" for days before they see something happen then they > loose interest (assumption). So preparing "building blocks" might be a > good approach and have them first implement higher level stuff and then > step by step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the > language there yet) to fly an obstacle course. So they see it is not > just something that happens on their iPads ;) > > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya > > wrote: > > The most important thing here I believe is to have a nice > collection of simple tasks/problems that are appealing to the > target audience and best (easiest/nicest) solved in Erlang. > > Amen! > The least relevant part of teaching kids programming is the syntax, > or the choice of language - they don't, and won't, give a s**t about > it. > As a simple thought experiment, just look at how you raised your > kids in a multi-lingual environment (yes my American brethren, this > is hard. Pretend :-) ) Notice how they - fluidly - bounce across > languages, massacring every grammar rule ever, but quite happily > making sure that you understand that "I amn't going to eat pea, ???? > ????????, ???? ????????, odio odio odio la piselli, i don't wanna, where > is my red truck?" > Mind you, they will pick up the rules over time, but the key here is > the importance of the problem at hand ("How To Avoid Eating Peas") - > the more immediately relevant it is to the young 'uns, the more > rapidly they will pick up the tools, the specifics of the language > be damned. > > Cheers > > On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser > > > wrote: > > The most important thing here I believe is to have a nice > collection of simple tasks/problems that are appealing to the > target audience and best (easiest/nicest) solved in Erlang. > That's a bit of a challenge considering that Erlang is created > to solve problems that are rather "industrial" and most people > "from outside" can't really relate to. If the audience is not > comfortable with understanding the problem itself then it is > tricky to make them understand/like the solution too. > > This we can see with many new people getting into Erlang: The > problems they are given are new and difficult to understand. So > they often just go off and eagerly try to solve all sort of > issues they are familiar with (even when they are not relevant > in the particular case) before even trying to understand what > the real challenge is. Then they start complaining that Erlang > is not very good for some/many of those issues they are busy with. > > And other way around: people coming to Erlang with the right > understanding of the problem area it is made for find it > amazingly simple to learn. > > Coming from the wrong (or right ?) background my imagination > fails to come up with these appealing challenges for the > youngster target group, but I'm sure many of you can do much > better. > > Ferenc > > > On 16 June 2014 11:31, Miles Fidelman > > > wrote: > > Garrett Smith wrote: > > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > > wrote: > > -snip- > > I think that a learning resource focused on teaching > people the Erlang model from the > ground up would be a great improvement. A clear > narrative around how do we solve a > problem the Erlang way. Teaching the basic > constructs is not the problem. > > My initial target for such a learning resources > would be young people in the higher > grades of elementary school, say 12-15 years. Why? > Because I want to influence them > before their minds are totally corrupted by other > programming models. > > I don't think we would have to dumb anything down in > particular for this group - we > just have to find a cool example and organise the > learning around how to become so > good that one can solve such a problem. > Some sort of game will probably be the best > candidate, say, some sort of Transport > Tycoon clone?!?! > > I don't have enough experience teaching programming to > this age group > to provide anything more than a hunch. But I suspect > that the Erlang > way, which is hard enough for very seasoned programmers > to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges > when you > isolate processes. It changes everything: your approach > to building > software (move from state oriented to activity > oriented), error > handling (move from defensive measures to > assertive/let-it-crash), > program structure (from monolith to system), and so on. > The benefits > of this shift are hard to get across, in my experience > anyway. I wish > it wasn't, or I wish I was better at communicating. > > > > I'm with the folks who suggest that this group has fewer > pre-conceptions to unlearn. > > It strikes me that the actor model is far more natural for > certain classes of problems - network code, simulation, and > gaming come to mind. It's simply conceptually easier to > think in terms of LOTS of independent processes. > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > * > *Mahesh Paolini-Subramanya > * > That tall bald Indian guy.. > * > * > Google+ | > Blog | Twitter > | LinkedIn > > * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From torben.hoffmann@REDACTED Mon Jun 16 14:18:16 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 14:18:16 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: Anthony Ramine writes: > Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition? Good question! I think that fault-tolerant, distributed programming is hard because there is a big context you need to address. The sheer about of things that can go wrong will make it difficult to get into. I think that concurrent programming is easy to learn: ------------------------------------------------------- I will start teaching your how to program in Erlang by showing you how the fundamental building block of Erlang, a process works. A process can receive and send messages. Sending messages is the only way two processes can communicate. Here's a simple process that just acknowledges that it has received a message and continues to do so over and over again: echo() -> receive Msg -> io:format("I'm happy, 'cause I recevied: ~p~n", [Msg] end, echo(). The file example1.erl contains the echo function. Open up the Erlang shell: $ erl c(example1). (this compiles the code and now you can start an echo process) Pid = spawn ( fun() -> echo() end ). (you just stored the process identifier (Pid) for the process you spawn, so now you can send it a message:) Pid ! "Erlang is cool". "I'm happy, 'cause I received: Erlang is cool" ------------------------------------------------------- Then one can add more layers to this, step by step. Pattern matching can be sneaked in very fast. We already have recursion going for us. Create a counter process and you have recursion with state data for a process. For a fresh mind it will be okay to have processes crash. They know of nothing else. But the key point is still to find a "killer" example that they find motivating. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From darach@REDACTED Mon Jun 16 14:29:32 2014 From: darach@REDACTED (Darach Ennis) Date: Mon, 16 Jun 2014 13:29:32 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: Hi guys, I have 4 kids under 10 years of age. They all program at some level except for the 2 year old. Although the 2 year old is already familiar with squishy circuits http://courseweb.stthomas.edu/apthomas/SquishyCircuits/ and conductive paint http://www.bareconductive.com/. So, the fact that diodes (namely LEDs) are directional (only work one way around) are familiar concepts to them from a young age. A good introductory language is scratch (http://scratch.mit.edu/) followed by Python (from about 7 years of age depending on the child, python works very well, the strict syntax is a benefit too). Python has excellent resources for kids and parents the "Python for Kids" book in http://www.amazon.co.uk/Python-Kids-Playful-Introduction-Programming/dp/1593274076/ref=sr_1_1?ie=UTF8&qid=1402920402&sr=8-1&keywords=python+for+kids which is playful. These are good starts but alone may not keep all children's interest. For this, tactile and interactive experiences are far better teaching aids. I use robotics, electronics, crafts together with scratch and python. With a basic feel for logic, structure and feedback from programming tools (with assistance) then Erlang would be a good next step. Torben is probably right with respect to age group by setting it to mid high school level. Elixir, also, would probably be an easier language to teach and to learn with fringe benefits (namely learning Elixir) for some of us... Kids program in their own time too. Games like minecraft reward pattern matching, for example. Far more important, in my experience, is allowing the kids drive the agenda and stepping back to assist, guide and encourage. As Mark points out, quick results are important so that the experience is playful and rewarding enough to keep interest levels high. For this, we would need a course that is fun, playful and assists both the teacher and student. Libraries like erlang-ale that allow interaction with cheap hardware such as arduino or raspberry pi also help to bring the subject to life. Another line of questioning exists around what to teach? Teach Erlang/Elixir the languages or teach the philosophy? A bit of both? I think the philosophy and modes of thinking are far more important... Cheers, Darach. On Mon, Jun 16, 2014 at 12:55 PM, Mark Nijhof < mark.nijhof@REDACTED> wrote: > +1 on this, this rings very true to home. But I also believe that it needs > to return results quickly. I.e. building a game is great, but if they have > to "code" for days before they see something happen then they loose > interest (assumption). So preparing "building blocks" might be a good > approach and have them first implement higher level stuff and then step by > step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the > language there yet) to fly an obstacle course. So they see it is not just > something that happens on their iPads ;) > > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. >> >> Amen! >> The least relevant part of teaching kids programming is the syntax, or >> the choice of language - they don't, and won't, give a s**t about it. >> As a simple thought experiment, just look at how you raised your kids in >> a multi-lingual environment (yes my American brethren, this is hard. >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >> massacring every grammar rule ever, but quite happily making sure that you >> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >> odio odio odio la piselli, i don't wanna, where is my red truck?" >> Mind you, they will pick up the rules over time, but the key here is the >> importance of the problem at hand ("How To Avoid Eating Peas") - the more >> immediately relevant it is to the young 'uns, the more rapidly they will >> pick up the tools, the specifics of the language be damned. >> >> Cheers >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>> that Erlang is created to solve problems that are rather "industrial" and >>> most people "from outside" can't really relate to. If the audience is not >>> comfortable with understanding the problem itself then it is tricky to make >>> them understand/like the solution too. >>> >>> This we can see with many new people getting into Erlang: The problems >>> they are given are new and difficult to understand. So they often just go >>> off and eagerly try to solve all sort of issues they are familiar with >>> (even when they are not relevant in the particular case) before even trying >>> to understand what the real challenge is. Then they start complaining that >>> Erlang is not very good for some/many of those issues they are busy with. >>> >>> And other way around: people coming to Erlang with the right >>> understanding of the problem area it is made for find it amazingly simple >>> to learn. >>> >>> Coming from the wrong (or right ?) background my imagination fails to >>> come up with these appealing challenges for the youngster target group, but >>> I'm sure many of you can do much better. >>> >>> Ferenc >>> >>> >>> On 16 June 2014 11:31, Miles Fidelman >>> wrote: >>> >>>> Garrett Smith wrote: >>>> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>> wrote: >>>>> >>>>> -snip- >>>>> >>>>> I think that a learning resource focused on teaching people the >>>>>> Erlang model from the >>>>>> ground up would be a great improvement. A clear narrative around how >>>>>> do we solve a >>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>> problem. >>>>>> >>>>>> My initial target for such a learning resources would be young people >>>>>> in the higher >>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>> influence them >>>>>> before their minds are totally corrupted by other programming models. >>>>>> >>>>>> I don't think we would have to dumb anything down in particular for >>>>>> this group - we >>>>>> just have to find a cool example and organise the learning around how >>>>>> to become so >>>>>> good that one can solve such a problem. >>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>> of Transport >>>>>> Tycoon clone?!?! >>>>>> >>>>> I don't have enough experience teaching programming to this age group >>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>> be a bit ambitious for these young learners. >>>>> >>>>> I'm speaking in particular about the model that emerges when you >>>>> isolate processes. It changes everything: your approach to building >>>>> software (move from state oriented to activity oriented), error >>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>> program structure (from monolith to system), and so on. The benefits >>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>> it wasn't, or I wish I was better at communicating. >>>>> >>>>> >>>>> >>>> I'm with the folks who suggest that this group has fewer >>>> pre-conceptions to unlearn. >>>> >>>> It strikes me that the actor model is far more natural for certain >>>> classes of problems - network code, simulation, and gaming come to mind. >>>> It's simply conceptually easier to think in terms of LOTS of independent >>>> processes. >>>> >>>> Miles Fidelman >>>> >>>> >>>> -- >>>> In theory, there is no difference between theory and practice. >>>> In practice, there is. .... Yogi Berra >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> >> * Mahesh Paolini-Subramanya >> That >> tall bald Indian guy..* >> * Google+ >> | Blog | Twitter >> | LinkedIn >> * >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Mon Jun 16 14:33:48 2014 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 16 Jun 2014 14:33:48 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: +1 Yes indeed, "simple" is key here. Probably the attention span in this age is still fairly short so quick results are very important. Actually in any age: quick results make learning more fun. Easy to use building blocks (functions) that make things more "spectacular" but allowing to stay focused on the key areas/ideas sound like a really good idea. On 16 June 2014 13:55, Mark Nijhof wrote: > +1 on this, this rings very true to home. But I also believe that it needs > to return results quickly. I.e. building a game is great, but if they have > to "code" for days before they see something happen then they loose > interest (assumption). So preparing "building blocks" might be a good > approach and have them first implement higher level stuff and then step by > step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the > language there yet) to fly an obstacle course. So they see it is not just > something that happens on their iPads ;) > > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. >> >> Amen! >> The least relevant part of teaching kids programming is the syntax, or >> the choice of language - they don't, and won't, give a s**t about it. >> As a simple thought experiment, just look at how you raised your kids in >> a multi-lingual environment (yes my American brethren, this is hard. >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >> massacring every grammar rule ever, but quite happily making sure that you >> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >> odio odio odio la piselli, i don't wanna, where is my red truck?" >> Mind you, they will pick up the rules over time, but the key here is the >> importance of the problem at hand ("How To Avoid Eating Peas") - the more >> immediately relevant it is to the young 'uns, the more rapidly they will >> pick up the tools, the specifics of the language be damned. >> >> Cheers >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>> that Erlang is created to solve problems that are rather "industrial" and >>> most people "from outside" can't really relate to. If the audience is not >>> comfortable with understanding the problem itself then it is tricky to make >>> them understand/like the solution too. >>> >>> This we can see with many new people getting into Erlang: The problems >>> they are given are new and difficult to understand. So they often just go >>> off and eagerly try to solve all sort of issues they are familiar with >>> (even when they are not relevant in the particular case) before even trying >>> to understand what the real challenge is. Then they start complaining that >>> Erlang is not very good for some/many of those issues they are busy with. >>> >>> And other way around: people coming to Erlang with the right >>> understanding of the problem area it is made for find it amazingly simple >>> to learn. >>> >>> Coming from the wrong (or right ?) background my imagination fails to >>> come up with these appealing challenges for the youngster target group, but >>> I'm sure many of you can do much better. >>> >>> Ferenc >>> >>> >>> On 16 June 2014 11:31, Miles Fidelman >>> wrote: >>> >>>> Garrett Smith wrote: >>>> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>> wrote: >>>>> >>>>> -snip- >>>>> >>>>> I think that a learning resource focused on teaching people the >>>>>> Erlang model from the >>>>>> ground up would be a great improvement. A clear narrative around how >>>>>> do we solve a >>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>> problem. >>>>>> >>>>>> My initial target for such a learning resources would be young people >>>>>> in the higher >>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>> influence them >>>>>> before their minds are totally corrupted by other programming models. >>>>>> >>>>>> I don't think we would have to dumb anything down in particular for >>>>>> this group - we >>>>>> just have to find a cool example and organise the learning around how >>>>>> to become so >>>>>> good that one can solve such a problem. >>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>> of Transport >>>>>> Tycoon clone?!?! >>>>>> >>>>> I don't have enough experience teaching programming to this age group >>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>> be a bit ambitious for these young learners. >>>>> >>>>> I'm speaking in particular about the model that emerges when you >>>>> isolate processes. It changes everything: your approach to building >>>>> software (move from state oriented to activity oriented), error >>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>> program structure (from monolith to system), and so on. The benefits >>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>> it wasn't, or I wish I was better at communicating. >>>>> >>>>> >>>>> >>>> I'm with the folks who suggest that this group has fewer >>>> pre-conceptions to unlearn. >>>> >>>> It strikes me that the actor model is far more natural for certain >>>> classes of problems - network code, simulation, and gaming come to mind. >>>> It's simply conceptually easier to think in terms of LOTS of independent >>>> processes. >>>> >>>> Miles Fidelman >>>> >>>> >>>> -- >>>> In theory, there is no difference between theory and practice. >>>> In practice, there is. .... Yogi Berra >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> >> * Mahesh Paolini-Subramanya >> That >> tall bald Indian guy..* >> * Google+ >> | Blog | Twitter >> | LinkedIn >> * >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Jun 16 14:47:34 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 16 Jun 2014 08:47:34 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <20140616124733.GL51530@ferdair.local> There's a lot to discuss in this thread (and Joe's one last week). This is a bit of a rambling from me, but yeah. On 06/16, Torben Hoffmann wrote: > Why is Erlang HardToLearn? > We should ask newcomers. When I started, Erlang was hard to learn for specific reasons: terminology, availability of information (we had the series of blog posts about an Erlang bank in OTP and the trapexit cookbooks, and that was most of it if you didn't feel like paying for a book) Since I've learned the language, the context changed in massive ways. LYSE is available, Cowboy has gained docs, Chicagoboss has a manual, more books have come around, more tutorials have been published, more talks have been made available. The problem isn't solved, but as a community, we shifted it to a new different area. Newcomers will have had the difficult pressure point somewhere else, and newcomers should therefore be able to tell us what *they* found hard, without having more experienced people contradicting them on many points -- We learned at a different time in a different context. We should ask people who have quit learning the language. Sometimes we will disagree, sometimes it will be due to their background of areas of interest, but there is a lot to for us to learn there. We should ask people who don't feel like learning it. We have pieces of data, such as people not liking the documentation, but we don't know *why* that is. Fixing the doc without fixing what's wrong is a bad idea, the same way premature optimization is. > how to think like an Erlanger. > > > I think that a learning resource focused on teaching people the Erlang model from the > ground up would be a great improvement. A clear narrative around how do we solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > Architecture is a definitive place where that needs to happen. I remember fumbling around wondering "but what do I make a process?" -- not sure if it's still an issue. I remember (and still often encounter) the issue of algorithms and datastructure. Everything you've learned before tends to assume O(1) access to mutable memory and it's no longer true. But then again, the relevance of this depends who you want to teach to. People who already program, or people who don't program yet. > My initial target for such a learning resources would be young people in the higher > grades of elementary school, say 12-15 years. Why? Because I want to influence them > before their minds are totally corrupted by other programming models. > Ah, so you want to be the first one to corrupt their minds, then! Snark aside, if we want to teach children, we should reach out to organisms such as https://www.codeclub.org.uk/ (who do this *every day*). We should look at what it is they do, ask them, see what they recommend, and tell us what wouldn't work. We can also look at How To Design Programs (http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed to teach programming to new people. They show you how to animate rocket ships in the first chapter. Erlang books (mine included) tell you what an atom is and why you should care. That's okay, they're not meant for newcomers. Or we can try reinventing the wheel based on what we feel is really important, but what we feel is really important likely doesn't overlap super well to what is important to a teenager. There are people who dedicate their lives to working on that problem, they're the ones from whom we should be looking for for guidance. Many of us know Erlang, but few of us know how to teach. A lot of us have forgotten what it is like to not know how to program. > > What is better about Elixir from a learning standpoint is, in my highly subjective > opinion, that you can get started quite easily with the mix tool. > If we want to reach out to crowds who aren't familiar with programming at all, mix isn't gonna cut it either. Look at Scratch (http://scratch.mit.edu/), look at Logo, look at Racket's graphical language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html), look at Arduino's documentation (http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which looks like it has another great intro. We have a long way to go, whether Elixir or Erlang is being used. Most people still put Erlang's sweet spot into the 'server' area in Garrett's data. Do we have to make the person we're gonna teach to care about servers to have teaching Erlang worth their time? Because it looks like otherwise, we might as well teach them a language more adapted to what they care about, not one adapted to what we care about. If we plan on reaching out to the already-programmign crowd, then yes, a tool like Mix is useful. It would also be useful within Erlang for its community. Rebar templates aren't even that far from allowing a lot of that functionality, but the community hasn't banded together to do it. There are probably deep-rooted reasons for it -- many of us adopted Erlang when you managed dependencies by downloading them and checking them in your repo, used makefiles all the time, and whatnot. The stuff rebar or erlang.mk do is already convenient enough for a lot of us to have felt the pain eased away, at least to the extent where we're not compelled to help fix the problem anymore. The workarounds are nicer than what we had before, so workarounds it will be. Forever. The same is true for the documentation. They're mostly reference manuals, which by definition are to be used as a reference -- it is expected you know their content and are only looking up additional information, or data to help you recall what you already learned. They won't be good to learn (the tutorials are nicer, but who knows about them?), and none of the regulars will have any incentive to fix it. Anyway, that's a long rant enough. Regards, Fred. From mononcqc@REDACTED Mon Jun 16 14:59:52 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 16 Jun 2014 08:59:52 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <20140616125952.GM51530@ferdair.local> Answers inline (and better seen through fixed-width font) On 06/16, Torben Hoffmann wrote: > I think that fault-tolerant, distributed programming is hard because there is a big > context you need to address. The sheer about of things that can go wrong will make it > difficult to get into. > > I think that concurrent programming is easy to learn: > I'm injecting myself in here to put emphasis on that part. The objective here is to teach concurrent programming and fault tolerance, right? > Here's a simple process that just acknowledges that it has received a message and > continues to do so over and over again: > > echo() -> > receive > Msg -> > io:format("I'm happy, 'cause I recevied: ~p~n", [Msg] > end, > echo(). > > The file example1.erl contains the echo function. > Open up the Erlang shell: > $ erl > > c(example1). > > (this compiles the code and now you can start an echo process) > > Pid = spawn ( fun() -> echo() end ). > > (you just stored the process identifier (Pid) for the process you spawn, so now you > can send it a message:) > > Pid ! "Erlang is cool". > > "I'm happy, 'cause I received: Erlang is cool" Here's what could be even nicer: have an IDE (or something like scratch). Every process is its own block on the screen, visual: *-------------[echo]--------------------------* *----[ProcX]-----* | echo() -> | | ... | | receive | *----------------* | Msg -> | | io:format("I'm happy, ...", [Msg]) | *---[Output]-----* | end, | | | | echo(), | | | *---------------------------------------------* *----------------* Click 'run'. Click the process, and have a prompt that lets you write in a message: "Erlang is cool". See the box hilighted when code runs there: *=============[echo]==========================* *----[ProcX]-----* || echo() -> || | ... | || receive || *----------------* || Msg -> || || io:format("I'm happy, ...", [Msg]) || *---[Output]-----* || end, || | | || echo(), || | | *=============================================* *----------------* see the output in another box: *-------------[echo]--------------------------* *----[ProcX]-----* | echo() -> | | ... | | receive | *----------------* | Msg -> | | io:format("I'm happy, ...", [Msg]) | *===[Output]=====* | end, | || I'm happy, || | echo(), | || 'cause I ... || *---------------------------------------------* *================* Hell, at this point it no longer needs to be Erlang, if you really want to teach the principles, and not the language. The question here really is: what's the objective? I mean, let people put colors on the boxes, even be able to change their shapes and brightness and events and they'll probably be able to create fancypants blinkenlight stuff, or want to use it as a monitoring dashboard for whatever. If the objective is to teach Erlang for them to learn the principles it stands for, teaching these principles should come before 'teaching Erlang' in how the educative environment is set up. If the objective is 'teach Erlang', then you'll have to make different assumptions entirely. Regards, Fred. From jon@REDACTED Mon Jun 16 15:10:31 2014 From: jon@REDACTED (Jon Schneider) Date: Mon, 16 Jun 2014 14:10:31 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <20140616125952.GM51530@ferdair.local> References: <20140616125952.GM51530@ferdair.local> Message-ID: <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> I think to understand fault tolerance you also need some understanding of business, customer service and the things that make a servers go offline such as power failure and road diggings. Therefore I am pretty sure think this particular aspect is not something a youngster is ever going to get. Jon From ivan@REDACTED Mon Jun 16 15:12:47 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 16 Jun 2014 14:12:47 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> References: <20140616125952.GM51530@ferdair.local> <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> Message-ID: <539EED4F.3000003@llaisdy.com> I'm in the UK. Youngsters here are quite familiar with power cuts and roadworks. Customer service not so much. On 16/06/2014 14:10, Jon Schneider wrote: > I think to understand fault tolerance you also need some understanding of > business, customer service and the things that make a servers go offline > such as power failure and road diggings. > > Therefore I am pretty sure think this particular aspect is not something a > youngster is ever going to get. > > Jon > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From essen@REDACTED Mon Jun 16 15:13:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 16 Jun 2014 15:13:19 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> References: <20140616125952.GM51530@ferdair.local> <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> Message-ID: <539EED6F.5020506@ninenines.eu> Don't assume clusters of servers. Even 4 year olds have experienced the annoyance of having a program crash. That's also what fault tolerance is about. On 06/16/2014 03:10 PM, Jon Schneider wrote: > I think to understand fault tolerance you also need some understanding of > business, customer service and the things that make a servers go offline > such as power failure and road diggings. > > Therefore I am pretty sure think this particular aspect is not something a > youngster is ever going to get. > > Jon > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Mon Jun 16 15:44:14 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 16 Jun 2014 09:44:14 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <539EED6F.5020506@ninenines.eu> References: <20140616125952.GM51530@ferdair.local> <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> <539EED6F.5020506@ninenines.eu> Message-ID: <20140616134413.GO51530@ferdair.local> Or teach it through side-channels with examples. Here's a random idea, probablu full of holes. Show them a bunch of castles with different things: heights for walls, thickness for walls, number of walls, towers, drawbridges, moats, etc. - Which castle is the best? - Which castle would protect you best against dragons? Against catapults? Against knights? Sorcerers? - Which castle would be the safest to be in? - Why is Castle A safer than Castle B for X? - There's an army of knights and catapults coming. How would you build a castle to protect you against it? - What do you do if the catapults break a wall or the drawbridge? - Here's my castle, can you make it safer against sorcerers? Maybe there's a way through there to lead a discussion into topics like redundancy, time to repair, and so on, without even needing to involve any computers or their related terminology in the first place. It may help to look at things such as Bloom's Taxonomy[1] into figuring out what to teach, how to teach it, and how to evaluate it, if one really wants to. [1]: http://en.wikipedia.org/wiki/Bloom%27s_taxonomy On 06/16, Lo?c Hoguin wrote: > Don't assume clusters of servers. Even 4 year olds have experienced the > annoyance of having a program crash. That's also what fault tolerance is > about. > > On 06/16/2014 03:10 PM, Jon Schneider wrote: > >I think to understand fault tolerance you also need some understanding of > >business, customer service and the things that make a servers go offline > >such as power failure and road diggings. > > > >Therefore I am pretty sure think this particular aspect is not something a > >youngster is ever going to get. > > > >Jon > > > >_______________________________________________ > >erlang-questions mailing list > >erlang-questions@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > http://ninenines.eu From donpedrothird@REDACTED Mon Jun 16 15:52:40 2014 From: donpedrothird@REDACTED (Evgeny M) Date: Mon, 16 Jun 2014 06:52:40 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> Imo the best tutorial for a beginner in any language (for someone who has experience in other ones) is something intermediate and familiar using some ready framework. Some thing which allows him/her to write in a hour something he used to build in other language. Often it is possible to do this even without knowing the language almost altogether. Like, tutorial on Django is a great way to start learning python. Something like this could be created for Erlang, either over pure Cowboy, or ChicagoBoss, or whatever. Just a dumb step by step (type this, run that) tutorial which can be done by anyone who has any programming background. In the end there will be a working site with forms, POSTs and other fancy stuff. I for one learned myself both python and erlang exactly this way (using Django and CB), skipping all the boring stuff. Doing hellowords, compiling modules, doing releases and other stuff like that is really very boring. You can do it later. Also I'd say talking about concurrency should start with OTP, and introduce spawn() later. First, OTP gen_server is just easier than standard spawn/receive for anyone with OO background. Second, spawn/receive is too similar to standard approaches to multithreading in mainstream languages and it is harder to see all the benefits of Erlang supervision and workers. Erlang as a language looks very hard for two weeks, then it suddenly becomes very easy (as a language, concurrency is always hard). Recursion is hard in any language without pattern matching. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Mon Jun 16 15:58:00 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Mon, 16 Jun 2014 09:58:00 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> Hi Torben, +1 for for teaching Erlang to kids. Back when dinosaurs roamed the earth, I was founding editor/publisher of Classroom Computer News, the first magazine in the U.S. devoted exclusively to instructional computer applications in K-12 classrooms. Subsequently I founded a company largely devoted to development of educational and consumer software for major publishers. We developed over 100 products ranging from Pockets the Learn and Do Kangaroo for pre-school youngsters to Algebra I for the high school set to The Scarsdale Medical Diet for obese adults for publishers ranging from Bantam to World Book. I bore you with this to make several points: 1) Don't underestimate what properly motivated kids can learn--- they're hard-wired to learn 2) Don't underestimate intrinsic curiosity as a motivator--- at least until it's squelched by repressive pedagogy 3) Create exploration environments to leverage intrinsic curiosity 4) Break the learning tasks into single key concepts that rest 100 percent on what the youngster already knows so concepts build one upon another 5) Keep it playful and fun 6) Tie the concepts into real-world (the child's world) issues and concerns 7) Challenge the youngster, but make success attainable 8) Reward success 9) Empower the youngster with demonstrable knowledge and skills that matter from the kid's perspective Additional thoughts --- My software development company was based on Forth so I was active in the exciting and innovative Forth community of the time. Given the limited resources of pcs of the era, Forth gave us tremendous competitive advantages. But I saw the Forth community wane and fizzle into near oblivion due, in part, to neglect of the interests of the upcoming generation of programmers. --- Tie into the Raspberry Pi phenomenon --- Show kids (and child-minded adults) how to build super computers out of Raspberry Pi, Odroid U3s or the super-cheap "mini pcs" coming out of China. (I'd love to work with anyone into that). Also, see: http://info.marygrove.edu/MATblog/bid/74832/Explore-Graph-Theory-with-Gifted-Elementary-Students [PDF] A Tangible Construction Kit for Exploring Graph Theory E Schweikardt, N Elumeze, M Eisenberg, MD Gross - code.arc.cmu.edu ABSTRACT Graphs are a versatile representation of many systems in computer science, the social sciences, and mathematics, but graph theory is not taught in schools. We present our work on Graphmaster, a computationally enhanced construction kit that enables children ... All the best, LRP Sent from my iPad > On Jun 16, 2014, at 3:51 AM, Torben Hoffmann wrote: > > Hi, > > The wonderful thread on "Beginners tutorials" > (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started > after the EUC last week has touched something in me and I want to get some feedback > on my ideas. > > I think that Joe's original suggestion in the "Beginners tutorials" thread can do > something with regards to easing people into Erlang, but it cannot be the only thing. > > I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use > Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a > number of things we, as a community, can do better. > > One thing that stood out in relation to this thread was HardToLearn. > > HardToLearn influences a lot of things, but it also drives the worry > FindingDevelopers, which bad for the career prospects for all of us. > See Garrett's talk (when online) and you will understand. > > Why is Erlang HardToLearn? > > One can point to documentation and say it is not optimal. > One can ask for books on Erlang Concurrency Patterns as Joe did. > > But I feel there is a more fundamental problem that we need to address: > how to think like an Erlanger. > > Erlang is a concurrent functional language with a unique failure model. > More than 2 nines of the people being taught anything on programming will be exposed > to procedural or object oriented languages with exceptions and be told that threads > are hard (they are 'cause they will make you loose your hair). > > I think that a learning resource focused on teaching people the Erlang model from the > ground up would be a great improvement. A clear narrative around how do we solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > > My initial target for such a learning resources would be young people in the higher > grades of elementary school, say 12-15 years. Why? Because I want to influence them > before their minds are totally corrupted by other programming models. > > I don't think we would have to dumb anything down in particular for this group - we > just have to find a cool example and organise the learning around how to become so > good that one can solve such a problem. > Some sort of game will probably be the best candidate, say, some sort of Transport > Tycoon clone?!?! > > And now for the controversial part of my idea: this should probably be done using > Elixir plus something for the GUI. > Yes, I said the other E word, so I'm ready to be stoned ;-) [1] > > Why Elixir? > > Programming Elixir requires the same understanding of the Erlang concurrency model in > order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame > and misses the boat totally. > > So using Elixir would allow us to expose people to the Erlang model, which I think is > the main point. The more people that uses the BEAM, the better for the > FindingDevelopers problem. > > What is better about Elixir from a learning standpoint is, in my highly subjective > opinion, that you can get started quite easily with the mix tool. > > Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old > son to have a look in the "Introducing Elixir" book and his initial reaction was > "That's easy to read, it looks like lua." Minimising the amount of surprise is a good > thing! > > Given that I think games are awesome for teaching there needs to be some sort of GUI > element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it > is functional, but other suggestions are most welcome. > > Am I on the right track to anything with this? > Is there a need for such a learning resource? > Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? > > Cheers, > Torben > > [1] https://www.youtube.com/watch?v=SYkbqzWVHZI > -- > Torben Hoffmann > CTO > Erlang Solutions Ltd. > Tel: +45 25 14 05 38 > http://www.erlang-solutions.com > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Mon Jun 16 16:04:32 2014 From: bob@REDACTED (Bob Ippolito) Date: Mon, 16 Jun 2014 09:04:32 -0500 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: On Monday, June 16, 2014, Mahesh Paolini-Subramanya < mahesh@REDACTED> wrote: > The most important thing here I believe is to have a nice collection of >> simple tasks/problems that are appealing to the target audience and best >> (easiest/nicest) solved in Erlang. > > Amen! > The least relevant part of teaching kids programming is the syntax, or the > choice of language - they don't, and won't, give a s**t about it. > As someone who has been trying to teach programming, I find that syntax is important in that syntax can get in the way. This is one of the reasons why the current fashion is to use visual languages for beginners as the "Lego" approach makes it impossible to violate syntax rules. Erlang might be the better choice as it has a simpler syntax with fewer rules and surprises in store. > As a simple thought experiment, just look at how you raised your kids in a > multi-lingual environment (yes my American brethren, this is hard. Pretend > :-) ) Notice how they - fluidly - bounce across languages, massacring > every grammar rule ever, but quite happily making sure that you understand > that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio > odio la piselli, i don't wanna, where is my red truck?" > Mind you, they will pick up the rules over time, but the key here is the > importance of the problem at hand ("How To Avoid Eating Peas") - the more > immediately relevant it is to the young 'uns, the more rapidly they will > pick up the tools, the specifics of the language be damned. > Human languages are different in that people can understand syntactically invalid spoken word or even mixed languages (per your example). With code you either write something that follows the rules and the computer understands it, or you have to figure out which rules you violated. If the tools are good and the rules are simple or at least consistent it might not be so frustrating to pick them up over time by trial and error, but having a few simple rules that are taught up-front might be even less frustrating than that. Cheers > > On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < > ferenc.holzhauser@REDACTED> wrote: > > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. That's a bit of a challenge considering > that Erlang is created to solve problems that are rather "industrial" and > most people "from outside" can't really relate to. If the audience is not > comfortable with understanding the problem itself then it is tricky to make > them understand/like the solution too. > > This we can see with many new people getting into Erlang: The problems > they are given are new and difficult to understand. So they often just go > off and eagerly try to solve all sort of issues they are familiar with > (even when they are not relevant in the particular case) before even trying > to understand what the real challenge is. Then they start complaining that > Erlang is not very good for some/many of those issues they are busy with. > > And other way around: people coming to Erlang with the right understanding > of the problem area it is made for find it amazingly simple to learn. > > Coming from the wrong (or right ?) background my imagination fails to come > up with these appealing challenges for the youngster target group, but I'm > sure many of you can do much better. > > Ferenc > > > On 16 June 2014 11:31, Miles Fidelman wrote: > > Garrett Smith wrote: > > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > > I think that a learning resource focused on teaching people the Erlang > model from the > ground up would be a great improvement. A clear narrative around how do we > solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > > My initial target for such a learning resources would be young people in > the higher > grades of elementary school, say 12-15 years. Why? Because I want to > influence them > before their minds are totally corrupted by other programming models. > > I don't think we would have to dumb anything down in particular for this > group - we > just have to find a cool example and organise the learning around how to > become so > good that one can solve such a problem. > Some sort of game will probably be the best candidate, say, some sort of > Transport > Tycoon clone?!?! > > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > > > > I'm with the folks who suggest that this group has fewer pre-conceptions > to unlearn. > > It strikes me that the actor model is far more natural for certain classes > of problems - network code, simulation, and gaming come to mind. It's > simply conceptually easier to think in terms of LOTS of independent > processes. > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. > > -- > > * Mahesh Paolini-Subramanya > That > tall bald Indian guy..* > * Google+ > | Blog | Twitter > | LinkedIn > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Jun 16 16:22:10 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 16 Jun 2014 16:22:10 +0200 Subject: [erlang-questions] node.js vs erlang Message-ID: I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. Program 1 is just fibonacci - I want a web server to compute fib(N) So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) My node.js attempt crashes Here's the code in fib.js --- fib.js var http = require('http'); var url = require('url'); function fib(n) { if (n < 2) { return 1; } else { return fib(n - 2) + fib(n - 1); } } http.createServer(function (req, res) { var q = url.parse(req.url, true).query; var n = q.n; var result = fib(n); console.log('fib('+ n + ')= '+result); res.writeHead(200, {'Content-Type': 'text/plain'}); res.end(result.toString()); }).listen(8124, "127.0.0.1"); console.log('Server running at http://127.0.0.1:8124/'); -- end -- now we run it $ node fib.js Server running at http://127.0.0.1:8124/ fib(2)= 2 /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 function fib(n) { ^ RangeError: Maximum call stack size exceeded fib(2) has run out of stack space???? $ node --version v0.8.21 Any ideas what I'm doing wrong Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Jun 16 16:24:23 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 16 Jun 2014 10:24:23 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> References: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> Message-ID: <539EFE17.8040602@meetinghouse.net> Lloyd R. Prentice wrote: > Hi Torben, > > +1 for for teaching Erlang to kids. > > Back when dinosaurs roamed the earth, I was founding editor/publisher > of Classroom Computer News, the first magazine in the U.S. devoted > exclusively to instructional computer applications in K-12 classrooms. > Subsequently I founded a company largely devoted to development of > educational and consumer software for major publishers. We developed > over 100 products ranging from Pockets the Learn and Do Kangaroo for > pre-school youngsters to Algebra I for the high school set to The > Scarsdale Medical Diet for obese adults for publishers ranging from > Bantam to World Book. > > I bore you with this to make several points: > > 1) Don't underestimate what properly motivated kids can learn--- > they're hard-wired to learn > 2) Don't underestimate intrinsic curiosity as a motivator--- at least > until it's squelched by repressive pedagogy > 3) Create exploration environments to leverage intrinsic curiosity > 4) Break the learning tasks into single key concepts that rest 100 > percent on what the youngster already knows so concepts build one upon > another > 5) Keep it playful and fun > 6) Tie the concepts into real-world (the child's world) issues and > concerns > 7) Challenge the youngster, but make success attainable > 8) Reward success > 9) Empower the youngster with demonstrable knowledge and skills that > matter from the kid's perspective > Good points all. Re. motivation: Robotics is big right now - particularly in the context of Lego Mindstorms and then the FIRST Robotics competitions. Erlang, as a language for robot behaviors (subsumption architecture) and cooperating robots, might be really cool. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jocke@REDACTED Mon Jun 16 16:44:38 2014 From: jocke@REDACTED (Joacim G.) Date: Mon, 16 Jun 2014 16:44:38 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <539F02D6.3080904@tail-f.com> I can't help with node.js but I found this informative: http://notes.ericjiang.com/posts/751 /Jocke 2014-06-16 16:22, Joe Armstrong skrev: > I'm trying to compare node.js with erlang. I'm a total node.js novice > BTW - but I've written some JS. > > Program 1 is just fibonacci - I want a web server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 should compute and return > fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at http://127.0.0.1:8124/' > ); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paulo.ferraz.oliveira@REDACTED Mon Jun 16 16:44:38 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Mon, 16 Jun 2014 15:44:38 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: Hello, Joe. If you include a console.log(req.url); inside your createServer callback you'll probably see that your browser is trying to obtain /favicon.ico (a second request), which causes the infinite loop, thus the RangeError, as n is undefined for the second call and you aren't dealing with this condition. Hope it helps. - Paulo F. Oliveira On 16 June 2014 15:22, Joe Armstrong wrote: > I'm trying to compare node.js with erlang. I'm a total node.js novice BTW > - but I've written some JS. > > Program 1 is just fibonacci - I want a web server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 should compute and return > fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at http://127.0.0.1:8124/'); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Jun 16 16:55:52 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 16 Jun 2014 07:55:52 -0700 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <20140616124733.GL51530@ferdair.local> References: <20140616124733.GL51530@ferdair.local> Message-ID: <1402930552.68297.YahooMailNeo@web163601.mail.gq1.yahoo.com> In the dark ages Ken Kahn demoed ToonTalk, which I thought was a pretty neat way of teaching concurrent programming (with actors) to kids.? ToonTalk - Wikipedia, the free encyclopedia ToonTalk - Wikipedia, the free encyclopedia ToonTalk is a computer programming system intended to be programmed by children. The "Toon" part stands for cartoon. The system's presentation is in the form of animated characters, including robots that can be trained by example. It is one of the few successful implementations ou... View on en.wikipedia.org Preview by Yahoo Or this:?Computer scientists ask "What is ToonTalk?" Computer scientists ask "What is ToonTalk?" The Computer Science behind ToonTalk ToonTalk is an interpreter for a concurrent constraint programming language. View on www.toontalk.com Preview by Yahoo Best, Thomas On Monday, June 16, 2014 2:47 PM, Fred Hebert wrote: > > >There's a lot to discuss in this thread (and Joe's one last week). This >is a bit of a rambling from me, but yeah. > >On 06/16, Torben Hoffmann wrote: >> Why is Erlang HardToLearn? >> > >We should ask newcomers. When I started, Erlang was hard to learn for >specific reasons: terminology, availability of information (we had the >series of blog posts about an Erlang bank in OTP and the trapexit >cookbooks, and that was most of it if you didn't feel like paying for a >book) > >Since I've learned the language, the context changed in massive ways. >LYSE is available, Cowboy has gained docs, Chicagoboss has a manual, >more books have come around, more tutorials have been published, more >talks have been made available. > >The problem isn't solved, but as a community, we shifted it to a new >different area. Newcomers will have had the difficult pressure point >somewhere else, and newcomers should therefore be able to tell us what >*they* found hard, without having more experienced people contradicting >them on many points -- We learned at a different time in a different >context. > >We should ask people who have quit learning the language. Sometimes we >will disagree, sometimes it will be due to their background of areas of >interest, but there is a lot to for us to learn there. > >We should ask people who don't feel like learning it. We have pieces of >data, such as people not liking the documentation, but we don't know >*why* that is. Fixing the doc without fixing what's wrong is a bad idea, >the same way premature optimization is. > > >>? ? how to think like an Erlanger. >> >> >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> > >Architecture is a definitive place where that needs to happen. I >remember fumbling around wondering "but what do I make a process?" -- >not sure if it's still an issue. > >I remember (and still often encounter) the issue of algorithms and >datastructure. Everything you've learned before tends to assume O(1) >access to mutable memory and it's no longer true. But then again, the >relevance of this depends who you want to teach to. People who already >program, or people who don't program yet. > >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> > >Ah, so you want to be the first one to corrupt their minds, then! > >Snark aside, if we want to teach children, we should reach out to >organisms such as https://www.codeclub.org.uk/ (who do this *every >day*). We should look at what it is they do, ask them, see what they >recommend, and tell us what wouldn't work. > >We can also look at How To Design Programs >(http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed >to teach programming to new people. They show you how to animate rocket >ships in the first chapter. Erlang books (mine included) tell you what >an atom is and why you should care. That's okay, they're not meant for >newcomers. > >Or we can try reinventing the wheel based on what we feel is really >important, but what we feel is really important likely doesn't overlap >super well to what is important to a teenager. There are people who >dedicate their lives to working on that problem, they're the ones from >whom we should be looking for for guidance. > >Many of us know Erlang, but few of us know how to teach. A lot of us >have forgotten what it is like to not know how to program. > >> >> What is better about Elixir from a learning standpoint is, in my highly subjective >> opinion, that you can get started quite easily with the mix tool. >> > >If we want to reach out to crowds who aren't familiar with programming >at all, mix isn't gonna cut it either. Look at Scratch >(http://scratch.mit.edu/), look at Logo, look at Racket's graphical >language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html), >look at Arduino's documentation >(http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which >looks like it has another great intro. > >We have a long way to go, whether Elixir or Erlang is being used. Most >people still put Erlang's sweet spot into the 'server' area in Garrett's >data. Do we have to make the person we're gonna teach to care about >servers to have teaching Erlang worth their time? Because it looks like >otherwise, we might as well teach them a language more adapted to what >they care about, not one adapted to what we care about. > >If we plan on reaching out to the already-programmign crowd, then yes, a >tool like Mix is useful. It would also be useful within Erlang for its >community. Rebar templates aren't even that far from allowing a lot of >that functionality, but the community hasn't banded together to do it. > >There are probably deep-rooted reasons for it -- many of us adopted >Erlang when you managed dependencies by downloading them and checking >them in your repo, used makefiles all the time, and whatnot. The stuff >rebar or erlang.mk do is already convenient enough for a lot of us to >have felt the pain eased away, at least to the extent where we're not >compelled to help fix the problem anymore. The workarounds are nicer >than what we had before, so workarounds it will be. Forever. > >The same is true for the documentation. They're mostly reference manuals, >which by definition are to be used as a reference -- it is expected you >know their content and are only looking up additional information, or >data to help you recall what you already learned. They won't be good to >learn (the tutorials are nicer, but who knows about them?), and none of >the regulars will have any incentive to fix it. > >Anyway, that's a long rant enough. > >Regards, >Fred. > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Mon Jun 16 16:39:49 2014 From: tom@REDACTED (Tom van Neerijnen) Date: Mon, 16 Jun 2014 15:39:49 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: I copy pasted your example and "$ curl http://127.0.0.1:8124/?n=2" =:= 2, so that works as expected. However "$ curl http://127.0.0.1:8124/" resulted in the same crash as you got. Put a console.log(q); and maybe a console.log(n); in your http.createServer callback to make sure n is what you expect it to be. My guess is it's undefined or something that isn't a number, which your base case will never match and cause your call stack to overflow. On Mon, Jun 16, 2014 at 3:22 PM, Joe Armstrong wrote: > I'm trying to compare node.js with erlang. I'm a total node.js novice BTW > - but I've written some JS. > > Program 1 is just fibonacci - I want a web server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 should compute and return > fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at http://127.0.0.1:8124/'); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Thomas van Neerijnen http://tomvn.com +4477 1709 7670 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.facorro@REDACTED Mon Jun 16 16:55:57 2014 From: juan.facorro@REDACTED (Juan Facorro) Date: Mon, 16 Jun 2014 07:55:57 -0700 (PDT) Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: Hi Joe, There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away. HTH, J On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: > > I'm trying to compare node.js with erlang. I'm a total node.js novice BTW > - but I've written some JS. > > Program 1 is just fibonacci - I want a web server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 should compute and return > fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at http://127.0.0.1:8124/'); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Mon Jun 16 18:12:41 2014 From: tony@REDACTED (Tony Rogvall) Date: Mon, 16 Jun 2014 18:12:41 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> On 16 jun 2014, at 13:55, Mark Nijhof wrote: > +1 on this, this rings very true to home. But I also believe that it needs to return results quickly. I.e. building a game is great, but if they have to "code" for days before they see something happen then they loose interest (assumption). So preparing "building blocks" might be a good approach and have them first implement higher level stuff and then step by step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the language there yet) to fly an obstacle course. So they see it is not just something that happens on their iPads ;) > You program drone in Erlang of course :-) https://github.com/tonyrog/edrone /Tony > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya wrote: > The most important thing here I believe is to have a nice collection of simple tasks/problems that are appealing to the target audience and best (easiest/nicest) solved in Erlang. > Amen! > The least relevant part of teaching kids programming is the syntax, or the choice of language - they don't, and won't, give a s**t about it. > As a simple thought experiment, just look at how you raised your kids in a multi-lingual environment (yes my American brethren, this is hard. Pretend :-) ) Notice how they - fluidly - bounce across languages, massacring every grammar rule ever, but quite happily making sure that you understand that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio odio la piselli, i don't wanna, where is my red truck?" > Mind you, they will pick up the rules over time, but the key here is the importance of the problem at hand ("How To Avoid Eating Peas") - the more immediately relevant it is to the young 'uns, the more rapidly they will pick up the tools, the specifics of the language be damned. > > Cheers > > On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser wrote: > The most important thing here I believe is to have a nice collection of simple tasks/problems that are appealing to the target audience and best (easiest/nicest) solved in Erlang. That's a bit of a challenge considering that Erlang is created to solve problems that are rather "industrial" and most people "from outside" can't really relate to. If the audience is not comfortable with understanding the problem itself then it is tricky to make them understand/like the solution too. > > This we can see with many new people getting into Erlang: The problems they are given are new and difficult to understand. So they often just go off and eagerly try to solve all sort of issues they are familiar with (even when they are not relevant in the particular case) before even trying to understand what the real challenge is. Then they start complaining that Erlang is not very good for some/many of those issues they are busy with. > > And other way around: people coming to Erlang with the right understanding of the problem area it is made for find it amazingly simple to learn. > > Coming from the wrong (or right ?) background my imagination fails to come up with these appealing challenges for the youngster target group, but I'm sure many of you can do much better. > > Ferenc > > > On 16 June 2014 11:31, Miles Fidelman wrote: > Garrett Smith wrote: > On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > wrote: > > -snip- > > I think that a learning resource focused on teaching people the Erlang model from the > ground up would be a great improvement. A clear narrative around how do we solve a > problem the Erlang way. Teaching the basic constructs is not the problem. > > My initial target for such a learning resources would be young people in the higher > grades of elementary school, say 12-15 years. Why? Because I want to influence them > before their minds are totally corrupted by other programming models. > > I don't think we would have to dumb anything down in particular for this group - we > just have to find a cool example and organise the learning around how to become so > good that one can solve such a problem. > Some sort of game will probably be the best candidate, say, some sort of Transport > Tycoon clone?!?! > I don't have enough experience teaching programming to this age group > to provide anything more than a hunch. But I suspect that the Erlang > way, which is hard enough for very seasoned programmers to grok, might > be a bit ambitious for these young learners. > > I'm speaking in particular about the model that emerges when you > isolate processes. It changes everything: your approach to building > software (move from state oriented to activity oriented), error > handling (move from defensive measures to assertive/let-it-crash), > program structure (from monolith to system), and so on. The benefits > of this shift are hard to get across, in my experience anyway. I wish > it wasn't, or I wish I was better at communicating. > > > > I'm with the folks who suggest that this group has fewer pre-conceptions to unlearn. > > It strikes me that the actor model is far more natural for certain classes of problems - network code, simulation, and gaming come to mind. It's simply conceptually easier to think in terms of LOTS of independent processes. > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Mahesh Paolini-Subramanya > That tall bald Indian guy.. > Google+ | Blog | Twitter | LinkedIn > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From co7eb@REDACTED Mon Jun 16 18:21:33 2014 From: co7eb@REDACTED (=?UTF-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Mon, 16 Jun 2014 12:21:33 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <006601cf897f$0df07cb0$29d17610$@frcuba.co.cu> Hi Joe, I did try nodejs some time ago and I can tell from that experience that regards to development performance and confortable programming, nodejs is very nice, it is very intelligent way to program, it is faster too, but I have to tell you this, nodejs as a program language is very close or even more nicely than Erlang, but as a technology it is the biggest crap I ever taste, sorry about that, everything there explode and you have no control at all of the explodes, if the stack ran out; and it does quickly and easily, it just ran out without any possible solution and the system goes down inevitably, I came out to think that you cannot program a serious thing over that! Despite of that simple fact, all other is fine, nicely coding programming I think. Best regards, Ivan. De: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] En nombre de Joe Armstrong Enviado el: lunes, 16 de junio de 2014 10:22 a.m. Para: Erlang Asunto: [erlang-questions] node.js vs erlang I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. Program 1 is just fibonacci - I want a web server to compute fib(N) So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) My node.js attempt crashes Here's the code in fib.js --- fib.js var http = require('http'); var url = require('url'); function fib(n) { if (n < 2) { return 1; } else { return fib(n - 2) + fib(n - 1); } } http.createServer(function (req, res) { var q = url.parse(req.url, true).query; var n = q.n; var result = fib(n); console.log('fib('+ n + ')= '+result); res.writeHead(200, {'Content-Type': 'text/plain'}); res.end(result.toString()); }).listen(8124, "127.0.0.1"); console.log('Server running at http://127.0.0.1:8124/'); -- end -- now we run it $ node fib.js Server running at http://127.0.0.1:8124/ fib(2)= 2 /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 function fib(n) { ^ RangeError: Maximum call stack size exceeded fib(2) has run out of stack space???? $ node --version v0.8.21 Any ideas what I'm doing wrong Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Jun 16 18:50:29 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 16 Jun 2014 18:50:29 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <006601cf897f$0df07cb0$29d17610$@frcuba.co.cu> References: <006601cf897f$0df07cb0$29d17610$@frcuba.co.cu> Message-ID: <6CDEE746-4F65-496F-BE00-EAC241FA2EE2@feuerlabs.com> On 16 Jun 2014, at 18:21, Ivan Carmenates Garc?a wrote: > I came out to think that you cannot program a serious thing over that! Despite of that simple fact, all other is fine, nicely coding programming I think. Good one! :) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Mon Jun 16 19:30:24 2014 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Mon, 16 Jun 2014 19:30:24 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> Message-ID: Robotics is really nice but in this case accessibility is even nicer. It is great if kids can play after class too with interesting things without having to put items of fairly significant value (for some) on their wishlist. These days a computer with internet access can be a fascinatingly accessible way of creativity. An idea could be to make a simple game backend to compete with their friends and fellow students (e.g. a 2d tank shooting game or something). Eventually with chat and similar functions to add. Then the teacher could make things go wrong on the server(s) that they'd need to fix (distribute/scale/fail over) depending on their progress. You could lure them into AI like things too if you fancy. I'm sure someone with the skills (e.g. SVG/ezwebframe) and time could make some simple client "building blocks" work for something like this. On 16 June 2014 18:12, Tony Rogvall wrote: > > On 16 jun 2014, at 13:55, Mark Nijhof > wrote: > > +1 on this, this rings very true to home. But I also believe that it needs > to return results quickly. I.e. building a game is great, but if they have > to "code" for days before they see something happen then they loose > interest (assumption). So preparing "building blocks" might be a good > approach and have them first implement higher level stuff and then step by > step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the > language there yet) to fly an obstacle course. So they see it is not just > something that happens on their iPads ;) > > You program drone in Erlang of course :-) > > https://github.com/tonyrog/edrone > > /Tony > > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. >> >> Amen! >> The least relevant part of teaching kids programming is the syntax, or >> the choice of language - they don't, and won't, give a s**t about it. >> As a simple thought experiment, just look at how you raised your kids in >> a multi-lingual environment (yes my American brethren, this is hard. >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >> massacring every grammar rule ever, but quite happily making sure that you >> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >> odio odio odio la piselli, i don't wanna, where is my red truck?" >> Mind you, they will pick up the rules over time, but the key here is the >> importance of the problem at hand ("How To Avoid Eating Peas") - the more >> immediately relevant it is to the young 'uns, the more rapidly they will >> pick up the tools, the specifics of the language be damned. >> >> Cheers >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>> that Erlang is created to solve problems that are rather "industrial" and >>> most people "from outside" can't really relate to. If the audience is not >>> comfortable with understanding the problem itself then it is tricky to make >>> them understand/like the solution too. >>> >>> This we can see with many new people getting into Erlang: The problems >>> they are given are new and difficult to understand. So they often just go >>> off and eagerly try to solve all sort of issues they are familiar with >>> (even when they are not relevant in the particular case) before even trying >>> to understand what the real challenge is. Then they start complaining that >>> Erlang is not very good for some/many of those issues they are busy with. >>> >>> And other way around: people coming to Erlang with the right >>> understanding of the problem area it is made for find it amazingly simple >>> to learn. >>> >>> Coming from the wrong (or right ?) background my imagination fails to >>> come up with these appealing challenges for the youngster target group, but >>> I'm sure many of you can do much better. >>> >>> Ferenc >>> >>> >>> On 16 June 2014 11:31, Miles Fidelman >>> wrote: >>> >>>> Garrett Smith wrote: >>>> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>> wrote: >>>>> >>>>> -snip- >>>>> >>>>> I think that a learning resource focused on teaching people the >>>>>> Erlang model from the >>>>>> ground up would be a great improvement. A clear narrative around how >>>>>> do we solve a >>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>> problem. >>>>>> >>>>>> My initial target for such a learning resources would be young people >>>>>> in the higher >>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>> influence them >>>>>> before their minds are totally corrupted by other programming models. >>>>>> >>>>>> I don't think we would have to dumb anything down in particular for >>>>>> this group - we >>>>>> just have to find a cool example and organise the learning around how >>>>>> to become so >>>>>> good that one can solve such a problem. >>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>> of Transport >>>>>> Tycoon clone?!?! >>>>>> >>>>> I don't have enough experience teaching programming to this age group >>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>> be a bit ambitious for these young learners. >>>>> >>>>> I'm speaking in particular about the model that emerges when you >>>>> isolate processes. It changes everything: your approach to building >>>>> software (move from state oriented to activity oriented), error >>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>> program structure (from monolith to system), and so on. The benefits >>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>> it wasn't, or I wish I was better at communicating. >>>>> >>>>> >>>>> >>>> I'm with the folks who suggest that this group has fewer >>>> pre-conceptions to unlearn. >>>> >>>> It strikes me that the actor model is far more natural for certain >>>> classes of problems - network code, simulation, and gaming come to mind. >>>> It's simply conceptually easier to think in terms of LOTS of independent >>>> processes. >>>> >>>> Miles Fidelman >>>> >>>> >>>> -- >>>> In theory, there is no difference between theory and practice. >>>> In practice, there is. .... Yogi Berra >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> >> * Mahesh Paolini-Subramanya >> That >> tall bald Indian guy..* >> * Google+ >> | Blog | Twitter >> | LinkedIn >> * >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Mon Jun 16 19:58:35 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Mon, 16 Jun 2014 13:58:35 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> Message-ID: I remember using Rur-ple http://rur-ple.sourceforge.net/ to get my daughter interested in programming. She seemed to find it fairly entertaining and I was quite impressed at how quickly she progressed. Something similar for Erlang may work quite well. Leonard -- On Mon, Jun 16, 2014 at 1:30 PM, Ferenc Holzhauser wrote: > Robotics is really nice but in this case accessibility is even nicer. It is > great if kids can play after class too with interesting things without > having to put items of fairly significant value (for some) on their > wishlist. These days a > computer with internet access can be a fascinatingly accessible way of > creativity. An idea could be to make a simple game backend to compete with > their friends and fellow students (e.g. a 2d tank shooting game or > something). Eventually with chat and similar functions to add. Then the > teacher could make things go wrong on the server(s) that they'd need to fix > (distribute/scale/fail over) depending on their progress. You could lure > them into AI like things too if you fancy. I'm sure someone with the skills > (e.g. SVG/ezwebframe) and time could make some simple client "building > blocks" work for something like this. > > > On 16 June 2014 18:12, Tony Rogvall wrote: >> >> >> On 16 jun 2014, at 13:55, Mark Nijhof >> wrote: >> >> +1 on this, this rings very true to home. But I also believe that it needs >> to return results quickly. I.e. building a game is great, but if they have >> to "code" for days before they see something happen then they loose interest >> (assumption). So preparing "building blocks" might be a good approach and >> have them first implement higher level stuff and then step by step dig >> deeper and implement the building blocks you prepared. >> >> An other exercise I planned is to program a drone (not sure about the >> language there yet) to fly an obstacle course. So they see it is not just >> something that happens on their iPads ;) >> >> You program drone in Erlang of course :-) >> >> https://github.com/tonyrog/edrone >> >> /Tony >> >> -Mark >> >> >> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya >> wrote: >>>> >>>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. >>> >>> Amen! >>> The least relevant part of teaching kids programming is the syntax, or >>> the choice of language - they don't, and won't, give a s**t about it. >>> As a simple thought experiment, just look at how you raised your kids in >>> a multi-lingual environment (yes my American brethren, this is hard. Pretend >>> :-) ) Notice how they - fluidly - bounce across languages, massacring >>> every grammar rule ever, but quite happily making sure that you understand >>> that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio odio >>> la piselli, i don't wanna, where is my red truck?" >>> Mind you, they will pick up the rules over time, but the key here is the >>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>> immediately relevant it is to the young 'uns, the more rapidly they will >>> pick up the tools, the specifics of the language be damned. >>> >>> Cheers >>> >>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser >>> wrote: >>>> >>>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>> that Erlang is created to solve problems that are rather "industrial" and >>>> most people "from outside" can't really relate to. If the audience is not >>>> comfortable with understanding the problem itself then it is tricky to make >>>> them understand/like the solution too. >>>> >>>> This we can see with many new people getting into Erlang: The problems >>>> they are given are new and difficult to understand. So they often just go >>>> off and eagerly try to solve all sort of issues they are familiar with (even >>>> when they are not relevant in the particular case) before even trying to >>>> understand what the real challenge is. Then they start complaining that >>>> Erlang is not very good for some/many of those issues they are busy with. >>>> >>>> And other way around: people coming to Erlang with the right >>>> understanding of the problem area it is made for find it amazingly simple to >>>> learn. >>>> >>>> Coming from the wrong (or right ?) background my imagination fails to >>>> come up with these appealing challenges for the youngster target group, but >>>> I'm sure many of you can do much better. >>>> >>>> Ferenc >>>> >>>> >>>> On 16 June 2014 11:31, Miles Fidelman >>>> wrote: >>>>> >>>>> Garrett Smith wrote: >>>>>> >>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>> wrote: >>>>>> >>>>>> -snip- >>>>>> >>>>>>> I think that a learning resource focused on teaching people the >>>>>>> Erlang model from the >>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>> do we solve a >>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>> problem. >>>>>>> >>>>>>> My initial target for such a learning resources would be young people >>>>>>> in the higher >>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>> influence them >>>>>>> before their minds are totally corrupted by other programming models. >>>>>>> >>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>> this group - we >>>>>>> just have to find a cool example and organise the learning around how >>>>>>> to become so >>>>>>> good that one can solve such a problem. >>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>> of Transport >>>>>>> Tycoon clone?!?! >>>>>> >>>>>> I don't have enough experience teaching programming to this age group >>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>> be a bit ambitious for these young learners. >>>>>> >>>>>> I'm speaking in particular about the model that emerges when you >>>>>> isolate processes. It changes everything: your approach to building >>>>>> software (move from state oriented to activity oriented), error >>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>> program structure (from monolith to system), and so on. The benefits >>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>> it wasn't, or I wish I was better at communicating. >>>>>> >>>>>> >>>>> >>>>> I'm with the folks who suggest that this group has fewer >>>>> pre-conceptions to unlearn. >>>>> >>>>> It strikes me that the actor model is far more natural for certain >>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>> processes. >>>>> >>>>> Miles Fidelman >>>>> >>>>> >>>>> -- >>>>> In theory, there is no difference between theory and practice. >>>>> In practice, there is. .... Yogi Berra >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> >>> -- >>> Mahesh Paolini-Subramanya >>> That tall bald Indian guy.. >>> Google+ | Blog | Twitter | LinkedIn >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> "Installing applications can lead to corruption over time. Applications >> gradually write over each other's libraries, partial upgrades occur, user >> and system errors happen, and minute changes may be unnoticeable and >> difficult to fix" >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From lloyd@REDACTED Mon Jun 16 20:57:55 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 16 Jun 2014 14:57:55 -0400 (EDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> Message-ID: <1402945075.869528733@apps.rackspace.com> Hello, So many great ideas. So many talented contributors. A fantasy--- One or more of... - a website - hosting platform - an e-book - free for download - a hard-cover book - royalties kick back to help kids - a hardware platform - profits kick back to help kids Projects - build your own website - chat with friends - organize your collections - build a multi-player game - control a robot - control your house - build your own supercomputer ???? Contest for project submissions Team - dedicated Erlang volunteers - perhaps formalize with a foundation ala Raspberry Pi Process - Dream - Brainstorm - Set goals - Organize - Delegate - Produce Platform - Software projects can be done on Windows assuming easy peasy Erlang install - How can we get youngsters into Linux? - A hardware platform would open up robotics and control applications: Cheap (under $100) ARM boards -- Arduino etc. -- Raspberry Pi -- I have an Odroid U3 on my desk. No time to fire it up yet; but very compact, quiet, low power, plenty of computing power, runs Linux. Total of $90 for board, pwr supply, HDMI cable, wi-fi module, and case. Would need an MicroSD card with Linux and Erlang installed. Over the past year there have been a slew of such devices hitting the market and more coming. Can we get /software/hardware cos to help sponsor the effort? Best, Lloyd -----Original Message----- From: "Ferenc Holzhauser" Sent: Monday, June 16, 2014 1:30pm To: "Tony Rogvall" Cc: "erlang-questions@REDACTED" Subject: Re: [erlang-questions] Erlang for youngsters _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions Robotics is really nice but in this case accessibility is even nicer. It is great if kids can play after class too with interesting things without having to put items of fairly significant value (for some) on their wishlist. These days a computer with internet access can be a fascinatingly accessible way of creativity. An idea could be to make a simple game backend to compete with their friends and fellow students (e.g. a 2d tank shooting game or something). Eventually with chat and similar functions to add. Then the teacher could make things go wrong on the server(s) that they'd need to fix (distribute/scale/fail over) depending on their progress. You could lure them into AI like things too if you fancy. I'm sure someone with the skills (e.g. SVG/ezwebframe) and time could make some simple client "building blocks" work for something like this. On 16 June 2014 18:12, Tony Rogvall wrote: > > On 16 jun 2014, at 13:55, Mark Nijhof > wrote: > > +1 on this, this rings very true to home. But I also believe that it needs > to return results quickly. I.e. building a game is great, but if they have > to "code" for days before they see something happen then they loose > interest (assumption). So preparing "building blocks" might be a good > approach and have them first implement higher level stuff and then step by > step dig deeper and implement the building blocks you prepared. > > An other exercise I planned is to program a drone (not sure about the > language there yet) to fly an obstacle course. So they see it is not just > something that happens on their iPads ;) > > You program drone in Erlang of course :-) > > https://github.com/tonyrog/edrone > > /Tony > > -Mark > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. >> >> Amen! >> The least relevant part of teaching kids programming is the syntax, or >> the choice of language - they don't, and won't, give a s**t about it. >> As a simple thought experiment, just look at how you raised your kids in >> a multi-lingual environment (yes my American brethren, this is hard. >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >> massacring every grammar rule ever, but quite happily making sure that you >> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >> odio odio odio la piselli, i don't wanna, where is my red truck?" >> Mind you, they will pick up the rules over time, but the key here is the >> importance of the problem at hand ("How To Avoid Eating Peas") - the more >> immediately relevant it is to the young 'uns, the more rapidly they will >> pick up the tools, the specifics of the language be damned. >> >> Cheers >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>> that Erlang is created to solve problems that are rather "industrial" and >>> most people "from outside" can't really relate to. If the audience is not >>> comfortable with understanding the problem itself then it is tricky to make >>> them understand/like the solution too. >>> >>> This we can see with many new people getting into Erlang: The problems >>> they are given are new and difficult to understand. So they often just go >>> off and eagerly try to solve all sort of issues they are familiar with >>> (even when they are not relevant in the particular case) before even trying >>> to understand what the real challenge is. Then they start complaining that >>> Erlang is not very good for some/many of those issues they are busy with. >>> >>> And other way around: people coming to Erlang with the right >>> understanding of the problem area it is made for find it amazingly simple >>> to learn. >>> >>> Coming from the wrong (or right ?) background my imagination fails to >>> come up with these appealing challenges for the youngster target group, but >>> I'm sure many of you can do much better. >>> >>> Ferenc >>> >>> >>> On 16 June 2014 11:31, Miles Fidelman >>> wrote: >>> >>>> Garrett Smith wrote: >>>> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>> wrote: >>>>> >>>>> -snip- >>>>> >>>>> I think that a learning resource focused on teaching people the >>>>>> Erlang model from the >>>>>> ground up would be a great improvement. A clear narrative around how >>>>>> do we solve a >>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>> problem. >>>>>> >>>>>> My initial target for such a learning resources would be young people >>>>>> in the higher >>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>> influence them >>>>>> before their minds are totally corrupted by other programming models. >>>>>> >>>>>> I don't think we would have to dumb anything down in particular for >>>>>> this group - we >>>>>> just have to find a cool example and organise the learning around how >>>>>> to become so >>>>>> good that one can solve such a problem. >>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>> of Transport >>>>>> Tycoon clone?!?! >>>>>> >>>>> I don't have enough experience teaching programming to this age group >>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>> be a bit ambitious for these young learners. >>>>> >>>>> I'm speaking in particular about the model that emerges when you >>>>> isolate processes. It changes everything: your approach to building >>>>> software (move from state oriented to activity oriented), error >>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>> program structure (from monolith to system), and so on. The benefits >>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>> it wasn't, or I wish I was better at communicating. >>>>> >>>>> >>>>> >>>> I'm with the folks who suggest that this group has fewer >>>> pre-conceptions to unlearn. >>>> >>>> It strikes me that the actor model is far more natural for certain >>>> classes of problems - network code, simulation, and gaming come to mind. >>>> It's simply conceptually easier to think in terms of LOTS of independent >>>> processes. >>>> >>>> Miles Fidelman >>>> >>>> >>>> -- >>>> In theory, there is no difference between theory and practice. >>>> In practice, there is. .... Yogi Berra >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> >> * Mahesh Paolini-Subramanya >> That >> tall bald Indian guy..* >> * Google+ >> | Blog | Twitter >> | LinkedIn >> * >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From mark.nijhof@REDACTED Mon Jun 16 21:14:32 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Mon, 16 Jun 2014 21:14:32 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <1402945075.869528733@apps.rackspace.com> References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: Not sure how much it helps but I am more then happy to have an unending (and publicly visible) coupon to get my book for free for kids. It is not specifically targeted to kids but does have a very high example driven approach. I.e. together we build stuff. Will make one tonight. http://gettingfunctionalwitherlang.com (btw not yet done). -Mark On Jun 16, 2014 8:58 PM, wrote: > Hello, > > So many great ideas. So many talented contributors. A fantasy--- > > One or more of... > > - a website > - hosting platform > - an e-book - free for download > - a hard-cover book - royalties kick back to help kids > - a hardware platform - profits kick back to help kids > > Projects > > - build your own website > - chat with friends > - organize your collections > - build a multi-player game > - control a robot > - control your house > - build your own supercomputer > ???? > > Contest for project submissions > > Team > > - dedicated Erlang volunteers > - perhaps formalize with a foundation ala Raspberry Pi > > Process > > - Dream > - Brainstorm > - Set goals > - Organize > - Delegate > - Produce > > Platform > > - Software projects can be done on Windows assuming easy peasy Erlang > install > > - How can we get youngsters into Linux? > > - A hardware platform would open up robotics and control applications: > > Cheap (under $100) ARM boards > > -- Arduino etc. > > -- Raspberry Pi > > -- I have an Odroid U3 on my desk. No time to fire it up yet; but very > compact, quiet, low power, plenty of computing power, runs Linux. Total of > $90 for board, pwr supply, HDMI cable, wi-fi module, and case. Would need > an MicroSD card with Linux and Erlang installed. > > Over the past year there have been a slew of such devices hitting the > market and more coming. > > Can we get /software/hardware cos to help sponsor the effort? > > Best, > > Lloyd > > > > > > > > > > > -----Original Message----- > From: "Ferenc Holzhauser" > Sent: Monday, June 16, 2014 1:30pm > To: "Tony Rogvall" > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang for youngsters > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > Robotics is really nice but in this case accessibility is even nicer. It is > great if kids can play after class too with interesting things without > having to put items of fairly significant value (for some) on their > wishlist. These days a > computer with internet access can be a fascinatingly accessible way of > creativity. An idea could be to make a simple game backend to compete with > their friends and fellow students (e.g. a 2d tank shooting game or > something). Eventually with chat and similar functions to add. Then the > teacher could make things go wrong on the server(s) that they'd need to fix > (distribute/scale/fail over) depending on their progress. You could lure > them into AI like things too if you fancy. I'm sure someone with the skills > (e.g. SVG/ezwebframe) and time could make some simple client "building > blocks" work for something like this. > > > On 16 June 2014 18:12, Tony Rogvall wrote: > > > > > On 16 jun 2014, at 13:55, Mark Nijhof > > wrote: > > > > +1 on this, this rings very true to home. But I also believe that it > needs > > to return results quickly. I.e. building a game is great, but if they > have > > to "code" for days before they see something happen then they loose > > interest (assumption). So preparing "building blocks" might be a good > > approach and have them first implement higher level stuff and then step > by > > step dig deeper and implement the building blocks you prepared. > > > > An other exercise I planned is to program a drone (not sure about the > > language there yet) to fly an obstacle course. So they see it is not just > > something that happens on their iPads ;) > > > > You program drone in Erlang of course :-) > > > > https://github.com/tonyrog/edrone > > > > /Tony > > > > -Mark > > > > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > > mahesh@REDACTED> wrote: > > > >> The most important thing here I believe is to have a nice collection of > >>> simple tasks/problems that are appealing to the target audience and > best > >>> (easiest/nicest) solved in Erlang. > >> > >> Amen! > >> The least relevant part of teaching kids programming is the syntax, or > >> the choice of language - they don't, and won't, give a s**t about it. > >> As a simple thought experiment, just look at how you raised your kids in > >> a multi-lingual environment (yes my American brethren, this is hard. > >> Pretend :-) ) Notice how they - fluidly - bounce across languages, > >> massacring every grammar rule ever, but quite happily making sure that > you > >> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, > >> odio odio odio la piselli, i don't wanna, where is my red truck?" > >> Mind you, they will pick up the rules over time, but the key here is the > >> importance of the problem at hand ("How To Avoid Eating Peas") - the > more > >> immediately relevant it is to the young 'uns, the more rapidly they will > >> pick up the tools, the specifics of the language be damned. > >> > >> Cheers > >> > >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < > >> ferenc.holzhauser@REDACTED> wrote: > >> > >>> The most important thing here I believe is to have a nice collection of > >>> simple tasks/problems that are appealing to the target audience and > best > >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge > considering > >>> that Erlang is created to solve problems that are rather "industrial" > and > >>> most people "from outside" can't really relate to. If the audience is > not > >>> comfortable with understanding the problem itself then it is tricky to > make > >>> them understand/like the solution too. > >>> > >>> This we can see with many new people getting into Erlang: The problems > >>> they are given are new and difficult to understand. So they often just > go > >>> off and eagerly try to solve all sort of issues they are familiar with > >>> (even when they are not relevant in the particular case) before even > trying > >>> to understand what the real challenge is. Then they start complaining > that > >>> Erlang is not very good for some/many of those issues they are busy > with. > >>> > >>> And other way around: people coming to Erlang with the right > >>> understanding of the problem area it is made for find it amazingly > simple > >>> to learn. > >>> > >>> Coming from the wrong (or right ?) background my imagination fails to > >>> come up with these appealing challenges for the youngster target > group, but > >>> I'm sure many of you can do much better. > >>> > >>> Ferenc > >>> > >>> > >>> On 16 June 2014 11:31, Miles Fidelman > >>> wrote: > >>> > >>>> Garrett Smith wrote: > >>>> > >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann > >>>>> wrote: > >>>>> > >>>>> -snip- > >>>>> > >>>>> I think that a learning resource focused on teaching people the > >>>>>> Erlang model from the > >>>>>> ground up would be a great improvement. A clear narrative around how > >>>>>> do we solve a > >>>>>> problem the Erlang way. Teaching the basic constructs is not the > >>>>>> problem. > >>>>>> > >>>>>> My initial target for such a learning resources would be young > people > >>>>>> in the higher > >>>>>> grades of elementary school, say 12-15 years. Why? Because I want to > >>>>>> influence them > >>>>>> before their minds are totally corrupted by other programming > models. > >>>>>> > >>>>>> I don't think we would have to dumb anything down in particular for > >>>>>> this group - we > >>>>>> just have to find a cool example and organise the learning around > how > >>>>>> to become so > >>>>>> good that one can solve such a problem. > >>>>>> Some sort of game will probably be the best candidate, say, some > sort > >>>>>> of Transport > >>>>>> Tycoon clone?!?! > >>>>>> > >>>>> I don't have enough experience teaching programming to this age group > >>>>> to provide anything more than a hunch. But I suspect that the Erlang > >>>>> way, which is hard enough for very seasoned programmers to grok, > might > >>>>> be a bit ambitious for these young learners. > >>>>> > >>>>> I'm speaking in particular about the model that emerges when you > >>>>> isolate processes. It changes everything: your approach to building > >>>>> software (move from state oriented to activity oriented), error > >>>>> handling (move from defensive measures to assertive/let-it-crash), > >>>>> program structure (from monolith to system), and so on. The benefits > >>>>> of this shift are hard to get across, in my experience anyway. I wish > >>>>> it wasn't, or I wish I was better at communicating. > >>>>> > >>>>> > >>>>> > >>>> I'm with the folks who suggest that this group has fewer > >>>> pre-conceptions to unlearn. > >>>> > >>>> It strikes me that the actor model is far more natural for certain > >>>> classes of problems - network code, simulation, and gaming come to > mind. > >>>> It's simply conceptually easier to think in terms of LOTS of > independent > >>>> processes. > >>>> > >>>> Miles Fidelman > >>>> > >>>> > >>>> -- > >>>> In theory, there is no difference between theory and practice. > >>>> In practice, there is. .... Yogi Berra > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>> > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> > >> > >> > >> -- > >> > >> * Mahesh Paolini-Subramanya > >> > That > >> tall bald Indian guy..* > >> * Google+ > >> | Blog | Twitter > >> | LinkedIn > >> * > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > > > > > > -- > > Mark Nijhof > > t: @MarkNijhof > > s: marknijhof > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > "Installing applications can lead to corruption over time. Applications > > gradually write over each other's libraries, partial upgrades occur, user > > and system errors happen, and minute changes may be unnoticeable and > > difficult to fix" > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Mon Jun 16 21:35:55 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Mon, 16 Jun 2014 21:35:55 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: Done, use: http://leanpub.com/functionalerlang/c/FreeForKids which is also listed on the website itself. -Mark On Mon, Jun 16, 2014 at 9:14 PM, Mark Nijhof wrote: > Not sure how much it helps but I am more then happy to have an unending > (and publicly visible) coupon to get my book for free for kids. It is not > specifically targeted to kids but does have a very high example driven > approach. I.e. together we build stuff. Will make one tonight. > > http://gettingfunctionalwitherlang.com (btw not yet done). > > -Mark > On Jun 16, 2014 8:58 PM, wrote: > >> Hello, >> >> So many great ideas. So many talented contributors. A fantasy--- >> >> One or more of... >> >> - a website >> - hosting platform >> - an e-book - free for download >> - a hard-cover book - royalties kick back to help kids >> - a hardware platform - profits kick back to help kids >> >> Projects >> >> - build your own website >> - chat with friends >> - organize your collections >> - build a multi-player game >> - control a robot >> - control your house >> - build your own supercomputer >> ???? >> >> Contest for project submissions >> >> Team >> >> - dedicated Erlang volunteers >> - perhaps formalize with a foundation ala Raspberry Pi >> >> Process >> >> - Dream >> - Brainstorm >> - Set goals >> - Organize >> - Delegate >> - Produce >> >> Platform >> >> - Software projects can be done on Windows assuming easy peasy Erlang >> install >> >> - How can we get youngsters into Linux? >> >> - A hardware platform would open up robotics and control applications: >> >> Cheap (under $100) ARM boards >> >> -- Arduino etc. >> >> -- Raspberry Pi >> >> -- I have an Odroid U3 on my desk. No time to fire it up yet; but very >> compact, quiet, low power, plenty of computing power, runs Linux. Total of >> $90 for board, pwr supply, HDMI cable, wi-fi module, and case. Would need >> an MicroSD card with Linux and Erlang installed. >> >> Over the past year there have been a slew of such devices hitting the >> market and more coming. >> >> Can we get /software/hardware cos to help sponsor the effort? >> >> Best, >> >> Lloyd >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: "Ferenc Holzhauser" >> Sent: Monday, June 16, 2014 1:30pm >> To: "Tony Rogvall" >> Cc: "erlang-questions@REDACTED" >> Subject: Re: [erlang-questions] Erlang for youngsters >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> Robotics is really nice but in this case accessibility is even nicer. It >> is >> great if kids can play after class too with interesting things without >> having to put items of fairly significant value (for some) on their >> wishlist. These days a >> computer with internet access can be a fascinatingly accessible way of >> creativity. An idea could be to make a simple game backend to compete with >> their friends and fellow students (e.g. a 2d tank shooting game or >> something). Eventually with chat and similar functions to add. Then the >> teacher could make things go wrong on the server(s) that they'd need to >> fix >> (distribute/scale/fail over) depending on their progress. You could lure >> them into AI like things too if you fancy. I'm sure someone with the >> skills >> (e.g. SVG/ezwebframe) and time could make some simple client "building >> blocks" work for something like this. >> >> >> On 16 June 2014 18:12, Tony Rogvall wrote: >> >> > >> > On 16 jun 2014, at 13:55, Mark Nijhof >> > wrote: >> > >> > +1 on this, this rings very true to home. But I also believe that it >> needs >> > to return results quickly. I.e. building a game is great, but if they >> have >> > to "code" for days before they see something happen then they loose >> > interest (assumption). So preparing "building blocks" might be a good >> > approach and have them first implement higher level stuff and then step >> by >> > step dig deeper and implement the building blocks you prepared. >> > >> > An other exercise I planned is to program a drone (not sure about the >> > language there yet) to fly an obstacle course. So they see it is not >> just >> > something that happens on their iPads ;) >> > >> > You program drone in Erlang of course :-) >> > >> > https://github.com/tonyrog/edrone >> > >> > /Tony >> > >> > -Mark >> > >> > >> > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >> > mahesh@REDACTED> wrote: >> > >> >> The most important thing here I believe is to have a nice collection of >> >>> simple tasks/problems that are appealing to the target audience and >> best >> >>> (easiest/nicest) solved in Erlang. >> >> >> >> Amen! >> >> The least relevant part of teaching kids programming is the syntax, or >> >> the choice of language - they don't, and won't, give a s**t about it. >> >> As a simple thought experiment, just look at how you raised your kids >> in >> >> a multi-lingual environment (yes my American brethren, this is hard. >> >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >> >> massacring every grammar rule ever, but quite happily making sure that >> you >> >> understand that "I amn't going to eat pea, ???? ????????, ???? >> ????????, >> >> odio odio odio la piselli, i don't wanna, where is my red truck?" >> >> Mind you, they will pick up the rules over time, but the key here is >> the >> >> importance of the problem at hand ("How To Avoid Eating Peas") - the >> more >> >> immediately relevant it is to the young 'uns, the more rapidly they >> will >> >> pick up the tools, the specifics of the language be damned. >> >> >> >> Cheers >> >> >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> >> ferenc.holzhauser@REDACTED> wrote: >> >> >> >>> The most important thing here I believe is to have a nice collection >> of >> >>> simple tasks/problems that are appealing to the target audience and >> best >> >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge >> considering >> >>> that Erlang is created to solve problems that are rather "industrial" >> and >> >>> most people "from outside" can't really relate to. If the audience is >> not >> >>> comfortable with understanding the problem itself then it is tricky >> to make >> >>> them understand/like the solution too. >> >>> >> >>> This we can see with many new people getting into Erlang: The problems >> >>> they are given are new and difficult to understand. So they often >> just go >> >>> off and eagerly try to solve all sort of issues they are familiar with >> >>> (even when they are not relevant in the particular case) before even >> trying >> >>> to understand what the real challenge is. Then they start complaining >> that >> >>> Erlang is not very good for some/many of those issues they are busy >> with. >> >>> >> >>> And other way around: people coming to Erlang with the right >> >>> understanding of the problem area it is made for find it amazingly >> simple >> >>> to learn. >> >>> >> >>> Coming from the wrong (or right ?) background my imagination fails to >> >>> come up with these appealing challenges for the youngster target >> group, but >> >>> I'm sure many of you can do much better. >> >>> >> >>> Ferenc >> >>> >> >>> >> >>> On 16 June 2014 11:31, Miles Fidelman >> >>> wrote: >> >>> >> >>>> Garrett Smith wrote: >> >>>> >> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >> >>>>> wrote: >> >>>>> >> >>>>> -snip- >> >>>>> >> >>>>> I think that a learning resource focused on teaching people the >> >>>>>> Erlang model from the >> >>>>>> ground up would be a great improvement. A clear narrative around >> how >> >>>>>> do we solve a >> >>>>>> problem the Erlang way. Teaching the basic constructs is not the >> >>>>>> problem. >> >>>>>> >> >>>>>> My initial target for such a learning resources would be young >> people >> >>>>>> in the higher >> >>>>>> grades of elementary school, say 12-15 years. Why? Because I want >> to >> >>>>>> influence them >> >>>>>> before their minds are totally corrupted by other programming >> models. >> >>>>>> >> >>>>>> I don't think we would have to dumb anything down in particular for >> >>>>>> this group - we >> >>>>>> just have to find a cool example and organise the learning around >> how >> >>>>>> to become so >> >>>>>> good that one can solve such a problem. >> >>>>>> Some sort of game will probably be the best candidate, say, some >> sort >> >>>>>> of Transport >> >>>>>> Tycoon clone?!?! >> >>>>>> >> >>>>> I don't have enough experience teaching programming to this age >> group >> >>>>> to provide anything more than a hunch. But I suspect that the Erlang >> >>>>> way, which is hard enough for very seasoned programmers to grok, >> might >> >>>>> be a bit ambitious for these young learners. >> >>>>> >> >>>>> I'm speaking in particular about the model that emerges when you >> >>>>> isolate processes. It changes everything: your approach to building >> >>>>> software (move from state oriented to activity oriented), error >> >>>>> handling (move from defensive measures to assertive/let-it-crash), >> >>>>> program structure (from monolith to system), and so on. The benefits >> >>>>> of this shift are hard to get across, in my experience anyway. I >> wish >> >>>>> it wasn't, or I wish I was better at communicating. >> >>>>> >> >>>>> >> >>>>> >> >>>> I'm with the folks who suggest that this group has fewer >> >>>> pre-conceptions to unlearn. >> >>>> >> >>>> It strikes me that the actor model is far more natural for certain >> >>>> classes of problems - network code, simulation, and gaming come to >> mind. >> >>>> It's simply conceptually easier to think in terms of LOTS of >> independent >> >>>> processes. >> >>>> >> >>>> Miles Fidelman >> >>>> >> >>>> >> >>>> -- >> >>>> In theory, there is no difference between theory and practice. >> >>>> In practice, there is. .... Yogi Berra >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> erlang-questions mailing list >> >>>> erlang-questions@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> erlang-questions mailing list >> >>> erlang-questions@REDACTED >> >>> http://erlang.org/mailman/listinfo/erlang-questions >> >>> >> >>> >> >> >> >> >> >> -- >> >> >> >> * Mahesh Paolini-Subramanya >> >> >> That >> >> tall bald Indian guy..* >> >> * Google+ >> >> | Blog | Twitter >> >> | LinkedIn >> >> * >> >> >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> > >> > >> > -- >> > Mark Nijhof >> > t: @MarkNijhof >> > s: marknijhof >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> > "Installing applications can lead to corruption over time. Applications >> > gradually write over each other's libraries, partial upgrades occur, >> user >> > and system errors happen, and minute changes may be unnoticeable and >> > difficult to fix" >> > >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Mon Jun 16 20:58:20 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 20:58:20 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <539ECD10.5090903@ninenines.eu> References: <539ECD10.5090903@ninenines.eu> Message-ID: Lo?c Hoguin writes: > I don't think the problem is so much that these things are hard to > learn, but rather that you *have* to learn them. OO was hard to learn. > Pointers took me a while also. In comparison Erlang was very fast to get > started with as I started writing parsers for binary files immediately, > then later on making it parallel and eventually learnt OTP and did other > small things with the language. > > At the time there was basically no resources. LYSE had about 5 chapters > so I didn't really use it. A few blog posts here and there helped a > little, but it was mostly Joe's book. Today we have tons of resources. I > do not think the docs problem shown by Garrett is the reason why Erlang > is hard to learn. I think it's just correlation. (Of course some of the > OTP docs are terrible, like sofs and bits of the common_test guide, but > the docs on erlang.org are impressive; only they do not help the Erlang > beginner, this is covered by Joe's book, LYSE and others.) If there is > causation then a link to the free version of LYSE from the erlang.org > docs page should be plenty enough to fix it. > > What I think is that people say Erlang is hard to learn because they > expect to go from 0 knowledge to be able to use it for their job in a > few hours. This is plain crazy, nobody learnt OO in a day, and nobody > can learn concurrent/fault tolerant in a day. And it's even harder if > your mind is stuck on a particular paradigm. > I think this is remarkably well put. It sort of hints the head on the nail for me. Respect for the learning curve. I too see a tendency of this from time to time. Thanks for articulating that, Lo?c! > Learning takes time. In today's impatient world this is seen as a > weakness, but those who do take the time to learn Erlang get an > exponential reward for their troubles. This is unfortunately hard to > demonstrate to people who want everything immediately without the effort. > > But to kids who have never done programming before? They'll learn Erlang > as easily as anything else. When you first start programming even "hello > world" is a magical moment. When you've programmed for years it's a very > boring moment and you want to skip ahead, which is impossible if you > have to learn a new paradigm entirely. Kids do not have that problem. So > stop worrying and teach them Erlang. > A kinderd spirit. So this boils down to motivation to sustain through the learning curve and pureness of the fresh minds to avoid having to unlearn other paradigms. Cheers, Torben > On 06/16/2014 12:20 PM, Anthony Ramine wrote: >> Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition? >> -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 16 21:28:34 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 21:28:34 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> References: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> Message-ID: Lloyd R. Prentice writes: > Hi Torben, > > +1 for for teaching Erlang to kids. > Great - hope you can accept Elixir if it ends up like that. (Ducking the stones!). > Back when dinosaurs roamed the earth, I was founding editor/publisher of Classroom > Computer News, the first magazine in the U.S. devoted exclusively to instructional > computer applications in K-12 classrooms. Subsequently I founded a company largely > devoted to development of educational and consumer software for major publishers. > We developed over 100 products ranging from Pockets the Learn and Do Kangaroo for > pre-school youngsters to Algebra I for the high school set to The Scarsdale Medical > Diet for obese adults for publishers ranging from Bantam to World Book. > Experience is highly underrated these days, so thanks for contributing. > I bore you with this to make several points: > > 1) Don't underestimate what properly motivated kids can learn--- they're hard-wired to learn > 2) Don't underestimate intrinsic curiosity as a motivator--- at least until it's squelched by repressive pedagogy > 3) Create exploration environments to leverage intrinsic curiosity > 4) Break the learning tasks into single key concepts that rest 100 percent on what the youngster already knows so concepts build one upon another > 5) Keep it playful and fun > 6) Tie the concepts into real-world (the child's world) issues and concerns > 7) Challenge the youngster, but make success attainable > 8) Reward success > 9) Empower the youngster with demonstrable knowledge and skills that matter from the kid's perspective > I totally agree with these points. In the dark ages I taught Java at the Technical University of Denmark and I tried - intuitively - to incorporate all of the points you mention. The course ratings went from 1.5 with the previous pedagogy heavy oldster to 4.5 on a 5 point scale. I used real-world examples and games. So I would say that these principles applies to all learners - regardless of age. As adults many forget to have fun and continuously tickle the learning desire in us. > Additional thoughts > > --- My software development company was based on Forth so I was active in the > exciting and innovative Forth community of the time. Given the limited resources of > pcs of the era, Forth gave us tremendous competitive advantages. But I saw the > Forth community wane and fizzle into near oblivion due, in part, to neglect of the > interests of the upcoming generation of programmers. > That is a very instructive story. I, for one, want to fight this. > --- Tie into the Raspberry Pi phenomenon > > --- Show kids (and child-minded adults) how to build super computers out of > Raspberry Pi, Odroid U3s or the super-cheap "mini pcs" coming out of China. (I'd > love to work with anyone into that). > At ESL we have worked with the R-Pi and created the Erlang/ALE library, but it has been a bit slow after the main driver left the company :-( > Also, see: > > http://info.marygrove.edu/MATblog/bid/74832/Explore-Graph-Theory-with-Gifted-Elementary-Students > Great resource. It sort of reinforces my core belief that in the right wrapping kids can learn a lot more than we think. Cheers, Torben > [PDF] A Tangible Construction Kit for Exploring Graph Theory > E Schweikardt, N Elumeze, M Eisenberg, MD Gross - code.arc.cmu.edu > ABSTRACT Graphs are a versatile representation of many systems in computer science, the > social sciences, and mathematics, but graph theory is not taught in schools. We present our > work on Graphmaster, a computationally enhanced construction kit that enables children ... > > All the best, > > LRP > > > Sent from my iPad > >> On Jun 16, 2014, at 3:51 AM, Torben Hoffmann wrote: >> >> Hi, >> >> The wonderful thread on "Beginners tutorials" >> (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started >> after the EUC last week has touched something in me and I want to get some feedback >> on my ideas. >> >> I think that Joe's original suggestion in the "Beginners tutorials" thread can do >> something with regards to easing people into Erlang, but it cannot be the only thing. >> >> I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use >> Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a >> number of things we, as a community, can do better. >> >> One thing that stood out in relation to this thread was HardToLearn. >> >> HardToLearn influences a lot of things, but it also drives the worry >> FindingDevelopers, which bad for the career prospects for all of us. >> See Garrett's talk (when online) and you will understand. >> >> Why is Erlang HardToLearn? >> >> One can point to documentation and say it is not optimal. >> One can ask for books on Erlang Concurrency Patterns as Joe did. >> >> But I feel there is a more fundamental problem that we need to address: >> how to think like an Erlanger. >> >> Erlang is a concurrent functional language with a unique failure model. >> More than 2 nines of the people being taught anything on programming will be exposed >> to procedural or object oriented languages with exceptions and be told that threads >> are hard (they are 'cause they will make you loose your hair). >> >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> >> I don't think we would have to dumb anything down in particular for this group - we >> just have to find a cool example and organise the learning around how to become so >> good that one can solve such a problem. >> Some sort of game will probably be the best candidate, say, some sort of Transport >> Tycoon clone?!?! >> >> And now for the controversial part of my idea: this should probably be done using >> Elixir plus something for the GUI. >> Yes, I said the other E word, so I'm ready to be stoned ;-) [1] >> >> Why Elixir? >> >> Programming Elixir requires the same understanding of the Erlang concurrency model in >> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame >> and misses the boat totally. >> >> So using Elixir would allow us to expose people to the Erlang model, which I think is >> the main point. The more people that uses the BEAM, the better for the >> FindingDevelopers problem. >> >> What is better about Elixir from a learning standpoint is, in my highly subjective >> opinion, that you can get started quite easily with the mix tool. >> >> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old >> son to have a look in the "Introducing Elixir" book and his initial reaction was >> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good >> thing! >> >> Given that I think games are awesome for teaching there needs to be some sort of GUI >> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it >> is functional, but other suggestions are most welcome. >> >> Am I on the right track to anything with this? >> Is there a need for such a learning resource? >> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? >> >> Cheers, >> Torben >> >> [1] https://www.youtube.com/watch?v=SYkbqzWVHZI >> -- >> Torben Hoffmann >> CTO >> Erlang Solutions Ltd. >> Tel: +45 25 14 05 38 >> http://www.erlang-solutions.com >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 16 21:36:27 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 21:36:27 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <539EFE17.8040602@meetinghouse.net> References: <5ECC7E5F-E56C-49DE-9AB1-5F807125B090@writersglen.com> <539EFE17.8040602@meetinghouse.net> Message-ID: Miles Fidelman writes: > Lloyd R. Prentice wrote: >> Hi Torben, >> >> +1 for for teaching Erlang to kids. >> >> Back when dinosaurs roamed the earth, I was founding editor/publisher >> of Classroom Computer News, the first magazine in the U.S. devoted >> exclusively to instructional computer applications in K-12 classrooms. >> Subsequently I founded a company largely devoted to development of >> educational and consumer software for major publishers. We developed >> over 100 products ranging from Pockets the Learn and Do Kangaroo for >> pre-school youngsters to Algebra I for the high school set to The >> Scarsdale Medical Diet for obese adults for publishers ranging from >> Bantam to World Book. >> >> I bore you with this to make several points: >> >> 1) Don't underestimate what properly motivated kids can learn--- >> they're hard-wired to learn >> 2) Don't underestimate intrinsic curiosity as a motivator--- at least >> until it's squelched by repressive pedagogy >> 3) Create exploration environments to leverage intrinsic curiosity >> 4) Break the learning tasks into single key concepts that rest 100 >> percent on what the youngster already knows so concepts build one upon >> another >> 5) Keep it playful and fun >> 6) Tie the concepts into real-world (the child's world) issues and >> concerns >> 7) Challenge the youngster, but make success attainable >> 8) Reward success >> 9) Empower the youngster with demonstrable knowledge and skills that >> matter from the kid's perspective >> > > Good points all. > > Re. motivation: Robotics is big right now - particularly in the context > of Lego Mindstorms and then the FIRST Robotics competitions. Erlang, as > a language for robot behaviors (subsumption architecture) and > cooperating robots, might be really cool. > > Miles Fidelman At ESL we had an intern who created a buggy using Erlang: http://www.erlang-embedded.com/2013/10/erlang-plays-pool/ Code at https://github.com/ivaniacono/ebuggy As you say Erlang is really good to structure hardware related things. The actor model shines here. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 16 21:43:19 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 21:43:19 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> Message-ID: Hi Evgeny, Evgeny M writes: > Imo the best tutorial for a beginner in any language (for someone who has > experience in other ones) is something intermediate and familiar using some > ready framework. Some thing which allows him/her to write in a hour > something he used to build in other language. Often it is possible to do > this even without knowing the language almost altogether. Like, tutorial on > Django is a great way to start learning python. Something like this could > be created for Erlang, either over pure Cowboy, or ChicagoBoss, or > whatever. Just a dumb step by step (type this, run that) tutorial which can > be done by anyone who has any programming background. In the end there will > be a working site with forms, POSTs and other fancy stuff. I for one > learned myself both python and erlang exactly this way (using Django and > CB), skipping all the boring stuff. > Doing hellowords, compiling modules, doing releases and other stuff like > that is really very boring. You can do it later. > For people with experiences in programming I think your suggestions are very valid. > Also I'd say talking about concurrency should start with OTP, and introduce > spawn() later. First, OTP gen_server is just easier than standard > spawn/receive for anyone with OO background. Second, spawn/receive is too > similar to standard approaches to multithreading in mainstream languages > and it is harder to see all the benefits of Erlang supervision and workers. > That is probably true. OTP should fit OO people just fine. > Erlang as a language looks very hard for two weeks, then it suddenly > becomes very easy (as a language, concurrency is always hard). Good observation! > Recursion is hard in any language without pattern matching. Good point - I actually never thought about like that. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 16 21:56:04 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 21:56:04 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: Yuri Lukyanov writes: > I'm not a teacher at all and I don't pretend to be objective here. But > my and my colleagues' experiences with Erlang tell me that Erlang is > simple to learn. Most of us came to the current company with _zero_ > experience in Erlang or any other functional programming experiences. > I personally was a complete PHP guy. My first impression on Erlang was > "it's very different and hard to learn". But in two weeks we was able > to read and understand Erlang code and write simple stuff. > > My point is that Erlang is not hard-to-learn, but rather > hard-to-realize-it-is-easy-to-learn. It's easier than one can imagine. > Perhaps, that could be a statement to spread out. > What happened for you guys? How did you approach the learning? What problems did you look at? What motivated you to look at Erlang in the first place? All info on your transformation is interesting. Cheers, Torben > Just thinking aloud. > > > On Mon, Jun 16, 2014 at 11:51 AM, Torben Hoffmann > wrote: >> Hi, >> >> The wonderful thread on "Beginners tutorials" >> (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started >> after the EUC last week has touched something in me and I want to get some feedback >> on my ideas. >> >> I think that Joe's original suggestion in the "Beginners tutorials" thread can do >> something with regards to easing people into Erlang, but it cannot be the only thing. >> >> I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use >> Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a >> number of things we, as a community, can do better. >> >> One thing that stood out in relation to this thread was HardToLearn. >> >> HardToLearn influences a lot of things, but it also drives the worry >> FindingDevelopers, which bad for the career prospects for all of us. >> See Garrett's talk (when online) and you will understand. >> >> Why is Erlang HardToLearn? >> >> One can point to documentation and say it is not optimal. >> One can ask for books on Erlang Concurrency Patterns as Joe did. >> >> But I feel there is a more fundamental problem that we need to address: >> how to think like an Erlanger. >> >> Erlang is a concurrent functional language with a unique failure model. >> More than 2 nines of the people being taught anything on programming will be exposed >> to procedural or object oriented languages with exceptions and be told that threads >> are hard (they are 'cause they will make you loose your hair). >> >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> >> I don't think we would have to dumb anything down in particular for this group - we >> just have to find a cool example and organise the learning around how to become so >> good that one can solve such a problem. >> Some sort of game will probably be the best candidate, say, some sort of Transport >> Tycoon clone?!?! >> >> And now for the controversial part of my idea: this should probably be done using >> Elixir plus something for the GUI. >> Yes, I said the other E word, so I'm ready to be stoned ;-) [1] >> >> Why Elixir? >> >> Programming Elixir requires the same understanding of the Erlang concurrency model in >> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame >> and misses the boat totally. >> >> So using Elixir would allow us to expose people to the Erlang model, which I think is >> the main point. The more people that uses the BEAM, the better for the >> FindingDevelopers problem. >> >> What is better about Elixir from a learning standpoint is, in my highly subjective >> opinion, that you can get started quite easily with the mix tool. >> >> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old >> son to have a look in the "Introducing Elixir" book and his initial reaction was >> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good >> thing! >> >> Given that I think games are awesome for teaching there needs to be some sort of GUI >> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it >> is functional, but other suggestions are most welcome. >> >> Am I on the right track to anything with this? >> Is there a need for such a learning resource? >> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? >> >> Cheers, >> Torben >> >> [1] https://www.youtube.com/watch?v=SYkbqzWVHZI >> -- >> Torben Hoffmann >> CTO >> Erlang Solutions Ltd. >> Tel: +45 25 14 05 38 >> http://www.erlang-solutions.com >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 16 23:36:54 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 16 Jun 2014 23:36:54 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <20140616124733.GL51530@ferdair.local> References: <20140616124733.GL51530@ferdair.local> Message-ID: Fred Hebert writes: > There's a lot to discuss in this thread (and Joe's one last week). This > is a bit of a rambling from me, but yeah. > The more the merrier! ;-) > On 06/16, Torben Hoffmann wrote: >> Why is Erlang HardToLearn? >> > > We should ask newcomers. When I started, Erlang was hard to learn for > specific reasons: terminology, availability of information (we had the > series of blog posts about an Erlang bank in OTP and the trapexit > cookbooks, and that was most of it if you didn't feel like paying for a > book) > > Since I've learned the language, the context changed in massive ways. > LYSE is available, Cowboy has gained docs, Chicagoboss has a manual, > more books have come around, more tutorials have been published, more > talks have been made available. > > The problem isn't solved, but as a community, we shifted it to a new > different area. Newcomers will have had the difficult pressure point > somewhere else, and newcomers should therefore be able to tell us what > *they* found hard, without having more experienced people contradicting > them on many points -- We learned at a different time in a different > context. > > We should ask people who have quit learning the language. Sometimes we > will disagree, sometimes it will be due to their background of areas of > interest, but there is a lot to for us to learn there. > > We should ask people who don't feel like learning it. We have pieces of > data, such as people not liking the documentation, but we don't know > *why* that is. Fixing the doc without fixing what's wrong is a bad idea, > the same way premature optimization is. > Good points. As we wander here in the darkness of the valley of Erlang teaching, it might be wise to take a more Lean Start-up like approach to solving the problem, i.e., build it incrementally and measure what works. I wonder if anyone has approached the creation of learning experiences this way?!?! > >> how to think like an Erlanger. >> >> >> I think that a learning resource focused on teaching people the Erlang model from the >> ground up would be a great improvement. A clear narrative around how do we solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> > > Architecture is a definitive place where that needs to happen. I > remember fumbling around wondering "but what do I make a process?" -- > not sure if it's still an issue. > I think that is the first thing to put into the learning - and focus on a working process for figuring out what the right amount of processes. As Robert Virding often says, we tend to make too few processes in our designs, so teaching people that they are cheap is probably the way to go. > I remember (and still often encounter) the issue of algorithms and > datastructure. Everything you've learned before tends to assume O(1) > access to mutable memory and it's no longer true. But then again, the > relevance of this depends who you want to teach to. People who already > program, or people who don't program yet. > +1 on that. Very few resources on how to really design with functions and perhaps even fewer on how to do concurrency, especially the Erlang style. >> My initial target for such a learning resources would be young people in the higher >> grades of elementary school, say 12-15 years. Why? Because I want to influence them >> before their minds are totally corrupted by other programming models. >> > > Ah, so you want to be the first one to corrupt their minds, then! > Yup, not ashamed of that! > Snark aside, if we want to teach children, we should reach out to > organisms such as https://www.codeclub.org.uk/ (who do this *every > day*). We should look at what it is they do, ask them, see what they > recommend, and tell us what wouldn't work. > > We can also look at How To Design Programs > (http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed > to teach programming to new people. They show you how to animate rocket > ships in the first chapter. Erlang books (mine included) tell you what > an atom is and why you should care. That's okay, they're not meant for > newcomers. Horses for courses! They make use of DrRacket, which has the upside that it can produce geometric figures quite easily, while still mixing in traditional operations on numbers and Booleans. Would be cool to do this with Erlang/Elixir and processing.org. > > Or we can try reinventing the wheel based on what we feel is really > important, but what we feel is really important likely doesn't overlap > super well to what is important to a teenager. There are people who > dedicate their lives to working on that problem, they're the ones from > whom we should be looking for for guidance. > > Many of us know Erlang, but few of us know how to teach. A lot of us > have forgotten what it is like to not know how to program. > True. Again, an iterative approach seems favourable from a risk standpoint. >> >> What is better about Elixir from a learning standpoint is, in my highly subjective >> opinion, that you can get started quite easily with the mix tool. >> > > If we want to reach out to crowds who aren't familiar with programming > at all, mix isn't gonna cut it either. Look at Scratch > (http://scratch.mit.edu/), look at Logo, look at Racket's graphical > language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html), > look at Arduino's documentation > (http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which > looks like it has another great intro. > We could definitely do Logo and Racket with Elixir by using a port. The Scratch approach is a different challenge. Until today the only graphical notation that has come close Erlang for me has been SDL, but a search revealed this: http://drakon-editor.sourceforge.net/drakon-erlang/intro.html It looks a lot like SDL, but it should be Turing-complete, so this might provide a visual way into the world of Erlang. > We have a long way to go, whether Elixir or Erlang is being used. Most > people still put Erlang's sweet spot into the 'server' area in Garrett's > data. Do we have to make the person we're gonna teach to care about > servers to have teaching Erlang worth their time? Because it looks like > otherwise, we might as well teach them a language more adapted to what > they care about, not one adapted to what we care about. > I think the Erlang programming model can be used for many things, so I think it is bestowed upon us to show that is is applicable to what they care about. > If we plan on reaching out to the already-programmign crowd, then yes, a > tool like Mix is useful. It would also be useful within Erlang for its > community. Rebar templates aren't even that far from allowing a lot of > that functionality, but the community hasn't banded together to do it. > Mix has taken one very sane decision: the configuration is written in Elixir! If make is not enough for a build problem the only sane thing is to step up the latter, i.e., go to a real programming language. Inventing a DSL (the rebar approach) is a step in the wrong direction. If Mix works for youngsters depends on how much command line they can accept. If they need the visual environment, Mix is not a good thing. > There are probably deep-rooted reasons for it -- many of us adopted > Erlang when you managed dependencies by downloading them and checking > them in your repo, used makefiles all the time, and whatnot. The stuff > rebar or erlang.mk do is already convenient enough for a lot of us to > have felt the pain eased away, at least to the extent where we're not > compelled to help fix the problem anymore. The workarounds are nicer > than what we had before, so workarounds it will be. Forever. > > The same is true for the documentation. They're mostly reference manuals, > which by definition are to be used as a reference -- it is expected you > know their content and are only looking up additional information, or > data to help you recall what you already learned. They won't be good to > learn (the tutorials are nicer, but who knows about them?), and none of > the regulars will have any incentive to fix it. > Good observations. Not sure how they relate to teaching. Elixir's library takes a stab at more consistency, so that is probably better for beginners. > Anyway, that's a long rant enough. > A good rant if you ask me! Cheers, Torben > Regards, > Fred. -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From lee.sylvester@REDACTED Mon Jun 16 23:51:17 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 16 Jun 2014 22:51:17 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: My 5 cents? I started using Google Go, as I needed concurrency with lightweight processes for cloud applications development. Problem was, it was too immature. I enjoyed the language, but I found I had to do so much grunt work that it was tiring and the road to completion was too long. So, I looked into Erlang. Same concurrent goodness. Same lightweight processes. Much more mature. The first thing I did was read Learn You Some Erlang for Great Good. Very good book, but very verbose. Still, it was worth reading. However, while Learn You Some Erlang helped me understand the grammar and the context of development in Erlang, it was Erlang/OTP in Action that grounded it and gave me a solid understanding in how apps should be written in Erlang. It took me a week to learn enough to write my first app. It took two weeks for me to feel comfortable with the language and platform as a whole. Now, I feel like Erlang is how platforms should be built. Recently, I jumped onto the Elixir bandwagon. Elixir is very much like Erlang in many ways, but taken a step further, with a nicer syntax and some added goodness. I think Elixir is where I?ll stay for some time :-) Btw, writing concurrent, fault-tolerant and scalable apps in Erlang is crazy simple. I often laugh to myself when things just work and scale like I wanted them to, with so little effort. Cheers, Lee On 16 Jun 2014, at 20:56, Torben Hoffmann wrote: > > Yuri Lukyanov writes: > >> I'm not a teacher at all and I don't pretend to be objective here. But >> my and my colleagues' experiences with Erlang tell me that Erlang is >> simple to learn. Most of us came to the current company with _zero_ >> experience in Erlang or any other functional programming experiences. >> I personally was a complete PHP guy. My first impression on Erlang was >> "it's very different and hard to learn". But in two weeks we was able >> to read and understand Erlang code and write simple stuff. >> >> My point is that Erlang is not hard-to-learn, but rather >> hard-to-realize-it-is-easy-to-learn. It's easier than one can imagine. >> Perhaps, that could be a statement to spread out. >> > What happened for you guys? > How did you approach the learning? > What problems did you look at? > What motivated you to look at Erlang in the first place? > > All info on your transformation is interesting. > > Cheers, > Torben > > >> Just thinking aloud. >> >> >> On Mon, Jun 16, 2014 at 11:51 AM, Torben Hoffmann >> wrote: >>> Hi, >>> >>> The wonderful thread on "Beginners tutorials" >>> (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started >>> after the EUC last week has touched something in me and I want to get some feedback >>> on my ideas. >>> >>> I think that Joe's original suggestion in the "Beginners tutorials" thread can do >>> something with regards to easing people into Erlang, but it cannot be the only thing. >>> >>> I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use >>> Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a >>> number of things we, as a community, can do better. >>> >>> One thing that stood out in relation to this thread was HardToLearn. >>> >>> HardToLearn influences a lot of things, but it also drives the worry >>> FindingDevelopers, which bad for the career prospects for all of us. >>> See Garrett's talk (when online) and you will understand. >>> >>> Why is Erlang HardToLearn? >>> >>> One can point to documentation and say it is not optimal. >>> One can ask for books on Erlang Concurrency Patterns as Joe did. >>> >>> But I feel there is a more fundamental problem that we need to address: >>> how to think like an Erlanger. >>> >>> Erlang is a concurrent functional language with a unique failure model. >>> More than 2 nines of the people being taught anything on programming will be exposed >>> to procedural or object oriented languages with exceptions and be told that threads >>> are hard (they are 'cause they will make you loose your hair). >>> >>> I think that a learning resource focused on teaching people the Erlang model from the >>> ground up would be a great improvement. A clear narrative around how do we solve a >>> problem the Erlang way. Teaching the basic constructs is not the problem. >>> >>> My initial target for such a learning resources would be young people in the higher >>> grades of elementary school, say 12-15 years. Why? Because I want to influence them >>> before their minds are totally corrupted by other programming models. >>> >>> I don't think we would have to dumb anything down in particular for this group - we >>> just have to find a cool example and organise the learning around how to become so >>> good that one can solve such a problem. >>> Some sort of game will probably be the best candidate, say, some sort of Transport >>> Tycoon clone?!?! >>> >>> And now for the controversial part of my idea: this should probably be done using >>> Elixir plus something for the GUI. >>> Yes, I said the other E word, so I'm ready to be stoned ;-) [1] >>> >>> Why Elixir? >>> >>> Programming Elixir requires the same understanding of the Erlang concurrency model in >>> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame >>> and misses the boat totally. >>> >>> So using Elixir would allow us to expose people to the Erlang model, which I think is >>> the main point. The more people that uses the BEAM, the better for the >>> FindingDevelopers problem. >>> >>> What is better about Elixir from a learning standpoint is, in my highly subjective >>> opinion, that you can get started quite easily with the mix tool. >>> >>> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old >>> son to have a look in the "Introducing Elixir" book and his initial reaction was >>> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good >>> thing! >>> >>> Given that I think games are awesome for teaching there needs to be some sort of GUI >>> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it >>> is functional, but other suggestions are most welcome. >>> >>> Am I on the right track to anything with this? >>> Is there a need for such a learning resource? >>> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? >>> >>> Cheers, >>> Torben >>> >>> [1] https://www.youtube.com/watch?v=SYkbqzWVHZI >>> -- >>> Torben Hoffmann >>> CTO >>> Erlang Solutions Ltd. >>> Tel: +45 25 14 05 38 >>> http://www.erlang-solutions.com >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > Torben Hoffmann > CTO > Erlang Solutions Ltd. > Tel: +45 25 14 05 38 > http://www.erlang-solutions.com > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Mon Jun 16 23:55:20 2014 From: raould@REDACTED (Raoul Duke) Date: Mon, 16 Jun 2014 14:55:20 -0700 Subject: [erlang-questions] too few processes (Re: Erlang for youngsters) Message-ID: it is hard to google up those previous statements. anybody summarize? things that come to mind are that if there are more processes there are advantages in being able to e.g. restart them or load balance them out. but that then means more "overhead" perhaps in the monitoring. but maybe OTP is set up such that the overhead isn't so bad at all. etc. pros/cons? thanks for any thoughts. > process for figuring out what the right amount of processes. As Robert Virding often > says, we tend to make too few processes in our designs, so teaching people that they > are cheap is probably the way to go. From raould@REDACTED Mon Jun 16 23:57:09 2014 From: raould@REDACTED (Raoul Duke) Date: Mon, 16 Jun 2014 14:57:09 -0700 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: i have been told / seen it more than once that if you are not doing OTP then you are just not getting the main core important seriously really super better aspects of Erlang. like you can just look at Erlang w/out OTP and be like "ok cool" but not really get a brain-change from that. basically that any time you write code it should be OTP code, not Erlang code. ? > development in Erlang, it was Erlang/OTP in Action that grounded it and gave > me a solid understanding in how apps should be written in Erlang. From bchesneau@REDACTED Tue Jun 17 01:04:31 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 17 Jun 2014 01:04:31 +0200 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released Message-ID: Hi all, I presented it rapidly during the EUC and it took some time to finish some feature but here the first release of cowdb: http://cowdb.org Cowdb implements an indexed, key/value storage engine in #Erlang. The primary index is an append-only btree implemented using CBT a btree library extracted from Apache #CouchDB. Main features are: - Append-Only b-tree using COW - Read/Write can happen independently - Put/Get/Delete/Fold operations - support transactions with transaction functions - Transaction log - Snapshotting support - Automatic compaction Enjoy!? - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.sylvester@REDACTED Tue Jun 17 01:07:24 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Tue, 17 Jun 2014 00:07:24 +0100 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released In-Reply-To: References: Message-ID: <7EA0281C-C4DE-4646-81EA-DF2781C71EF4@gmail.com> Hi Benoit, Awesome stuff. I?m guessing this is a file based db, like SQLite? What scalability does it have? Cheers, Lee On 17 Jun 2014, at 00:04, Benoit Chesneau wrote: > Hi all, > > I presented it rapidly during the EUC and it took some time to finish some feature but here the first release of cowdb: > > http://cowdb.org > > Cowdb implements an indexed, key/value storage engine in #Erlang. The primary index is an append-only btree implemented using CBT a btree library extracted from Apache #CouchDB. > > Main features are: > > - Append-Only b-tree using COW > - Read/Write can happen independently > - Put/Get/Delete/Fold operations > - support transactions with transaction functions > - Transaction log > - Snapshotting support > - Automatic compaction > > Enjoy!? > > - benoit > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jun 17 01:12:08 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 17 Jun 2014 01:12:08 +0200 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released Message-ID: Looks great! Can't wait to start using it. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Benoit Chesneau Sent:Tue, 17 Jun 2014 01:04:31 +0200 To:erlang-questions@REDACTED Subject:[erlang-questions] [ANN] cowdb 0.1.0 released >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Tue Jun 17 01:34:26 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 17 Jun 2014 01:34:26 +0200 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released In-Reply-To: <7EA0281C-C4DE-4646-81EA-DF2781C71EF4@gmail.com> References: <7EA0281C-C4DE-4646-81EA-DF2781C71EF4@gmail.com> Message-ID: On Tue, Jun 17, 2014 at 1:07 AM, Lee Sylvester wrote: > Hi Benoit, > > Awesome stuff. I?m guessing this is a file based db, like SQLite? What > scalability does it have? > > Cheers, > Lee > > You're right it's file based. In term of scalability I didn't do yet proper benchmarks, should be done in coming days. Write and read are independent and can happen concurrently. Most of read are cached by the filesystem. Also the btree is well tested over the last 4 years in Apache CouchDB. Let me know if you find anything. I have mostly written this db so I can use a pure erlang database (other than mnesia) in my coming project enki that will be opensourced before the end of the month. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Jun 17 03:26:07 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 17 Jun 2014 13:26:07 +1200 Subject: [erlang-questions] Beware of wildcards on Mac OS + NFS Message-ID: <4A4E390C-76FE-422A-9110-5CDBDD87EBAB@cs.otago.ac.nz> While installing rebar today, I ran into a problem. The problem *happened* to bite me in rebar, but it is in no way a rebar-specific problem. It's quite easy to patch around the problem in rebar, but it's worth discussing whether a more general fix is appropriate. Here's the symptom: m% ./bootstrap Recompile: src/._rebar src/._rebar.erl:1: unterminated string starting with "l\000\000\016?\000\000\000\230\000\000\000N\000\000\000" src/._rebar.erl:1: no module definition Failed to compile rebar files! Here's one of the two causes: %% Compile all src/*.erl to ebin case make:files(filelib:wildcard("src/*.erl"), The whole setup has - no problems in Linux - no problems in Solaris - no problems in OpenBSD - no problems in Mac OS X with its native file system BUT - is broken in Mac OS X with files accessed over NFS. The basic issue is that Mac OS X still wants files to have "data forks" and "resource forks", which it uses for "extended attributes". Like these: m% ls -l@ rebar-master.zip -rw-r--r--@ 1 ok csstaff 247237 17 Jun 11:37 rebar-master.zip com.apple.quarantine 78 com.apple.metadata:kMDItemWhereFroms 132 com.apple.metadata:kMDItemDownloadedDate 53 This is actually quite handy; using the 'xattr' command I can discover not just that it was Safari that downloaded the file, but where it was downloaded from. It's also the case that when you unpack downloaded files, the extracted files get the same 'quarantine' information. It's not just downloading. This all works smoothly in the Mac's own file system, but when your home directory is held on a departmental file server and accessed through NFS, it's handled by giving each file xxx a a ._xxx shadow. See for example http://support.grouplogic.com/?p=1496 This is not a problem in shell scripts. m% cd rebar-master/src; ls *.erl will not show the AppleDouble dot-underscore files, because shell wild cards don't match leading dots. However, it appears that filelib:wildcard(...) wildcards DO match leading dots. m% mkdir FOO m% cd FOO m% touch .foo .barfood .foogol m% erl 1> filelib:wildcard("*"). [".barfood",".foo",".foogol"] 2> filelib:wildcard("*.foo*"). [".foo",".foogol"] This discrepancy between Erlang wildcards and UNIX wildcards is not a bug waiting to happen. It is a bug that *has* happened. The documentation for filelib:wildcard/1 http://www.erlang.org/doc/man/filelib.html#wildcard-1 not only does not mention the problem, it goes out of its way to present examples that *WILL* go wrong in Mac OS X. From a user perspective, the simplest and by far the best change would be to make "*" wildcards act like their Unix analogues and NOT match leading dots, and the same with "?". This would immediately fix quite a few programs that are now broken (like all of the wildcard examples in the documentation). The least effort change would alter the documentation: wildcard(Wildcard) -> [file:filename()] Types: Wildcard = filename() | dirname() The wildcard/1 function returns a list of all files that match Unix-style wildcard-string Wildcard. The wildcard string looks like an ordinary filename, except that certain "wildcard characters" are interpreted in a special way. The following characters are special: ? Matches one character. * Matches any number of characters up to the end of the filename, the next dot, or the next slash. +++ BEWARE: in the Unix shells, a * wildcard will never +++ match a leading dot. Thus the file name "._stuff.erl" +++ won't match "*.erl" in a shell. But in this function +++ it WILL match. .... [Character1,Character2,...] ^ ^ *** compile_charset/2 does not in fact require commas or process *** them specially; remove the commas from the documentation. +++ Character classes in ``re'' regular expressions and csh(1) +++ command lines can be complemented using "^". ksh(1) uses +++ "!" for complementing. bash(1) allows both "^" and "!". +++ This function allows neither. You cannot complement a +++ character class at all. To find all .beam files in all applications, the following line can be used: filelib:wildcard("lib/*/ebin/*.beam"). +++ BEWARE: if you are using Mac OS X and accessing files through +++ NFS the extended attributes of a snark.beam file will be held +++ in a ._snark.beam file, *which this pattern will match*. Then all the examples need fixing, but unfortunately it's rather hard to fix them. The simplest patch to the examples would be to change e.g. "lib/*/ebin/*.beam" to "lib/*/ebin/[^.]*.beam". Unfortunately, filelib:wildcard/1 not only does not support complement character set patterns, it doesn't know (and the documentation doesn't say) that there is an issue. m% touch '^x.foo' '.y.foo' 4> filelib:wildcard("[^.]*.foo"). [".y.foo","^x.foo"] 5> filelib:wildcard("[!.]*.foo"). [".y.foo"] The absence of character class complementation means that there is currently NO easy way for Erlang programmers to write wild-card patterns that do the right thing, which is why I think that fixing the semantics is the best thing to do. From jdavid.eisenberg@REDACTED Tue Jun 17 06:57:19 2014 From: jdavid.eisenberg@REDACTED (J David Eisenberg) Date: Mon, 16 Jun 2014 21:57:19 -0700 Subject: [erlang-questions] Erlang for youngsters Message-ID: On Mon, Jun 16, 2014 at 6:26 PM, wrote: > Send erlang-questions mailing list submissions to > erlang-questions@REDACTED > > To subscribe or unsubscribe via the World Wide Web, visit > http://erlang.org/mailman/listinfo/erlang-questions > or, via email, send a message with subject or body 'help' to > erlang-questions-request@REDACTED > > You can reach the person managing the list at > erlang-questions-owner@REDACTED > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of erlang-questions digest..." > > > Today's Topics: > > Date: Mon, 16 Jun 2014 20:58:20 +0200 > From: Torben Hoffmann > To: Lo?c Hoguin > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang for youngsters > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > Lo?c Hoguin writes: > >> I don't think the problem is so much that these things are hard to >> learn, but rather that you *have* to learn them. OO was hard to learn. >> Pointers took me a while also. In comparison Erlang was very fast to get >> started with as I started writing parsers for binary files immediately, >> then later on making it parallel and eventually learnt OTP and did other >> small things with the language. >> >> At the time there was basically no resources. LYSE had about 5 chapters >> so I didn't really use it. A few blog posts here and there helped a >> little, but it was mostly Joe's book. Today we have tons of resources. I >> do not think the docs problem shown by Garrett is the reason why Erlang >> is hard to learn. I think it's just correlation. (Of course some of the >> OTP docs are terrible, like sofs and bits of the common_test guide, but >> the docs on erlang.org are impressive; only they do not help the Erlang >> beginner, this is covered by Joe's book, LYSE and others.) If there is >> causation then a link to the free version of LYSE from the erlang.org >> docs page should be plenty enough to fix it. >> >> What I think is that people say Erlang is hard to learn because they >> expect to go from 0 knowledge to be able to use it for their job in a >> few hours. This is plain crazy, nobody learnt OO in a day, and nobody >> can learn concurrent/fault tolerant in a day. And it's even harder if >> your mind is stuck on a particular paradigm. >> > I think this is remarkably well put. It sort of hints the head on the nail for me. > Respect for the learning curve. I too see a tendency of this from time to time. > This is true, but you want to provide beginners with a "success experience" quickly, with the explicit statement that it *is* just a beginning step. ("Don't try this at work!") > Thanks for articulating that, Lo?c! > >> Learning takes time. In today's impatient world this is seen as a >> weakness, but those who do take the time to learn Erlang get an >> exponential reward for their troubles. This is unfortunately hard to >> demonstrate to people who want everything immediately without the effort. >> >> But to kids who have never done programming before? They'll learn Erlang >> as easily as anything else. When you first start programming even "hello >> world" is a magical moment. When you've programmed for years it's a very >> boring moment and you want to skip ahead, which is impossible if you >> have to learn a new paradigm entirely. Kids do not have that problem. So >> stop worrying and teach them Erlang. >> I tell my programming students: "You can either pay now or pay later; pay later is almost always more expensive." That is, the time spent in planning (pay now) is a much better use of your time than randomly thrashing about trying things until you get something that seems to work--until it doesn't, and you have to fix it (pay later). Or, more cynically: "hours of programming can save you minutes of planning." Erlang especially seems to be a language where "pay now" is far less expensive. With functional programming in particular, programs written at the keyboard look like it, and that is not a compliment. (A REPL is great for testing hypothesis and small snippets, but certainly not for composing an entire program.) > A kinderd spirit. > > So this boils down to motivation to sustain through the learning curve and pureness > of the fresh minds to avoid having to unlearn other paradigms. Other thoughts about this: 1) Graphics: An absolute necessity. "Hey, kids, let's output Fibonacci numbers!" falls flat. "Hey, kids, let's draw this cool spiral (which happens to use Fibonacci numbers)!" is much more appealing. As for Erlang and graphics, there's Wings 3D, and I'm not sure how easy that is to get into 2) Elixir vs. Erlang: I'm going to vote for Erlang here. I like Elixir, and I like its libraries that make general-purpose programming easier. However, it *looks* like an imperative language, and that will cause interference for those beginners who may have done some JavaScript or Python (i.e., Raspberry Pi programmers). One advantage of Erlang (or LFE or Clojure) is that it doesn't look anything like a typical imperative language, so I'm not tempted to think in imperative terms. Erlang's single assignment vs. Elixir's ability to rebind a variable is another way that Erlang will "lead me not into temptation." 3) Existing materials for other languages: I'm very impressed by http://www.bootstrapworld.org/ 4) What do you really want to teach/Erlang's problem space. Erlang is designed for solving problems of "fault-tolerant, concurrent, distributed programming" -- are you teaching Erlang for those properties, in which case you need to map them into the problem space that young programmers might be interested in, or are you teaching it as a general functional programming language? That's not the same as a general-purpose programming language, of course. > > Cheers, > Torben > > >> On 06/16/2014 12:20 PM, Anthony Ramine wrote: >>> Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition? >>> > > > -- > Torben Hoffmann > CTO > Erlang Solutions Ltd. > Tel: +45 25 14 05 38 > http://www.erlang-solutions.com > From fishballian@REDACTED Tue Jun 17 08:43:53 2014 From: fishballian@REDACTED (=?ISO-8859-1?B?ZmlzaGJhbGw=?=) Date: Tue, 17 Jun 2014 14:43:53 +0800 Subject: [erlang-questions] Efficiency of function call Message-ID: Hi As I read the Efficiency Guide, I found something interesting:(see http://www.erlang.org/doc/efficiency_guide/functions.html#id67357) Here is an intentionally rough guide to the relative costs of different kinds of calls. It is based on benchmark figures run on Solaris/Sparc: Calls to local or external functions (foo(), m:foo()) are the fastest kind of calls. Calling or applying a fun (Fun(), apply(Fun, [])) is about three times as expensive as calling a local function. Applying an exported function (Mod:Name(), apply(Mod, Name, [])) is about twice as expensive as calling a fun, or about six times as expensive as calling a local function. But I get another result when I run these code in my computer: foo() -> ok. test() -> List = lists:seq(1, 50000000), statistics(wall_clock), statistics(runtime), %% [foo() || _ <- List], %%test result 358 ~ 358 %% [?MODULE:foo() || _ <- List], %%test result 358 ~ 358 %% [apply(?MODULE, foo, [] || _ <- List], %%test result 358 ~ 358 [apply(fun() -> ok end, []) || _ <- List], %%test result 2247 ~ 1716 {_, Time1} = statistics(wall_clock), {_, Time2} = statistics(runtime), io:format("calc ~p ~~ ~p~n", [Time1, Time2]).Applying a fun is even slower than apply/3, Why? I also notice "apply/3 must look up the code for the function to execute in a hash table. Therefore, it will always be slower than a direct call or a fun call". So I test in my project which include many modules and I get the same result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Tue Jun 17 09:18:36 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Tue, 17 Jun 2014 09:18:36 +0200 Subject: [erlang-questions] Efficiency of function call In-Reply-To: References: Message-ID: It is because you construct and execute the fun in the same timeslot. You want to benchmark something like this: F = fun() -> ok end, %% Take start time [F() || _ <- List] %% Take end time Unfortunately fun does not come for free. Lukas On Tue, Jun 17, 2014 at 8:43 AM, fishball wrote: > Hi > As I read the *Efficiency Guide*, I found something interesting:(see > http://www.erlang.org/doc/efficiency_guide/functions.html#id67357) > > Here is an intentionally rough guide to the relative costs of different > kinds of calls. It is based on benchmark figures run on Solaris/Sparc: > > - Calls to local or external functions (foo(), m:foo()) are the > fastest kind of calls. > > > - Calling or applying a fun (Fun(), apply(Fun, [])) is about three > times as expensive as calling a local function. > > > - Applying an exported function (Mod:Name(), apply(Mod, Name, [])) is > about twice as expensive as calling a fun, or about six times as > expensive as calling a local function. > > But I get another result when I run these code in my computer: > > foo() -> > ok. > test() -> > List = lists:seq(1, 50000000), > statistics(wall_clock), > statistics(runtime), > %% [foo() || _ <- List], %%test result > 358 ~ 358 > %% [?MODULE:foo() || _ <- List], %%test result 358 ~ > 358 > %% [apply(?MODULE, foo, [] || _ <- List], %%test result 358 ~ 358 > [apply(fun() -> ok end, []) || _ <- List], %%test result 2247 > ~ 1716 > {_, Time1} = statistics(wall_clock), > {_, Time2} = statistics(runtime), > io:format("calc ~p ~~ ~p~n", [Time1, Time2]). > > Applying a fun is even slower than apply/3, Why? > I also notice "apply/3 must look up the code for the function to execute > in a hash table. Therefore, it will always be slower than a direct call or > a fun call". > So I test in my project which include many modules and I get the same > result. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semmitmondo@REDACTED Tue Jun 17 10:24:54 2014 From: semmitmondo@REDACTED (semmit mondo) Date: Tue, 17 Jun 2014 10:24:54 +0200 (CEST) Subject: [erlang-questions] Intel Xeon Phi Message-ID: Hi List, Is the Erlang runtime capable of spawning processes on a Xeon Phicoprocessor? Or is this piece of hardware too rare for Erlang to beable to take advatage of it? U. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martink@REDACTED Tue Jun 17 10:31:13 2014 From: martink@REDACTED (Martin Karlsson) Date: Tue, 17 Jun 2014 20:31:13 +1200 Subject: [erlang-questions] mnesia:table_info(Table, memory) when storing binaries Message-ID: Hi all, I'm storing binaries in mnesia in a simple key value fashion. The tables are disc_copies tables and (optionally) fragmented. When doing mnesia:table_info(Table, memory) the result coming back is not actually reflecting the memory used. I understand this is because mnesia stores pointers to the binaries rather than the binary itself and the binaries are not accounted for in the memory information; just the pointers. What would be a reliable way to get the actual memory used? The size of the disk_log files seems to match up but perhaps that is just by chance. If not can I do a simple file:file_info on all the fragments for a table? What other ways are there? Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Tue Jun 17 09:14:16 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Tue, 17 Jun 2014 09:14:16 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <20140616125952.GM51530@ferdair.local> References: <20140616125952.GM51530@ferdair.local> Message-ID: Fred Hebert writes: > Answers inline (and better seen through fixed-width font) > > On 06/16, Torben Hoffmann wrote: >> I think that fault-tolerant, distributed programming is hard because there is a big >> context you need to address. The sheer about of things that can go wrong will make it >> difficult to get into. >> >> I think that concurrent programming is easy to learn: >> > > I'm injecting myself in here to put emphasis on that part. The objective > here is to teach concurrent programming and fault tolerance, right? > To be precise: the objective would be to teach how processes and message passing can be used to architect solutions. I think that the underlying message passing is part of what leads to architectures that are loosely coupled despite the fact that we always strive for using processes through their API instead of sending messages directly. In Visual Erlang I have notation for both calling a function and sending a message, but calling an API function has the easiest arrow, namely a line with an arrow at the end. That it looks like sending a message due to the arrow is fully intentional, because that is how one talks about it. Or at least that's how I and those in my neighbourhood talk about it. >> Here's a simple process that just acknowledges that it has received a message and >> continues to do so over and over again: >> >> echo() -> >> receive >> Msg -> >> io:format("I'm happy, 'cause I recevied: ~p~n", [Msg] >> end, >> echo(). >> >> The file example1.erl contains the echo function. >> Open up the Erlang shell: >> $ erl >> >> c(example1). >> >> (this compiles the code and now you can start an echo process) >> >> Pid = spawn ( fun() -> echo() end ). >> >> (you just stored the process identifier (Pid) for the process you spawn, so now you >> can send it a message:) >> >> Pid ! "Erlang is cool". >> >> "I'm happy, 'cause I received: Erlang is cool" > > > Here's what could be even nicer: have an IDE (or something like > scratch). Every process is its own block on the screen, visual: > > > *-------------[echo]--------------------------* *----[ProcX]-----* > | echo() -> | | ... | > | receive | *----------------* > | Msg -> | > | io:format("I'm happy, ...", [Msg]) | *---[Output]-----* > | end, | | | > | echo(), | | | > *---------------------------------------------* *----------------* > > Click 'run'. Click the process, and have a prompt that lets you write in > a message: "Erlang is cool". See the box hilighted when code runs there: > > *=============[echo]==========================* *----[ProcX]-----* > || echo() -> || | ... | > || receive || *----------------* > || Msg -> || > || io:format("I'm happy, ...", [Msg]) || *---[Output]-----* > || end, || | | > || echo(), || | | > *=============================================* *----------------* > > see the output in another box: > > *-------------[echo]--------------------------* *----[ProcX]-----* > | echo() -> | | ... | > | receive | *----------------* > | Msg -> | > | io:format("I'm happy, ...", [Msg]) | *===[Output]=====* > | end, | || I'm happy, || > | echo(), | || 'cause I ... || > *---------------------------------------------* *================* > > Hell, at this point it no longer needs to be Erlang, if you really want > to teach the principles, and not the language. The question here really > is: what's the objective? > > I mean, let people put colors on the boxes, even be able to change > their shapes and brightness and events and they'll probably be able to > create fancypants blinkenlight stuff, or want to use it as a monitoring > dashboard for whatever. > > If the objective is to teach Erlang for them to learn the principles it > stands for, teaching these principles should come before 'teaching > Erlang' in how the educative environment is set up. > This is a very good idea. I wish I had gotten it first. Creating an IDE where creating processes and functions without having to worry about modules, compilation and what-have-you would be the ideal way of teaching concurrency based on processes and message passing. I think that Visual Erlang could be augmented to provide the visual part of the IDE. After solving an exercise the resulting code could be shown like learn.code.org does it - that would open up the door to the more complicated modules in an lenient manner. Basically, there would be an ability to gradually move from visuals to actual typing of code. > If the objective is 'teach Erlang', then you'll have to make different > assumptions entirely. > Totally. I had a hunch about what I thought might work, but this thread gives me a lot of input regarding what the solution or solutions could be. Cheers, Torben > Regards, > Fred. -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Tue Jun 17 10:17:06 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Tue, 17 Jun 2014 10:17:06 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <1402945075.869528733@apps.rackspace.com> References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: lloyd@REDACTED writes: > Hello, > > So many great ideas. So many talented contributors. Indeed! > A fantasy--- > > One or more of... > > - a website > - hosting platform > - an e-book - free for download > - a hard-cover book - royalties kick back to help kids > - a hardware platform - profits kick back to help kids > > Projects > > - build your own website > - chat with friends > - organize your collections > - build a multi-player game > - control a robot > - control your house > - build your own supercomputer > ???? > > Contest for project submissions > > Team > > - dedicated Erlang volunteers > - perhaps formalize with a foundation ala Raspberry Pi > > Process > > - Dream > - Brainstorm > - Set goals > - Organize > - Delegate > - Produce > I think the dreaming has started... but lets get the main direction in place before we run into things. I had a look at the CodeClub organisation that Fred mentioned. Though it is targeted at 9-11 year old kids they - like many others - start with a visual environment. They use Scratch - Fred outlined what it could look like for Erlang/Elixir elsewhere in this thread (http://erlang.org/pipermail/erlang-questions/2014-June/079563.html). I initially sat the target to be 12-15 year old kids, but I have a feeling that a visual environment would still have a lot of mileage with that group. Basically, it would be nice to have a one-stop installer that contains both the environment and the Erlang/Elixir system. Simply no friction if at all possible. So that is the first branching point: visual or text? Staying on the visual track for a second; I had a look at the DRAKON editor (http://drakon-editor.sourceforge.net/drakon-erlang/intro.html) which has support for Erlang to generate code. Unfortunately it does not generate idiomatic Erlang code and the Tcl UI feels a bit dated. Visual Erlang (https://github.com/esl/visual_erlang) is still in its infancy, but adding extensions to fit the teaching purpose is not impossible. One can steal ideas from DRAKON and other notations like SDL. All of this is something that is non-trivial to do. The MIT team behind Scratch has spent years getting their environment to work. Second branching point: Erlang or Elixir? The main objective should still be to introduce the Erlang way of approaching programming which is the foundation of Elixir as well, so either language would work for this. I think we need to device some sort of experiment that can gauge which is the right choice. That, unfortunately, requires work on both of them, but it beats the alternative of running down the wrong path only to realise it when it might be too late. > Platform > > - Software projects can be done on Windows assuming easy peasy Erlang install > Erlang runs on every platform, but Windows is the one with the worst support. > - How can we get youngsters into Linux? > > - A hardware platform would open up robotics and control applications: > > Cheap (under $100) ARM boards > > -- Arduino etc. > > -- Raspberry Pi > > -- I have an Odroid U3 on my desk. No time to fire it up yet; but very compact, > quiet, low power, plenty of computing power, runs Linux. Total of $90 for board, > pwr supply, HDMI cable, wi-fi module, and case. Would need an MicroSD card with > Linux and Erlang installed. > > Over the past year there have been a slew of such devices hitting the market and > more coming. > That hits the third branching point: computer or embedded? At ESL we have some experience with the embedded side of things. It adds a lot of extra variables to the equation, but it is arguably also a lot of fun. We might be able to get Erlang to run on a thing like the Arduino Yun (http://store.arduino.cc/index.php?main_page=product_info&cPath=11_12&products_id=313), but only on the Linux side. Running on the micro controller is out of the question - 32KB RAM is not enough for Erlang. Raspberry Pi just works. Going embedded means that doing things with graphics is impossible. On a computer we could tap into graphical libraries, say Processing, and create a very visual feedback. Opinions on the branching points most welcome! Cheers, Torben > Can we get /software/hardware cos to help sponsor the effort? > > Best, > > Lloyd > > > > > > > > > > > -----Original Message----- > From: "Ferenc Holzhauser" > Sent: Monday, June 16, 2014 1:30pm > To: "Tony Rogvall" > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Erlang for youngsters > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > Robotics is really nice but in this case accessibility is even nicer. It is > great if kids can play after class too with interesting things without > having to put items of fairly significant value (for some) on their > wishlist. These days a > computer with internet access can be a fascinatingly accessible way of > creativity. An idea could be to make a simple game backend to compete with > their friends and fellow students (e.g. a 2d tank shooting game or > something). Eventually with chat and similar functions to add. Then the > teacher could make things go wrong on the server(s) that they'd need to fix > (distribute/scale/fail over) depending on their progress. You could lure > them into AI like things too if you fancy. I'm sure someone with the skills > (e.g. SVG/ezwebframe) and time could make some simple client "building > blocks" work for something like this. > > > On 16 June 2014 18:12, Tony Rogvall wrote: > >> >> On 16 jun 2014, at 13:55, Mark Nijhof >> wrote: >> >> +1 on this, this rings very true to home. But I also believe that it needs >> to return results quickly. I.e. building a game is great, but if they have >> to "code" for days before they see something happen then they loose >> interest (assumption). So preparing "building blocks" might be a good >> approach and have them first implement higher level stuff and then step by >> step dig deeper and implement the building blocks you prepared. >> >> An other exercise I planned is to program a drone (not sure about the >> language there yet) to fly an obstacle course. So they see it is not just >> something that happens on their iPads ;) >> >> You program drone in Erlang of course :-) >> >> https://github.com/tonyrog/edrone >> >> /Tony >> >> -Mark >> >> >> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >> mahesh@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. >>> >>> Amen! >>> The least relevant part of teaching kids programming is the syntax, or >>> the choice of language - they don't, and won't, give a s**t about it. >>> As a simple thought experiment, just look at how you raised your kids in >>> a multi-lingual environment (yes my American brethren, this is hard. >>> Pretend :-) ) Notice how they - fluidly - bounce across languages, >>> massacring every grammar rule ever, but quite happily making sure that you >>> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >>> odio odio odio la piselli, i don't wanna, where is my red truck?" >>> Mind you, they will pick up the rules over time, but the key here is the >>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>> immediately relevant it is to the young 'uns, the more rapidly they will >>> pick up the tools, the specifics of the language be damned. >>> >>> Cheers >>> >>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >>> ferenc.holzhauser@REDACTED> wrote: >>> >>>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>> that Erlang is created to solve problems that are rather "industrial" and >>>> most people "from outside" can't really relate to. If the audience is not >>>> comfortable with understanding the problem itself then it is tricky to make >>>> them understand/like the solution too. >>>> >>>> This we can see with many new people getting into Erlang: The problems >>>> they are given are new and difficult to understand. So they often just go >>>> off and eagerly try to solve all sort of issues they are familiar with >>>> (even when they are not relevant in the particular case) before even trying >>>> to understand what the real challenge is. Then they start complaining that >>>> Erlang is not very good for some/many of those issues they are busy with. >>>> >>>> And other way around: people coming to Erlang with the right >>>> understanding of the problem area it is made for find it amazingly simple >>>> to learn. >>>> >>>> Coming from the wrong (or right ?) background my imagination fails to >>>> come up with these appealing challenges for the youngster target group, but >>>> I'm sure many of you can do much better. >>>> >>>> Ferenc >>>> >>>> >>>> On 16 June 2014 11:31, Miles Fidelman >>>> wrote: >>>> >>>>> Garrett Smith wrote: >>>>> >>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>> wrote: >>>>>> >>>>>> -snip- >>>>>> >>>>>> I think that a learning resource focused on teaching people the >>>>>>> Erlang model from the >>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>> do we solve a >>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>> problem. >>>>>>> >>>>>>> My initial target for such a learning resources would be young people >>>>>>> in the higher >>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>> influence them >>>>>>> before their minds are totally corrupted by other programming models. >>>>>>> >>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>> this group - we >>>>>>> just have to find a cool example and organise the learning around how >>>>>>> to become so >>>>>>> good that one can solve such a problem. >>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>> of Transport >>>>>>> Tycoon clone?!?! >>>>>>> >>>>>> I don't have enough experience teaching programming to this age group >>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>> be a bit ambitious for these young learners. >>>>>> >>>>>> I'm speaking in particular about the model that emerges when you >>>>>> isolate processes. It changes everything: your approach to building >>>>>> software (move from state oriented to activity oriented), error >>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>> program structure (from monolith to system), and so on. The benefits >>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>> it wasn't, or I wish I was better at communicating. >>>>>> >>>>>> >>>>>> >>>>> I'm with the folks who suggest that this group has fewer >>>>> pre-conceptions to unlearn. >>>>> >>>>> It strikes me that the actor model is far more natural for certain >>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>> processes. >>>>> >>>>> Miles Fidelman >>>>> >>>>> >>>>> -- >>>>> In theory, there is no difference between theory and practice. >>>>> In practice, there is. .... Yogi Berra >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> >>> * Mahesh Paolini-Subramanya >>> That >>> tall bald Indian guy..* >>> * Google+ >>> | Blog | Twitter >>> | LinkedIn >>> * >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> "Installing applications can lead to corruption over time. Applications >> gradually write over each other's libraries, partial upgrades occur, user >> and system errors happen, and minute changes may be unnoticeable and >> difficult to fix" >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From bjorn@REDACTED Tue Jun 17 11:17:04 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 17 Jun 2014 11:17:04 +0200 Subject: [erlang-questions] file:file_info/1 broken on R17 In-Reply-To: <52529427.6099.1402394041373.JavaMail.zimbra@tpip.net> References: <1651476655.6093.1402393923906.JavaMail.zimbra@tpip.net> <52529427.6099.1402394041373.JavaMail.zimbra@tpip.net> Message-ID: On Tue, Jun 10, 2014 at 11:54 AM, Andreas Schultz wrote: > Hi, > > file:file_info/1 is marked obsolete, but it is still there and > should probably not be broken, right? There is only a stub there. The actual function was removed a long time ago. Unfortunately the person who removed the code (probably me) forgot to remove the documentation as well. We will remove the documentation in the upcoming release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From jose.valim@REDACTED Tue Jun 17 11:50:11 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 17 Jun 2014 11:50:11 +0200 Subject: [erlang-questions] Beware of wildcards on Mac OS + NFS In-Reply-To: <4A4E390C-76FE-422A-9110-5CDBDD87EBAB@cs.otago.ac.nz> References: <4A4E390C-76FE-422A-9110-5CDBDD87EBAB@cs.otago.ac.nz> Message-ID: There is a solution that can be used meanwhile which seems to work at least back to R15. filelib:wildcard/2 allows a module that gets information from the filesystem to be passed as second argument. The module only needs to export read_file_info/1 and list_dir/1, as defined here: https://github.com/erlang/otp/blob/maint/lib/stdlib/src/filelib.erl#L490-L508 Given the module defined below: -module(file_no_dot_match). -export([read_file_info/1, list_dir/1]). read_file_info(File) -> file:read_link_info(File). list_dir(Dir) -> case file:list_dir(Dir) of {ok, Files} -> {ok, [File || File <- Files, hd(File) /= $.]}; Other -> Other end. You can now get filelib:wildcard/2 to ignore files starting with dot by passing the module as argument: filelib:wildcard(Pattern, file_no_dot_match). I have run some tests locally and this approach seem to initially work fine. *, ** and ? now all ignore dots at the beginning of the file name. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Tue, Jun 17, 2014 at 3:26 AM, Richard A. O'Keefe wrote: > While installing rebar today, I ran into a problem. > The problem *happened* to bite me in rebar, but it > is in no way a rebar-specific problem. It's quite > easy to patch around the problem in rebar, but it's > worth discussing whether a more general fix is > appropriate. > > Here's the symptom: > > m% ./bootstrap > Recompile: src/._rebar > src/._rebar.erl:1: unterminated string starting with > "l\000\000\016?\000\000\000\230\000\000\000N\000\000\000" > src/._rebar.erl:1: no module definition > Failed to compile rebar files! > > Here's one of the two causes: > > %% Compile all src/*.erl to ebin > case make:files(filelib:wildcard("src/*.erl"), > > The whole setup has > - no problems in Linux > - no problems in Solaris > - no problems in OpenBSD > - no problems in Mac OS X with its native file system > BUT > - is broken in Mac OS X with files accessed over NFS. > > The basic issue is that Mac OS X still wants files to > have "data forks" and "resource forks", which it uses > for "extended attributes". Like these: > > m% ls -l@ rebar-master.zip > -rw-r--r--@ 1 ok csstaff 247237 17 Jun 11:37 rebar-master.zip > com.apple.quarantine 78 > com.apple.metadata:kMDItemWhereFroms 132 > com.apple.metadata:kMDItemDownloadedDate 53 > > This is actually quite handy; using the 'xattr' command I can > discover not just that it was Safari that downloaded the file, > but where it was downloaded from. > > It's also the case that when you unpack downloaded files, > the extracted files get the same 'quarantine' information. > > It's not just downloading. > > This all works smoothly in the Mac's own file system, but when > your home directory is held on a departmental file server and > accessed through NFS, it's handled by giving each file xxx a > a ._xxx shadow. See for example http://support.grouplogic.com/?p=1496 > > This is not a problem in shell scripts. > m% cd rebar-master/src; ls *.erl > will not show the AppleDouble dot-underscore files, > because shell wild cards don't match leading dots. > > However, it appears that filelib:wildcard(...) wildcards > DO match leading dots. > > m% mkdir FOO > m% cd FOO > m% touch .foo .barfood .foogol > m% erl > 1> filelib:wildcard("*"). > [".barfood",".foo",".foogol"] > 2> filelib:wildcard("*.foo*"). > [".foo",".foogol"] > > This discrepancy between Erlang wildcards and UNIX wildcards > is not a bug waiting to happen. It is a bug that *has* happened. > The documentation for filelib:wildcard/1 > http://www.erlang.org/doc/man/filelib.html#wildcard-1 > not only does not mention the problem, it goes out of its way > to present examples that *WILL* go wrong in Mac OS X. > > From a user perspective, the simplest and by far the best change > would be to make "*" wildcards act like their Unix analogues and > NOT match leading dots, and the same with "?". > > This would immediately fix quite a few programs that are now > broken (like all of the wildcard examples in the documentation). > > The least effort change would alter the documentation: > > wildcard(Wildcard) -> [file:filename()] > > Types: > > Wildcard = filename() | dirname() > > The wildcard/1 function returns a list of all files that match > Unix-style wildcard-string Wildcard. > > The wildcard string looks like an ordinary filename, except that > certain "wildcard characters" are interpreted in a special way. > The following characters are special: > > ? > Matches one character. > > * > Matches any number of characters up to the end of the > filename, the next dot, or the next slash. > +++ BEWARE: in the Unix shells, a * wildcard will never > +++ match a leading dot. Thus the file name "._stuff.erl" > +++ won't match "*.erl" in a shell. But in this function > +++ it WILL match. > > .... > > [Character1,Character2,...] > ^ ^ > > *** compile_charset/2 does not in fact require commas or process > *** them specially; remove the commas from the documentation. > > +++ Character classes in ``re'' regular expressions and csh(1) > +++ command lines can be complemented using "^". ksh(1) uses > +++ "!" for complementing. bash(1) allows both "^" and "!". > +++ This function allows neither. You cannot complement a > +++ character class at all. > > To find all .beam files in all applications, the > following line can be used: > > filelib:wildcard("lib/*/ebin/*.beam"). > > +++ BEWARE: if you are using Mac OS X and accessing files through > +++ NFS the extended attributes of a snark.beam file will be held > +++ in a ._snark.beam file, *which this pattern will match*. > > Then all the examples need fixing, but unfortunately it's rather > hard to fix them. The simplest patch to the examples would be > to change e.g. "lib/*/ebin/*.beam" to "lib/*/ebin/[^.]*.beam". > > Unfortunately, filelib:wildcard/1 not only does not support > complement character set patterns, it doesn't know (and the > documentation doesn't say) that there is an issue. > > m% touch '^x.foo' '.y.foo' > 4> filelib:wildcard("[^.]*.foo"). > [".y.foo","^x.foo"] > 5> filelib:wildcard("[!.]*.foo"). > [".y.foo"] > > The absence of character class complementation means that there > is currently NO easy way for Erlang programmers to write wild-card > patterns that do the right thing, which is why I think that > fixing the semantics is the best thing to do. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jun 17 12:19:25 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Jun 2014 12:19:25 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 12:10 PM, Greg Young wrote: > Can you really compare the two? :) > Yes - there are many things we can measure. Performance, Latency, memory usage and so on. Right now I'm measuring latency - I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses. the results will be published when I understand them :-) /Joe > > > On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro > wrote: > >> Hi Joe, >> >> There's a semicolon missing after the declaration of fib(), which for >> some reason, causes the stack overflow. After adding it the error went away. >> >> HTH, >> >> J >> >> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>> >>> I'm trying to compare node.js with erlang. I'm a total node.js novice >>> BTW - but I've written some JS. >>> >>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>> >>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and return >>> fib(2) >>> >>> My node.js attempt crashes >>> Here's the code in fib.js >>> >>> --- fib.js >>> >>> var http = require('http'); >>> var url = require('url'); >>> >>> function fib(n) { >>> if (n < 2) { >>> return 1; >>> } else { >>> return fib(n - 2) + fib(n - 1); >>> } >>> } >>> >>> http.createServer(function (req, res) { >>> var q = url.parse(req.url, true).query; >>> var n = q.n; >>> var result = fib(n); >>> console.log('fib('+ n + ')= '+result); >>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>> res.end(result.toString()); >>> }).listen(8124, "127.0.0.1"); >>> >>> console.log('Server running at http://127.0.0.1:8124/'); >>> >>> -- end >>> >>> -- now we run it >>> >>> $ node fib.js >>> Server running at http://127.0.0.1:8124/ >>> fib(2)= 2 >>> >>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>> function fib(n) { >>> ^ >>> RangeError: Maximum call stack size exceeded >>> >>> fib(2) has run out of stack space???? >>> >>> $ node --version >>> v0.8.21 >>> >>> Any ideas what I'm doing wrong >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> >>> >>> >>> -- >> Remember to send a copy to erlang (dot) questions (at) erlang (dot) org >> when posting. >> --- >> You received this message because you are subscribed to the Google Groups >> "Erlang Programming" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to erlang-programming+unsubscribe@REDACTED >> To post to this group, send email to erlang-programming@REDACTED >> Visit this group at http://groups.google.com/group/erlang-programming. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Studying for the Turing test > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.sylvester@REDACTED Tue Jun 17 12:22:00 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Tue, 17 Jun 2014 11:22:00 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <17D36FB7-0DBF-4507-A778-8A0D6624EF21@gmail.com> As a heads up; I once built an app in NodeJS which did a lot of heavy lifting on connections and database calls. I ran into some pretty major issues with file descriptors and resource usage which ended up being crippling with little room to manoeuvre. I don?t get those issues, anymore, with Erlang :-) Lee On 17 Jun 2014, at 11:19, Joe Armstrong wrote: > > > On Tue, Jun 17, 2014 at 12:10 PM, Greg Young wrote: > Can you really compare the two? :) > > Yes - there are many things we can measure. Performance, Latency, memory usage and so on. > > Right now I'm measuring latency - > > I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses. > > the results will be published when I understand them :-) > > /Joe > > > > > > > > On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro wrote: > Hi Joe, > > There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away. > > HTH, > > J > > On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: > I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. > > Program 1 is just fibonacci - I want a web server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at http://127.0.0.1:8124/'); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. > --- > You received this message because you are subscribed to the Google Groups "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED > To post to this group, send email to erlang-programming@REDACTED > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/d/optout. > > > > -- > Studying for the Turing test > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jun 17 13:48:12 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Jun 2014 13:48:12 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 1:00 PM, Greg Young wrote: > Are you testing against single threaded node or one of the clustered > versions or multiple processes or? > > > Single threaded /Joe > On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: > >> >> >> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >> wrote: >> >>> Can you really compare the two? :) >>> >> >> Yes - there are many things we can measure. Performance, Latency, memory >> usage and so on. >> >> Right now I'm measuring latency - >> >> I set up a few thousand parallel processes which request fib(N) and >> measure the latency of the responses. >> >> the results will be published when I understand them :-) >> >> /Joe >> >> >> >> >> >> >>> >>> >>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>> wrote: >>> >>>> Hi Joe, >>>> >>>> There's a semicolon missing after the declaration of fib(), which for >>>> some reason, causes the stack overflow. After adding it the error went away. >>>> >>>> HTH, >>>> >>>> J >>>> >>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>> >>>>> I'm trying to compare node.js with erlang. I'm a total node.js novice >>>>> BTW - but I've written some JS. >>>>> >>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>> >>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and return >>>>> fib(2) >>>>> >>>>> My node.js attempt crashes >>>>> Here's the code in fib.js >>>>> >>>>> --- fib.js >>>>> >>>>> var http = require('http'); >>>>> var url = require('url'); >>>>> >>>>> function fib(n) { >>>>> if (n < 2) { >>>>> return 1; >>>>> } else { >>>>> return fib(n - 2) + fib(n - 1); >>>>> } >>>>> } >>>>> >>>>> http.createServer(function (req, res) { >>>>> var q = url.parse(req.url, true).query; >>>>> var n = q.n; >>>>> var result = fib(n); >>>>> console.log('fib('+ n + ')= '+result); >>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>> res.end(result.toString()); >>>>> }).listen(8124, "127.0.0.1"); >>>>> >>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>> >>>>> -- end >>>>> >>>>> -- now we run it >>>>> >>>>> $ node fib.js >>>>> Server running at http://127.0.0.1:8124/ >>>>> fib(2)= 2 >>>>> >>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>> function fib(n) { >>>>> ^ >>>>> RangeError: Maximum call stack size exceeded >>>>> >>>>> fib(2) has run out of stack space???? >>>>> >>>>> $ node --version >>>>> v0.8.21 >>>>> >>>>> Any ideas what I'm doing wrong >>>>> >>>>> Cheers >>>>> >>>>> /Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) org >>>> when posting. >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Erlang Programming" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to erlang-programming+unsubscribe@REDACTED >>>> To post to this group, send email to >>>> erlang-programming@REDACTED >>>> Visit this group at http://groups.google.com/group/erlang-programming. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Studying for the Turing test >>> >> >> > > > -- > Studying for the Turing test > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darach@REDACTED Tue Jun 17 14:05:19 2014 From: darach@REDACTED (Darach Ennis) Date: Tue, 17 Jun 2014 13:05:19 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: Hi all, For this to be comparable both Erlang and Node.js need to be running similarly. I don't see how a concurrent Erlang runtime with multiple schedulers can be compared with a single-threaded Node.js implementation objectively or fairly... Using node cluster with the same number of cluster instances as erlang schedulers might be a fairer environment for comparison. However, as numeric computations are fairly efficient in Node.js and inefficient in Erlang relative to Java or C it may take a few iterations to get a fair comparison in place. Node cluster is a standard part of node.js: http://nodejs.org/api/cluster.html There are various attempts at implementing fibers and lightweight threads in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is nothing common here. This would approximate an erlang runtime more closely at the cost of deviating a little from a commonly found node runtime... Ho hum. As javascript runtimes start to adopt vectorized instructions and other optimisations their speed relative to a C baseline has and will continue to steadily improve and has been for a number of years, especially with V8. Good luck with the benchmarking! Cheers, Darach. On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: > > > > On Tue, Jun 17, 2014 at 1:00 PM, Greg Young > wrote: > >> Are you testing against single threaded node or one of the clustered >> versions or multiple processes or? >> >> >> > Single threaded > > /Joe > > >> On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: >> >>> >>> >>> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >>> wrote: >>> >>>> Can you really compare the two? :) >>>> >>> >>> Yes - there are many things we can measure. Performance, Latency, memory >>> usage and so on. >>> >>> Right now I'm measuring latency - >>> >>> I set up a few thousand parallel processes which request fib(N) and >>> measure the latency of the responses. >>> >>> the results will be published when I understand them :-) >>> >>> /Joe >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>>> wrote: >>>> >>>>> Hi Joe, >>>>> >>>>> There's a semicolon missing after the declaration of fib(), which for >>>>> some reason, causes the stack overflow. After adding it the error went away. >>>>> >>>>> HTH, >>>>> >>>>> J >>>>> >>>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>> >>>>>> I'm trying to compare node.js with erlang. I'm a total node.js novice >>>>>> BTW - but I've written some JS. >>>>>> >>>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>> >>>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and >>>>>> return fib(2) >>>>>> >>>>>> My node.js attempt crashes >>>>>> Here's the code in fib.js >>>>>> >>>>>> --- fib.js >>>>>> >>>>>> var http = require('http'); >>>>>> var url = require('url'); >>>>>> >>>>>> function fib(n) { >>>>>> if (n < 2) { >>>>>> return 1; >>>>>> } else { >>>>>> return fib(n - 2) + fib(n - 1); >>>>>> } >>>>>> } >>>>>> >>>>>> http.createServer(function (req, res) { >>>>>> var q = url.parse(req.url, true).query; >>>>>> var n = q.n; >>>>>> var result = fib(n); >>>>>> console.log('fib('+ n + ')= '+result); >>>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>> res.end(result.toString()); >>>>>> }).listen(8124, "127.0.0.1"); >>>>>> >>>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>>> >>>>>> -- end >>>>>> >>>>>> -- now we run it >>>>>> >>>>>> $ node fib.js >>>>>> Server running at http://127.0.0.1:8124/ >>>>>> fib(2)= 2 >>>>>> >>>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>> function fib(n) { >>>>>> ^ >>>>>> RangeError: Maximum call stack size exceeded >>>>>> >>>>>> fib(2) has run out of stack space???? >>>>>> >>>>>> $ node --version >>>>>> v0.8.21 >>>>>> >>>>>> Any ideas what I'm doing wrong >>>>>> >>>>>> Cheers >>>>>> >>>>>> /Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) >>>>> org when posting. >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Erlang Programming" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to erlang-programming+unsubscribe@REDACTED >>>>> To post to this group, send email to >>>>> erlang-programming@REDACTED >>>>> Visit this group at http://groups.google.com/group/erlang-programming. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Studying for the Turing test >>>> >>> >>> >> >> >> -- >> Studying for the Turing test >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jun 17 14:41:28 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 17 Jun 2014 14:41:28 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis wrote: > Hi all, > > For this to be comparable both Erlang and Node.js need to be running > similarly. I don't see how a concurrent Erlang runtime with multiple > schedulers > can be compared with a single-threaded Node.js implementation objectively > or > fairly... > > It's actually the programming models I want to compare and not the performance - what worries me about node is the run-to-completion semantics of event callbacks - namely that a long-running event will block the server preventing short computations from being performed. The short jobs which could be done immediately have to wait until the long jobs have finished - this should reflect in the average latencies of a request. I made a little experiment (a fibonacci server in erlang and node) and fired off 1000 parallel requests to compute fib(N) with N a random number from 10..40. As I suspected many of the fib(10) events are blocked by ongoing computation of fib(40) - this reflect in the latencies. Node is about 1.6 times faster than Erlang - but the latencies for small computations are terrible - Erlang never blocks so the response times are more predictable. And yes I know that fib can be offloaded to a background processor or parallelised in JS with a bit of black magic - but manually converting a long lived computation into a re-entrant non-blocking version is very difficult. The node books say something like "make sure that callbacks run-to-completion quickly" I would say that complying with this advice is extremely difficult. It's very difficult to guess which computations will take a long time, and even if you know it's difficult to break them into small re-entrant chunks. Node is very popular so I'm trying to understand what it is about node that is attractive. npm for example, looks well engineered and something we could learn from. The node web servers are easy to setup and run, so I'd like to see if we could make equally easy to use Erlang servers. Performance is not a primary concern - easy of programming and correctness are. Cheers /Joe > Using node cluster with the same number of cluster instances as erlang > schedulers might be a fairer environment for comparison. However, as > numeric computations are fairly efficient in Node.js and inefficient in > Erlang > relative to Java or C it may take a few iterations to get a fair comparison > in place. Node cluster is a standard part of node.js: > > http://nodejs.org/api/cluster.html > > There are various attempts at implementing fibers and lightweight threads > in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is > nothing > common here. This would approximate an erlang runtime more closely at > the cost of deviating a little from a commonly found node runtime... Ho > hum. > > As javascript runtimes start to adopt vectorized instructions and other > optimisations their speed relative to a C baseline has and will continue to > steadily improve and has been for a number of years, especially with V8. > > Good luck with the benchmarking! > > Cheers, > > Darach. > > > On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: > >> >> >> >> On Tue, Jun 17, 2014 at 1:00 PM, Greg Young >> wrote: >> >>> Are you testing against single threaded node or one of the clustered >>> versions or multiple processes or? >>> >>> >>> >> Single threaded >> >> /Joe >> >> >>> On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: >>> >>>> >>>> >>>> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >>>> wrote: >>>> >>>>> Can you really compare the two? :) >>>>> >>>> >>>> Yes - there are many things we can measure. Performance, Latency, >>>> memory usage and so on. >>>> >>>> Right now I'm measuring latency - >>>> >>>> I set up a few thousand parallel processes which request fib(N) and >>>> measure the latency of the responses. >>>> >>>> the results will be published when I understand them :-) >>>> >>>> /Joe >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>>>> wrote: >>>>> >>>>>> Hi Joe, >>>>>> >>>>>> There's a semicolon missing after the declaration of fib(), which for >>>>>> some reason, causes the stack overflow. After adding it the error went away. >>>>>> >>>>>> HTH, >>>>>> >>>>>> J >>>>>> >>>>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>> >>>>>>> I'm trying to compare node.js with erlang. I'm a total node.js >>>>>>> novice BTW - but I've written some JS. >>>>>>> >>>>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>> >>>>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and >>>>>>> return fib(2) >>>>>>> >>>>>>> My node.js attempt crashes >>>>>>> Here's the code in fib.js >>>>>>> >>>>>>> --- fib.js >>>>>>> >>>>>>> var http = require('http'); >>>>>>> var url = require('url'); >>>>>>> >>>>>>> function fib(n) { >>>>>>> if (n < 2) { >>>>>>> return 1; >>>>>>> } else { >>>>>>> return fib(n - 2) + fib(n - 1); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> http.createServer(function (req, res) { >>>>>>> var q = url.parse(req.url, true).query; >>>>>>> var n = q.n; >>>>>>> var result = fib(n); >>>>>>> console.log('fib('+ n + ')= '+result); >>>>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>> res.end(result.toString()); >>>>>>> }).listen(8124, "127.0.0.1"); >>>>>>> >>>>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>>>> >>>>>>> -- end >>>>>>> >>>>>>> -- now we run it >>>>>>> >>>>>>> $ node fib.js >>>>>>> Server running at http://127.0.0.1:8124/ >>>>>>> fib(2)= 2 >>>>>>> >>>>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>> function fib(n) { >>>>>>> ^ >>>>>>> RangeError: Maximum call stack size exceeded >>>>>>> >>>>>>> fib(2) has run out of stack space???? >>>>>>> >>>>>>> $ node --version >>>>>>> v0.8.21 >>>>>>> >>>>>>> Any ideas what I'm doing wrong >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> /Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) >>>>>> org when posting. >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Erlang Programming" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to erlang-programming+unsubscribe@REDACTED >>>>>> To post to this group, send email to >>>>>> erlang-programming@REDACTED >>>>>> Visit this group at http://groups.google.com/group/erlang-programming >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Studying for the Turing test >>>>> >>>> >>>> >>> >>> >>> -- >>> Studying for the Turing test >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulo.ferraz.oliveira@REDACTED Tue Jun 17 15:07:00 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 17 Jun 2014 14:07:00 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: "Node is very popular so I'm trying to understand what it is about node that is attractive." Having recently moved from Node.js (JavaScript really) to Erlang, a few things come to mind: 1. a lot of browser frontend (i.e. JavaScript) developers almost don't have to learn anything new to develop server-side code using Node.js 2. npm (for sure) is one of the best package management systems I've used... really simple (oh, and the fact that you can use specific versions of deps in your app and not be restricted by a previous choice, sure helps a lot) 3. npmjs.org :D 4. the debugger (node-inspector): I miss this :( 5. you can share server-side and browser-side code On the other hand, for high concurrency, I wouldn't recommend it (it's heavy when you have to spawn a few thousand processes to do _parallel_ and then the OS can't easily cope with this), as it's single threaded (ok, there's Cluster, but...). And also, the fact that tail recursion is non-existing... At the moment, though, I enjoy prototyping with Node.js and implementing with Erlang. :) - Paulo F. Oliveira On 17 June 2014 13:41, Joe Armstrong wrote: > > On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis wrote: > >> Hi all, >> >> For this to be comparable both Erlang and Node.js need to be running >> similarly. I don't see how a concurrent Erlang runtime with multiple >> schedulers >> can be compared with a single-threaded Node.js implementation objectively >> or >> fairly... >> >> > It's actually the programming models I want to compare and not the > performance - what worries me about node is the run-to-completion > semantics of event callbacks - namely that a long-running event will block > the server preventing short computations from being performed. The > short jobs which could be done immediately have to wait until the long jobs > have finished - this should reflect in the average latencies of a request. > > I made a little experiment (a fibonacci server in erlang and node) and > fired off > 1000 parallel requests to compute fib(N) with N a random number from > 10..40. > > As I suspected many of the fib(10) events are blocked by ongoing > computation of > fib(40) - this reflect in the latencies. > > Node is about 1.6 times faster than Erlang - but the latencies for small > computations > are terrible - Erlang never blocks so the response times are more > predictable. > > And yes I know that fib can be offloaded to a background processor or > parallelised > in JS with a bit of black magic - but manually converting a long lived > computation into > a re-entrant non-blocking version is very difficult. > > The node books say something like "make sure that callbacks > run-to-completion quickly" > I would say that complying with this advice is extremely difficult. It's > very difficult to guess > which computations will take a long time, and even if you know it's > difficult to break them into > small re-entrant chunks. > > Node is very popular so I'm trying to understand what it is about node > that is attractive. > npm for example, looks well engineered and something we could learn from. > The node > web servers are easy to setup and run, so I'd like to see if we could make > equally > easy to use Erlang servers. > > Performance is not a primary concern - easy of programming and correctness > are. > > Cheers > > /Joe > > > > > > > >> Using node cluster with the same number of cluster instances as erlang >> schedulers might be a fairer environment for comparison. However, as >> numeric computations are fairly efficient in Node.js and inefficient in >> Erlang >> relative to Java or C it may take a few iterations to get a fair >> comparison >> in place. Node cluster is a standard part of node.js: >> >> http://nodejs.org/api/cluster.html >> >> There are various attempts at implementing fibers and lightweight threads >> in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is >> nothing >> common here. This would approximate an erlang runtime more closely at >> the cost of deviating a little from a commonly found node runtime... Ho >> hum. >> >> As javascript runtimes start to adopt vectorized instructions and other >> optimisations their speed relative to a C baseline has and will continue >> to >> steadily improve and has been for a number of years, especially with V8. >> >> Good luck with the benchmarking! >> >> Cheers, >> >> Darach. >> >> >> On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: >> >>> >>> >>> >>> On Tue, Jun 17, 2014 at 1:00 PM, Greg Young >>> wrote: >>> >>>> Are you testing against single threaded node or one of the clustered >>>> versions or multiple processes or? >>>> >>>> >>>> >>> Single threaded >>> >>> /Joe >>> >>> >>>> On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >>>>> wrote: >>>>> >>>>>> Can you really compare the two? :) >>>>>> >>>>> >>>>> Yes - there are many things we can measure. Performance, Latency, >>>>> memory usage and so on. >>>>> >>>>> Right now I'm measuring latency - >>>>> >>>>> I set up a few thousand parallel processes which request fib(N) and >>>>> measure the latency of the responses. >>>>> >>>>> the results will be published when I understand them :-) >>>>> >>>>> /Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>>>> > wrote: >>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> There's a semicolon missing after the declaration of fib(), which >>>>>>> for some reason, causes the stack overflow. After adding it the error went >>>>>>> away. >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> J >>>>>>> >>>>>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>>> >>>>>>>> I'm trying to compare node.js with erlang. I'm a total node.js >>>>>>>> novice BTW - but I've written some JS. >>>>>>>> >>>>>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>>> >>>>>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and >>>>>>>> return fib(2) >>>>>>>> >>>>>>>> My node.js attempt crashes >>>>>>>> Here's the code in fib.js >>>>>>>> >>>>>>>> --- fib.js >>>>>>>> >>>>>>>> var http = require('http'); >>>>>>>> var url = require('url'); >>>>>>>> >>>>>>>> function fib(n) { >>>>>>>> if (n < 2) { >>>>>>>> return 1; >>>>>>>> } else { >>>>>>>> return fib(n - 2) + fib(n - 1); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> http.createServer(function (req, res) { >>>>>>>> var q = url.parse(req.url, true).query; >>>>>>>> var n = q.n; >>>>>>>> var result = fib(n); >>>>>>>> console.log('fib('+ n + ')= '+result); >>>>>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>>> res.end(result.toString()); >>>>>>>> }).listen(8124, "127.0.0.1"); >>>>>>>> >>>>>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>>>>> >>>>>>>> -- end >>>>>>>> >>>>>>>> -- now we run it >>>>>>>> >>>>>>>> $ node fib.js >>>>>>>> Server running at http://127.0.0.1:8124/ >>>>>>>> fib(2)= 2 >>>>>>>> >>>>>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>>> function fib(n) { >>>>>>>> ^ >>>>>>>> RangeError: Maximum call stack size exceeded >>>>>>>> >>>>>>>> fib(2) has run out of stack space???? >>>>>>>> >>>>>>>> $ node --version >>>>>>>> v0.8.21 >>>>>>>> >>>>>>>> Any ideas what I'm doing wrong >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> /Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) >>>>>>> org when posting. >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Erlang Programming" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to erlang-programming+unsubscribe@REDACTED >>>>>>> To post to this group, send email to >>>>>>> erlang-programming@REDACTED >>>>>>> Visit this group at >>>>>>> http://groups.google.com/group/erlang-programming. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Studying for the Turing test >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Studying for the Turing test >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Tue Jun 17 15:17:54 2014 From: john@REDACTED (John Kemp) Date: Tue, 17 Jun 2014 09:17:54 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <53A04002.2030001@jkemp.net> On 06/17/2014 08:41 AM, Joe Armstrong wrote: > [...] > Performance is not a primary concern - easy of programming and > correctness are. I would note that it is possible to show that node is not as easy to program as Erlang without measuring performance. It is possible to do so by reading any node code that uses nested callbacks (pretty much any example) vs. reading equivalent Erlang code. In the node case, it is not easy to follow the flow of the code by reading it (ie. in which order the callbacks will fire) leading to many mistakes in programming which do not show up until a particular ordering of activities occurs. By contrast with Erlang, it is usually (in my experience) easy to follow the flow of code by reading it. This leads to easier verification of "correctness" too. Just write a piece of non-blocking event-driven node code which implements more than one callback function, where callbacks may be nested. Then write the same code in Erlang. Which is easier to read? Is it even possible to verify the correctness of the node code in all cases? Regards, - johnk > > Cheers > > /Joe > > > > > > Using node cluster with the same number of cluster instances as erlang > schedulers might be a fairer environment for comparison. However, as > numeric computations are fairly efficient in Node.js and inefficient > in Erlang > relative to Java or C it may take a few iterations to get a fair > comparison > in place. Node cluster is a standard part of node.js: > > http://nodejs.org/api/cluster.html > > There are various attempts at implementing fibers and lightweight > threads > in Node.js (eg: https://github.com/laverdet/node-fibers/) but there > is nothing > common here. This would approximate an erlang runtime more closely at > the cost of deviating a little from a commonly found node runtime... > Ho hum. > > As javascript runtimes start to adopt vectorized instructions and other > optimisations their speed relative to a C baseline has and will > continue to > steadily improve and has been for a number of years, especially with V8. > > Good luck with the benchmarking! > > Cheers, > > Darach. > > > On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong > wrote: > > > > > On Tue, Jun 17, 2014 at 1:00 PM, Greg Young > > wrote: > > Are you testing against single threaded node or one of the > clustered versions or multiple processes or? > > > > Single threaded > > /Joe > > On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong > > wrote: > > > > On Tue, Jun 17, 2014 at 12:10 PM, Greg Young > > wrote: > > Can you really compare the two? :) > > > Yes - there are many things we can measure. Performance, > Latency, memory usage and so on. > > Right now I'm measuring latency - > > I set up a few thousand parallel processes which request > fib(N) and measure the latency of the responses. > > the results will be published when I understand them :-) > > /Joe > > > > > > > On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro > > wrote: > > Hi Joe, > > There's a semicolon missing after the > declaration of fib(), which for some reason, > causes the stack overflow. After adding it the > error went away. > > HTH, > > J > > On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe > Armstrong wrote: > > I'm trying to compare node.js with erlang. > I'm a total node.js novice BTW - but I've > written some JS. > > Program 1 is just fibonacci - I want a web > server to compute fib(N) > > So requesting http://127.0.0.1:8124/fib?n=2 > should compute and return fib(2) > > My node.js attempt crashes > Here's the code in fib.js > > --- fib.js > > var http = require('http'); > var url = require('url'); > > function fib(n) { > if (n < 2) { > return 1; > } else { > return fib(n - 2) + fib(n - 1); > } > } > > http.createServer(function (req, res) { > var q = url.parse(req.url, true).query; > var n = q.n; > var result = fib(n); > console.log('fib('+ n + ')= '+result); > res.writeHead(200, {'Content-Type': > 'text/plain'}); > res.end(result.toString()); > }).listen(8124, "127.0.0.1"); > > console.log('Server running at > http://127.0.0.1:8124/'); > > -- end > > -- now we run it > > $ node fib.js > Server running at http://127.0.0.1:8124/ > fib(2)= 2 > > /home/ejoearm/Dropbox/__experiments/hello_world/fib.__js:5 > function fib(n) { > ^ > RangeError: Maximum call stack size exceeded > > fib(2) has run out of stack space???? > > $ node --version > v0.8.21 > > Any ideas what I'm doing wrong > > Cheers > > /Joe > > > > > > > -- > Remember to send a copy to erlang (dot) > questions (at) erlang (dot) org when posting. > --- > You received this message because you are > subscribed to the Google Groups "Erlang > Programming" group. > To unsubscribe from this group and stop > receiving emails from it, send an email to > erlang-programming+unsubscribe@REDACTED > . > To post to this group, send email to > erlang-programming@REDACTED > . > Visit this group at > http://groups.google.com/group/erlang-programming. > For more options, visit > https://groups.google.com/d/optout. > > > > > -- > Studying for the Turing test > > > > > > -- > Studying for the Turing test > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jesper.louis.andersen@REDACTED Tue Jun 17 15:39:21 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 17 Jun 2014 15:39:21 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 2:41 PM, Joe Armstrong wrote: > It's actually the programming models I want to compare and not the > performance - what worries me about node is the run-to-completion > semantics of event callbacks - namely that a long-running event will block > the server preventing short computations from being performed. The > short jobs which could be done immediately have to wait until the long jobs > have finished - this should reflect in the average latencies of a request. > Shameless plug: Have you by any chance read http://jlouisramblings.blogspot.dk/2010/12/differences-between-nodejs-and-erlang_14.html because I was down this road years ago. And I would like to hear if anything has happened. The graphical plots are gone, but the R summaries still hold and explain miserable variance for Node.js. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Tue Jun 17 15:58:06 2014 From: john@REDACTED (John Kemp) Date: Tue, 17 Jun 2014 09:58:06 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <53A0496E.7000909@jkemp.net> On 06/17/2014 08:41 AM, Joe Armstrong wrote: [...] > Node is very popular so I'm trying to understand what it is about node > that is attractive. One of the reasons not yet mentioned for the popularity of node is the "non-blocking, event-driven model" it uses. But performance, ultimately, comes down to the underlying resources you have (unit CPU, unit memory, network bandwidth between units) and how they are allocated. It's not that node gets this advantage "wrong". But in my experience, any programming language can be used to exploit these underlying resources appropriately, depending on how one arranges the resources, and programs the whole system. This only changes when you consider changes in the way underlying resources are configured (standard CPU vs GPU vs FPGA for example) Ruby vs. Java vs. node vs. Erlang vs. whatever makes no sense on that level - they can all be used to make systems that work, depending on how you use threads, processes and callbacks in a scalable manner, and how much scale you need. So in one sense, you should simply use your favourite language to do whatever you want to do - as long as you understand how your system will need to scale, and you are happy with whatever you will have to do to make it scale for use, then all is good. Certain things, however, make scaling simpler. One of those things is having the ability to write a serial-looking program, and yet having it easily form part of a parallel system. This makes following the flow of control in a program much easier. Another of those things is being able to "know" that your variable is assigned only once and doesn't change after initial assignment. I could mention other features of Erlang that make acquiring good-enough performance much easier than it is with other languages. In summary though, I believe that at a "whole-systems" level, node has no particular performance advantage (assuming standard CPU architecture) that would make me choose it over Ruby, Java or Erlang (all of which I find easier to program, for different reasons). I might choose node because the other developers on the project are node specialists. But similarly, I would feel comfortable choosing whatever other language made sense for reasons of team experience, or readability, or some other non-performance reason. Having used Erlang, it is difficult for me to use other languages, because of the combination of elegance and large-systems functionality. But I do it, knowing that teaching others how to program Erlang is not my primary job responsibility, and that appropriately-scalable systems can be built in most common languages, as long as you understand how to make a reasonable rough cut at the first version of the system and what to do with the measurements you should make afterwards :) So, I think that what makes node attractive is pretty much a fallacy, or rather, that this claimed advantage of node (non-blocking, event-driven IO) has significant disadvantages over other languages, when thinking at a whole-systems level. Regards, - johnk From roger@REDACTED Tue Jun 17 16:21:15 2014 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 17 Jun 2014 15:21:15 +0100 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? Message-ID: I'm currently refactoring some code, and I've got something like this: handle_foo(#state { type = bar, id = Id }) -> whatever; handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. ...and I'm wondering whether it's considered bad form to access record fields at the same time as matching them in a function clause. I'm matching on 'type', and accessing 'id' at the same time, I mean. Instead, should I consider something like the following? handle_foo(#state { type = bar }) -> Id = State#state.id, whatever; handle_foo(#state { type = baz }) -> ParentId = State#state.parent_id, whatever. The first form makes it explicit that for different types, different fields matter (which might be a smell by itself), but it gets hard to see the match on 'type' once I'm accessing more than one or two fields. I know this is stylistic, and there's no "right" answer; I just wondered what other people tend to do? Or, more generally, do people prefer using pattern matching to access record values, or plain-ol' Foo = State#state.foo expressions? Thanks, Roger. From rvg.mailing@REDACTED Tue Jun 17 16:25:11 2014 From: rvg.mailing@REDACTED (Rudolph van Graan) Date: Tue, 17 Jun 2014 15:25:11 +0100 Subject: [erlang-questions] Generating a certificate from a CSR with public_key Message-ID: Hi there, I'm trying to work out how I can generate and sign a certificate from a certificate signing request (CSR) using pure Erlang. It doesn't look as if the public_key application has support for this. Does anyone have pointers for doing this? (I know how to do this with openssl). Thanks, Rudolph From essen@REDACTED Tue Jun 17 16:25:29 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 17 Jun 2014 16:25:29 +0200 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: References: Message-ID: <53A04FD9.6020709@ninenines.eu> I wish State#state.key were removed from the language entirely. You are differentiating "match" and "access" in the function clause, but in fact both are a "match". Plus if you match that way you can also use guards as needed, which is much clearer than sometimes a function clause and sometimes a case clause. On 06/17/2014 04:21 PM, Roger Lipscombe wrote: > I'm currently refactoring some code, and I've got something like this: > > handle_foo(#state { type = bar, id = Id }) -> whatever; > handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. > > ...and I'm wondering whether it's considered bad form to access record > fields at the same time as matching them in a function clause. I'm > matching on 'type', and accessing 'id' at the same time, I mean. > > Instead, should I consider something like the following? > > handle_foo(#state { type = bar }) -> > Id = State#state.id, > whatever; > handle_foo(#state { type = baz }) -> > ParentId = State#state.parent_id, > whatever. > > The first form makes it explicit that for different types, different > fields matter (which might be a smell by itself), but it gets hard to > see the match on 'type' once I'm accessing more than one or two > fields. > > I know this is stylistic, and there's no "right" answer; I just > wondered what other people tend to do? > > Or, more generally, do people prefer using pattern matching to access > record values, or plain-ol' Foo = State#state.foo expressions? > > Thanks, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From bengt.kleberg@REDACTED Tue Jun 17 16:28:17 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 17 Jun 2014 16:28:17 +0200 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: References: Message-ID: <1403015297.4702.251.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, A long time ago it was better to use 1) #rec1{asd=A} = R then 2) R#rec1.asd I think it were some additional checks done in the first case. So a long habit makes 1) my normal choice. When pattern matching in a function clause I move the matching record member(s) to the left, and the access ones to the right. bengt On Tue, 2014-06-17 at 15:21 +0100, Roger Lipscombe wrote: > I'm currently refactoring some code, and I've got something like this: > > handle_foo(#state { type = bar, id = Id }) -> whatever; > handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. > > ...and I'm wondering whether it's considered bad form to access record > fields at the same time as matching them in a function clause. I'm > matching on 'type', and accessing 'id' at the same time, I mean. > > Instead, should I consider something like the following? > > handle_foo(#state { type = bar }) -> > Id = State#state.id, > whatever; > handle_foo(#state { type = baz }) -> > ParentId = State#state.parent_id, > whatever. > > The first form makes it explicit that for different types, different > fields matter (which might be a smell by itself), but it gets hard to > see the match on 'type' once I'm accessing more than one or two > fields. > > I know this is stylistic, and there's no "right" answer; I just > wondered what other people tend to do? > > Or, more generally, do people prefer using pattern matching to access > record values, or plain-ol' Foo = State#state.foo expressions? > > Thanks, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Tue Jun 17 16:32:36 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 17 Jun 2014 16:32:36 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A0496E.7000909@jkemp.net> References: <53A0496E.7000909@jkemp.net> Message-ID: On Tue, Jun 17, 2014 at 3:58 PM, John Kemp wrote: > In summary though, I believe that at a "whole-systems" level, node has no > particular performance advantage (assuming standard CPU architecture) that > would make me choose it over Ruby, Java or Erlang (all of which I find > easier to program, for different reasons). In fact, if the Node.js model is so good, I'd go with OCaml+Core.Async any day. Async defines enough tooling through operators that I can get a monad in which my writing style can be direct while having all the advantages of a "non-blocking" system. But the existence of languages like Erlang and Go, the realization Haskell/GHC contains lots of tooling for doing concurrent work kind of tells a story that this might not be enough. And the existence of Mozart/Oz and Erlang also tells a different equally important story about distribution. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Jun 17 16:34:39 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 17 Jun 2014 16:34:39 +0200 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 4:21 PM, Roger Lipscombe wrote: > I'm currently refactoring some code, and I've got something like this: > > handle_foo(#state { type = bar, id = Id }) -> whatever; > handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. > > ...and I'm wondering whether it's considered bad form to access record > fields at the same time as matching them in a function clause. I'm > matching on 'type', and accessing 'id' at the same time, I mean. > Not at all! I think this is the more powerful form. Matching on patterns is such an integral concept in functional languages, so exploiting it is good. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Jun 17 16:50:45 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 17 Jun 2014 10:50:45 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: <59EBE8A4-E690-4583-A0F6-DB79DD94F4B3@writersglen.com> Hi Torben, Good thoughts. But note re: > Going embedded means that doing things with graphics is impossible. > On a computer we could tap into graphical libraries, say Processing, and create a > very visual feedback. Odroid U3 runs Ubuntu, has HD HDMI graphics with a fairly powerful graphic coprocessor. It also has an active community and a very attractive magazine packed with interesting projects: magazine.odroid.com I don't want to overly pitch the case since I haven't fired it up and can't speak to warts. But based on printed specs and price/performance, this is a very interesting device. Summary of specs Hardkernel lists these specifications for the Odroid-U3: Processor ? Samsung Exynos 4412 Prime SoC: CPU ? Quad-core ARM Cortex-A9, clocked at 1.7GHz GPU ? 3D accelerator Mali-400 Quad Core 440MHz RAM ? 2GB LP-DDR2 SDRAM Storage: MicroSD card socket eMMC module socket HDMI video interface: Supports 1080p (H.264+AAC based MP4 container format) micro HDMI connector Audio ? 3.5mm headphone jack LAN ? 10/100Mb Ethernet (RJ-45 Jack) USB: 3x USB2.0 Host ports (standard A type connectors) 1x USB2.0 OTG Device port (Micro USB) 8-pin I/O expansion header ? UART, IRQ, I2C, GPIO, power Power ? 5VDC @ 2A Operating system ? Xubuntu 13.10; U-Boot 2010.12; Linux kernel 3.0.x; Android 4.x Dimensions ? 83 x 48 x 22mm (with heatsink) Weight ? 48g (with heatsink) More here: http://blog.hsc.com/android/technology-trends/raspberry-pi-vs-odroid-u3/ http://hardkernel.com/main/products/prdt_info.php All the best, Lloyd Sent from my iPad > On Jun 17, 2014, at 4:17 AM, Torben Hoffmann wrote: > > > lloyd@REDACTED writes: > >> Hello, >> >> So many great ideas. So many talented contributors. > Indeed! > >> A fantasy--- >> >> One or more of... >> >> - a website >> - hosting platform >> - an e-book - free for download >> - a hard-cover book - royalties kick back to help kids >> - a hardware platform - profits kick back to help kids >> >> Projects >> >> - build your own website >> - chat with friends >> - organize your collections >> - build a multi-player game >> - control a robot >> - control your house >> - build your own supercomputer >> ???? >> >> Contest for project submissions >> >> Team >> >> - dedicated Erlang volunteers >> - perhaps formalize with a foundation ala Raspberry Pi >> >> Process >> >> - Dream >> - Brainstorm >> - Set goals >> - Organize >> - Delegate >> - Produce > I think the dreaming has started... but lets get the main direction in place before > we run into things. > > I had a look at the CodeClub organisation that Fred mentioned. > Though it is targeted at 9-11 year old kids they - like many others - start with a > visual environment. They use Scratch - Fred outlined what it could look like for > Erlang/Elixir elsewhere in this thread > (http://erlang.org/pipermail/erlang-questions/2014-June/079563.html). > > I initially sat the target to be 12-15 year old kids, but I have a feeling that a > visual environment would still have a lot of mileage with that group. > Basically, it would be nice to have a one-stop installer that contains both the > environment and the Erlang/Elixir system. Simply no friction if at all possible. > > So that is the first branching point: visual or text? > > Staying on the visual track for a second; I had a look at the DRAKON editor > (http://drakon-editor.sourceforge.net/drakon-erlang/intro.html) which has > support for Erlang to generate code. Unfortunately it does not generate idiomatic > Erlang code and the Tcl UI feels a bit dated. > > Visual Erlang (https://github.com/esl/visual_erlang) is still in its infancy, but > adding extensions to fit the teaching purpose is not impossible. One can steal ideas > from DRAKON and other notations like SDL. > > All of this is something that is non-trivial to do. The MIT team behind Scratch has > spent years getting their environment to work. > > Second branching point: Erlang or Elixir? > > The main objective should still be to introduce the Erlang way of approaching > programming which is the foundation of Elixir as well, so either language would work > for this. > > I think we need to device some sort of experiment that can gauge which is the right > choice. That, unfortunately, requires work on both of them, but it beats the > alternative of running down the wrong path only to realise it when it might be too > late. > > >> Platform >> >> - Software projects can be done on Windows assuming easy peasy Erlang install > Erlang runs on every platform, but Windows is the one with the worst support. > >> - How can we get youngsters into Linux? >> >> - A hardware platform would open up robotics and control applications: >> >> Cheap (under $100) ARM boards >> >> -- Arduino etc. >> >> -- Raspberry Pi >> >> -- I have an Odroid U3 on my desk. No time to fire it up yet; but very compact, >> quiet, low power, plenty of computing power, runs Linux. Total of $90 for board, >> pwr supply, HDMI cable, wi-fi module, and case. Would need an MicroSD card with >> Linux and Erlang installed. >> >> Over the past year there have been a slew of such devices hitting the market and >> more coming. > That hits the third branching point: computer or embedded? > > At ESL we have some experience with the embedded side of things. It adds a lot of > extra variables to the equation, but it is arguably also a lot of fun. > > We might be able to get Erlang to run on a thing like the Arduino Yun > (http://store.arduino.cc/index.php?main_page=product_info&cPath=11_12&products_id=313), > but only on the Linux side. Running on the micro controller is out of the question - > 32KB RAM is not enough for Erlang. Raspberry Pi just works. > > Going embedded means that doing things with graphics is impossible. > On a computer we could tap into graphical libraries, say Processing, and create a > very visual feedback. > > Opinions on the branching points most welcome! > > Cheers, > Torben > > > >> Can we get /software/hardware cos to help sponsor the effort? >> >> Best, >> >> Lloyd >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: "Ferenc Holzhauser" >> Sent: Monday, June 16, 2014 1:30pm >> To: "Tony Rogvall" >> Cc: "erlang-questions@REDACTED" >> Subject: Re: [erlang-questions] Erlang for youngsters >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> Robotics is really nice but in this case accessibility is even nicer. It is >> great if kids can play after class too with interesting things without >> having to put items of fairly significant value (for some) on their >> wishlist. These days a >> computer with internet access can be a fascinatingly accessible way of >> creativity. An idea could be to make a simple game backend to compete with >> their friends and fellow students (e.g. a 2d tank shooting game or >> something). Eventually with chat and similar functions to add. Then the >> teacher could make things go wrong on the server(s) that they'd need to fix >> (distribute/scale/fail over) depending on their progress. You could lure >> them into AI like things too if you fancy. I'm sure someone with the skills >> (e.g. SVG/ezwebframe) and time could make some simple client "building >> blocks" work for something like this. >> >> >>>> On 16 June 2014 18:12, Tony Rogvall wrote: >>> >>> >>> On 16 jun 2014, at 13:55, Mark Nijhof >>> wrote: >>> >>> +1 on this, this rings very true to home. But I also believe that it needs >>> to return results quickly. I.e. building a game is great, but if they have >>> to "code" for days before they see something happen then they loose >>> interest (assumption). So preparing "building blocks" might be a good >>> approach and have them first implement higher level stuff and then step by >>> step dig deeper and implement the building blocks you prepared. >>> >>> An other exercise I planned is to program a drone (not sure about the >>> language there yet) to fly an obstacle course. So they see it is not just >>> something that happens on their iPads ;) >>> >>> You program drone in Erlang of course :-) >>> >>> https://github.com/tonyrog/edrone >>> >>> /Tony >>> >>> -Mark >>> >>> >>> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >>> mahesh@REDACTED> wrote: >>> >>>> The most important thing here I believe is to have a nice collection of >>>>> simple tasks/problems that are appealing to the target audience and best >>>>> (easiest/nicest) solved in Erlang. >>>> >>>> Amen! >>>> The least relevant part of teaching kids programming is the syntax, or >>>> the choice of language - they don't, and won't, give a s**t about it. >>>> As a simple thought experiment, just look at how you raised your kids in >>>> a multi-lingual environment (yes my American brethren, this is hard. >>>> Pretend :-) ) Notice how they - fluidly - bounce across languages, >>>> massacring every grammar rule ever, but quite happily making sure that you >>>> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >>>> odio odio odio la piselli, i don't wanna, where is my red truck?" >>>> Mind you, they will pick up the rules over time, but the key here is the >>>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>>> immediately relevant it is to the young 'uns, the more rapidly they will >>>> pick up the tools, the specifics of the language be damned. >>>> >>>> Cheers >>>> >>>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >>>> ferenc.holzhauser@REDACTED> wrote: >>>> >>>>> The most important thing here I believe is to have a nice collection of >>>>> simple tasks/problems that are appealing to the target audience and best >>>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>>> that Erlang is created to solve problems that are rather "industrial" and >>>>> most people "from outside" can't really relate to. If the audience is not >>>>> comfortable with understanding the problem itself then it is tricky to make >>>>> them understand/like the solution too. >>>>> >>>>> This we can see with many new people getting into Erlang: The problems >>>>> they are given are new and difficult to understand. So they often just go >>>>> off and eagerly try to solve all sort of issues they are familiar with >>>>> (even when they are not relevant in the particular case) before even trying >>>>> to understand what the real challenge is. Then they start complaining that >>>>> Erlang is not very good for some/many of those issues they are busy with. >>>>> >>>>> And other way around: people coming to Erlang with the right >>>>> understanding of the problem area it is made for find it amazingly simple >>>>> to learn. >>>>> >>>>> Coming from the wrong (or right ?) background my imagination fails to >>>>> come up with these appealing challenges for the youngster target group, but >>>>> I'm sure many of you can do much better. >>>>> >>>>> Ferenc >>>>> >>>>> >>>>> On 16 June 2014 11:31, Miles Fidelman >>>>> wrote: >>>>> >>>>>> Garrett Smith wrote: >>>>>> >>>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>>> wrote: >>>>>>> >>>>>>> -snip- >>>>>>> >>>>>>> I think that a learning resource focused on teaching people the >>>>>>>> Erlang model from the >>>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>>> do we solve a >>>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>>> problem. >>>>>>>> >>>>>>>> My initial target for such a learning resources would be young people >>>>>>>> in the higher >>>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>>> influence them >>>>>>>> before their minds are totally corrupted by other programming models. >>>>>>>> >>>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>>> this group - we >>>>>>>> just have to find a cool example and organise the learning around how >>>>>>>> to become so >>>>>>>> good that one can solve such a problem. >>>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>>> of Transport >>>>>>>> Tycoon clone?!?! >>>>>>> I don't have enough experience teaching programming to this age group >>>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>>> be a bit ambitious for these young learners. >>>>>>> >>>>>>> I'm speaking in particular about the model that emerges when you >>>>>>> isolate processes. It changes everything: your approach to building >>>>>>> software (move from state oriented to activity oriented), error >>>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>>> program structure (from monolith to system), and so on. The benefits >>>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>>> it wasn't, or I wish I was better at communicating. >>>>>> I'm with the folks who suggest that this group has fewer >>>>>> pre-conceptions to unlearn. >>>>>> >>>>>> It strikes me that the actor model is far more natural for certain >>>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>>> processes. >>>>>> >>>>>> Miles Fidelman >>>>>> >>>>>> >>>>>> -- >>>>>> In theory, there is no difference between theory and practice. >>>>>> In practice, there is. .... Yogi Berra >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> -- >>>> >>>> * Mahesh Paolini-Subramanya >>>> That >>>> tall bald Indian guy..* >>>> * Google+ >>>> | Blog | Twitter >>>> | LinkedIn >>>> * >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> -- >>> Mark Nijhof >>> t: @MarkNijhof >>> s: marknijhof >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> "Installing applications can lead to corruption over time. Applications >>> gradually write over each other's libraries, partial upgrades occur, user >>> and system errors happen, and minute changes may be unnoticeable and >>> difficult to fix" >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > Torben Hoffmann > CTO > Erlang Solutions Ltd. > Tel: +45 25 14 05 38 > http://www.erlang-solutions.com From mononcqc@REDACTED Tue Jun 17 16:51:59 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 17 Jun 2014 10:51:59 -0400 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: <53A04FD9.6020709@ninenines.eu> References: <53A04FD9.6020709@ninenines.eu> Message-ID: <20140617145158.GS51530@ferdair.local> On 06/17, Lo?c Hoguin wrote: > I wish State#state.key were removed from the language entirely. > It kind of makes sense to keep it if you want to allow the use of #record.field, as in lists:keysearch(Val, #record.field, ListOfRecs). It does break the abstraction around records in that they're tuples, but yeah. From zxq9@REDACTED Tue Jun 17 17:12:24 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 18 Jun 2014 00:12:24 +0900 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <6461553.KSmPgYYSSL@jalapeno> On Tuesday 17 June 2014 14:41:28 Joe Armstrong wrote: > ... but manually converting a long lived computation into > a re-entrant non-blocking version is very difficult. > > The node books say something like "make sure that callbacks > run-to-completion quickly" > I would say that complying with this advice is extremely difficult. It's > very difficult to guess > which computations will take a long time, and even if you know it's > difficult to break them into > small re-entrant chunks. This. You can't hit the nail any more precisely on the head. > Node is very popular so I'm trying to understand what it is about node that > is attractive. > npm for example, looks well engineered and something we could learn from. > The node > web servers are easy to setup and run, so I'd like to see if we could make > equally > easy to use Erlang servers. "Easy" is not the same thing as "simple". A lot of people are familiar with JS and node.js is a fad that speaks to the web 2.0 crowd that can't/won't digest a serious discussion about the issues you are raising above. *Anything* in JS is going to be easier for this legion of web folks compared to, well, anything that isn't JS. You are trying to apply your deep technical expertise to a shallow social phenomenon. As Alan Kay somewhat recently observed, computer science has become pop-culture and has very little to do with engineering. I'd go further and say he was really talking about the software development landscape as applies to the web and other low-performance applications. Folks like you are coming from a different world than the folks that use and (especially) have made node.js a pop phenomenon. So, don't worry about what is popular. (Popularity is no indication of value -- I don't think this point needs further support.) If you do that at the language/platform/infrastructure level you will merely re-discover that Richard Gabriel was correct, marketing trumps engineering, the Huns will always crush an overly domesticated Rome, and worse is indeed better. IOW, you'll turn Erlang and its platform into Java and its vm. That would make me sad -- for so many reasons. -CRE PS: The corrolary to the above is that if the goal is popularity, then neither the means nor the path to success can be inherently technical in nature. From yehohanan7@REDACTED Tue Jun 17 14:40:22 2014 From: yehohanan7@REDACTED (john pradeep) Date: Tue, 17 Jun 2014 18:10:22 +0530 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: That's a good point Darach. Just to add to to that, it would be even nice if the bench marking is performed for 2 cases: CPU intensive & IO intensive code. Would love to see Joe's comparison! Cheers! On Tue, Jun 17, 2014 at 5:35 PM, Darach Ennis wrote: > Hi all, > > For this to be comparable both Erlang and Node.js need to be running > similarly. I don't see how a concurrent Erlang runtime with multiple > schedulers > can be compared with a single-threaded Node.js implementation objectively > or > fairly... > > Using node cluster with the same number of cluster instances as erlang > schedulers might be a fairer environment for comparison. However, as > numeric computations are fairly efficient in Node.js and inefficient in > Erlang > relative to Java or C it may take a few iterations to get a fair comparison > in place. Node cluster is a standard part of node.js: > > http://nodejs.org/api/cluster.html > > There are various attempts at implementing fibers and lightweight threads > in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is > nothing > common here. This would approximate an erlang runtime more closely at > the cost of deviating a little from a commonly found node runtime... Ho > hum. > > As javascript runtimes start to adopt vectorized instructions and other > optimisations their speed relative to a C baseline has and will continue to > steadily improve and has been for a number of years, especially with V8. > > Good luck with the benchmarking! > > Cheers, > > Darach. > > > On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: > >> >> >> >> On Tue, Jun 17, 2014 at 1:00 PM, Greg Young >> wrote: >> >>> Are you testing against single threaded node or one of the clustered >>> versions or multiple processes or? >>> >>> >>> >> Single threaded >> >> /Joe >> >> >>> On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: >>> >>>> >>>> >>>> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >>>> wrote: >>>> >>>>> Can you really compare the two? :) >>>>> >>>> >>>> Yes - there are many things we can measure. Performance, Latency, >>>> memory usage and so on. >>>> >>>> Right now I'm measuring latency - >>>> >>>> I set up a few thousand parallel processes which request fib(N) and >>>> measure the latency of the responses. >>>> >>>> the results will be published when I understand them :-) >>>> >>>> /Joe >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>>>> wrote: >>>>> >>>>>> Hi Joe, >>>>>> >>>>>> There's a semicolon missing after the declaration of fib(), which for >>>>>> some reason, causes the stack overflow. After adding it the error went away. >>>>>> >>>>>> HTH, >>>>>> >>>>>> J >>>>>> >>>>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>> >>>>>>> I'm trying to compare node.js with erlang. I'm a total node.js >>>>>>> novice BTW - but I've written some JS. >>>>>>> >>>>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>> >>>>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and >>>>>>> return fib(2) >>>>>>> >>>>>>> My node.js attempt crashes >>>>>>> Here's the code in fib.js >>>>>>> >>>>>>> --- fib.js >>>>>>> >>>>>>> var http = require('http'); >>>>>>> var url = require('url'); >>>>>>> >>>>>>> function fib(n) { >>>>>>> if (n < 2) { >>>>>>> return 1; >>>>>>> } else { >>>>>>> return fib(n - 2) + fib(n - 1); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> http.createServer(function (req, res) { >>>>>>> var q = url.parse(req.url, true).query; >>>>>>> var n = q.n; >>>>>>> var result = fib(n); >>>>>>> console.log('fib('+ n + ')= '+result); >>>>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>> res.end(result.toString()); >>>>>>> }).listen(8124, "127.0.0.1"); >>>>>>> >>>>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>>>> >>>>>>> -- end >>>>>>> >>>>>>> -- now we run it >>>>>>> >>>>>>> $ node fib.js >>>>>>> Server running at http://127.0.0.1:8124/ >>>>>>> fib(2)= 2 >>>>>>> >>>>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>> function fib(n) { >>>>>>> ^ >>>>>>> RangeError: Maximum call stack size exceeded >>>>>>> >>>>>>> fib(2) has run out of stack space???? >>>>>>> >>>>>>> $ node --version >>>>>>> v0.8.21 >>>>>>> >>>>>>> Any ideas what I'm doing wrong >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> /Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) >>>>>> org when posting. >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Erlang Programming" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to erlang-programming+unsubscribe@REDACTED >>>>>> To post to this group, send email to >>>>>> erlang-programming@REDACTED >>>>>> Visit this group at http://groups.google.com/group/erlang-programming >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Studying for the Turing test >>>>> >>>> >>>> >>> >>> >>> -- >>> Studying for the Turing test >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.revington@REDACTED Tue Jun 17 15:17:51 2014 From: p.revington@REDACTED (=?UTF-8?Q?Pedro_Narciso_Garc=C3=ADa_Revington?=) Date: Tue, 17 Jun 2014 15:17:51 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: Hey Joe Node is very popular so I'm trying to understand what it is about node that > is attractive. Lots of people already know js, so it seems an easy platform to get in. What I love about node: - npm - modules ecosystem - easy to deploy - easy to start: you can use js, you do not need a specific ide, easy to install, good documentation, and examples - tjhollowaychuck: this guy have made lots of projects that makes your life easier: express, mocha, jade, supertest, commander. Lots of examples, simplicity, elegant design and good documentation https://github.com/visionmedia - You can develop applications very fast due to javascripts nature (dynamic typing, closures, easy introspection, prototype inheritance) 2014-06-17 14:41 GMT+02:00 Joe Armstrong : > > On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis wrote: > >> Hi all, >> >> For this to be comparable both Erlang and Node.js need to be running >> similarly. I don't see how a concurrent Erlang runtime with multiple >> schedulers >> can be compared with a single-threaded Node.js implementation objectively >> or >> fairly... >> >> > It's actually the programming models I want to compare and not the > performance - what worries me about node is the run-to-completion > semantics of event callbacks - namely that a long-running event will block > the server preventing short computations from being performed. The > short jobs which could be done immediately have to wait until the long jobs > have finished - this should reflect in the average latencies of a request. > > I made a little experiment (a fibonacci server in erlang and node) and > fired off > 1000 parallel requests to compute fib(N) with N a random number from > 10..40. > > As I suspected many of the fib(10) events are blocked by ongoing > computation of > fib(40) - this reflect in the latencies. > > Node is about 1.6 times faster than Erlang - but the latencies for small > computations > are terrible - Erlang never blocks so the response times are more > predictable. > > And yes I know that fib can be offloaded to a background processor or > parallelised > in JS with a bit of black magic - but manually converting a long lived > computation into > a re-entrant non-blocking version is very difficult. > > The node books say something like "make sure that callbacks > run-to-completion quickly" > I would say that complying with this advice is extremely difficult. It's > very difficult to guess > which computations will take a long time, and even if you know it's > difficult to break them into > small re-entrant chunks. > > Node is very popular so I'm trying to understand what it is about node > that is attractive. > npm for example, looks well engineered and something we could learn from. > The node > web servers are easy to setup and run, so I'd like to see if we could make > equally > easy to use Erlang servers. > > Performance is not a primary concern - easy of programming and correctness > are. > > Cheers > > /Joe > > > > > > > >> Using node cluster with the same number of cluster instances as erlang >> schedulers might be a fairer environment for comparison. However, as >> numeric computations are fairly efficient in Node.js and inefficient in >> Erlang >> relative to Java or C it may take a few iterations to get a fair >> comparison >> in place. Node cluster is a standard part of node.js: >> >> http://nodejs.org/api/cluster.html >> >> There are various attempts at implementing fibers and lightweight threads >> in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is >> nothing >> common here. This would approximate an erlang runtime more closely at >> the cost of deviating a little from a commonly found node runtime... Ho >> hum. >> >> As javascript runtimes start to adopt vectorized instructions and other >> optimisations their speed relative to a C baseline has and will continue >> to >> steadily improve and has been for a number of years, especially with V8. >> >> Good luck with the benchmarking! >> >> Cheers, >> >> Darach. >> >> >> On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: >> >>> >>> >>> >>> On Tue, Jun 17, 2014 at 1:00 PM, Greg Young >>> wrote: >>> >>>> Are you testing against single threaded node or one of the clustered >>>> versions or multiple processes or? >>>> >>>> >>>> >>> Single threaded >>> >>> /Joe >>> >>> >>>> On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 17, 2014 at 12:10 PM, Greg Young >>>>> wrote: >>>>> >>>>>> Can you really compare the two? :) >>>>>> >>>>> >>>>> Yes - there are many things we can measure. Performance, Latency, >>>>> memory usage and so on. >>>>> >>>>> Right now I'm measuring latency - >>>>> >>>>> I set up a few thousand parallel processes which request fib(N) and >>>>> measure the latency of the responses. >>>>> >>>>> the results will be published when I understand them :-) >>>>> >>>>> /Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro >>>>> > wrote: >>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> There's a semicolon missing after the declaration of fib(), which >>>>>>> for some reason, causes the stack overflow. After adding it the error went >>>>>>> away. >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> J >>>>>>> >>>>>>> On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>>> >>>>>>>> I'm trying to compare node.js with erlang. I'm a total node.js >>>>>>>> novice BTW - but I've written some JS. >>>>>>>> >>>>>>>> Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>>> >>>>>>>> So requesting http://127.0.0.1:8124/fib?n=2 should compute and >>>>>>>> return fib(2) >>>>>>>> >>>>>>>> My node.js attempt crashes >>>>>>>> Here's the code in fib.js >>>>>>>> >>>>>>>> --- fib.js >>>>>>>> >>>>>>>> var http = require('http'); >>>>>>>> var url = require('url'); >>>>>>>> >>>>>>>> function fib(n) { >>>>>>>> if (n < 2) { >>>>>>>> return 1; >>>>>>>> } else { >>>>>>>> return fib(n - 2) + fib(n - 1); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> http.createServer(function (req, res) { >>>>>>>> var q = url.parse(req.url, true).query; >>>>>>>> var n = q.n; >>>>>>>> var result = fib(n); >>>>>>>> console.log('fib('+ n + ')= '+result); >>>>>>>> res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>>> res.end(result.toString()); >>>>>>>> }).listen(8124, "127.0.0.1"); >>>>>>>> >>>>>>>> console.log('Server running at http://127.0.0.1:8124/'); >>>>>>>> >>>>>>>> -- end >>>>>>>> >>>>>>>> -- now we run it >>>>>>>> >>>>>>>> $ node fib.js >>>>>>>> Server running at http://127.0.0.1:8124/ >>>>>>>> fib(2)= 2 >>>>>>>> >>>>>>>> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>>> function fib(n) { >>>>>>>> ^ >>>>>>>> RangeError: Maximum call stack size exceeded >>>>>>>> >>>>>>>> fib(2) has run out of stack space???? >>>>>>>> >>>>>>>> $ node --version >>>>>>>> v0.8.21 >>>>>>>> >>>>>>>> Any ideas what I'm doing wrong >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> /Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Remember to send a copy to erlang (dot) questions (at) erlang (dot) >>>>>>> org when posting. >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Erlang Programming" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to erlang-programming+unsubscribe@REDACTED >>>>>>> To post to this group, send email to >>>>>>> erlang-programming@REDACTED >>>>>>> Visit this group at >>>>>>> http://groups.google.com/group/erlang-programming. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Studying for the Turing test >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Studying for the Turing test >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay@REDACTED Tue Jun 17 18:15:19 2014 From: jay@REDACTED (Jay Nelson) Date: Tue, 17 Jun 2014 09:15:19 -0700 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? Message-ID: <6119FD5A-A87C-4276-9B49-4158F1A15367@duomark.com> I agree with the responses that in general pattern-matching in the function head is preferred. There are two caveats, one which you mention and another one that is deeper and related to data abstraction. To differentiate between pattern-match and free variable binding, this would be a perfectly acceptable style: handle_foo( #state{type=bar} = State) -> #state{id=Id, parent=Parent} = State, ? ; handle_foo( #state{type=baz} = State) -> #state{sibling=Sibling, parent=Parent} = State, ? . At the cost of a little redundancy, you make a distinction in the function head of things that are filtering the patterns, and as a side-effect keep a handle on the full record as State, then you set up some new local variables for the fields you are going to compute with. When there are several fields in a record you are accessing, this separation makes for cleaner semantics which are easier to read. The key to the record-matching style, is to get a function head pattern-match crash if the wrong type of data is supplied to the function call. That is desired. If you don?t match on the #state{} construct, but later access State#state.field you will get a very different kind of crash and I prefer knowing about bad datatypes at the entry point to a function call. The above approach retains that feature and clarifies which elements matter to the function case. As Loic mentioned, you would also want to include any fields which are best filtered using a guard on the function head. The second issue relates to the tradition of data abstraction. If you use a #state{} record as an implementation and start pattern-matching in code, then everywhere you access the data structure the implementation is exposed. You cannot change the implementation without changing all those code locations. You also cannot easily enforce dependent default values or correlated dependencies among field values without replicating the logic throughout your code. The case of gen_server, et al, localizes the code references to a single module and that makes things clear within the module and opaque outside the module. But if you pass the record to other modules and do pattern-matching you will run across two issues eventually: 1) records are compile-time constructs, communicating to other nodes can get out of sync if compiled on different versions causing bad, bad problems 2) you will be reluctant to change the implementation of the data model when a better approach is available because it will affect too much code jay From lists@REDACTED Tue Jun 17 18:21:23 2014 From: lists@REDACTED (Camille Troillard) Date: Tue, 17 Jun 2014 18:21:23 +0200 Subject: [erlang-questions] Erlang Numbers Message-ID: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> Dear list, My question is surely outside the scope of Erlang, but I thought I?d ask it here as it is the language I will use, and I am sure you guys have experience in the domain of numbers. I understand Erlang uses the IEEE-754 specs for floating-point numbers arithmetic. So when I type in the console: 1> 0.2 + 0.1. 0.30000000000000004 This is fine, I was expecting that. However, why the following works: 2> 0.1. 0.1 Is it because of some rounding behaviour? Thanks! Camille From bob@REDACTED Tue Jun 17 18:23:18 2014 From: bob@REDACTED (Bob Ippolito) Date: Tue, 17 Jun 2014 11:23:18 -0500 Subject: [erlang-questions] Erlang Numbers In-Reply-To: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> References: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> Message-ID: Yes, floats may be (accurately) rounded when printed. On Tue, Jun 17, 2014 at 11:21 AM, Camille Troillard wrote: > Dear list, > > My question is surely outside the scope of Erlang, but I thought I?d ask > it here as it is the language I will use, and I am sure you guys have > experience in the domain of numbers. > > I understand Erlang uses the IEEE-754 specs for floating-point numbers > arithmetic. So when I type in the console: > > 1> 0.2 + 0.1. > 0.30000000000000004 > > This is fine, I was expecting that. However, why the following works: > > 2> 0.1. > 0.1 > > Is it because of some rounding behaviour? > > > Thanks! > Camille > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@REDACTED Tue Jun 17 18:31:53 2014 From: lists@REDACTED (Camille Troillard) Date: Tue, 17 Jun 2014 18:31:53 +0200 Subject: [erlang-questions] Erlang Numbers In-Reply-To: References: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> Message-ID: <1AD8C199-F8D7-4054-BF2A-4891511476D4@tuli.pe> > Yes, floats may be (accurately) rounded when printed. Thanks Bob. That?s interesting, what do you mean by ?accurately?? From bob@REDACTED Tue Jun 17 18:41:01 2014 From: bob@REDACTED (Bob Ippolito) Date: Tue, 17 Jun 2014 11:41:01 -0500 Subject: [erlang-questions] Erlang Numbers In-Reply-To: <1AD8C199-F8D7-4054-BF2A-4891511476D4@tuli.pe> References: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> <1AD8C199-F8D7-4054-BF2A-4891511476D4@tuli.pe> Message-ID: On Tuesday, June 17, 2014, Camille Troillard wrote: > > > Yes, floats may be (accurately) rounded when printed. > > Thanks Bob. > That?s interesting, what do you mean by ?accurately?? If you parse the printed representation you'll get the same number you started with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Jun 17 18:42:49 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 17 Jun 2014 18:42:49 +0200 Subject: [erlang-questions] Erlang Numbers In-Reply-To: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> References: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> Message-ID: On Tue, Jun 17, 2014 at 6:21 PM, Camille Troillard wrote: > Is it because of some rounding behaviour? It is due to the representation. A floating point number is really a rational number, which has been constructed in a way to make most numbers readily representable in the notation. This means some numbers can be represented in an exact way, whereas other numbers can't. As Bob suggests, there are also rounding, which will sometimes make a number being slightly off seem to be correct. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.muehmer@REDACTED Tue Jun 17 20:12:52 2014 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Tue, 17 Jun 2014 20:12:52 +0200 Subject: [erlang-questions] Crazyflie and Erlang: Anyone already playing with this? (Triggered by "Erlang for youngsters") Message-ID: My interest in quadcopters started with the following videos (in chronological order I watched them): 1) Raffaello D'Andrea: The astounding athletic power of quadcopters: https://www.youtube.com/watch?v=w2itwFJCgFQ 2) Drone In-flight Firmware Upgrade: https://www.youtube.com/watch?v=96UzSHyp0F8 3) Crazyflie Nano Quadcopter pre-release video: https://www.youtube.com/watch?v=3WBUVYZkODI After watching 1) and my first searches for quadcopters resulted in quite some interesting models, but somehow there were too "professional", especially when looking at the price tag. The Parrot AR.Drone 2 (I believe it was used in video 2) isn't that cheap, but it suited the price I had in mind much better (and Erlang was used to interface it, if I didn't get that part wrong), but still I thought it was too large for playing around in a small room and the system was too "closed". Then I found the Crazyflie project (http://www.bitcraze.se/). Here is a list of things I liked about it: - it is very small (perfect for indoor tests) - it is cheap - it is an open platform - the range for the radio is up to 80 meters (looks like I need to get a larger flat) So my questions boils down to this: Is there anyone (beside the feuerlab guys) already fiddling around with Erlang and the Crazyflie (or other quadcopters)? Regards Boris PS: Also have a look at this video "Crazyflie Nano Quadcopter - Assembly video" http://www.youtube.com/watch?v=kS3qR1IjeGE PPS: Reading the "Handbook of Neuroevolution Through Erlang" ( http://www.springer.com/computer/swe/book/978-1-4614-4462-6) gave me even more crazy ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Tue Jun 17 21:10:23 2014 From: tony@REDACTED (Tony Rogvall) Date: Tue, 17 Jun 2014 21:10:23 +0200 Subject: [erlang-questions] Crazyflie and Erlang: Anyone already playing with this? (Triggered by "Erlang for youngsters") In-Reply-To: References: Message-ID: Sadly enough the Cazyflie only has 20Kb RAM and 128Kb flash. This is, sadly enough, too small for Erlang. You could probably implement the client, I did both the client for the regular firmware (and a plenty of porting and hacking for the onboard Erlang controller firmware for the AR.Drone.) And that was a plenty of fun as well. /Tony On 17 jun 2014, at 20:12, Boris M?hmer wrote: > My interest in quadcopters started with the following videos (in chronological order I watched them): > 1) Raffaello D'Andrea: The astounding athletic power of quadcopters: > https://www.youtube.com/watch?v=w2itwFJCgFQ > 2) Drone In-flight Firmware Upgrade: > https://www.youtube.com/watch?v=96UzSHyp0F8 > 3) Crazyflie Nano Quadcopter pre-release video: > https://www.youtube.com/watch?v=3WBUVYZkODI > > After watching 1) and my first searches for quadcopters resulted in quite some interesting models, but somehow there were too "professional", especially when looking at the price tag. > > The Parrot AR.Drone 2 (I believe it was used in video 2) isn't that cheap, but it suited the price I had in mind much better (and Erlang was used to interface it, if I didn't get that part wrong), but still I thought it was too large for playing around in a small room and the system was too "closed". > > Then I found the Crazyflie project (http://www.bitcraze.se/). Here is a list of things I liked about it: > - it is very small (perfect for indoor tests) > - it is cheap > - it is an open platform > - the range for the radio is up to 80 meters (looks like I need to get a larger flat) > > So my questions boils down to this: Is there anyone (beside the feuerlab guys) already fiddling around with Erlang and the Crazyflie (or other quadcopters)? > > > Regards > Boris > > PS: Also have a look at this video "Crazyflie Nano Quadcopter - Assembly video" > http://www.youtube.com/watch?v=kS3qR1IjeGE > PPS: Reading the "Handbook of Neuroevolution Through Erlang" (http://www.springer.com/computer/swe/book/978-1-4614-4462-6) gave me even more crazy ideas. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Tue Jun 17 21:23:11 2014 From: raould@REDACTED (Raoul Duke) Date: Tue, 17 Jun 2014 12:23:11 -0700 Subject: [erlang-questions] Fwd: node.js vs erlang In-Reply-To: References: <6461553.KSmPgYYSSL@jalapeno> Message-ID: yes and no. there are things to learn *from* node, but they probably aren't *node* itself, they are the ecosystem. :-) On Tue, Jun 17, 2014 at 8:12 AM, zxq9 wrote: > On Tuesday 17 June 2014 14:41:28 Joe Armstrong wrote: >> ... but manually converting a long lived computation into >> a re-entrant non-blocking version is very difficult. >> >> The node books say something like "make sure that callbacks >> run-to-completion quickly" >> I would say that complying with this advice is extremely difficult. It's >> very difficult to guess >> which computations will take a long time, and even if you know it's >> difficult to break them into >> small re-entrant chunks. > > This. > > You can't hit the nail any more precisely on the head. > >> Node is very popular so I'm trying to understand what it is about node that >> is attractive. >> npm for example, looks well engineered and something we could learn from. >> The node >> web servers are easy to setup and run, so I'd like to see if we could make >> equally >> easy to use Erlang servers. > > "Easy" is not the same thing as "simple". A lot of people are familiar with JS > and node.js is a fad that speaks to the web 2.0 crowd that can't/won't digest > a serious discussion about the issues you are raising above. *Anything* in JS > is going to be easier for this legion of web folks compared to, well, anything > that isn't JS. > > You are trying to apply your deep technical expertise to a shallow social > phenomenon. As Alan Kay somewhat recently observed, computer science has > become pop-culture and has very little to do with engineering. I'd go further > and say he was really talking about the software development landscape as > applies to the web and other low-performance applications. Folks like you are > coming from a different world than the folks that use and (especially) have > made node.js a pop phenomenon. > > So, don't worry about what is popular. (Popularity is no indication of value > -- I don't think this point needs further support.) If you do that at the > language/platform/infrastructure level you will merely re-discover that > Richard Gabriel was correct, marketing trumps engineering, the Huns will > always crush an overly domesticated Rome, and worse is indeed better. IOW, > you'll turn Erlang and its platform into Java and its vm. > > That would make me sad -- for so many reasons. > > -CRE > > PS: The corrolary to the above is that if the goal is popularity, then neither > the means nor the path to success can be inherently technical in nature. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From boris.muehmer@REDACTED Tue Jun 17 21:35:01 2014 From: boris.muehmer@REDACTED (=?UTF-8?Q?Boris_M=C3=BChmer?=) Date: Tue, 17 Jun 2014 21:35:01 +0200 Subject: [erlang-questions] Crazyflie and Erlang: Anyone already playing with this? (Triggered by "Erlang for youngsters") In-Reply-To: References: Message-ID: Well, the Crazyflie is like an Andruino on "wings"... I didn't want to run Erlang on top of it. Instead I want to interface the Crazyradio: model the controllable parts of the Crazyflie as "processes", interact with them, which in turn communicate using the Crazyradio to control the Crazyflie. Somewhere on the Bitcraze web-site was a hint to put a Raspberry Pi on top of the Crazyflie. Maybe run Erlang on the Rasperry Pi to autonomously control the Crazyflie. On the other hand, this may be too big for an Raspberry Pi... or it may be too slow. I couldn't find much information about the AR.Drone. I even think, that somewhere in the SDK was a passage, that developers aren't allowed to fiddle with the internals/firmware; that was something quite surprising, with what can be seen in the "Drone In-flight Firmware Upgrade" video. Regards, Boris 2014-06-17 21:10 GMT+02:00 Tony Rogvall : > Sadly enough the Cazyflie only has 20Kb RAM and 128Kb flash. > This is, sadly enough, too small for Erlang. > > You could probably implement the client, I did both the client for the > regular firmware > (and a plenty of porting and hacking for the onboard Erlang controller > firmware for the AR.Drone.) > And that was a plenty of fun as well. > > /Tony > > On 17 jun 2014, at 20:12, Boris M?hmer wrote: > > My interest in quadcopters started with the following videos (in > chronological order I watched them): > 1) Raffaello D'Andrea: The astounding athletic power of quadcopters: > https://www.youtube.com/watch?v=w2itwFJCgFQ > 2) Drone In-flight Firmware Upgrade: > https://www.youtube.com/watch?v=96UzSHyp0F8 > 3) Crazyflie Nano Quadcopter pre-release video: > https://www.youtube.com/watch?v=3WBUVYZkODI > > After watching 1) and my first searches for quadcopters resulted in quite > some interesting models, but somehow there were too "professional", > especially when looking at the price tag. > > The Parrot AR.Drone 2 (I believe it was used in video 2) isn't that cheap, > but it suited the price I had in mind much better (and Erlang was used to > interface it, if I didn't get that part wrong), but still I thought it was > too large for playing around in a small room and the system was too > "closed". > > Then I found the Crazyflie project (http://www.bitcraze.se/). Here is a > list of things I liked about it: > - it is very small (perfect for indoor tests) > - it is cheap > - it is an open platform > - the range for the radio is up to 80 meters (looks like I need to get a > larger flat) > > So my questions boils down to this: Is there anyone (beside the feuerlab > guys) already fiddling around with Erlang and the Crazyflie (or other > quadcopters)? > > > Regards > Boris > > PS: Also have a look at this video "Crazyflie Nano Quadcopter - Assembly > video" > http://www.youtube.com/watch?v=kS3qR1IjeGE > PPS: Reading the "Handbook of Neuroevolution Through Erlang" ( > http://www.springer.com/computer/swe/book/978-1-4614-4462-6) gave me even > more crazy ideas. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Tue Jun 17 21:49:32 2014 From: raould@REDACTED (Raoul Duke) Date: Tue, 17 Jun 2014 12:49:32 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: p.s. others have pointed out / complained about node.js of course! we're not alone! http://ncannasse.fr/blog/is_nodejs_wrong From thomasl_erlang@REDACTED Tue Jun 17 22:06:35 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 17 Jun 2014 13:06:35 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> A couple of years ago, I had a BSc student implement a simple but realistic web service (realistic enough to be a replacement for one we were using in production), in Ruby, Node and Erlang. Ruby was slowest, as expected. Overall, Erlang beat Node. In particular, while they were roughly the same "best" performance, Node had a much greater variation in response latency. Best, Thomas On Tuesday, June 17, 2014 2:41 PM, Joe Armstrong wrote: > > > > >On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis wrote: > >Hi all, >> >> >>For this to be comparable both Erlang and Node.js need to be running >>similarly. I don't see how a concurrent Erlang runtime with multiple schedulers >>can be compared with a single-threaded Node.js implementation objectively or >>fairly... >> >> > > >It's actually the programming models I want to compare and not the >performance - what worries me about node is the run-to-completion >semantics of event callbacks - namely that a long-running event will block >the server preventing short computations from being performed. The >short jobs which could be done immediately have to wait until the long jobs >have finished - this should reflect in the average latencies of a request. > > >I made a little experiment (a fibonacci server in erlang and node) and fired off >1000 parallel requests to compute fib(N) with N a random number from 10..40. > > >As I suspected many of the fib(10) events are blocked by ongoing computation of >fib(40) - this reflect in the latencies. > > >Node is about 1.6 times faster than Erlang - but the latencies for small computations >are terrible - Erlang never blocks so the response times are more predictable. > > >And yes I know that fib can be offloaded to a background processor or parallelised >in JS with a bit of black magic - but manually converting a long lived computation into >a re-entrant non-blocking version is very difficult. > > >The node books say something like "make sure that callbacks run-to-completion quickly" >I would say that complying with this advice is extremely difficult. It's very difficult to guess >which computations will take a long time, and even if you know it's difficult to break them into >small re-entrant chunks. > > >Node is very popular so I'm trying to understand what it is about node that is attractive. >npm for example, looks well engineered and something we could learn from. The node >web servers are easy to setup and run, so I'd like to see if we could make equally? >easy to use Erlang servers. > > >Performance is not a primary concern - easy of programming and correctness are. > > >Cheers > > >/Joe > > > > > > > > > > >? >Using node cluster with the same number of cluster instances as erlang >>schedulers might be a fairer environment for comparison. However, as >>numeric computations are fairly efficient in Node.js and inefficient in Erlang >>relative to Java or C it may take a few iterations to get a fair comparison >>in place. Node cluster is a standard part of node.js: >> >> >>http://nodejs.org/api/cluster.html >> >> >> >>There are various attempts at implementing fibers and lightweight threads >>in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is nothing >>common here. This would approximate an erlang runtime more closely at >>the cost of deviating a little from a commonly found node runtime... Ho hum. >> >> >>As javascript runtimes start to adopt vectorized instructions and other >>optimisations their speed relative to a C baseline has and will continue to >>steadily improve and has been for a number of years, especially with V8. >> >> >>Good luck with the benchmarking! >> >> >>Cheers, >> >> >>Darach. >> >> >> >>On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: >> >> >>> >>> >>> >>> >>>On Tue, Jun 17, 2014 at 1:00 PM, Greg Young wrote: >>> >>>Are you testing against single threaded node or one of the clustered versions or multiple processes or? >>>> >>>> >>>> >>> >>> >>>Single threaded >>> >>> >>>/Joe >>>? >>>On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: >>>> >>>> >>>>> >>>>> >>>>>On Tue, Jun 17, 2014 at 12:10 PM, Greg Young wrote: >>>>> >>>>>Can you really compare the two? :)? >>>>> >>>>> >>>>>Yes - there are many things we can measure. Performance, Latency, memory usage and so on. >>>>> >>>>> >>>>>Right now I'm measuring latency -? >>>>> >>>>> >>>>>I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses. >>>>> >>>>> >>>>>the results will be published when I understand them :-) >>>>> >>>>> >>>>>/Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>? >>>>> >>>>>> >>>>>> >>>>>>On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro wrote: >>>>>> >>>>>>Hi Joe, >>>>>>> >>>>>>> >>>>>>>There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away. >>>>>>> >>>>>>> >>>>>>>HTH, >>>>>>> >>>>>>> >>>>>>>J >>>>>>> >>>>>>>On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>>I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. >>>>>>>> >>>>>>>> >>>>>>>>Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>>> >>>>>>>> >>>>>>>>So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) >>>>>>>> >>>>>>>> >>>>>>>>My node.js attempt crashes >>>>>>>>Here's the code in fib.js >>>>>>>> >>>>>>>> >>>>>>>>--- fib.js >>>>>>>> >>>>>>>> >>>>>>>>var http = require('http'); >>>>>>>>var url ?= require('url'); >>>>>>>> >>>>>>>> >>>>>>>>function fib(n) { >>>>>>>>? if (n < 2) { >>>>>>>>? ? return 1; >>>>>>>>? } else { >>>>>>>>? ? return fib(n - 2) + fib(n - 1); >>>>>>>>? } >>>>>>>>} >>>>>>>> >>>>>>>> >>>>>>>>http.createServer(function (req, res) { >>>>>>>>? ? var q = url.parse(req.url, true).query; >>>>>>>>? ? var n = q.n; >>>>>>>>? ? var result = fib(n); >>>>>>>>? ? console.log('fib('+ n + ')= '+result); >>>>>>>>? ? res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>>>? ? res.end(result.toString()); >>>>>>>>}).listen(8124, "127.0.0.1"); >>>>>>>> >>>>>>>> >>>>>>>>console.log('Server running at http://127.0.0.1:8124/'); >>>>>>>> >>>>>>>> >>>>>>>>-- end >>>>>>>> >>>>>>>> >>>>>>>>-- now we run it >>>>>>>> >>>>>>>> >>>>>>>>$ node fib.js >>>>>>>>Server running at http://127.0.0.1:8124/ >>>>>>>>fib(2)= 2 >>>>>>>> >>>>>>>> >>>>>>>>/home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>>>function fib(n) { >>>>>>>>? ? ? ? ? ? ^ >>>>>>>>RangeError: Maximum call stack size exceeded >>>>>>>> >>>>>>>> >>>>>>>>fib(2) has run out of stack space???? >>>>>>>> >>>>>>>> >>>>>>>>$ node --version >>>>>>>>v0.8.21 >>>>>>>> >>>>>>>> >>>>>>>>Any ideas what I'm doing wrong >>>>>>>> >>>>>>>> >>>>>>>>Cheers >>>>>>>> >>>>>>>> >>>>>>>>/Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. >>>>>>>--- >>>>>>>You received this message because you are subscribed to the Google Groups "Erlang Programming" group. >>>>>>>To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED >>>>>>>To post to this group, send email to erlang-programming@REDACTED >>>>>>>Visit this group at http://groups.google.com/group/erlang-programming. >>>>>>>For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>> >>>>>>Studying for the Turing test >>>>> >>>> >>>> >>>> >>>>-- >>>> >>>>Studying for the Turing test >>> >>> >>>_______________________________________________ >>>erlang-questions mailing list >>>erlang-questions@REDACTED >>>http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Tue Jun 17 22:16:42 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 17 Jun 2014 13:16:42 -0700 Subject: [erlang-questions] Tail-f acquired by Cisco Message-ID: <1403036202.85672.YahooMailNeo@web163601.mail.gq1.yahoo.com> Since I haven't seen it mentioned yet, I thought I'd do it. I was notified today that Tail-f, a company founded by a number of well-known erlang guys and employing a largish number of erlang developers, is being acquired by Cisco for $175 million. Their product portfolio is of course to a large extent written in erlang. Congratulations guys! Cisco to Buy Hot Startup Tail-f for $175M | Light Reading? Cisco to Buy Hot Startup Tail-f for $175M | Light Readin... Cisco has struck a deal to acquire next-generation network management and orchestration specialist Tail-f, one of the darlings of the SDN world. View on www.lightreading.com Preview by Yahoo Best, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Tue Jun 17 22:18:29 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 17 Jun 2014 13:18:29 -0700 Subject: [erlang-questions] Fw: node.js vs erlang In-Reply-To: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> Message-ID: <1403036309.78041.YahooMailNeo@web163605.mail.gq1.yahoo.com> A couple of years ago, I had a BSc student implement a simple but realistic web service (realistic enough to be a replacement for one we were using in production), in Ruby, Node and Erlang. Ruby was slowest, as expected. Overall, Erlang beat Node. In particular, while they were roughly the same "best" performance, Node had a much greater variation in response latency. Best, Thomas On Tuesday, June 17, 2014 10:06 PM, Thomas Lindgren wrote: > >On Tuesday, June 17, 2014 2:41 PM, Joe Armstrong wrote: > > >> >> >> >> >>On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis wrote: >> >>Hi all, >>> >>> >>>For this to be comparable both Erlang and Node.js need to be running >>>similarly. I don't see how a concurrent Erlang runtime with multiple schedulers >>>can be compared with a single-threaded Node.js implementation objectively or >>>fairly... >>> >>> >> >> >>It's actually the programming models I want to compare and not the >>performance - what worries me about node is the run-to-completion >>semantics of event callbacks - namely that a long-running event will block >>the server preventing short computations from being performed. The >>short jobs which could be done immediately have to wait until the long jobs >>have finished - this should reflect in the average latencies of a request. >> >> >>I made a little experiment (a fibonacci server in erlang and node) and fired off >>1000 parallel requests to compute fib(N) with N a random number from 10..40. >> >> >>As I suspected many of the fib(10) events are blocked by ongoing computation of >>fib(40) - this reflect in the latencies. >> >> >>Node is about 1.6 times faster than Erlang - but the latencies for small computations >>are terrible - Erlang never blocks so the response times are more predictable. >> >> >>And yes I know that fib can be offloaded to a background processor or parallelised >>in JS with a bit of black magic - but manually converting a long lived computation into >>a re-entrant non-blocking version is very difficult. >> >> >>The node books say something like "make sure that callbacks run-to-completion quickly" >>I would say that complying with this advice is extremely difficult. It's very difficult to guess >>which computations will take a long time, and even if you know it's difficult to break them into >>small re-entrant chunks. >> >> >>Node is very popular so I'm trying to understand what it is about node that is attractive. >>npm for example, looks well engineered and something we could learn from. The node >>web servers are easy to setup and run, so I'd like to see if we could make equally? >>easy to use Erlang servers. >> >> >>Performance is not a primary concern - easy of programming and correctness are. >> >> >>Cheers >> >> >>/Joe >> >> >> >> >> >> >> >> >> >> >>? >>Using node cluster with the same number of cluster instances as erlang >>>schedulers might be a fairer environment for comparison. However, as >>>numeric computations are fairly efficient in Node.js and inefficient in Erlang >>>relative to Java or C it may take a few iterations to get a fair comparison >>>in place. Node cluster is a standard part of node.js: >>> >>> >>>http://nodejs.org/api/cluster.html >>> >>> >>> >>>There are various attempts at implementing fibers and lightweight threads >>>in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is nothing >>>common here. This would approximate an erlang runtime more closely at >>>the cost of deviating a little from a commonly found node runtime... Ho hum. >>> >>> >>>As javascript runtimes start to adopt vectorized instructions and other >>>optimisations their speed relative to a C baseline has and will continue to >>>steadily improve and has been for a number of years, especially with V8. >>> >>> >>>Good luck with the benchmarking! >>> >>> >>>Cheers, >>> >>> >>>Darach. >>> >>> >>> >>>On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong wrote: >>> >>> >>>> >>>> >>>> >>>> >>>>On Tue, Jun 17, 2014 at 1:00 PM, Greg Young wrote: >>>> >>>>Are you testing against single threaded node or one of the clustered versions or multiple processes or? >>>>> >>>>> >>>>> >>>> >>>> >>>>Single threaded >>>> >>>> >>>>/Joe >>>>? >>>>On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>>On Tue, Jun 17, 2014 at 12:10 PM, Greg Young wrote: >>>>>> >>>>>>Can you really compare the two? :)? >>>>>> >>>>>> >>>>>>Yes - there are many things we can measure. Performance, Latency, memory usage and so on. >>>>>> >>>>>> >>>>>>Right now I'm measuring latency -? >>>>>> >>>>>> >>>>>>I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses. >>>>>> >>>>>> >>>>>>the results will be published when I understand them :-) >>>>>> >>>>>> >>>>>>/Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>? >>>>>> >>>>>>> >>>>>>> >>>>>>>On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro wrote: >>>>>>> >>>>>>>Hi Joe, >>>>>>>> >>>>>>>> >>>>>>>>There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away. >>>>>>>> >>>>>>>> >>>>>>>>HTH, >>>>>>>> >>>>>>>> >>>>>>>>J >>>>>>>> >>>>>>>>On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: >>>>>>>>I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. >>>>>>>>> >>>>>>>>> >>>>>>>>>Program 1 is just fibonacci - I want a web server to compute fib(N) >>>>>>>>> >>>>>>>>> >>>>>>>>>So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) >>>>>>>>> >>>>>>>>> >>>>>>>>>My node.js attempt crashes >>>>>>>>>Here's the code in fib.js >>>>>>>>> >>>>>>>>> >>>>>>>>>--- fib.js >>>>>>>>> >>>>>>>>> >>>>>>>>>var http = require('http'); >>>>>>>>>var url ?= require('url'); >>>>>>>>> >>>>>>>>> >>>>>>>>>function fib(n) { >>>>>>>>>? if (n < 2) { >>>>>>>>>? ? return 1; >>>>>>>>>? } else { >>>>>>>>>? ? return fib(n - 2) + fib(n - 1); >>>>>>>>>? } >>>>>>>>>} >>>>>>>>> >>>>>>>>> >>>>>>>>>http.createServer(function (req, res) { >>>>>>>>>? ? var q = url.parse(req.url, true).query; >>>>>>>>>? ? var n = q.n; >>>>>>>>>? ? var result = fib(n); >>>>>>>>>? ? console.log('fib('+ n + ')= '+result); >>>>>>>>>? ? res.writeHead(200, {'Content-Type': 'text/plain'}); >>>>>>>>>? ? res.end(result.toString()); >>>>>>>>>}).listen(8124, "127.0.0.1"); >>>>>>>>> >>>>>>>>> >>>>>>>>>console.log('Server running at http://127.0.0.1:8124/'); >>>>>>>>> >>>>>>>>> >>>>>>>>>-- end >>>>>>>>> >>>>>>>>> >>>>>>>>>-- now we run it >>>>>>>>> >>>>>>>>> >>>>>>>>>$ node fib.js >>>>>>>>>Server running at http://127.0.0.1:8124/ >>>>>>>>>fib(2)= 2 >>>>>>>>> >>>>>>>>> >>>>>>>>>/home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 >>>>>>>>>function fib(n) { >>>>>>>>>? ? ? ? ? ? ^ >>>>>>>>>RangeError: Maximum call stack size exceeded >>>>>>>>> >>>>>>>>> >>>>>>>>>fib(2) has run out of stack space???? >>>>>>>>> >>>>>>>>> >>>>>>>>>$ node --version >>>>>>>>>v0.8.21 >>>>>>>>> >>>>>>>>> >>>>>>>>>Any ideas what I'm doing wrong >>>>>>>>> >>>>>>>>> >>>>>>>>>Cheers >>>>>>>>> >>>>>>>>> >>>>>>>>>/Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. >>>>>>>>--- >>>>>>>>You received this message because you are subscribed to the Google Groups "Erlang Programming" group. >>>>>>>>To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED >>>>>>>>To post to this group, send email to erlang-programming@REDACTED >>>>>>>>Visit this group at http://groups.google.com/group/erlang-programming. >>>>>>>>For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>> >>>>>>>Studying for the Turing test >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>> >>>>>Studying for the Turing test >>>> >>>> >>>>_______________________________________________ >>>>erlang-questions mailing list >>>>erlang-questions@REDACTED >>>>http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> >> >> >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Jun 17 22:53:14 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 17 Jun 2014 16:53:14 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> Message-ID: <53A0AABA.9060605@meetinghouse.net> Folks, Let's not forget what node.js is, and it's intent: It's an implementation of server-side javascript, pure and simple. Personally, I liked Jaxer (before it died) better. Where node.js is framed more as a general purpose environment, Jaxer was framed more as "let's push some the browser to the server" - which was just perfect for things like database access, comms access, etc. Essentially it was 'write a web page/app with javascript, then designate some of it for server-side execution.' And Aptana did a nice job of an IDE for both client- and server- side code. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mark.nijhof@REDACTED Tue Jun 17 23:02:09 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Tue, 17 Jun 2014 23:02:09 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A0AABA.9060605@meetinghouse.net> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: I just found this: http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ which I think is an interesting comparison And here is an interesting thread as well: http://programmers.stackexchange.com/questions/85975/learning-erlang-vs-learning-node-js -Mark On Tue, Jun 17, 2014 at 10:53 PM, Miles Fidelman wrote: > Folks, > > Let's not forget what node.js is, and it's intent: It's an implementation > of server-side javascript, pure and simple. > > Personally, I liked Jaxer (before it died) better. Where node.js is > framed more as a general purpose environment, Jaxer was framed more as > "let's push some the browser to the server" - which was just perfect for > things like database access, comms access, etc. Essentially it was 'write a > web page/app with javascript, then designate some of it for server-side > execution.' > > And Aptana did a nice job of an IDE for both client- and server- side code. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.revington@REDACTED Tue Jun 17 23:18:36 2014 From: p.revington@REDACTED (=?UTF-8?Q?Pedro_Narciso_Garc=C3=ADa_Revington?=) Date: Tue, 17 Jun 2014 23:18:36 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: Hey Mark, That benchmark is a little bit outdated. Have a look at this one http://www.techempower.com/benchmarks 2014-06-17 23:02 GMT+02:00 Mark Nijhof : > I just found this: > http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ > which I think is an interesting comparison > > And here is an interesting thread as well: > http://programmers.stackexchange.com/questions/85975/learning-erlang-vs-learning-node-js > > -Mark > > > > On Tue, Jun 17, 2014 at 10:53 PM, Miles Fidelman < > mfidelman@REDACTED> wrote: > >> Folks, >> >> Let's not forget what node.js is, and it's intent: It's an >> implementation of server-side javascript, pure and simple. >> >> Personally, I liked Jaxer (before it died) better. Where node.js is >> framed more as a general purpose environment, Jaxer was framed more as >> "let's push some the browser to the server" - which was just perfect for >> things like database access, comms access, etc. Essentially it was 'write a >> web page/app with javascript, then designate some of it for server-side >> execution.' >> >> And Aptana did a nice job of an IDE for both client- and server- side >> code. >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Tue Jun 17 23:20:39 2014 From: tony@REDACTED (Tony Rogvall) Date: Tue, 17 Jun 2014 23:20:39 +0200 Subject: [erlang-questions] Crazyflie and Erlang: Anyone already playing with this? (Triggered by "Erlang for youngsters") In-Reply-To: References: Message-ID: <4D07D6C5-4A76-4747-B810-6F49898E7209@rogvall.se> On 17 jun 2014, at 21:35, Boris M?hmer wrote: > Well, the Crazyflie is like an Andruino on "wings"... I didn't want to run Erlang on top of it. Instead I want to interface the Crazyradio: model the controllable parts of the Crazyflie as "processes", interact with them, which in turn communicate using the Crazyradio to control the Crazyflie. > A client would probably be easy enough to hack. > Somewhere on the Bitcraze web-site was a hint to put a Raspberry Pi on top of the Crazyflie. Maybe run Erlang on the Rasperry Pi to autonomously control the Crazyflie. On the other hand, this may be too big for an Raspberry Pi... or it may be too slow. > Sound like a cool enough idea. If the copter can carry the Raspberry Pi and an extra battery. Why not. (A bit strange but fun ... :-) > I couldn't find much information about the AR.Drone. I even think, that somewhere in the SDK was a passage, that developers aren't allowed to fiddle with the internals/firmware; that was something quite surprising, with what can be seen in the "Drone In-flight Firmware Upgrade" video. > Oops, but it is my property and I want to destroy. We we asked for permission but never got a reply. If it gets "big", I guess they will probably ask me to remove it. And yes, I did do some (easy) reverse engineering to figure out where the gpio/uart/i2c was located etc. But they are using linux so they must supply any software modification they do... /Tony > > Regards, > Boris > > > > > 2014-06-17 21:10 GMT+02:00 Tony Rogvall : > Sadly enough the Cazyflie only has 20Kb RAM and 128Kb flash. > This is, sadly enough, too small for Erlang. > > You could probably implement the client, I did both the client for the regular firmware > (and a plenty of porting and hacking for the onboard Erlang controller firmware for the AR.Drone.) > And that was a plenty of fun as well. > > /Tony > > On 17 jun 2014, at 20:12, Boris M?hmer wrote: > >> My interest in quadcopters started with the following videos (in chronological order I watched them): >> 1) Raffaello D'Andrea: The astounding athletic power of quadcopters: >> https://www.youtube.com/watch?v=w2itwFJCgFQ >> 2) Drone In-flight Firmware Upgrade: >> https://www.youtube.com/watch?v=96UzSHyp0F8 >> 3) Crazyflie Nano Quadcopter pre-release video: >> https://www.youtube.com/watch?v=3WBUVYZkODI >> >> After watching 1) and my first searches for quadcopters resulted in quite some interesting models, but somehow there were too "professional", especially when looking at the price tag. >> >> The Parrot AR.Drone 2 (I believe it was used in video 2) isn't that cheap, but it suited the price I had in mind much better (and Erlang was used to interface it, if I didn't get that part wrong), but still I thought it was too large for playing around in a small room and the system was too "closed". >> >> Then I found the Crazyflie project (http://www.bitcraze.se/). Here is a list of things I liked about it: >> - it is very small (perfect for indoor tests) >> - it is cheap >> - it is an open platform >> - the range for the radio is up to 80 meters (looks like I need to get a larger flat) >> >> So my questions boils down to this: Is there anyone (beside the feuerlab guys) already fiddling around with Erlang and the Crazyflie (or other quadcopters)? >> >> >> Regards >> Boris >> >> PS: Also have a look at this video "Crazyflie Nano Quadcopter - Assembly video" >> http://www.youtube.com/watch?v=kS3qR1IjeGE >> PPS: Reading the "Handbook of Neuroevolution Through Erlang" (http://www.springer.com/computer/swe/book/978-1-4614-4462-6) gave me even more crazy ideas. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Tue Jun 17 23:35:49 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Tue, 17 Jun 2014 23:35:49 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: Thanks, seen it before but forgot about it On Tue, Jun 17, 2014 at 11:18 PM, Pedro Narciso Garc?a Revington < p.revington@REDACTED> wrote: > Hey Mark, > > That benchmark is a little bit outdated. Have a look at this one > http://www.techempower.com/benchmarks > > > > 2014-06-17 23:02 GMT+02:00 Mark Nijhof : > > I just found this: >> http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ >> which I think is an interesting comparison >> >> And here is an interesting thread as well: >> http://programmers.stackexchange.com/questions/85975/learning-erlang-vs-learning-node-js >> >> -Mark >> >> >> >> On Tue, Jun 17, 2014 at 10:53 PM, Miles Fidelman < >> mfidelman@REDACTED> wrote: >> >>> Folks, >>> >>> Let's not forget what node.js is, and it's intent: It's an >>> implementation of server-side javascript, pure and simple. >>> >>> Personally, I liked Jaxer (before it died) better. Where node.js is >>> framed more as a general purpose environment, Jaxer was framed more as >>> "let's push some the browser to the server" - which was just perfect for >>> things like database access, comms access, etc. Essentially it was 'write a >>> web page/app with javascript, then designate some of it for server-side >>> execution.' >>> >>> And Aptana did a nice job of an IDE for both client- and server- side >>> code. >>> >>> Miles Fidelman >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. .... Yogi Berra >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Wed Jun 18 00:14:15 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 18 Jun 2014 00:14:15 +0200 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released In-Reply-To: References: Message-ID: I just released the version 0.2.0 which add unit-testing and contains some fixes: https://wiki.refuge.io/display/COWDB/Changelog#Changelog-0.2.0-2014/06/17 Enjoy! - benoit On Tue, Jun 17, 2014 at 1:04 AM, Benoit Chesneau wrote: > Hi all, > > I presented it rapidly during the EUC and it took some time to finish some > feature but here the first release of cowdb: > > http://cowdb.org > > Cowdb implements an indexed, key/value storage engine in #Erlang. The > primary index is an append-only btree implemented using CBT a btree library > extracted from Apache #CouchDB. > > Main features are: > > - Append-Only b-tree using COW > - Read/Write can happen independently > - Put/Get/Delete/Fold operations > - support transactions with transaction functions > - Transaction log > - Snapshotting support > - Automatic compaction > > Enjoy!? > > - benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Jun 18 00:33:56 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 18 Jun 2014 10:33:56 +1200 Subject: [erlang-questions] Erlang Numbers In-Reply-To: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> References: <5A1D7C1B-63A4-460D-B23F-F5721D3BD19F@tuli.pe> Message-ID: <11025C64-AA0D-45D9-9BA1-E89835627988@cs.otago.ac.nz> On 18/06/2014, at 4:21 AM, Camille Troillard wrote: > I understand Erlang uses the IEEE-754 specs for floating-point numbers arithmetic. So when I type in the console: > > 1> 0.2 + 0.1. > 0.30000000000000004 > > This is fine, I was expecting that. However, why the following works: > > 2> 0.1. > 0.1 > > Is it because of some rounding behaviour? If the question you're asking is whether it is because of some *Erlang-specific* rounding behaviour, the answer is NO. m% gsi Gambit v4.6.0 > (+ 0.2 0.1) .30000000000000004 > 0.1 .1 > (* 0.1 3) .30000000000000004 > (- (* 0.1 10) 1) 0. > (- (* (+ 0.1 0.2) 10) 3) 4.440892098500626e-16 What we want from output is - the shortest number that reads back as what we started with and for 0.1 that happens to be "0.1". From zxq9@REDACTED Wed Jun 18 00:51:32 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 18 Jun 2014 07:51:32 +0900 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A0AABA.9060605@meetinghouse.net> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: <5922236.OvZnJaGshk@jalapeno> On Tuesday 17 June 2014 16:53:14 Miles Fidelman wrote: > Folks, > > Let's not forget what node.js is, and it's intent: It's an > implementation of server-side javascript, pure and simple. > > Personally, I liked Jaxer (before it died) better. Where node.js is > framed more as a general purpose environment, Jaxer was framed more as > "let's push some the browser to the server" - which was just perfect for > things like database access, comms access, etc. Essentially it was > 'write a web page/app with javascript, then designate some of it for > server-side execution.' > > And Aptana did a nice job of an IDE for both client- and server- side code. It is unclear whether considering intent and role with regard to the web is useful. An argument can be made that most elements related to the web today have already forgotten their roles and intent -- the point of dark comedy. From be.dmitry@REDACTED Wed Jun 18 01:22:28 2014 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Wed, 18 Jun 2014 09:22:28 +1000 Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: References: Message-ID: Why not to use different records for different contents? -- Best wishes, Dmitry Belyaev On 18 June 2014 12:21:15 AM AEST, Roger Lipscombe wrote: >I'm currently refactoring some code, and I've got something like this: > >handle_foo(#state { type = bar, id = Id }) -> whatever; >handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. > >...and I'm wondering whether it's considered bad form to access record >fields at the same time as matching them in a function clause. I'm >matching on 'type', and accessing 'id' at the same time, I mean. > >Instead, should I consider something like the following? > >handle_foo(#state { type = bar }) -> > Id = State#state.id, > whatever; >handle_foo(#state { type = baz }) -> > ParentId = State#state.parent_id, > whatever. > >The first form makes it explicit that for different types, different >fields matter (which might be a smell by itself), but it gets hard to >see the match on 'type' once I'm accessing more than one or two >fields. > >I know this is stylistic, and there's no "right" answer; I just >wondered what other people tend to do? > >Or, more generally, do people prefer using pattern matching to access >record values, or plain-ol' Foo = State#state.foo expressions? > >Thanks, >Roger. >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Wed Jun 18 01:36:39 2014 From: raould@REDACTED (Raoul Duke) Date: Tue, 17 Jun 2014 16:36:39 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A0AABA.9060605@meetinghouse.net> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: > Let's not forget what node.js is, and it's intent: It's an implementation > of server-side javascript, pure and simple. hrm, i do not believe that statement is correct. something like Rhino would more fit that statement, i think. or even just V8. node = V8 + more stuff, so i think that sorta disproves what you wrote? From mfidelman@REDACTED Wed Jun 18 04:25:58 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 17 Jun 2014 22:25:58 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> Message-ID: <53A0F8B6.1010408@meetinghouse.net> Raoul Duke wrote: >> Let's not forget what node.js is, and it's intent: It's an implementation >> of server-side javascript, pure and simple. > hrm, i do not believe that statement is correct. something like Rhino > would more fit that statement, i think. or even just V8. node = V8 + > more stuff, so i think that sorta disproves what you wrote? > _______________________________________________ > Not quite. V8 is a javascript engine, as is Rhino, as is SpiderMonkey, as is WebKit, etc. In particular, V8 is the javascript engine for the Chrome browser. node wraps glue around it to create a server-side environment. A couple of references from http://nodejs.org/about/ - both 'intro to node.js' type slide decks from Ryan Dahl - who is kind of the ultimate authority, in that he's the author of node: Slide 2 (right after the cover) of http://nodejs.org/jsconf2010.pdf starts with this statement: "node.js: Evented Server-side Javascript" A slightly earlier version (http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf) says this (again, slide 2): node.js in brief: Server-side Javascript Built on Google?s V8 Evented, non-blocking I/O. Similar to EventMachine or Twisted. CommonJS module system. 8000 lines of C/C++, 2000 lines of Javascript, 14 contributors. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From fritchie@REDACTED Wed Jun 18 06:11:41 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 17 Jun 2014 23:11:41 -0500 Subject: [erlang-questions] How would you implement a blob store In-Reply-To: Message of "Thu, 12 Jun 2014 10:46:36 +0200." Message-ID: <42430.1403064701@snookles.snookles.com> Hi, Joe. You've probably moved on to 7 different project since you started this thread, but perhaps the Erlang User Conference slowed you down? ^_^ Joe Armstrong wrote: ja> - The values are variable size binaries (max 56 KB) ja> - The keys are SHA1 hashes of the values ja> - I want to store max 1M blobs ja> - Efficiency is not a concern (...) ja> The *simplest* way I can think of is to use the file store [...] Your proposed addition of the additional subdirectory layers is overkill, when considering both your "simplest" desire (or perhaps just "simple") and also today's file systems: most are going to do just fine with 1 million files in a single subdirectory. If you're worried about data integrity on disk at all times, then you'll have to do do something like this untested code: ok = file:write_file(Path ++ ".tmp", FileContents), ok = file:rename(Path ++ ".tmp", Path) ... and then when reading the file's contents, compare the hash to the filename (which you'd said *is* the hash of the file's contents). Bitcask would do just fine, though for such a small amount of data, the speed gained by having all keys in Bitcask's keydir and file write speed by merely appending your <56KByte objects to a big file ... probably won't gain you much. -Scott From co7eb@REDACTED Wed Jun 18 07:49:13 2014 From: co7eb@REDACTED (=?utf-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Wed, 18 Jun 2014 01:49:13 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A0F8B6.1010408@meetinghouse.net> References: <1403035595.66115.YahooMailNeo@web163604.mail.gq1.yahoo.com> <53A0AABA.9060605@meetinghouse.net> <53A0F8B6.1010408@meetinghouse.net> Message-ID: <000001cf8ab9$0a3e4670$1ebad350$@frcuba.co.cu> Hi all, Joe, I think the understanding of how node became so popular, is because the one who invented node, he had one goal in mind, to take the advantage of the already well formed and big javascript community, javascript became so popular it had its reasons, but it was just a client-side technology!, so what about a server side technology that complements that already fully operational client-side tec? Using the same community? noting to create, noting to grow, only putting in the eyes of the fools another foolish. That's what nodejs is. Now imagine the turn of programming technics if all browser companies could include interpretation for Erlang natively? And you could communicate two Erlang's nodes one in the client (browser) another in the server as the same way as Erlang always do, Even so without having that big community, I'm sure the entire web community will be forced to see that new tec that is in all browsers and have the same counterpart in the server Best, Ivan. -----Mensaje original----- De: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] En nombre de Miles Fidelman Enviado el: martes, 17 de junio de 2014 10:26 p.m. Para: Erlang Asunto: Re: [erlang-questions] node.js vs erlang Raoul Duke wrote: >> Let's not forget what node.js is, and it's intent: It's an >> implementation of server-side javascript, pure and simple. > hrm, i do not believe that statement is correct. something like Rhino > would more fit that statement, i think. or even just V8. node = V8 + > more stuff, so i think that sorta disproves what you wrote? > _______________________________________________ > Not quite. V8 is a javascript engine, as is Rhino, as is SpiderMonkey, as is WebKit, etc. In particular, V8 is the javascript engine for the Chrome browser. node wraps glue around it to create a server-side environment. A couple of references from http://nodejs.org/about/ - both 'intro to node.js' type slide decks from Ryan Dahl - who is kind of the ultimate authority, in that he's the author of node: Slide 2 (right after the cover) of http://nodejs.org/jsconf2010.pdf starts with this statement: "node.js: Evented Server-side Javascript" A slightly earlier version (http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf) says this (again, slide 2): node.js in brief: Server-side Javascript Built on Google?s V8 Evented, non-blocking I/O. Similar to EventMachine or Twisted. CommonJS module system. 8000 lines of C/C++, 2000 lines of Javascript, 14 contributors. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From co7eb@REDACTED Wed Jun 18 07:49:13 2014 From: co7eb@REDACTED (=?utf-8?Q?Ivan_Carmenates_Garc=C3=ADa?=) Date: Wed, 18 Jun 2014 01:49:13 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <000101cf8ab9$0c7809d0$25681d70$@frcuba.co.cu> Hi all, Paulo F. Oliveira says: ??At the moment, though, I enjoy prototyping with Node.js and implementing with Erlang. :)?? Yes Paulo, I definely think that it is what nodejs is about, it is very nice to prototyping things because of the code, easily to understand and program; a different way of thinking (no so nice like Erlang but.. still..), but noting seriously such as what you can do with Erlang you can build with nodejs I think. Best, Ivan. De: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] En nombre de Paulo F. Oliveira Enviado el: martes, 17 de junio de 2014 09:07 a.m. Para: Joe Armstrong CC: Greg Young; Juan Facorro; Erlang; erlang-programming@REDACTED Asunto: Re: [erlang-questions] node.js vs erlang "Node is very popular so I'm trying to understand what it is about node that is attractive." Having recently moved from Node.js (JavaScript really) to Erlang, a few things come to mind: 1. a lot of browser frontend (i.e. JavaScript) developers almost don't have to learn anything new to develop server-side code using Node.js 2. npm (for sure) is one of the best package management systems I've used... really simple (oh, and the fact that you can use specific versions of deps in your app and not be restricted by a previous choice, sure helps a lot) 3. npmjs.org :D 4. the debugger (node-inspector): I miss this :( 5. you can share server-side and browser-side code On the other hand, for high concurrency, I wouldn't recommend it (it's heavy when you have to spawn a few thousand processes to do _parallel_ and then the OS can't easily cope with this), as it's single threaded (ok, there's Cluster, but...). And also, the fact that tail recursion is non-existing... At the moment, though, I enjoy prototyping with Node.js and implementing with Erlang. :) - Paulo F. Oliveira On 17 June 2014 13:41, Joe Armstrong < erlang@REDACTED> wrote: On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis < darach@REDACTED> wrote: Hi all, For this to be comparable both Erlang and Node.js need to be running similarly. I don't see how a concurrent Erlang runtime with multiple schedulers can be compared with a single-threaded Node.js implementation objectively or fairly... It's actually the programming models I want to compare and not the performance - what worries me about node is the run-to-completion semantics of event callbacks - namely that a long-running event will block the server preventing short computations from being performed. The short jobs which could be done immediately have to wait until the long jobs have finished - this should reflect in the average latencies of a request. I made a little experiment (a fibonacci server in erlang and node) and fired off 1000 parallel requests to compute fib(N) with N a random number from 10..40. As I suspected many of the fib(10) events are blocked by ongoing computation of fib(40) - this reflect in the latencies. Node is about 1.6 times faster than Erlang - but the latencies for small computations are terrible - Erlang never blocks so the response times are more predictable. And yes I know that fib can be offloaded to a background processor or parallelised in JS with a bit of black magic - but manually converting a long lived computation into a re-entrant non-blocking version is very difficult. The node books say something like "make sure that callbacks run-to-completion quickly" I would say that complying with this advice is extremely difficult. It's very difficult to guess which computations will take a long time, and even if you know it's difficult to break them into small re-entrant chunks. Node is very popular so I'm trying to understand what it is about node that is attractive. npm for example, looks well engineered and something we could learn from. The node web servers are easy to setup and run, so I'd like to see if we could make equally easy to use Erlang servers. Performance is not a primary concern - easy of programming and correctness are. Cheers /Joe Using node cluster with the same number of cluster instances as erlang schedulers might be a fairer environment for comparison. However, as numeric computations are fairly efficient in Node.js and inefficient in Erlang relative to Java or C it may take a few iterations to get a fair comparison in place. Node cluster is a standard part of node.js: http://nodejs.org/api/cluster.html There are various attempts at implementing fibers and lightweight threads in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is nothing common here. This would approximate an erlang runtime more closely at the cost of deviating a little from a commonly found node runtime... Ho hum. As javascript runtimes start to adopt vectorized instructions and other optimisations their speed relative to a C baseline has and will continue to steadily improve and has been for a number of years, especially with V8. Good luck with the benchmarking! Cheers, Darach. On Tue, Jun 17, 2014 at 12:48 PM, Joe Armstrong < erlang@REDACTED> wrote: On Tue, Jun 17, 2014 at 1:00 PM, Greg Young < gregoryyoung1@REDACTED> wrote: Are you testing against single threaded node or one of the clustered versions or multiple processes or? Single threaded /Joe On Tue, Jun 17, 2014 at 1:19 PM, Joe Armstrong < erlang@REDACTED> wrote: On Tue, Jun 17, 2014 at 12:10 PM, Greg Young < gregoryyoung1@REDACTED> wrote: Can you really compare the two? :) Yes - there are many things we can measure. Performance, Latency, memory usage and so on. Right now I'm measuring latency - I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses. the results will be published when I understand them :-) /Joe On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro < juan.facorro@REDACTED> wrote: Hi Joe, There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away. HTH, J On Monday, June 16, 2014 11:22:23 AM UTC-3, Joe Armstrong wrote: I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS. Program 1 is just fibonacci - I want a web server to compute fib(N) So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2) My node.js attempt crashes Here's the code in fib.js --- fib.js var http = require('http'); var url = require('url'); function fib(n) { if (n < 2) { return 1; } else { return fib(n - 2) + fib(n - 1); } } http.createServer(function (req, res) { var q = url.parse(req.url, true).query; var n = q.n; var result = fib(n); console.log('fib('+ n + ')= '+result); res.writeHead(200, {'Content-Type': 'text/plain'}); res.end(result.toString()); }).listen(8124, "127.0.0.1"); console.log('Server running at http://127.0.0.1:8124/'); -- end -- now we run it $ node fib.js Server running at http://127.0.0.1:8124/ fib(2)= 2 /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5 function fib(n) { ^ RangeError: Maximum call stack size exceeded fib(2) has run out of stack space???? $ node --version v0.8.21 Any ideas what I'm doing wrong Cheers /Joe -- Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. --- You received this message because you are subscribed to the Google Groups "Erlang Programming" group. To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED To post to this group, send email to erlang-programming@REDACTED Visit this group at http://groups.google.com/group/erlang-programming. For more options, visit https://groups.google.com/d/optout. -- Studying for the Turing test -- Studying for the Turing test _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseigo@REDACTED Wed Jun 18 09:39:00 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Wed, 18 Jun 2014 09:39 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: <1831314.qTF9aCn5q6@freedom> (apologies for the length of this email .. i've been poking at it for a couple days since Joe's first email and finally combined the ramblings into something resembling a reply. it's a set of ponderings / reflections of someone new to erlang who has written non-trivial apps with node.js ... which seems to be pretty much exactly where Joe is trying to explore :) On Tuesday, June 17, 2014 14:41:28 Joe Armstrong wrote: > The node books say something like "make sure that callbacks > run-to-completion quickly" > I would say that complying with this advice is extremely difficult. It's > very difficult to guess > which computations will take a long time, and even if you know it's > difficult to break them into > small re-entrant chunks. ... which is generally why CPU-bound tasks are to be avoided in the node.js world. conventional wisdom (be that as it may) is that node is appropriate for I/O bound processes which operate on streams. anything else and one ends spawning processes and waiting for response (which makes it async in the node.js runtime again, but that is not particularly lightweight ...) as such, your choice of benchmarks (fib) is not really going to produce representative benchmarks of node.js as used in the wild. (by sane people anyways :) an i/o bound process is going to show a more typical node.js performance profile e.g.: * call into a database (sql or key/value, whatever) and retrieve N rows from a large dataset based on the client query (i.e. an offset and limit), do some light post-processing of the retrieved data (if any) and return the results as a json response (typical of the ajax-y style apps node.js is often pressed into...) * stream a file back to a client on request, reading from the local file and writing to the socket both happening in chunked async requests (made easy with the built-in file module) in those workloads, or so the theory goes, much of the wall clock time is spent waiting for response from the data source (i.e. the database in the above example) and related i/o to the client. using that time to run other application code is a good way to handle concurrent requests at greater volume / lower latency. and it does work reasonably well, if not presenting an optimal solution. (nothing in that paragraph is rocket science, of course :) (p.s. benchmarking is hard, so props for taking a run at this ..) > Node is very popular so I'm trying to understand what it is about node that > is attractive. > npm for example, looks well engineered and something we could learn from. for many node.js projects, including ones i've worked on, this has been a HUGE part of the reason to go with it. the monstrous number of easily integrated 3rd party modules is a significant asset, and helps make up for many of the annoyances. the path to node.js seems to go something like: * developer hears the hype about node.js (scalable, easy, ..) * figuring how they already "know" javascript, developer dips a toe in the node.js water and finds that it is easy to do simple things (e.g. a toy project to learn the framework with) * developer discovers npm and is hooked ("I don't have to write most of my app myself!") that progression from "hear the hype" through to finding the killer feature of node (npm and the wide world of node.js modules) is quick and rewarding (via instant success). perhaps that is sth that erlang can learn from :) > The node > web servers are easy to setup and run, so I'd like to see if we could make express is indeed pretty damn fine, but some of the other modules such as async[1][2] are hugely critical by encapsulating a lot of the typical patterns that would otherwise be repetitive drudgework (mostly due to the async nature of node.js). without these sorts of modules, using node.js would be a lot less attractive (which is why they got written, obviously -> itch scratched!). so when looking at what makes it easy to get started, the web server modules (e.g. express) are only part of the story. (and of course, being able to easily share and include modules is a key part of why those modules exist in the first place ...) comparing with cowboy, the differences are glaring. for instance, in the "getting started" guide for cowboy: * we live in the microwave popcorn and 10-minutes-is-a-long-video-on-youtube age. yet the first FOUR sections are not about cowboy at all, but talking about the modern web and how to learn erlang. as someone moderately familiar with the web, i don't care about this. *just let me get started already!* if i'm reading the getting started guide for cowboy, i probably don't need to be sold on either the modern web OR erlang. * being a good, modern developer with the attention span of the average backyard squirrel i simply skipped straight to the "Getting Started" section. the FIRST sentence is this: "Setting up a working Erlang application is a little more complex than for most other languages. The reason is that Erlang is designed to build systems and not just simple applications." ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], and my application IS simple. so cowboy is not for me! right? * the rest of the "getting started" walks me through doing a ton of boilerplate stuff. it's nice to know how things work, but i'm a busy web dev (have i mentioned my lack of attention span yet? oh look, a peanut! and it's an event driven async peanut! yum! *runs off*). everything in that section ought to be boiled down to "run this one simple command and everything is done for you. click here to read about the gory details." and doing so should give me a fully functional application template that i can immediately start. that one command should probably take a simple config file with things like the app name and other variable details (such as which erlang apps to include in my awesome new project, including but also in addition to cowboy). basically, an npm-for-erlang. oh, and bonus points if there is a file created just for route definitions which would then be automatically included by the foo_app.erl to be passed to cowboy_router:compile. having a "well known" place to define routes will standardize cowboy using applications and allow the starting dev to focus on what they care about (routes and handlers) while ignoring the details like the app module. yes, yes, eventually they'll likely want to dig into that as well, but not at the beginning. (this is an area that cowboy+erlang could be even better than express+node.js) * i couldn't find the bragging section of the docs. ;) more seriously, the getting started guide tries to sell me on the modern web and erlang's place in it, but how about a fun little one-pager that backs up the claims made in the main README: "Cowboy is a small, fast and modular HTTP server written in Erlang." and " It is optimized for low latency and low memory usage". show me the money^Hmeasurements! a simple set of charts showing how many simultaneous connections can be handled and what kind of latencies app the developers achieve on regular ol' hardware, along with a LOC-you-need-to-write-for-a- barebones-app count would help convince people and would be the thing that would get passed around on stackoverflow, g+, twitter, etc. when justifying / recommending cowboy. [1] really, i personally don't care; but i'm channeling the spirit of the average web dev here :) > Performance is not a primary concern - easy of programming and correctness > are. this is a fundamental weakness with node.js imho. it is definitely easy to get *started* with a node.js based project, but keeping it sane takes discipline. which means most applications likely become horrible little monsters given enough time. i am convinced that it is unpossible (similar to, but not the same, as impossible ;) to write and maintain a large, reliable node.js application without *extensive* unit tests which are run continuously during development (not just integration). as the order of blocks in the source code does not correlate with the actual execution order, and that execution order will vary at runtime due to fluctuations in the surrounding aether (read: database and network latency), it is very difficult to write code that can be easily debugged simply by reading it or naively instrumenting it with debug statements. (yes, this is not how to maintain a code base, but it's how many devs actually work.) the answer is LOTS of unit tests, including for cases one normally wouldn't test for in other languages / frameworks (unless being paid by the test unit ;). it was also uncomfortably common (i.e. more times than zero) to see tests fail due to the peculiarities of node.js messing with the test framework, resulting in false negatives that often take a fair amount of time to identify and then instrument around. yep: a testing run may not behave sufficiently similar to the production run, which kind of erodes the value of having tests .... thankfully node has lovely tools like mocha and istanbul to drive unit tests and generate coverage reports relatively quickly, making the may-as- well-be-enforced TDD manageable. combine this with a language that requires defensive programming (resulting in more paths to test, obviously) and the ugliness becomes evident. even though it is a scripted environment, getting a node.js app to spew errors everywhere or even crash outright is far too easy without extensive defensive programming. so it is pretty much expected that your node.js app will at some point fall over and die. which is why there are tools like forever and node modules offering integration with systemd so provide supervision. only if node.js had such concepts built in, how wonderful would that be? wish i knew of such a language ;) if erlang can learn something from node it might be the value of loudly, clearly and enthusiastically telling the world what it is REALLY DAMN GOOD at. people will forgive warts and annoyances if they understand the thing they *want* about a given framework. people think 25k connections on a multi-core system is mindblowing; that multi-process / threading *must* be hard (enough to avoid if you can, anyways); that one simple frameworks are going to be good at i/o or cpu bound tasks, but rarely both (to get both you get to use a complex language+framework) ... erlang addresses exactly those issues, and as such has an amazing story for the needs of modern network services (among other use cases). there are some truly amazing things written in erlang (something that i don't think enough people are aware of, btw) that would help in emphasizing that story .... i had erlang on my "list of things to investigate" for a while, and when i finally got around to it i found it to be a minor revelation in terms of design and capabilities. not perfect, but closer to perfect than most of the alternatives i've used. i really should not have had to investigate to find that out, though: i ought to have been driven to erlang because that set of revelations was widely distributed in easy-to-digest form (and without a bunch of warnings about how string manip sucks, or how erlang runtimes are complex to set up, or ...) [1] https://github.com/caolan/async [2] http://www.sebastianseilund.com/nodejs-async-in-practice -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aschultz@REDACTED Wed Jun 18 10:56:48 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 18 Jun 2014 08:56:48 +0000 (UTC) Subject: [erlang-questions] Generating a certificate from a CSR with public_key In-Reply-To: References: Message-ID: <680061701.35040.1403081808511.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hi there, > > I'm trying to work out how I can generate and sign a certificate from a > certificate signing request (CSR) using pure Erlang. It doesn't look as if > the public_key application has support for this. > > Does anyone have pointers for doing this? (I know how to do this with > openssl). There is not one-stop support for it, but it should be doable. lib/public_key/test/erl_make_certs.erl has code that generates certificates. You would have to parse the CSR (lib/public_key/src/pubkey_pem.erl seems to have support for it) and construct the newly signed certificate with the code from erl_make_certs. Andreas > > Thanks, > > Rudolph > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz From essen@REDACTED Wed Jun 18 11:02:13 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Jun 2014 11:02:13 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <1831314.qTF9aCn5q6@freedom> References: <1831314.qTF9aCn5q6@freedom> Message-ID: <53A15595.2090000@ninenines.eu> Okay I wanted to skip this thread entirely but you mentioned Cowboy and said weird things about it so I'll bite. On 06/18/2014 09:39 AM, Aaron J. Seigo wrote: > comparing with cowboy, the differences are glaring. for instance, in the > "getting started" guide for cowboy: > > * we live in the microwave popcorn and 10-minutes-is-a-long-video-on-youtube > age. yet the first FOUR sections are not about cowboy at all, but talking about > the modern web and how to learn erlang. as someone moderately familiar with > the web, i don't care about this. *just let me get started already!* if i'm > reading the getting started guide for cowboy, i probably don't need to be sold > on either the modern web OR erlang. I'm not sure why you call it a "getting started guide" all over your email. It's the user guide. It may have one "getting started" chapter, but its goal is not to get people started, but to be a complete guide. This includes not only practical examples but also theory. Why theory? Well everyone coming to Cowboy isn't a web developer, or even an Erlang developer. Some of my users were happy enough that these chapters were in the guide that they contacted me directly to tell me they liked them. If you are a web developer, then why are you reading these chapters? Do you read the documentation for every computer you buy? Do you need to learn how to put the power plug in to charge it? You probably don't need that. But some people do, and that's why we put these "obvious" things in the docs. > * being a good, modern developer with the attention span of the average > backyard squirrel i simply skipped straight to the "Getting Started" section. > the FIRST sentence is this: > > "Setting up a working Erlang application is a little more complex than for > most other languages. The reason is that Erlang is designed to build systems > and not just simple applications." > > ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], and my > application IS simple. so cowboy is not for me! right? Well there's nothing we can do about that. We can't just write one file and run a program on it. That's simply not how Erlang works. We have to create an OTP application, compile, start the VM with the right paths etc. That's not just Cowboy deciding to be more complex than nodejs, that's how Erlang was designed. And while it's improving (you should have seen things 4 years ago when I started, the getting started in Cowboy is *immensely* simpler than it would have been then), it'll never be as simple as nodejs. Because most of the stuff in the getting started chapter is necessary as I'll explain in a bit. > * the rest of the "getting started" walks me through doing a ton of > boilerplate stuff. it's nice to know how things work, but i'm a busy web dev > (have i mentioned my lack of attention span yet? oh look, a peanut! and it's > an event driven async peanut! yum! *runs off*). everything in that section > ought to be boiled down to "run this one simple command and everything is done > for you. click here to read about the gory details." and doing so should give > me a fully functional application template that i can immediately start. that > one command should probably take a simple config file with things like the app > name and other variable details (such as which erlang apps to include in my > awesome new project, including but also in addition to cowboy). basically, an > npm-for-erlang. The next erlang.mk version will make it a little easier by generating a base project (using templates, as you say). But that will not change the getting started chapter much, as we will still have to explain things. Instead of saying "create" it will say "edit", basically. It may sound like a lot for someone with as little attention span as you, but going through these steps saves you an immense amount of time later on. If Erlang beginners start using releases immediately, we win. They will not have to suffer going through hoops like we did to get to that point. They will not have to fiddle with paths, or make start scripts, or deal with complex deployment issues, or anything that we struggled with for years. It *is* a big step, and we probably can't reduce it much more, but it's an incredible time saver. But of course impatient people will prefer to waste their time by missing out on it. And to be honest if we weren't doing this then we would have to explain how to write a start function, start erl with the -s option and make a start script for frequent use. It wouldn't be simpler, it would just be different, and we would just miss an opportunity to teach beginners "the right way" from the start. > oh, and bonus points if there is a file created just for route definitions which > would then be automatically included by the foo_app.erl to be passed to > cowboy_router:compile. having a "well known" place to define routes will > standardize cowboy using applications and allow the starting dev to focus on > what they care about (routes and handlers) while ignoring the details like the > app module. yes, yes, eventually they'll likely want to dig into that as well, > but not at the beginning. (this is an area that cowboy+erlang could be even > better than express+node.js) Cowboy isn't a Web framework. There's nothing to standardize. It's a thin HTTP layer implementing the various HTTP specs. That's it. Yes, routing is also part of the spec, as it is a way to map URIs to resources which is well covered by the spec. There's tons of Web frameworks built on top of Cowboy if you want standards. Everything in Cowboy is done by calling a function (or Cowboy calling one of your functions). The application module is simply the only place where you can run code at startup, so we have to cover it. Besides I don't see much difference between explaining how to run code in this module vs explaining the structure of a configuration file (it's harder to do the latter really). > * i couldn't find the bragging section of the docs. ;) more seriously, the > getting started guide tries to sell me on the modern web and erlang's place in > it, but how about a fun little one-pager that backs up the claims made in the > main README: "Cowboy is a small, fast and modular HTTP server written in > Erlang." and " It is optimized for low latency and low memory usage". show me > the money^Hmeasurements! a simple set of charts showing how many simultaneous > connections can be handled and what kind of latencies app the developers > achieve on regular ol' hardware, along with a LOC-you-need-to-write-for-a- > barebones-app count would help convince people and would be the thing that > would get passed around on stackoverflow, g+, twitter, etc. when justifying / > recommending cowboy. Would you believe me if I told you Cowboy is capable of handling millions of concurrent Websocket connections on a middle sized server, with *no impact* on latency? And would you believe me if I told you I do not have the slightest idea what the upper limit for the number of connections Cowboy can actually handle *is*? Because that's the truth. This is in large part due to Erlang, Cowboy mostly tries to be careful about memory use, and could do a better job at it. But still, how do you even brag about a difference that big with other platforms, and make people actually believe you? Besides, if you look at the benchmark of the week, they're still all focused on glorified "hello world" measuring requests per second. Cowboy obviously can't compete there, as these are won by JITs not by the underlaying code. Not to mention these benchmarks are the most misleading and useless kind you can ever write. -- Lo?c Hoguin http://ninenines.eu From kunthar@REDACTED Wed Jun 18 11:38:09 2014 From: kunthar@REDACTED (Gokhan Boranalp) Date: Wed, 18 Jun 2014 12:38:09 +0300 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A15595.2090000@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: On Wed, Jun 18, 2014 at 12:02 PM, Lo?c Hoguin wrote: > Okay I wanted to skip this thread entirely but you mentioned Cowboy and > said weird things about it so I'll bite. > > > On 06/18/2014 09:39 AM, Aaron J. Seigo wrote: > >> comparing with cowboy, the differences are glaring. for instance, in the >> "getting started" guide for cowboy: >> > > > >> * we live in the microwave popcorn and 10-minutes-is-a-long-video-on- >> youtube >> age. yet the first FOUR sections are not about cowboy at all, but talking >> about >> the modern web and how to learn erlang. as someone moderately familiar >> with >> the web, i don't care about this. *just let me get started already!* if >> i'm >> reading the getting started guide for cowboy, i probably don't need to be >> sold >> on either the modern web OR erlang. >> > > I'm not sure why you call it a "getting started guide" all over your > email. It's the user guide. It may have one "getting started" chapter, but > its goal is not to get people started, but to be a complete guide. This > includes not only practical examples but also theory. Why theory? Well > everyone coming to Cowboy isn't a web developer, or even an Erlang > developer. Some of my users were happy enough that these chapters were in > the guide that they contacted me directly to tell me they liked them. > > If you are a web developer, then why are you reading these chapters? Do > you read the documentation for every computer you buy? Do you need to learn > how to put the power plug in to charge it? You probably don't need that. > But some people do, and that's why we put these "obvious" things in the > docs. > > > * being a good, modern developer with the attention span of the average >> backyard squirrel i simply skipped straight to the "Getting Started" >> section. >> the FIRST sentence is this: >> >> "Setting up a working Erlang application is a little more complex than for >> most other languages. The reason is that Erlang is designed to build >> systems >> and not just simple applications." >> >> ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], >> and my >> application IS simple. so cowboy is not for me! right? >> > > Well there's nothing we can do about that. We can't just write one file > and run a program on it. That's simply not how Erlang works. We have to > create an OTP application, compile, start the VM with the right paths etc. > That's not just Cowboy deciding to be more complex than nodejs, that's how > Erlang was designed. > > And while it's improving (you should have seen things 4 years ago when I > started, the getting started in Cowboy is *immensely* simpler than it would > have been then), it'll never be as simple as nodejs. Because most of the > stuff in the getting started chapter is necessary as I'll explain in a bit. > > > * the rest of the "getting started" walks me through doing a ton of >> boilerplate stuff. it's nice to know how things work, but i'm a busy web >> dev >> (have i mentioned my lack of attention span yet? oh look, a peanut! and >> it's >> an event driven async peanut! yum! *runs off*). everything in that section >> ought to be boiled down to "run this one simple command and everything is >> done >> for you. click here to read about the gory details." and doing so should >> give >> me a fully functional application template that i can immediately start. >> that >> one command should probably take a simple config file with things like >> the app >> name and other variable details (such as which erlang apps to include in >> my >> awesome new project, including but also in addition to cowboy). >> basically, an >> npm-for-erlang. >> > > The next erlang.mk version will make it a little easier by generating a > base project (using templates, as you say). But that will not change the > getting started chapter much, as we will still have to explain things. > Instead of saying "create" it will say "edit", basically. > > It may sound like a lot for someone with as little attention span as you, > but going through these steps saves you an immense amount of time later on. > If Erlang beginners start using releases immediately, we win. They will not > have to suffer going through hoops like we did to get to that point. They > will not have to fiddle with paths, or make start scripts, or deal with > complex deployment issues, or anything that we struggled with for years. It > *is* a big step, and we probably can't reduce it much more, but it's an > incredible time saver. > > But of course impatient people will prefer to waste their time by missing > out on it. > > And to be honest if we weren't doing this then we would have to explain > how to write a start function, start erl with the -s option and make a > start script for frequent use. It wouldn't be simpler, it would just be > different, and we would just miss an opportunity to teach beginners "the > right way" from the start. > > > oh, and bonus points if there is a file created just for route >> definitions which >> would then be automatically included by the foo_app.erl to be passed to >> cowboy_router:compile. having a "well known" place to define routes will >> standardize cowboy using applications and allow the starting dev to focus >> on >> what they care about (routes and handlers) while ignoring the details >> like the >> app module. yes, yes, eventually they'll likely want to dig into that as >> well, >> but not at the beginning. (this is an area that cowboy+erlang could be >> even >> better than express+node.js) >> > > Cowboy isn't a Web framework. There's nothing to standardize. It's a thin > HTTP layer implementing the various HTTP specs. That's it. Yes, routing is > also part of the spec, as it is a way to map URIs to resources which is > well covered by the spec. > > There's tons of Web frameworks built on top of Cowboy if you want > standards. Everything in Cowboy is done by calling a function (or Cowboy > calling one of your functions). The application module is simply the only > place where you can run code at startup, so we have to cover it. Besides I > don't see much difference between explaining how to run code in this module > vs explaining the structure of a configuration file (it's harder to do the > latter really). > > > * i couldn't find the bragging section of the docs. ;) more seriously, the >> getting started guide tries to sell me on the modern web and erlang's >> place in >> it, but how about a fun little one-pager that backs up the claims made in >> the >> main README: "Cowboy is a small, fast and modular HTTP server written in >> Erlang." and " It is optimized for low latency and low memory usage". >> show me >> the money^Hmeasurements! a simple set of charts showing how many >> simultaneous >> connections can be handled and what kind of latencies app the developers >> achieve on regular ol' hardware, along with a LOC-you-need-to-write-for-a- >> barebones-app count would help convince people and would be the thing that >> would get passed around on stackoverflow, g+, twitter, etc. when >> justifying / >> recommending cowboy. >> > > Would you believe me if I told you Cowboy is capable of handling millions > of concurrent Websocket connections on a middle sized server, with *no > impact* on latency? And would you believe me if I told you I do not have > the slightest idea what the upper limit for the number of connections > Cowboy can actually handle *is*? Because that's the truth. > > This is in large part due to Erlang, Cowboy mostly tries to be careful > about memory use, and could do a better job at it. > > But still, how do you even brag about a difference that big with other > platforms, and make people actually believe you? > > Besides, if you look at the benchmark of the week, they're still all > focused on glorified "hello world" measuring requests per second. Cowboy > obviously can't compete there, as these are won by JITs not by the > underlaying code. Not to mention these benchmarks are the most misleading > and useless kind you can ever write. > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- BR, \|/ Kunthar -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseigo@REDACTED Wed Jun 18 12:10:49 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Wed, 18 Jun 2014 12:10:49 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A15595.2090000@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: <2279746.6nRx3fUCjJ@freedom> On Wednesday, June 18, 2014 11:02:13 Lo?c Hoguin wrote: > Okay I wanted to skip this thread entirely but you mentioned Cowboy and > said weird things about it so I'll bite. s,weird,typical first impression, the two can often feel the same from the developer's perspective ;) btw, i'm quite impressed with cowboy. i think it is extremely nifty _and_ highly useful, two things one doesn't always get in one package .... > On 06/18/2014 09:39 AM, Aaron J. Seigo wrote: > > comparing with cowboy, the differences are glaring. for instance, in the > > "getting started" guide for cowboy: > > > > * we live in the microwave popcorn and > > 10-minutes-is-a-long-video-on-youtube age. yet the first FOUR sections > > are not about cowboy at all, but talking about the modern web and how to > > learn erlang. as someone moderately familiar with the web, i don't care > > about this. *just let me get started already!* if i'm reading the getting > > started guide for cowboy, i probably don't need to be sold on either the > > modern web OR erlang. > > I'm not sure why you call it a "getting started guide" all over your > email. It's the user guide. a) Go to https://github.com/extend/cowboy b) scroll down to "Getting Started" c) first link: Read the Guide you are (obviously) correct that it is the user guide. but it is presented to the (naive) first-time visitor as "Getting Started -> Guide" and it indeed starts with an Introduction part and has a "Getting Started" chapter. in lieu of an "actual" getting started guide, the user guide *is* what i used to get started. ergo, it is the de facto getting started guide. > It may have one "getting started" chapter, > but its goal is not to get people started, but to be a complete guide. understood :) > This includes not only practical examples but also theory. Why theory? .. > that. But some people do, and that's why we put these "obvious" things > in the docs. i'm not trying to tell you that what you've done is empirically wrong, but how non-optimal results may come from what is there right now in the way it is presented. whether you choose to pick anything useful from that is obviously up to you :) specifically, i'd suggest that a more streamlined "getting started" guide that gets straight to the "your first cowboy server in one command" story would be valuable. it is something that the (quite nice) user guide does not provide, and which is something most people i know who are in the process of casually evaluating new frameworks are really helped by. > > * being a good, modern developer with the attention span of the average > > backyard squirrel i simply skipped straight to the "Getting Started" > > section. the FIRST sentence is this: > > > > "Setting up a working Erlang application is a little more complex than for > > most other languages. The reason is that Erlang is designed to build > > systems and not just simple applications." > > > > ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], and > > my application IS simple. so cowboy is not for me! right? > > Well there's nothing we can do about that. We can't just write one file > and run a program on it. That's simply not how Erlang works. We have to > create an OTP application, compile, start the VM with the right paths > etc. That's not just Cowboy deciding to be more complex than nodejs, > that's how Erlang was designed. i completely understand. however, you don't need to confront the potential adopter with that rather scary proclamation as the *very first sentence*. how do you *know* that everyone who reads that section will think "damn, THAT was super complicated!" honestly, that's not the impression i would have come away with myself ... but you *told* me it was complicated before i even got to decide. show, don't tell. :) now, as for "you can't just have one file" that's obvious true. but you *can* have a helper app that creates the file structure and basic files described in the (very clear!) step-by-step "getting started" section. i know because i have written and used exactly such tools many times in the past which generate significantly more complex boilerplate. > And while it's improving (you should have seen things 4 years ago when I > started, the getting started in Cowboy is *immensely* simpler than it > would have been then), it shows -> cowboy is very nice ... > it'll never be as simple as nodejs. it doesn't have to be. "make everything as simple as possible, but no simpler," so said Einstein. dude was right. :) setting up a first "make me a toy demo app" with cowboy is not as simple as it could be. it does not need to be as simple as nodejs, but that particular step can be a lot simpler than it currently is. > The next erlang.mk version will make it a little easier by generating a > base project (using templates, as you say). But that will not change the that will already be a very nice improvement! :) > getting started chapter much, as we will still have to explain things. > Instead of saying "create" it will say "edit", basically. not really ... the getting started page can be condensed a LOT by skipping over details until the user has started the dummy app for the first time. THEN it can start saying "now edit this file..." the reward (seeing a running cowboy app) is delayed; move that up a bit and then after that first hit of success start laying in the details. > It may sound like a lot for someone with as little attention span as > you, but going through these steps saves you an immense amount of time > later on. that assumes there IS a "later on". if you lose me in the first page of documentation, then there will be no later on. to catch the squirrels out there, you need to convince them to stay so there is a "later on". you can do that by giving me something that works immediately with as little effort, and explanation, as possible. if i can point my web browser to localhost:8080 after 30s and have a "hello, partner!" message appear i am much, much more likely to stick around for the explanations of how that just happened. this is *exactly* what nodejs and other popular frameworks do. they are not as simple as they first look either. their little copy-n-paste toys are just a way to give the new comer a glimpse of possibility and give them a first success ... all the learning lay ahead, and people are willing to put in that effort once they've decided it's "easy enough". people are funny that way :) > If Erlang beginners start using releases immediately, we win. > They will not have to suffer going through hoops like we did to get to > that point. They will not have to fiddle with paths, or make start > scripts, or deal with complex deployment issues, or anything that we > struggled with for years. It *is* a big step, and we probably can't > reduce it much more, but it's an incredible time saver. amen. > And to be honest if we weren't doing this then we would have to explain > how to write a start function, start erl with the -s option and make a > start script for frequent use. It wouldn't be simpler, it would just be > different, and we would just miss an opportunity to teach beginners "the > right way" from the start. the first job is not to teach someone the right way. the first job is to convince the person considering using the technology that they want to invest the time and effort to learn the right way. more people will do that once they've agreed that it is within their reach. one way to do that is to provide a quick and easy "win" with as few steps as possible. then once they've gotten to a first quick success, dirty and ignorant of the details, start them through the process of explaining how everything works and why. > > oh, and bonus points if there is a file created just for route definitions > > which would then be automatically included by the foo_app.erl to be > > passed to cowboy_router:compile. having a "well known" place to define > > routes will standardize cowboy using applications and allow the starting > > dev to focus on what they care about (routes and handlers) while ignoring > > the details like the app module. yes, yes, eventually they'll likely want > > to dig into that as well, but not at the beginning. (this is an area that > > cowboy+erlang could be even better than express+node.js) > > Cowboy isn't a Web framework. There's nothing to standardize. It's a > thin HTTP layer implementing the various HTTP specs. That's it. Yes, > routing is also part of the spec, as it is a way to map URIs to > resources which is well covered by the spec. i evidently skipped a step in my mental process here.. let me back up and try again ... when i followed the cowboy user guide's "getting started" section, my first thought was "where should i put another route? should i just plonk it in hello_erlang_app:start/2, or is it cleaner to put it somewhere else ...?" that matters because every. single. question. a person evaluating a new technology has while getting started is a barrier. it signals to them that this is difficult and requires lots of decision making. yet, if there was a nice little "routes.hrl" (or whatever) and the read was directed to add new routes there, it removes that question entirely. i could get to adding a second route to play with the toy app and see if i actually do understand the idea of handlers without having to look into hello_erlange_app.erl at all. streamline. so i'm not suggesting cowboy should be a complete web framework, but that it should present what it already presents in a way that is more structured and therefore more approachable to the average new-comer. because that is who will be reading / using that part of the documentation :) > There's tons of Web frameworks built on top of Cowboy if you want > standards. Everything in Cowboy is done by calling a function (or Cowboy > calling one of your functions). The application module is simply the > only place where you can run code at startup, so we have to cover it. > Besides I don't see much difference between explaining how to run code > in this module vs explaining the structure of a configuration file (it's > harder to do the latter really). the difference is that the example does this: Dispatch = cowboy_router:compile([ %% {URIHost, list({URIPath, Handler, Opts})} {'_', [{'_', hello_handler, []}]} ]) ok, there's the hello_handler route. awesome. now... if i want to add a second one, should i modify it in-place right there? should i create a list of routes elsewhere and pass that in, for readablity's sake? as a new comer, i wouldn't be ready to make those decisions and that means uncertainty because i'm being asked to make a decision i'm not ready to. so answer it for them. given them a .hrl file with sth like: routes = [ {'_', [{'_', hello_handler, []}]} ]. one could even provide a bunch of different sample routes with some in-line documentation describing what they do. it could be used in the very nicely written Routing section without having the "noise" of the rest of the hello_erlang_app.erl to step around. yes, many (most) people really struggle with learning that much. for people who pick things up quickly, that seems very alien, but it's just how it is. there is no changing everyone else ;) > > * i couldn't find the bragging section of the docs. ;) more seriously, the > > getting started guide tries to sell me on the modern web and erlang's > > place in it, but how about a fun little one-pager that backs up the > > claims made in the main README: "Cowboy is a small, fast and modular HTTP > > server written in Erlang." and " It is optimized for low latency and low > > memory usage". show me the money^Hmeasurements! a simple set of charts > > showing how many simultaneous connections can be handled and what kind of > > latencies app the developers achieve on regular ol' hardware, along with > > a LOC-you-need-to-write-for-a- barebones-app count would help convince > > people and would be the thing that would get passed around on > > stackoverflow, g+, twitter, etc. when justifying / recommending cowboy. > > Would you believe me if I told you Cowboy is capable of handling > millions of concurrent Websocket connections on a middle sized server, > with *no impact* on latency? And would you believe me if I told you I do > not have the slightest idea what the upper limit for the number of > connections Cowboy can actually handle *is*? Because that's the truth. yes, i would believe you :) > But still, how do you even brag about a difference that big with other > platforms, and make people actually believe you? numbers. in graphs. no, seriously, it's just that simple. let me give you a fun example: http://hyperdex.org/performance/ (was sent that the other day by a "helpful" friend ...) there is really no useful context offered and very little way to validate the findings other than the links buried in the bottom "Discussion and Insights" footnote. here's another (rather less suspect to me) example: http://haproxy.1wt.eu/10g.html that is not a scientific result, in the sense that it does not provide a reproducable test, but it provides numbers from the developer (who is obviously invested and therefore biased) and people accept these numbers as guidelines for setting expectations. and they link to these pages endlessly. and regurgitate them in their postings on reddit and stackoverflow. and, heaven forbid, slashdot ;) in the case of the cowboy, i don't think you'd need to compare #s with other frameworks. simply show some numbers of real-world tests you (or your minions :) have done that demonstrate performance. just show the true capabilities of cowboy/erlang clearly as in the above two examples and people will accept it. they do so every day for other projects / products. > Besides, if you look at the benchmark of the week, they're still all > focused on glorified "hello world" measuring requests per second. Cowboy > obviously can't compete there, as these are won by JITs not by the > underlaying code. Not to mention these benchmarks are the most > misleading and useless kind you can ever write. so benchmark what matters to you. people who care about those things will respond positively, and those who don't might start realizing that they ought to care about those things ;) hell, write a paragraph about how you aren't benchmarking synthetic "hello world" performance because that only measures the benefit of having a JIT based system rather than the real world performance of a system (JIT or not) and include that on your page of numbers. :) -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ulf@REDACTED Wed Jun 18 12:22:21 2014 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 18 Jun 2014 12:22:21 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <000101cf8ab9$0c7809d0$25681d70$@frcuba.co.cu> References: <000101cf8ab9$0c7809d0$25681d70$@frcuba.co.cu> Message-ID: <62D53867-5094-47C4-9208-045E90D7E73E@feuerlabs.com> On 18 Jun 2014, at 07:49, Ivan Carmenates Garc?a wrote: > Yes Paulo, I definely think that it is what nodejs is about, it is very nice to prototyping things because of the code, easily to understand and program; a different way of thinking (no so nice like Erlang but.. still..), but noting seriously such as what you can do with Erlang you can build with nodejs I think. An interesting exercise might be to map https://github.com/uwiger/pots, specifically the lim_asynch.erl API, to e.g. websockets, and try to program the POTS subscriber loop in node.js. The challenges of the exercise are outlined in this presentation: http://www.infoq.com/presentations/Death-by-Accidental-Complexity I know that there are techniques developed in node.js to deal with the sort of issues that arise. The problem is illustrating to people when they are needed, and just how bad it can get without them. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adb23@REDACTED Wed Jun 18 12:07:34 2014 From: adb23@REDACTED (Adam Barwell) Date: Wed, 18 Jun 2014 11:07:34 +0100 Subject: [erlang-questions] [ANN] Skel Message-ID: <554930F55FC34BA69C906A420A598CBD@st-andrews.ac.uk> Dear all, We are happy to present Skel, an abstract skeleton library for Erlang to assist with parallelisation. Code, documentation, and a tutorial may be found at: skel.weebly.com Whilst Erlang makes the introduction of concurrency simple, manually manipulating processes remains a headache. Skel hides these details, providing a number of patterns, or skeletons, that are invoked using one of two functions. These skeletons are designed to be easily manipulated, and are nestable, allowing their use in a variety of contexts. Through its skeletons, Skel allows the simple and safe introduction of parallelism, not just the concurrency built into Erlang. More information may be found at the above link; we hope you find it useful. Skel is currently in development, so comments and suggestions for improvement are very welcome. -- Adam D. Barwell From essen@REDACTED Wed Jun 18 13:28:26 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Jun 2014 13:28:26 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <2279746.6nRx3fUCjJ@freedom> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <2279746.6nRx3fUCjJ@freedom> Message-ID: <53A177DA.5070906@ninenines.eu> On 06/18/2014 12:10 PM, Aaron J. Seigo wrote: > a) Go to https://github.com/extend/cowboy > b) scroll down to "Getting Started" > c) first link: Read the Guide > > you are (obviously) correct that it is the user guide. but it is presented to > the (naive) first-time visitor as "Getting Started -> Guide" and it indeed > starts with an Introduction part and has a "Getting Started" chapter. > > in lieu of an "actual" getting started guide, the user guide *is* what i used > to get started. ergo, it is the de facto getting started guide. That's stretching it. All the documentation and examples are in that section of the readme. It's not particularly ordered either, some people prefer starting with examples, others a reference, yet others a guide. And in those people will need one or another element of information. > i'm not trying to tell you that what you've done is empirically wrong, but how > non-optimal results may come from what is there right now in the way it is > presented. whether you choose to pick anything useful from that is obviously > up to you :) > > specifically, i'd suggest that a more streamlined "getting started" guide that > gets straight to the "your first cowboy server in one command" story would be > valuable. it is something that the (quite nice) user guide does not provide, > and which is something most people i know who are in the process of casually > evaluating new frameworks are really helped by. I don't really care about people who casually evaluate things. Why would I? I never did, and that never stopped Cowboy from getting new users. I care about my current users. All the work I do is for the sake of current users. Even the theory stuff was added at the demand of current, albeit beginner, users. All the work I do now is entirely based on feedback I receive. I'm not sure why people would use the getting started chapter to casually evaluate Cowboy though. There are a dozen or more prebuilt examples that can be ran with a single command. They range from hello world to Websocket to REST services. The getting started isn't there to replace them, it's there to get people who have decided to use Cowboy, well, started. > i completely understand. however, you don't need to confront the potential > adopter with that rather scary proclamation as the *very first sentence*. Maybe not. But it's easier to send a patch than tell completely unrelated people it's wrong to do that in a completely unrelated topic. > now, as for "you can't just have one file" that's obvious true. but you *can* > have a helper app that creates the file structure and basic files described in > the (very clear!) step-by-step "getting started" section. i know because i > have written and used exactly such tools many times in the past which generate > significantly more complex boilerplate. We'll still have to describe it though, so it makes little difference to the text, as I said before. It'll just save a couple keystrokes to the user. Which is obviously good, but not to die for. >> it'll never be as simple as nodejs. > > it doesn't have to be. "make everything as simple as possible, but no > simpler," so said Einstein. dude was right. :) setting up a first "make me a > toy demo app" with cowboy is not as simple as it could be. it does not need to > be as simple as nodejs, but that particular step can be a lot simpler than it > currently is. Then you should explain how. Send a patch showing how you think it should be done, for example. At least we'll know exactly what can be improved. >> getting started chapter much, as we will still have to explain things. >> Instead of saying "create" it will say "edit", basically. > > not really ... the getting started page can be condensed a LOT by skipping > over details until the user has started the dummy app for the first time. > > THEN it can start saying "now edit this file..." the reward (seeing a running > cowboy app) is delayed; move that up a bit and then after that first hit of > success start laying in the details. But you need to edit the file to get it working. I'm not sure what you're getting at there. > you can do that by giving me something that works immediately with as little > effort, and explanation, as possible. if i can point my web browser to > localhost:8080 after 30s and have a "hello, partner!" message appear i am > much, much more likely to stick around for the explanations of how that just > happened. That's what the examples are for. You can even copy paste an example and add your things directly if that's what you want. Many people start this way. But it doesn't fit everyone's way of learning things. You're taking a small part of the documentation like it's the only thing Cowboy has. It's not. Different people use different things to experiment or get started. I think we cover a pretty large part of the population with what Cowboy offers. >> And to be honest if we weren't doing this then we would have to explain >> how to write a start function, start erl with the -s option and make a >> start script for frequent use. It wouldn't be simpler, it would just be >> different, and we would just miss an opportunity to teach beginners "the >> right way" from the start. > > the first job is not to teach someone the right way. But teaching them the wrong way is more immediate work for them. And completely unrelated to actually learning Cowboy. I'm not sure what you're getting at there. > one way to do that is to provide a quick and easy "win" with as few steps as > possible. then once they've gotten to a first quick success, dirty and ignorant > of the details, start them through the process of explaining how everything > works and why. That's actually what the getting started is. It doesn't actually explain anything. It is just a step by step to making a Cowboy based application. I'm not sure where you see details in there. > when i followed the cowboy user guide's "getting started" section, my first > thought was "where should i put another route? should i just plonk it in > hello_erlang_app:start/2, or is it cleaner to put it somewhere else ...?" It tells you where to put them. At no point will you see the documentation, examples or even me saying to put the routes anywhere else. I'm not sure what made you want to put them in a different file, perhaps habit from using other things. The only thing I would ever do different compared to that is to make a function in that same module returning the routes, but then only if I'll ever need to update them live. And that'd be a very advanced subject that is not covered in the guide at this point. > so i'm not suggesting cowboy should be a complete web framework, but that it > should present what it already presents in a way that is more structured and > therefore more approachable to the average new-comer. because that is who will > be reading / using that part of the documentation :) I'm not sure how going from "everything is functions" to "everything is functions except these things that are configuration files" is going to help anyone. Keep it simple. > yes, many (most) people really struggle with learning that much. for people > who pick things up quickly, that seems very alien, but it's just how it is. > there is no changing everyone else ;) Perhaps, but then it's the first such feedback I get. And I have both smart and dumb users. (No offense! I'm definitely in the dumb category myself.) It sounds more and more that it's just unusual for you that there's no configuration file and it's all done using functions. Well that's not going to change anytime soon because that's kind of the point. > in the case of the cowboy, i don't think you'd need to compare #s with other > frameworks. simply show some numbers of real-world tests you (or your minions > :) have done that demonstrate performance. just show the true capabilities of > cowboy/erlang clearly as in the above two examples and people will accept it. > they do so every day for other projects / products. I could. But it takes a lot of time. And other things take precedence, like finishing the guide and such. If anyone wants to put numbers out for Erlang and Cowboy though, be my guest. It's not obvious anyone would care anyway. Whatsapp published a few times their peaks, having almost 3 million concurrent connections on one server using Erlang, and we didn't really see an influx of new Erlang users because of that. Most people don't play in that category. > so benchmark what matters to you. people who care about those things will > respond positively, and those who don't might start realizing that they ought > to care about those things ;) I don't really benchmark anymore. I just do when I want to make sure a change didn't kill performance. Benchmarks don't matter much to me. There's more important things to take care of before I go back to benchmarking. > hell, write a paragraph about how you aren't benchmarking synthetic "hello > world" performance because that only measures the benefit of having a JIT based > system rather than the real world performance of a system (JIT or not) and > include that on your page of numbers. :) I'm not sure how to write a benchmark that does not give an unfair advantage to a JIT based system. I'm not even sure how to write a good benchmark. They're a nice tool to have a general idea that what you did isn't worse than what you had before, but that's all they are. -- Lo?c Hoguin http://ninenines.eu From gleber.p@REDACTED Wed Jun 18 13:45:02 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 18 Jun 2014 13:45:02 +0200 Subject: [erlang-questions] [ANN] Skel In-Reply-To: <554930F55FC34BA69C906A420A598CBD@st-andrews.ac.uk> References: <554930F55FC34BA69C906A420A598CBD@st-andrews.ac.uk> Message-ID: That's a very nice library! Thanks for sharing! I love the image merger example in the tutorial :D http://chrisb.host.cs.st-andrews.ac.uk/skel-test-master/tutorial/bin/tutorial.html#example On Wed, Jun 18, 2014 at 12:07 PM, Adam Barwell wrote: > Dear all, > > We are happy to present Skel, an abstract skeleton library for Erlang to assist with parallelisation. Code, documentation, and a tutorial may be found at: > > skel.weebly.com > > Whilst Erlang makes the introduction of concurrency simple, manually manipulating processes remains a headache. Skel hides these details, providing a number of patterns, or skeletons, that are invoked using one of two functions. These skeletons are designed to be easily manipulated, and are nestable, allowing their use in a variety of contexts. Through its skeletons, Skel allows the simple and safe introduction of parallelism, not just the concurrency built into Erlang. > > More information may be found at the above link; we hope you find it useful. Skel is currently in development, so comments and suggestions for improvement are very welcome. > > -- > Adam D. Barwell > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From daniel.goertzen@REDACTED Wed Jun 18 16:57:57 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 18 Jun 2014 09:57:57 -0500 Subject: [erlang-questions] maps match specifications Message-ID: Maps match specifications are not working for me (see below). I know they were absent in the early maps branch, but I could not find anything saying they are absent from R17. I suspect they are just absent, but thought I would ask in case I've done something stupid or stumbled on a bug Thanks, Dan. 12> ets:fun2ms(fun({_,#{foo:=bar}}) -> true end). ** exception error: no function clause matching ms_transform:normalise({map,1,[{map_field_exact,1,{atom,1,foo},{atom,1,bar}}]}) (ms_transform.erl, line 1063) in function ms_transform:normalise_list/1 (ms_transform.erl, line 1091) in call from ms_transform:normalise_list/1 (ms_transform.erl, line 1091) in call from ms_transform:normalise/1 (ms_transform.erl, line 1081) in call from ms_transform:normalise_list/1 (ms_transform.erl, line 1091) in call from ms_transform:normalise/1 (ms_transform.erl, line 1081) in call from ms_transform:normalise/1 (ms_transform.erl, line 1079) in call from ms_transform:transform_from_shell/3 (ms_transform.erl, line 215) -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.facorro@REDACTED Wed Jun 18 21:20:52 2014 From: juan.facorro@REDACTED (=?UTF-8?B?SnVhbiBNYXJ0w61u?=) Date: Wed, 18 Jun 2014 16:20:52 -0300 Subject: [erlang-questions] [ANN] Lasse 0.1.0 Message-ID: Hello Erlangers! Inaka is happy to announce the release of *Lasse*, a library for implementing Cowboy[1] SSE (Server-Sent Events [2]) handlers. https://github.com/inaka/lasse/ SSE is a technology that allows a server to push events to a client using HTTP/1.1 chunked responses. The motivation behind this library is we noticed these type of handlers have a lot in common with each other in terms of their implementation and the type of messages they process. All the details related to establishing a connection and generating events is included in the library, so that the module that implements the *lasse_handler* behavior has to only be concerned with the logic and contents of the events sent. There's currently a single toy example under the *examples* folder: a handler that broadcasts a "pong" to all clients when it receives a *ping* message. *All feedback is extremely welcome. * This is my first library in Erlang, please be kind! Thanks, Juan Facorro juan.facorro@REDACTED [1]: https://github.com/extend/cowboy [2]: http://dev.w3.org/html5/eventsource/ -- Juan Facorro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciprian.craciun@REDACTED Wed Jun 18 21:37:12 2014 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Wed, 18 Jun 2014 22:37:12 +0300 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: On Tue, Jun 17, 2014 at 3:41 PM, Joe Armstrong wrote: > It's actually the programming models I want to compare and not the > performance - what worries me about node is the run-to-completion > semantics of event callbacks - namely that a long-running event will block > the server preventing short computations from being performed. The > short jobs which could be done immediately have to wait until the long jobs > have finished - this should reflect in the average latencies of a request. > > I made a little experiment (a fibonacci server in erlang and node) and fired > off > 1000 parallel requests to compute fib(N) with N a random number from 10..40. > > As I suspected many of the fib(10) events are blocked by ongoing computation > of > fib(40) - this reflect in the latencies. I'm not if someone suggested this before, you Joe hinted at it, but if you need to do a lengthy computational job in pure NodeJS (thus no background threads / processes / other magic), you could use the `process.nextTick` and manually implement "reductions" like the BEAM interpreter does. http://nodejs.org/api/process.html#process_process_nexttick_callback For example (completely untested code, and probably with "off-by-one bugs"): ~~~~ var fibReductions = 10; function fib (n, onCompletion) { fibRec (2, 1, 1, n, fibReductions, onCompletion); } function fibRec (i, s1, s2, n, reductions, onCompletion) { if (i >= n) { // see notes below why we use `process.nextTick` even here! process.nextTick (function () { onCompletion (s2); }); return; } if (reductions > 0) fibRec (i + 1, s2, s1 + s2, n, reductions - 1, onCompletion); else process.nextTick (function () { fibRec (i + 1, s2, s1 + s2, n, fibReductions, onCompletion); }); } ~~~~ Indeed I cheated by applying the tail-recursive technique to my function, which eases the implementation of the reduction technique, else my code would have been more convoluted than this. But I hope this proves the point that if needed NodeJS could be used even in these cases. Ciprian. P.S.: I chose to always call `process.nextTick (function () { callback (outcome); })` even if the result is immediate, because me as a developer expect that a callback is always called after I exit from my function, like in the example below: ~~~~ function doSomeStuff () { var someClosure = {}; initiateAction (function (outcome) { doSomethingElse (someClosure.expectedValue, outcome); }); someClosure.expectedValue = ...; ... } ~~~~ From raould@REDACTED Wed Jun 18 22:14:54 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 18 Jun 2014 13:14:54 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: Message-ID: [how did this thread get onto multiple erlang lists? :-] > But I hope this proves the point that if needed NodeJS could be > used even in these cases. personally, i hope this proves the point that nodejs sucks. ;-) From kenneth.lundin@REDACTED Wed Jun 18 22:22:42 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 18 Jun 2014 22:22:42 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A15595.2090000@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: On Wed, Jun 18, 2014 at 11:02 AM, Lo?c Hoguin wrote: > Okay I wanted to skip this thread entirely but you mentioned Cowboy and > said weird things about it so I'll bite. > "Setting up a working Erlang application is a little more complex than for > >> most other languages. The reason is that Erlang is designed to build >> systems >> and not just simple applications." >> >> ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], >> and my >> application IS simple. so cowboy is not for me! right? >> > > Well there's nothing we can do about that. We can't just write one file > and run a program on it. That's simply not how Erlang works. We have to > create an OTP application, compile, start the VM with the right paths etc. > That's not just Cowboy deciding to be more complex than nodejs, that's how > Erlang was designed. > If this is written in the Cowboy User Guide I think it is a bit unfortunate. I don't agree that it need to be more complex to set up a working Erlang application than it is in many other languages. Maybe it is true in the way you have choosen but for sure there are more simplistic ways also. And in other languages it is also more complicated if you need a serious server with logging, possibility to upgrade etc. I can come up with many non complex approaches. Whats wrong with erl -run ..... and having the module(s) in the current path? I mean that if you have a more complex set up with Erlang maybe you also get features that you don't get with a simple setup in another language? > And while it's improving (you should have seen things 4 years ago when I > started, the getting started in Cowboy is *immensely* simpler than it would > have been then), it'll never be as simple as nodejs. Because most of the > stuff in the getting started chapter is necessary as I'll explain in a bit. > > > * the rest of the "getting started" walks me through doing a ton of >> boilerplate stuff. it's nice to know how things work, but i'm a busy web >> dev >> (have i mentioned my lack of attention span yet? oh look, a peanut! and >> it's >> an event driven async peanut! yum! *runs off*). everything in that section >> ought to be boiled down to "run this one simple command and everything is >> done >> for you. click here to read about the gory details." and doing so should >> give >> me a fully functional application template that i can immediately start. >> that >> one command should probably take a simple config file with things like >> the app >> name and other variable details (such as which erlang apps to include in >> my >> awesome new project, including but also in addition to cowboy). >> basically, an >> npm-for-erlang. >> > > The next erlang.mk version will make it a little easier by generating a > base project (using templates, as you say). But that will not change the > getting started chapter much, as we will still have to explain things. > Instead of saying "create" it will say "edit", basically. > > It may sound like a lot for someone with as little attention span as you, > but going through these steps saves you an immense amount of time later on. > If Erlang beginners start using releases immediately, we win. They will not > have to suffer going through hoops like we did to get to that point. They > will not have to fiddle with paths, or make start scripts, or deal with > complex deployment issues, or anything that we struggled with for years. It > *is* a big step, and we probably can't reduce it much more, but it's an > incredible time saver. > > But of course impatient people will prefer to waste their time by missing > out on it. > > And to be honest if we weren't doing this then we would have to explain > how to write a start function, start erl with the -s option and make a > start script for frequent use. It wouldn't be simpler, it would just be > different, and we would just miss an opportunity to teach beginners "the > right way" from the start. That is what I meant, you are using a more complex setup with Erlang in order to get more features. So the comparision with other languages "simple setup" is not fair. Cut, cut ..... But also note that I think it is important to make it easier for beginners to approach Erlang. We are working on that and are happy to cooperate with the Erlang community on this. > -- > Lo?c Hoguin > http://ninenines.eu > > Kenneth, Erlang/OTP, Ericsson > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Wed Jun 18 23:21:19 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 18 Jun 2014 17:21:19 -0400 Subject: [erlang-questions] Web app back-ends Message-ID: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> Hello, Jesse Gumm and I are working on a Nitrogen how-to book. We'd like to BRIEFLY point our readers in the right direction when they consider a database back-end for their web apps. We understand that this is a much more challenging decision than can be addressed without careful analysis. But we'd like to provide a conceptual framework to help narrow the field and avoid "flavor-of-the-day" snap decisions. Can some experienced Erlangers help correct any misperceptions below and fill in blanks. Please, no flame wars. Many thanks, Lloyd SQL/Relational Databases: postgeSQL - consider when: you want to use a battle-tested relational data store. - reject when: your data needs are more key-value oriented or free form/less structured. MySQL/MariaDB/etc: - consider when: You want a SQL datastore that's fast, but that is known to take some shortcuts in the name of speed or "ease of use" (such as silently truncating strings if too long for fields), and master/slave replication is good enough. - reject when: Your data needs are more key-value oriented or free form/less structured. NoSQL/Key-Value stores: ets - consider when: speed is a high priority, since it's all data is stored in ram, like a cache system - reject when: you can afford to lose data, or data needs to be replicated across a cluster. dets - consider when: speed is not a priority, since all requests immediately go to and come from disk - reject when: speed is essential or you need replication. mnesia - consider when: you want built-in clustering/replication, storing Erlang records and terms natively, and built into the Erlang system (no dependencies needed) - reject when: you don't want to mess around with records or QLC. couchDB - consider when _______ - reject when __________ cowDB - consider when _______ - reject when __________ riak - consider when: you need high availability, no-single-point-of-failure, replicated clustered key-value datastore. - reject when: __________ mongoDB: - consider when: https://www.youtube.com/watch?v=b2F-DItXtZs - reject when: https://www.youtube.com/watch?v=b2F-DItXtZs leoFS - consider when _______ - reject when __________ other _________________ - consider when _______ - reject when __________ none of the above - consider when _______ Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Thu Jun 19 00:11:45 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 19 Jun 2014 00:11:45 +0200 Subject: [erlang-questions] Web app back-ends In-Reply-To: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> References: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> Message-ID: Redis great for a key/value server, and provides several other base data access patterns (e.g. list and set maintenance). Don't use this for relational database patterns. It runs in memory which limits it practically for very large databases. This is a feature complete Erlang binding: https://github.com/gar1t/erlang-redis On Wed, Jun 18, 2014 at 11:21 PM, Lloyd R. Prentice wrote: > Hello, > > Jesse Gumm and I are working on a Nitrogen how-to book. We'd like to BRIEFLY > point our readers in the right direction when they consider a database > back-end for their web apps. We understand that this is a much more > challenging decision than can be addressed without careful analysis. But > we'd like to provide a conceptual framework to help narrow the field and > avoid "flavor-of-the-day" snap decisions. Can some experienced Erlangers > help correct any misperceptions below and fill in blanks. Please, no flame > wars. > > Many thanks, > > Lloyd > > SQL/Relational Databases: > > postgeSQL > - consider when: you want to use a battle-tested relational data store. > - reject when: your data needs are more key-value oriented or free form/less > structured. > > MySQL/MariaDB/etc: > - consider when: You want a SQL datastore that's fast, but that is known to > take some shortcuts in the name of speed or "ease of use" (such as silently > truncating strings if too long for fields), and master/slave replication is > good enough. > - reject when: Your data needs are more key-value oriented or free form/less > structured. > > NoSQL/Key-Value stores: > > ets > - consider when: speed is a high priority, since it's all data is stored in > ram, like a cache system > - reject when: you can afford to lose data, or data needs to be replicated > across a cluster. > > dets > - consider when: speed is not a priority, since all requests immediately go > to and come from disk > - reject when: speed is essential or you need replication. > > mnesia > - consider when: you want built-in clustering/replication, storing Erlang > records and terms natively, and built into the Erlang system (no > dependencies needed) > - reject when: you don't want to mess around with records or QLC. > > couchDB > - consider when _______ > - reject when __________ > > cowDB > - consider when _______ > - reject when __________ > > riak > - consider when: you need high availability, no-single-point-of-failure, > replicated clustered key-value datastore. > - reject when: __________ > > mongoDB: > - consider when: https://www.youtube.com/watch?v=b2F-DItXtZs > - reject when: https://www.youtube.com/watch?v=b2F-DItXtZs > > leoFS > - consider when _______ > - reject when __________ > > other _________________ > - consider when _______ > - reject when __________ > > none of the above > - consider when _______ > > Sent from my iPad > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From essen@REDACTED Thu Jun 19 01:30:02 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 01:30:02 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: <53A220FA.1060407@ninenines.eu> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: > That is what I meant, you are using a more complex setup with Erlang in > order to get more features. So the comparision with other languages > "simple setup" is not fair. The setup is more complex but the way we get there isn't. Have you read the getting started chapter[1]? The release part is smaller than it would take to explain "erl -run" or "erl -s": we don't have to write extra code for it, we don't have to manually setup paths, we don't have to deal with reltool, and so on. It's literally "create relx.config, put this in it, run make again". Bam you got a release. That part can't get any simpler. Erlang *is* more complex to use than many other languages (it is still simpler than C, C++ and the like though). Either you do things manually by downloading dependencies manually and such, or you use a build system like erlang.mk (or rebar) to automate things which requires you to create an OTP application. Because erlang.mk automates the use of relx to build releases it is actually simpler to make a release than manually setup paths and whatnot. We just have to create the one file! We don't deal with reltool here, creating the release is *really* easier than not. There's no simpler alternative to all that in the Erlang ecosystem. We will be able to make it a little simpler by having templates instead of making the user copy things, but the getting started chapter will not go down in length dramatically because of this. We could remove all explanations to make it perhaps half the size it currently is, but then we removed all explanations. It's a chapter about getting started, it's supposed to provide initial pointers to users, not just get them to run an example and then ask themselves "now what?". We have actual examples for people that want that already. I am not even sure what triggers all these good comments about the nodejs documentation. Sure it has a 6 lines and 1 command example on its front page. There's no denying that. Then what? A link to API docs. I have *no* idea how people manage to learn how to use it. Surely by using other resources than these, because while I'm confident I could run the front page example quickly, I am also confident that's about all I could do with it for a rather long time until I manage to figure out how to do anything meaningful, if I were to only use the official docs. [1] http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Thu Jun 19 01:33:04 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 01:33:04 +0200 Subject: [erlang-questions] Web app back-ends In-Reply-To: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> References: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> Message-ID: <53A221B0.9040408@ninenines.eu> On 06/18/2014 11:21 PM, Lloyd R. Prentice wrote: > MySQL/MariaDB/etc: Never consider. Don't even dare say it takes shortcuts in the name of speed if you're not properly explaining that those shortcuts are a frequent source of bugs in programs built with it, and that they're actually not even faster than a proper implementation like postgres. -- Lo?c Hoguin http://ninenines.eu From erlang-questions@REDACTED Thu Jun 19 05:10:31 2014 From: erlang-questions@REDACTED (erlang-questions@REDACTED) Date: Thu, 19 Jun 2014 03:10:31 +0000 Subject: [erlang-questions] Generating a certificate from a CSR with public_key In-Reply-To: References: Message-ID: <5375baf62fea60ce96d9b094d85f2059@mail.emte.net.au> Rudolph, I have built a service that signs certificates for database clients connecting to MySQL over SSL. This gist: https://gist.github.com/emtenet/b48f948102d9a4904a78 contains some of the Certificate/CSR logic used. Hope it helps. Michael. ---- Original Message ---- From: "Rudolph van Graan" To: "erlang-questions Questions" Sent: Wed, Jun 18, 2014, 00:25 Subject: [erlang-questions] Generating a certificate from a CSR with public_key Hi there, I'm trying to work out how I can generate and sign a certificate from a certificate signing request (CSR) using pure Erlang. It doesn't look as if the public_key application has support for this. Does anyone have pointers for doing this? (I know how to do this with openssl). Thanks, Rudolph _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) http://erlang.org/mailman/listinfo/erlang-questions (http://erlang.org/mailman/listinfo/erlang-questions) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aseigo@REDACTED Thu Jun 19 08:50:46 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Thu, 19 Jun 2014 08:50:46 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A220FA.1060407@ninenines.eu> References: <53A220FA.1060407@ninenines.eu> Message-ID: <2340610.0den0akeT5@freedom> On Thursday, June 19, 2014 01:30:02 Lo?c Hoguin wrote: > I am not even sure what triggers all these good comments about the > nodejs documentation. Sure it has a 6 lines and 1 command example on its > front page. There's no denying that. Then what? A link to API docs. I > have *no* idea how people manage to learn how to use it. Surely by using that's exactly the (non-intuitive) lesson to take away: you can have poor documentation and expect people to do lots of self-training and research BUT if you do these three "simple" things you can still be successful at spreading your tech: 0. attract: tell everyone what your product is really good at in a very simple, positive manner[1] 1. be positive: greet potential adopters with positivity[1] and they will reflect that back 2. have a "quick hook": give people something super quick and super easy to do at the very start. this gives them the feeling of accomplishment, even if it is completely trivial[3]. having tasted success (trivial as it may be) they will invest time/energy to get more. by doing those 3 things, nodejs can have a steep learning curve and still succeed in getting lots of users. conversely, you can have awesome documentation, but if you don't attract and quickly hook potential adopters, fewer people will adopt the technology. personally, i think cowboy's docs are pretty damn good. but i can see how some potential adopters are being lost. if the three things above were implemented, without changing anything substantial in the documentation, more people might end up using cowboy / erlang. which would always be nice :) tell you what: i've been looking for an area of erlang docs to contribute to, perhaps this is a good place to start. i'll try my hand at implementing the above 3-point-strategy in cowboy's docs and submit a pull request when i'm done ... always better to do than to the tell, right? :) i'll try and block some time for this in the next few days .... [1] that usually means it isn't 100% complete and accurate due to summarizing and glossing over details to keep it simple; the performance benchmarks i referenced in a previous email are good examples of this [2] the opening statement on the node.js website, and the first page of their documentations, are only about positives. they don't warn people about how tricky dynamic, async code that gets called non-sequentially can be , for instance. [3] for nodejs, that is "An Example: A Webserver" bit on their homepage -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From essen@REDACTED Thu Jun 19 10:52:06 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 10:52:06 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <2340610.0den0akeT5@freedom> References: <53A220FA.1060407@ninenines.eu> <2340610.0den0akeT5@freedom> Message-ID: <53A2A4B6.3020203@ninenines.eu> On 06/19/2014 08:50 AM, Aaron J. Seigo wrote: > by doing those 3 things, nodejs can have a steep learning curve and still > succeed in getting lots of users. That's another thing I don't understand. People always say nodejs has lots of users. Yet I haven't heard of a single success story. Erlang, you don't have to look far. Most big companies use Erlang. Half the world's phone communications go through Erlang. You can find Erlang in space. Heck even npm, the nodejs package manager, uses Erlang. So my question then is: on what is the hype built? It certainly doesn't seem to be built on the capabilities of the platform. I doubt it's because it has one short example on its front page either. It probably *helps* but it's not *why* there's hype about it. If you want to attract hypey people you have to build hype around Erlang, and that's much harder because you can't just hop in, everything is different and you have to restart learning from scratch. As simple as an example you might put on its front page, it will not get the point across as well as one for a familiar language. -- Lo?c Hoguin http://ninenines.eu From ivan@REDACTED Thu Jun 19 11:07:56 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 19 Jun 2014 10:07:56 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2A4B6.3020203@ninenines.eu> References: <53A220FA.1060407@ninenines.eu> <2340610.0den0akeT5@freedom> <53A2A4B6.3020203@ninenines.eu> Message-ID: <53A2A86C.1090302@llaisdy.com> Afaics nodejs is aimed squarely at people who (a) only know javascript, and (b) don't want to learn any other programming languages. For this market segment, I can certainly imagine nodejs is very exciting. On 19/06/2014 09:52, Lo?c Hoguin wrote: > On 06/19/2014 08:50 AM, Aaron J. Seigo wrote: >> by doing those 3 things, nodejs can have a steep learning curve and still >> succeed in getting lots of users. > > That's another thing I don't understand. People always say nodejs has > lots of users. Yet I haven't heard of a single success story. > > Erlang, you don't have to look far. Most big companies use Erlang. Half > the world's phone communications go through Erlang. You can find Erlang > in space. Heck even npm, the nodejs package manager, uses Erlang. > > So my question then is: on what is the hype built? It certainly doesn't > seem to be built on the capabilities of the platform. I doubt it's > because it has one short example on its front page either. It probably > *helps* but it's not *why* there's hype about it. > > If you want to attract hypey people you have to build hype around > Erlang, and that's much harder because you can't just hop in, everything > is different and you have to restart learning from scratch. As simple as > an example you might put on its front page, it will not get the point > across as well as one for a familiar language. > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From erlangsiri@REDACTED Thu Jun 19 11:10:14 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 19 Jun 2014 11:10:14 +0200 Subject: [erlang-questions] gb_trees utility functions In-Reply-To: References: Message-ID: Hi Cobus! We have had a look at your code, and we think that this is indeed something that you could contribute to the gb_trees module (we do not want a new module for this). A pull request is the way to go. Please follow these guidelines: https://github.com/erlang/otp/wiki/submitting-patches. Please note that tests must be done using common_test (stdlib/test/dict_SUITE.erl) and documentation must be added to stdlib/doc/src/gb_trees.xml. Best Regards /siri 2014-04-22 20:42 GMT+02:00 Cobus Carstens : > Hi all > > I wrote 4 utility functions[1] that allows searching a gb_tree for: > - the smallest key greater than the specified one > - the smallest key greater or equal to the specified one > - the greatest key smaller than the specified one > - the greatest key smaller or equal to the specified one. > > This is nothing special, but my question (mostly directed to the OTP > people) is: Would this be something that I can contribute to the > gb_trees module (or maybe a gb_trees_utils module)? Would a > pull-request suffice? > > [1] For those interested, the implementation can be found at: > https://github.com/cobusc/erlang_gb_trees_utils > > Regards, > Cobus > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jun 19 11:17:58 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 19 Jun 2014 11:17:58 +0200 Subject: [erlang-questions] Web app back-ends In-Reply-To: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> References: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> Message-ID: Replying inline On Wed, Jun 18, 2014 at 11:21 PM, Lloyd R. Prentice wrote: > > > SQL/Relational Databases: > > postgeSQL > - consider when: you want to use a battle-tested relational data store. > - reject when: your data needs are more key-value oriented or > free form/less structured. > > This is a bad reason for rejecting it. Postgres usually outperforms MongoDB for workloads with a good write/read split around 50/50. Furthermore, in 9.4, the jsonb type will make short work of anything that MongoDB stands for. The major weakness is a foreign store and this might slow prototyping down. > MySQL/MariaDB/etc: > - consider when: You want a SQL datastore that's fast, but that is known > to take some shortcuts in the name of speed or "ease of use" (such as > silently truncating strings if too long for fields), and master/slave > replication is good enough. > - reject when: Your data needs are more key-value oriented or > free form/less structured. > Never use. Never ever use. Only a viable option if an existing part of the infrastructure use MySQL. The very reason MySQL got market share is ease-of-use. They targeted making it easy to get up and running and the weak constraint validation is a big part of this. > NoSQL/Key-Value stores: > > dets > - consider when: speed is not a priority, since all requests immediately > go to and come from disk > - reject when: speed is essential or you need replication. > > Reject when your data grows beyond 2 gigabyte. > mnesia > - consider when: you want built-in clustering/replication, storing Erlang > records and terms natively, and built into the Erlang system (no > dependencies needed) > - reject when: you don't want to mess around with records or QLC. > Excellent choice for databases up to 128-1024 gigabyte, depending on how beefy a machine you can get. Read the original mnesia white paper on this one (it's on erlang.se somewhere) * sub microsecond k/v lookup. * occasional transactions with no soft-realtime-guarantee * distribution for live replication of the data store > riak > - consider when: you need high availability, no-single-point-of-failure, > replicated clustered key-value datastore. > - reject when: __________ > A good reason for rejecting is your data size. Most people can store all of their data in less than a Terabyte and then there is less need for something like Riak. > mongoDB: > - consider when: https://www.youtube.com/watch?v=b2F-DItXtZs > - reject when: https://www.youtube.com/watch?v=b2F-DItXtZs > MongoDB understands time to market. Look at their focus: * Good drivers for major languages * Easy interface * Very easy to set up and get running * Excellent for prototyping On the other hand: * Do not trust it real-world-data * Performance suffers once your data size grows * The distribution features has historically been unstable and full of problems -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Jun 19 11:49:21 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Jun 2014 11:49:21 +0200 Subject: [erlang-questions] gb_trees utility functions In-Reply-To: References: Message-ID: <6B3427FC-7F37-4CFE-9D7D-53952E8B2BB3@gmail.com> Yay for stdlib additions! Cobus: if you need help with Git or contributing to the test suited and whatnot, feel free to come on IRC where people (myself included) will be very happy to help. -- Anthony Ramine > Le 19 juin 2014 ? 11:10, Siri Hansen a ?crit : > > Hi Cobus! > > We have had a look at your code, and we think that this is indeed something that you could contribute to the gb_trees module (we do not want a new module for this). A pull request is the way to go. Please follow these guidelines: https://github.com/erlang/otp/wiki/submitting-patches. > > Please note that tests must be done using common_test (stdlib/test/dict_SUITE.erl) and documentation must be added to stdlib/doc/src/gb_trees.xml. > > Best Regards > /siri > > > 2014-04-22 20:42 GMT+02:00 Cobus Carstens : >> Hi all >> >> I wrote 4 utility functions[1] that allows searching a gb_tree for: >> - the smallest key greater than the specified one >> - the smallest key greater or equal to the specified one >> - the greatest key smaller than the specified one >> - the greatest key smaller or equal to the specified one. >> >> This is nothing special, but my question (mostly directed to the OTP >> people) is: Would this be something that I can contribute to the >> gb_trees module (or maybe a gb_trees_utils module)? Would a >> pull-request suffice? >> >> [1] For those interested, the implementation can be found at: >> https://github.com/cobusc/erlang_gb_trees_utils >> >> Regards, >> Cobus >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjnilsson@REDACTED Thu Jun 19 10:05:43 2014 From: kjnilsson@REDACTED (Karl Nilsson) Date: Thu, 19 Jun 2014 09:05:43 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A220FA.1060407@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> Message-ID: I followed the cowboy getting started tutorial and found it very reassuring to be taken all the way to generating a release. I am pretty sure I could build on that sample and actually create something that could be used. I think there is a lot of value in that. Personally I find tweet sized getting started examples very unsatisfactory and prefer something that gives and indication of workflow as well as the language. Hipsters may feel differently. Karl On 19 June 2014 00:30, Lo?c Hoguin wrote: > On 06/18/2014 10:22 PM, Kenneth Lundin wrote: > >> That is what I meant, you are using a more complex setup with Erlang in >> order to get more features. So the comparision with other languages >> "simple setup" is not fair. >> > > The setup is more complex but the way we get there isn't. Have you read > the getting started chapter[1]? The release part is smaller than it would > take to explain "erl -run" or "erl -s": we don't have to write extra code > for it, we don't have to manually setup paths, we don't have to deal with > reltool, and so on. It's literally "create relx.config, put this in it, run > make again". Bam you got a release. That part can't get any simpler. > > Erlang *is* more complex to use than many other languages (it is still > simpler than C, C++ and the like though). Either you do things manually by > downloading dependencies manually and such, or you use a build system like > erlang.mk (or rebar) to automate things which requires you to create an > OTP application. > > Because erlang.mk automates the use of relx to build releases it is > actually simpler to make a release than manually setup paths and whatnot. > We just have to create the one file! We don't deal with reltool here, > creating the release is *really* easier than not. > > There's no simpler alternative to all that in the Erlang ecosystem. We > will be able to make it a little simpler by having templates instead of > making the user copy things, but the getting started chapter will not go > down in length dramatically because of this. > > We could remove all explanations to make it perhaps half the size it > currently is, but then we removed all explanations. It's a chapter about > getting started, it's supposed to provide initial pointers to users, not > just get them to run an example and then ask themselves "now what?". We > have actual examples for people that want that already. > > I am not even sure what triggers all these good comments about the nodejs > documentation. Sure it has a 6 lines and 1 command example on its front > page. There's no denying that. Then what? A link to API docs. I have *no* > idea how people manage to learn how to use it. Surely by using other > resources than these, because while I'm confident I could run the front > page example quickly, I am also confident that's about all I could do with > it for a rather long time until I manage to figure out how to do anything > meaningful, if I were to only use the official docs. > > [1] http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Karl Nilsson* twitter: @kjnilsson blog: coderkarl.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Thu Jun 19 12:53:58 2014 From: john@REDACTED (John Kemp) Date: Thu, 19 Jun 2014 06:53:58 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2A86C.1090302@llaisdy.com> References: <53A220FA.1060407@ninenines.eu> <2340610.0den0akeT5@freedom> <53A2A4B6.3020203@ninenines.eu> <53A2A86C.1090302@llaisdy.com> Message-ID: <53A2C146.8030104@jkemp.net> On 06/19/2014 05:07 AM, Ivan Uemlianin wrote: > Afaics nodejs is aimed squarely at people who (a) only know javascript, What is wrong with that? Cowboy is aimed at people who know Erlang. Rails is aimed at people who know Ruby. Personally, I program in several languages, including Javascript. I found node easy to write because of my Javascript experience, mostly because of how callbacks are used. But I don't "only know Javascript". > and (b) don't want to learn any other programming languages. For this > market segment, I can certainly imagine nodejs is very exciting. Eh? I try to regularly evaluate new languages and platforms to use, and I doubt I'm the only person who does that. Node was exciting (to me) because it promised a nice solution to the I/O-bound scenarios which (I think) Aaron described in pretty good detail. "Event-driven, non-blocking I/O, server-side Javascript". Node delivers on those fronts, just like it says it does. It doesn't matter that there are better things out there (for some definition of better). Yes, there is hype around node. And yes, it has problems too. But the platform does have benefits. Disparaging the platform or the people who use it seems less than helpful. Helping aid in the understanding of how Erlang compares to node may be more helpful. - johnk > > On 19/06/2014 09:52, Lo?c Hoguin wrote: >> On 06/19/2014 08:50 AM, Aaron J. Seigo wrote: >>> by doing those 3 things, nodejs can have a steep learning curve and >>> still >>> succeed in getting lots of users. >> >> That's another thing I don't understand. People always say nodejs has >> lots of users. Yet I haven't heard of a single success story. >> >> Erlang, you don't have to look far. Most big companies use Erlang. Half >> the world's phone communications go through Erlang. You can find Erlang >> in space. Heck even npm, the nodejs package manager, uses Erlang. >> >> So my question then is: on what is the hype built? It certainly doesn't >> seem to be built on the capabilities of the platform. I doubt it's >> because it has one short example on its front page either. It probably >> *helps* but it's not *why* there's hype about it. >> >> If you want to attract hypey people you have to build hype around >> Erlang, and that's much harder because you can't just hop in, everything >> is different and you have to restart learning from scratch. As simple as >> an example you might put on its front page, it will not get the point >> across as well as one for a familiar language. >> > From zxq9@REDACTED Thu Jun 19 12:57:06 2014 From: zxq9@REDACTED (zxq9) Date: Thu, 19 Jun 2014 19:57:06 +0900 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A220FA.1060407@ninenines.eu> Message-ID: <2720179.2JvfftKefp@jalapeno> On Thursday 19 June 2014 09:05:43 Karl Nilsson wrote: > I followed the cowboy getting started tutorial and found it very reassuring > to be taken all the way to generating a release. I am pretty sure I could > build on that sample and actually create something that could be used. I > think there is a lot of value in that. Personally I find tweet sized > getting started examples very unsatisfactory and prefer something that > gives and indication of workflow as well as the language. Hipsters may feel > differently. Django users certainly don't. The Django documentation and the Python documentation -- two non-trivial documentation projects if there ever were -- are primary examples of how to speak directly to an open source community in its own language while making things approachable without dumbing anything down. The Postgres docs are another stellar example of documentation, notable particularly because they are *not* written for the average grade-school student and have only become popular very, very slowly as (a few elements of) the web dev crowd have matured and realized that mysql doesn't fit every purpose. The Erlang docs already fall into the Postgres category. The challenge is to explain the *runtime* and its capabilities in a way that compares to the Django docs -- in particular, how to think of a problem in terms of independent, concurrent processes (instead of getting bogged down in the management of concurrency the way teaching the same ideas in C/Java/Python/etc would) and how to leverage the Erlang system. The Erlang language itself does not need much explanation. Teaching basic functional programming paradigms is not the best way for the Erlang community to use its time -- RWH, LYAH, LYSE, and SICP already do an excellent job of that. After going through any one of those Erlang is readable. This whole discussion is still not separating Erlang the language from Erlang the platform, and it must if we want to understand how popularity works -- and let's be clear, this whole discussion is an envy-driven brainstorm about how ubiquitous low-tech could possibly trump something of clear technical superiority. From erlang@REDACTED Thu Jun 19 13:06:04 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 Jun 2014 13:06:04 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A15595.2090000@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: On Wed, Jun 18, 2014 at 11:02 AM, Lo?c Hoguin wrote: > Okay I wanted to skip this thread entirely but you mentioned Cowboy and > said weird things about it so I'll bite. > > > On 06/18/2014 09:39 AM, Aaron J. Seigo wrote: > >> comparing with cowboy, the differences are glaring. for instance, in the >> "getting started" guide for cowboy: >> > > > >> * we live in the microwave popcorn and 10-minutes-is-a-long-video-on- >> youtube >> age. yet the first FOUR sections are not about cowboy at all, but talking >> about >> the modern web and how to learn erlang. as someone moderately familiar >> with >> the web, i don't care about this. *just let me get started already!* if >> i'm >> reading the getting started guide for cowboy, i probably don't need to be >> sold >> on either the modern web OR erlang. >> > > I'm not sure why you call it a "getting started guide" all over your > email. It's the user guide. It may have one "getting started" chapter, but > its goal is not to get people started, but to be a complete guide. This > includes not only practical examples but also theory. Why theory? Well > everyone coming to Cowboy isn't a web developer, or even an Erlang > developer. Some of my users were happy enough that these chapters were in > the guide that they contacted me directly to tell me they liked them. > > If you are a web developer, then why are you reading these chapters? Do > you read the documentation for every computer you buy? Do you need to learn > how to put the power plug in to charge it? You probably don't need that. > But some people do, and that's why we put these "obvious" things in the > docs. > > > * being a good, modern developer with the attention span of the average >> backyard squirrel i simply skipped straight to the "Getting Started" >> section. >> the FIRST sentence is this: >> >> "Setting up a working Erlang application is a little more complex than for >> most other languages. The reason is that Erlang is designed to build >> systems >> and not just simple applications." >> >> ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], >> and my >> application IS simple. so cowboy is not for me! right? >> > > Well there's nothing we can do about that. We can't just write one file > and run a program on it. That's simply not how Erlang works. No no no. You can - Here is an example of a single file cowboy server that computes fib(N) - --- start ws3.es #!/usr/bin/env escript % -*- erlang -*- %%! -smp enable -pa ../erl_github_imports/deps/cowboy/ebin -pa ../erl_github_imports/deps/ranch/ebin -pa ../erl_github_imports/deps/cowlib/ebin -mode(compile). -export([init/3, handle/2, terminate/3]). main(_) -> io:format("ws3:starting~n"), ok = application:start(crypto), ok = application:start(ranch), ok = application:start(cowlib), ok = application:start(cowboy), Env = os:getenv("HOME"), Dispatch = cowboy_router:compile([{'_', [{'_', ?MODULE, Env}]}]), io:format("Dispatch=~p~n",[Dispatch]), io:format("Root=~p~n",[Env]), io:format("Info:~p~n",[?MODULE:module_info()]), start_http (8124, Dispatch), forever(). start_http(Port, Dispatch) -> NumberOfAcceptors = 1000, V = cowboy:start_http(http, NumberOfAcceptors, [{port, Port}], [{env, [{dispatch, Dispatch}]} ]), io:format("Http Running on Port:~w V=~p~n",[Port, V]). init({tcp,http}, Req, Env) -> io:format("Init~n"), {ok, Req, {http, Env}}. handle(Req, Env) -> {Path0,Req1} = cowboy_req:path(Req), Path = binary_to_list(Path0), io:format("Path=~p~n",[Path]), case Path of "/fib" -> {Args, Req2} = cowboy_req:qs_vals(Req1), case Args of [{<<"n">>,BN}] -> N = list_to_integer(binary_to_list(BN)), F = fib(N), io:format("fib(~p) = ~p~n",[N,F]), reply_html(integer_to_list(F), Req2, Env); _ -> reply_html(<<"error">>, Req2, Env) end; _ -> reply_html(<<"error">>, Req1, Env) end. reply_html(Obj, Req, Env) -> {ok, Req1} = send_page(html, Obj, Req), {ok, Req1, Env}. terminate(Reason,_Req,State) -> io:format("Terminated:~p ~p~n",[Reason,State]), %% ignore why we terminate ok. fib(0) -> 1; fib(1) -> 1; fib(N) when is_integer(N), N > 0 -> fib(N-1) + fib(N-2). send_page(Type, Data, Req) -> cowboy_req:reply(200, [{<<"Content-Type">>, list_to_binary(mime_type(Type))}], Data, Req). mime_type(html) -> "text/html". forever() -> receive after infinity -> true end. --- end Put this in a file. chmod it to u+x and run it Then got to http://localhost:8124/fib?n=10 And fib(10) will be returned Note - I haven't built an application. With a small amount of refactoring this could be make just as simple as the node.js examples The second counter example is rebar? - it's ONE file - There are two ways to make single file applications 1) make an escript and stick everything in one file. Use the compile flag if you want the escript to be compiled and not interpreted. 2) make a packed escript that packs all the compiled code into a single file rebar is a good example of this The code in https://github.com/basho/rebar/blob/develop/bootstrap is a stand-alone script that builds rebar Personally I'm rather surprised that there are so few single file programs like rebar - they are far easier for the beginner to use and don't break if they moved to new directories - A single file web server would be very nice to have (hint) ... > We have to create an OTP application, compile, start the VM with the right paths etc. No you don't - I have large number of programs that are just erlang modules started with a top level "erl -s ...." command. Both node and java applications require paths to be correctly set, or for files to be in a particular directory structure. > That's not just Cowboy deciding to be more complex than nodejs, that's how > Erlang was designed. > Erlang was not designed to be complex - the primitives in Erlang (spawn_link, trap_exits, etc.) were designed to be as simple as possible and were intended to be called from library routines. For example, remote procedure calls are not defined in Erlang, but can be built using send and receive. If you'd said "OTP was designed for solving more complex problems than node.js" I'd agree . > > And while it's improving (you should have seen things 4 years ago when I > started, the getting started in Cowboy is *immensely* simpler than it would > have been then), it'll never be as simple as nodejs. Because most of the > stuff in the getting started chapter is necessary as I'll explain in a bit. > > > > * the rest of the "getting started" walks me through doing a ton of >> boilerplate stuff. it's nice to know how things work, but i'm a busy web >> dev >> (have i mentioned my lack of attention span yet? oh look, a peanut! and >> it's >> an event driven async peanut! yum! *runs off*). everything in that section >> ought to be boiled down to "run this one simple command and everything is >> done >> for you. click here to read about the gory details." and doing so should >> give >> me a fully functional application template that i can immediately start. >> that >> one command should probably take a simple config file with things like >> the app >> name and other variable details (such as which erlang apps to include in >> my >> awesome new project, including but also in addition to cowboy). >> basically, an >> npm-for-erlang. >> > > The next erlang.mk version will make it a little easier by generating a > base project (using templates, as you say). But that will not change the > getting started chapter much, as we will still have to explain things. > Instead of saying "create" it will say "edit", basically. > > It may sound like a lot for someone with as little attention span as you, > but going through these steps saves you an immense amount of time later on. > If Erlang beginners start using releases immediately, we win. They will not > have to suffer going through hoops like we did to get to that point. They > will not have to fiddle with paths, or make start scripts, or deal with > complex deployment issues, or anything that we struggled with for years. It > *is* a big step, and we probably can't reduce it much more, but it's an > incredible time saver. > > But of course impatient people will prefer to waste their time by missing > out on it. > > And to be honest if we weren't doing this then we would have to explain > how to write a start function, start erl with the -s option and make a > start script for frequent use. It wouldn't be simpler, it would just be > different, and we would just miss an opportunity to teach beginners "the > right way" from the start. > > > oh, and bonus points if there is a file created just for route >> definitions which >> would then be automatically included by the foo_app.erl to be passed to >> cowboy_router:compile. having a "well known" place to define routes will >> standardize cowboy using applications and allow the starting dev to focus >> on >> what they care about (routes and handlers) while ignoring the details >> like the >> app module. yes, yes, eventually they'll likely want to dig into that as >> well, >> but not at the beginning. (this is an area that cowboy+erlang could be >> even >> better than express+node.js) >> > > Cowboy isn't a Web framework. There's nothing to standardize. It's a thin > HTTP layer implementing the various HTTP specs. That's it. Yes, routing is > also part of the spec, as it is a way to map URIs to resources which is > well covered by the spec. > > There's tons of Web frameworks built on top of Cowboy if you want > standards. Everything in Cowboy is done by calling a function (or Cowboy > calling one of your functions). The application module is simply the only > place where you can run code at startup, so we have to cover it. Besides I > don't see much difference between explaining how to run code in this module > vs explaining the structure of a configuration file (it's harder to do the > latter really). > > > * i couldn't find the bragging section of the docs. ;) more seriously, the >> getting started guide tries to sell me on the modern web and erlang's >> place in >> it, but how about a fun little one-pager that backs up the claims made in >> the >> main README: "Cowboy is a small, fast and modular HTTP server written in >> Erlang." and " It is optimized for low latency and low memory usage". >> show me >> the money^Hmeasurements! a simple set of charts showing how many >> simultaneous >> connections can be handled and what kind of latencies app the developers >> achieve on regular ol' hardware, along with a LOC-you-need-to-write-for-a- >> barebones-app count would help convince people and would be the thing that >> would get passed around on stackoverflow, g+, twitter, etc. when >> justifying / >> recommending cowboy. >> > > Would you believe me if I told you Cowboy is capable of handling millions > of concurrent Websocket connections on a middle sized server, with *no > impact* on latency? And would you believe me if I told you I do not have > the slightest idea what the upper limit for the number of connections > Cowboy can actually handle *is*? Because that's the truth. > > This is in large part due to Erlang, Cowboy mostly tries to be careful > about memory use, and could do a better job at it. > > But still, how do you even brag about a difference that big with other > platforms, and make people actually believe you? > > Besides, if you look at the benchmark of the week, they're still all > focused on glorified "hello world" measuring requests per second. Cowboy > obviously can't compete there, as these are won by JITs not by the > underlaying code. Not to mention these benchmarks are the most misleading > and useless kind you can ever write. > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jun 19 13:33:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 13:33:23 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> Message-ID: <53A2CA83.7030502@ninenines.eu> On 06/19/2014 01:06 PM, Joe Armstrong wrote: > You can - Here is an example of a single file cowboy server that computes > fib(N) - > [snip huge file] > > Put this in a file. chmod it to u+x and run it > > Then got to http://localhost:8124/fib?n=10 > > And fib(10) will be returned Joe, your one file example is longer than my many files getting started, not to mention completely cryptic. The shebang up there isn't something you can just drop on people, you have to explain it. You also have to say why you have an infinite receive and how to stop the program. Plus, doing this you'd also have to explain them that they have to download 3 different projects manually and to put them in the appropriate folder. And of course, the worst is that by taking this one file example, people immediately get stuck. How do they add a second handler? I personally have no idea how to go from that one handler escript to something bigger. > 2) make a packed escript that packs all the compiled code into a > single file > rebar is a good example of this That script takes an OTP application and bundles it into one escript. It makes little difference with taking an OTP application and generating a release, except the release is a lot more useful for servers. > Erlang was not designed to be complex - the primitives in Erlang > (spawn_link, trap_exits, etc.) were designed to be as simple as possible > and were intended to be called from library routines. I didn't say Erlang was designed to be complex. I'm saying running the Erlang VM is of higher complexity than dropping a PHP file into a folder or running nodejs myfile.js. And yes, that's true even if you use escripts. -- Lo?c Hoguin http://ninenines.eu From mfidelman@REDACTED Thu Jun 19 15:10:03 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 19 Jun 2014 09:10:03 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <2340610.0den0akeT5@freedom> References: <53A220FA.1060407@ninenines.eu> <2340610.0den0akeT5@freedom> Message-ID: <53A2E12B.3060707@meetinghouse.net> Aaron J. Seigo wrote: >> >> that's exactly the (non-intuitive) lesson to take away: you can have poor >> documentation and expect people to do lots of self-training and research BUT >> if you do these three "simple" things you can still be successful at spreading >> your tech: Somehow, I don't think that any of this has much to do with success at "spreading your tech." Maybe at differentiating your tech, but other factors dominate which technology people use. Right of the bat, technology selection is almost always driven by: 1. Absolute dictates of your application environment (e.g., objective-c for iPad applications) 2. What your employer or client dictates (current employer builds everything in .NET and MSQL stored procedures, there's an awful lot of COBOL still out there) 3. A language you learned early, and feel comfortable in - for me, that's Fortran or LISP, yes it dates me, today schools seem to teach C, Java, and maybe Python 4. After that, you're into the world of picking the most appropriate language for the application at hand - for numerical stuff: Fortran, APL, R, MATLAB - for mission-critical hard-real-time: Ada (yes, it's alive in both aerospace and SCADA) - for web sites: pick a platform/ecosystem first (notably Drupal, WordPress, Joomla, ..) and one usually ends up at PHP or perl (and for perl, it's CPAN that makes it) - now if I'm going to develop a distributed simulator, or a middleware platform - Erlang is the obvious choice (and if I didn't already know about it, I'd go looking for something like Erlang, and there's only one thing I'd find) Erlang is not taught in mainstream computer science curricula. Personally, I think it should be - it covers two concepts: Functional Programming, Actor formalism, and it provides a basis for exploring the structure of large, complex, highly concurrent, highly available, distributed systems. Beyond that, Erlang is something one actively goes looking for - because it provides unique capabilities ideal for particular classes of problems that are generally not in the mainstream, and tend to be the purview of experienced, senior people. Personally, when someone says "Erlang is too hard to learn" - I think what they're really saying is: - the concepts are radically different from what I'm used to (e.g., functional programming, actors), and/or, - my application doesn't require capabilities that are unique to Erlang, so why bother? In this context: > > 0. attract: tell everyone what your product is really good at in a very > simple, positive manner[1] Erlang: highly concurrent, highly distributed, highly available, near-real-time systems This kind of narrows the scope rather significantly. And, when you get into this world, people do serious technology assessment and selection efforts. Making Erlang a bit better known, and easier to evaluate might help adoption - but that's questionable - my experience is that people who are looking for Erlang either know about it, or find it quickly; and adoption is driven more by political and business decisions than technical ones. When it comes to the mass market, Erlang is more likely to be buried in something else - like a web platform (e.g., Cowboy) or a noSQL database (e.g., CouchDB). In this regard, the messaging does become important - but Erlang has very little to do with what makes CouchDB or Cowboy the right platform for a job. >> >> 1. be positive: greet potential adopters with positivity[1] and they will >> reflect that back Well, that's more about the community - and the Erlang community is pretty positive, helpful, and welcoming. >> >> 2. have a "quick hook": give people something super quick and super easy to do >> at the very start. this gives them the feeling of accomplishment, even if it >> is completely trivial[3]. having tasted success (trivial as it may be) they >> will invest time/energy to get more. >> >> by doing those 3 things, nodejs can have a steep learning curve and still >> succeed in getting lots of users. >> >> Personally, I think that's irrelevant when it comes to Erlang. - "Hello, World" is pretty trivial in Erlang, as with any other language - once you get into real work, Erlang is either overkill, or the concepts actually require some serious learning Folks who need Erlang (or something like it) are going in expecting a steep learning curve, and are not going to be dissuaded by lack of something trivial. Just one man's opinion, of course. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Thu Jun 19 15:29:27 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 19 Jun 2014 09:29:27 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A220FA.1060407@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> Message-ID: <53A2E5B7.1000300@meetinghouse.net> Lo?c Hoguin wrote: > On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >> That is what I meant, you are using a more complex setup with Erlang in >> order to get more features. So the comparision with other languages >> "simple setup" is not fair. > > The setup is more complex but the way we get there isn't. Have you > read the getting started chapter[1]? The release part is smaller than > it would take to explain "erl -run" or "erl -s": we don't have to > write extra code for it, we don't have to manually setup paths, we > don't have to deal with reltool, and so on. It's literally "create > relx.config, put this in it, run make again". Bam you got a release. > That part can't get any simpler. > > Erlang *is* more complex to use than many other languages (it is still > simpler than C, C++ and the like though). Either you do things > manually by downloading dependencies manually and such, or you use a > build system like erlang.mk (or rebar) to automate things which > requires you to create an OTP application. I think that's highly debatable. At least from my perspective, Erlang ISN'T more complex than many other languages, and is perhaps simpler, when you factor in the entire ecosystem required to do any kind of serious work. For example, to get serious work done in C, you need to know about: - a text editor or IDE - I wouldn't call emacs, or vim, or Eclipse trivial to learn - version control - language details - including libraries - program/application structure - header files, linking - run-time environments and dependencies - build system (anybody know an easy tutorial for gnutools?, and these days add in Jenkins) - packaging system(s) - logging, monitoring hooks - and probably stuff I've left out Java is no different, but is maybe easier to pick up if you already know all of the above for C: - OOP is a new set of concepts (but not if you've been doing C++ or Objective-C) - you're still using emacs, or vim, or Eclipse - you're still using git or svn (or switching to something similar) - when it gets to everything else, there's pretty much a 1-1 relationship between things your familiar with and the new environment (e.g., gnutools vs. maven, ant, etc.) In once sense, Erlang is no different - "Hello, World" is easy, it's the details and the ecosystem that require serious learning. In another sense, it's different in several key respects: - the core concepts are unfamiliar to many (functional programming, actor model) - the run-time environment is different - the structure of applications is different (as is the tooling) I.e., one is not simply learning the same concepts in new clothing. In that regard, one does have to learn more (unless Erlang is the first language you learn). But whether it's more complex is debatable (e.g., no header files to worry about, no automake, and so forth). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From g@REDACTED Thu Jun 19 15:31:38 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 19 Jun 2014 15:31:38 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A220FA.1060407@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> Message-ID: It may be worth mentioning that in the survey results, Node.js does not show up as a strong alternative. The usual suspects wrt Erlang alternatives are Go, the JVM languages (largely Clojure and Scala), Haskell, and to a lesser extent Elixir. One of the contributors to this thread described Node.js as "the biggest crap I ever taste" which, from my own non scientific experience, is not an isolated opinion. I don't know if it's worth investing a lot of energy in reverse engineering the popularity of this platform. Btw here's the tag cloud for the Erlang language/framework alternatives: http://www.gar1t.com/presentations/2014-06-10-euc/#slide-76 golang.org was cited many times as an outstanding resource for learning Go. On 06/18/2014 10:22 PM, Kenneth Lundin wrote: > That is what I meant, you are using a more complex setup with Erlang in > order to get more features. So the comparision with other languages > "simple setup" is not fair. > The setup is more complex but the way we get there isn't. Have you read the getting started chapter[1]? The release part is smaller than it would take to explain "erl -run" or "erl -s": we don't have to write extra code for it, we don't have to manually setup paths, we don't have to deal with reltool, and so on. It's literally "create relx.config, put this in it, run make again". Bam you got a release. That part can't get any simpler. Erlang *is* more complex to use than many other languages (it is still simpler than C, C++ and the like though). Either you do things manually by downloading dependencies manually and such, or you use a build system like erlang.mk (or rebar) to automate things which requires you to create an OTP application. Because erlang.mk automates the use of relx to build releases it is actually simpler to make a release than manually setup paths and whatnot. We just have to create the one file! We don't deal with reltool here, creating the release is *really* easier than not. There's no simpler alternative to all that in the Erlang ecosystem. We will be able to make it a little simpler by having templates instead of making the user copy things, but the getting started chapter will not go down in length dramatically because of this. We could remove all explanations to make it perhaps half the size it currently is, but then we removed all explanations. It's a chapter about getting started, it's supposed to provide initial pointers to users, not just get them to run an example and then ask themselves "now what?". We have actual examples for people that want that already. I am not even sure what triggers all these good comments about the nodejs documentation. Sure it has a 6 lines and 1 command example on its front page. There's no denying that. Then what? A link to API docs. I have *no* idea how people manage to learn how to use it. Surely by using other resources than these, because while I'm confident I could run the front page example quickly, I am also confident that's about all I could do with it for a rather long time until I manage to figure out how to do anything meaningful, if I were to only use the official docs. [1] http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jun 19 15:36:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 15:36:23 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2E5B7.1000300@meetinghouse.net> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> Message-ID: <53A2E757.3070803@ninenines.eu> On 06/19/2014 03:29 PM, Miles Fidelman wrote: > Lo?c Hoguin wrote: >> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >>> That is what I meant, you are using a more complex setup with Erlang in >>> order to get more features. So the comparision with other languages >>> "simple setup" is not fair. >> >> The setup is more complex but the way we get there isn't. Have you >> read the getting started chapter[1]? The release part is smaller than >> it would take to explain "erl -run" or "erl -s": we don't have to >> write extra code for it, we don't have to manually setup paths, we >> don't have to deal with reltool, and so on. It's literally "create >> relx.config, put this in it, run make again". Bam you got a release. >> That part can't get any simpler. >> >> Erlang *is* more complex to use than many other languages (it is still >> simpler than C, C++ and the like though). Either you do things >> manually by downloading dependencies manually and such, or you use a >> build system like erlang.mk (or rebar) to automate things which >> requires you to create an OTP application. > > I think that's highly debatable. At least from my perspective, Erlang > ISN'T more complex than many other languages, and is perhaps simpler, > when you factor in the entire ecosystem required to do any kind of > serious work. I didn't repeat but what I said was about getting started, and in particular in a web development setting, where pretty much every other platform just require you to drop a file in the right folder and you're done. Erlang is simpler than C for sure, and I don't know (nor care) about Java but I wouldn't be surprised if it was simpler too. Only those aren't really used for web development. (Some people do, but you're a lot more likely to find a PHP web developer than a C/Java one, at least in my experience.) -- Lo?c Hoguin http://ninenines.eu From mahesh@REDACTED Thu Jun 19 15:42:10 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Thu, 19 Jun 2014 09:42:10 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2E757.3070803@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> Message-ID: "Complexity" is a remarkably loaded term - I'm fairly certain that things that are complex for me (Getting anywhere via mass-transit in Tokyo) are pretty trivial for others (e.g., Loic). Whats more, complexity of systems has nothing to do with the complexity of the individual components involved (DNA is a bit of a prime example here). That said, I would claim that erlang systems are more _comprehensible_ than others. Mind you, this does require some mastery of erlang, which is not as much of a chicken-and-egg scenario as you might imagine. Cheers On Thu, Jun 19, 2014 at 9:36 AM, Lo?c Hoguin wrote: > On 06/19/2014 03:29 PM, Miles Fidelman wrote: > >> Lo?c Hoguin wrote: >> >>> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >>> >>>> That is what I meant, you are using a more complex setup with Erlang in >>>> order to get more features. So the comparision with other languages >>>> "simple setup" is not fair. >>>> >>> >>> The setup is more complex but the way we get there isn't. Have you >>> read the getting started chapter[1]? The release part is smaller than >>> it would take to explain "erl -run" or "erl -s": we don't have to >>> write extra code for it, we don't have to manually setup paths, we >>> don't have to deal with reltool, and so on. It's literally "create >>> relx.config, put this in it, run make again". Bam you got a release. >>> That part can't get any simpler. >>> >>> Erlang *is* more complex to use than many other languages (it is still >>> simpler than C, C++ and the like though). Either you do things >>> manually by downloading dependencies manually and such, or you use a >>> build system like erlang.mk (or rebar) to automate things which >>> requires you to create an OTP application. >>> >> >> I think that's highly debatable. At least from my perspective, Erlang >> ISN'T more complex than many other languages, and is perhaps simpler, >> when you factor in the entire ecosystem required to do any kind of >> serious work. >> > > I didn't repeat but what I said was about getting started, and in > particular in a web development setting, where pretty much every other > platform just require you to drop a file in the right folder and you're > done. > > Erlang is simpler than C for sure, and I don't know (nor care) about Java > but I wouldn't be surprised if it was simpler too. Only those aren't really > used for web development. (Some people do, but you're a lot more likely to > find a PHP web developer than a C/Java one, at least in my experience.) > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Mahesh Paolini-Subramanya That tall bald Indian guy..* *Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Jun 19 15:51:47 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 19 Jun 2014 09:51:47 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2E757.3070803@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> Message-ID: <53A2EAF3.6040602@meetinghouse.net> Lo?c Hoguin wrote: > On 06/19/2014 03:29 PM, Miles Fidelman wrote: >> Lo?c Hoguin wrote: >>> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >>>> That is what I meant, you are using a more complex setup with >>>> Erlang in >>>> order to get more features. So the comparision with other languages >>>> "simple setup" is not fair. >>> >>> The setup is more complex but the way we get there isn't. Have you >>> read the getting started chapter[1]? The release part is smaller than >>> it would take to explain "erl -run" or "erl -s": we don't have to >>> write extra code for it, we don't have to manually setup paths, we >>> don't have to deal with reltool, and so on. It's literally "create >>> relx.config, put this in it, run make again". Bam you got a release. >>> That part can't get any simpler. >>> >>> Erlang *is* more complex to use than many other languages (it is still >>> simpler than C, C++ and the like though). Either you do things >>> manually by downloading dependencies manually and such, or you use a >>> build system like erlang.mk (or rebar) to automate things which >>> requires you to create an OTP application. >> >> I think that's highly debatable. At least from my perspective, Erlang >> ISN'T more complex than many other languages, and is perhaps simpler, >> when you factor in the entire ecosystem required to do any kind of >> serious work. > > I didn't repeat but what I said was about getting started, and in > particular in a web development setting, where pretty much every other > platform just require you to drop a file in the right folder and > you're done. > Except that's simply not true, unless you're talking about dropping HTML files (maybe including JavaScript) into an Apache directory - and even that assumes that Apache is already set up. More commonly, we're talking about: - select a platform (Drupal, Wordpress, Joomla, Plone), install (and, guess what, not all that easy - particularly if you're wiring it up with Apache) - select and install a database - configure the platform and database - selection and configure modues - define pages and behaviors through GUI interfaces - and then we're into the world of custom module development The underlying language doesn't enter into the picture at all, except for: - install-time dependencies - writing custom modules - things that are external to the web-site such as database applications At which point: > Erlang is simpler than C for sure, and I don't know (nor care) about > Java but I wouldn't be surprised if it was simpler too. Only those > aren't really used for web development. (Some people do, but you're a > lot more likely to find a PHP web developer than a C/Java one, at > least in my experience.) > What exactly are we comparing here? Programming language <> run-time-environment <> (web) platform <> development environment. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mark.nijhof@REDACTED Thu Jun 19 15:58:04 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Thu, 19 Jun 2014 15:58:04 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> Message-ID: Could a large part of its success be explained by the fact that making anything in either .Net or Java takes such an amount of effort that something like Node is seen as a godsent (which in fairness for a lot uses it really is). Everyone of those devs knows the language well enough to get going. -Mark On Jun 19, 2014 3:42 PM, "Mahesh Paolini-Subramanya" < mahesh@REDACTED> wrote: "Complexity" is a remarkably loaded term - I'm fairly certain that things that are complex for me (Getting anywhere via mass-transit in Tokyo) are pretty trivial for others (e.g., Loic). Whats more, complexity of systems has nothing to do with the complexity of the individual components involved (DNA is a bit of a prime example here). That said, I would claim that erlang systems are more _comprehensible_ than others. Mind you, this does require some mastery of erlang, which is not as much of a chicken-and-egg scenario as you might imagine. Cheers On Thu, Jun 19, 2014 at 9:36 AM, Lo?c Hoguin wrote: > On 06/19/2014 03:29 PM, Miles Fidelman wrote: > >> Lo?c Hoguin wrote: >> >>> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >>> >>>> That is what I meant, you are using a more complex setup with Erlang in >>>> order to get more features. So the comparision with other languages >>>> "simple setup" is not fair. >>>> >>> >>> The setup is more complex but the way we get there isn't. Have you >>> read the getting started chapter[1]? The release part is smaller than >>> it would take to explain "erl -run" or "erl -s": we don't have to >>> write extra code for it, we don't have to manually setup paths, we >>> don't have to deal with reltool, and so on. It's literally "create >>> relx.config, put this in it, run make again". Bam you got a release. >>> That part can't get any simpler. >>> >>> Erlang *is* more complex to use than many other languages (it is still >>> simpler than C, C++ and the like though). Either you do things >>> manually by downloading dependencies manually and such, or you use a >>> build system like erlang.mk (or rebar) to automate things which >>> requires you to create an OTP application. >>> >> >> I think that's highly debatable. At least from my perspective, Erlang >> ISN'T more complex than many other languages, and is perhaps simpler, >> when you factor in the entire ecosystem required to do any kind of >> serious work. >> > > I didn't repeat but what I said was about getting started, and in > particular in a web development setting, where pretty much every other > platform just require you to drop a file in the right folder and you're > done. > > Erlang is simpler than C for sure, and I don't know (nor care) about Java > but I wouldn't be surprised if it was simpler too. Only those aren't really > used for web development. (Some people do, but you're a lot more likely to > find a PHP web developer than a C/Java one, at least in my experience.) > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- * Mahesh Paolini-Subramanya That tall bald Indian guy..* * Google+ | Blog | Twitter | LinkedIn * _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Thu Jun 19 16:09:02 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Thu, 19 Jun 2014 10:09:02 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> Message-ID: I quite agree - if you just want to get _something_ up, and don't particularly care about any of the long term consequences of your design decisions, you can do far, _far_ worse than an Angular/Node implementation. And, FWIW, I quite encourage this, odds are that there will be _no_ long term consequences :-) cheers On Thu, Jun 19, 2014 at 9:58 AM, Mark Nijhof wrote: > Could a large part of its success be explained by the fact that making > anything in either .Net or Java takes such an amount of effort that > something like Node is seen as a godsent (which in fairness for a lot uses > it really is). Everyone of those devs knows the language well enough to get > going. > > -Mark > On Jun 19, 2014 3:42 PM, "Mahesh Paolini-Subramanya" < > mahesh@REDACTED> wrote: > > "Complexity" is a remarkably loaded term - I'm fairly certain that things > that are complex for me (Getting anywhere via mass-transit in Tokyo) are > pretty trivial for others (e.g., Loic). > Whats more, complexity of systems has nothing to do with the complexity of > the individual components involved (DNA is a bit of a prime example here). > > That said, I would claim that erlang systems are more _comprehensible_ > than others. > Mind you, this does require some mastery of erlang, which is not as much > of a chicken-and-egg scenario as you might imagine. > > Cheers > > > On Thu, Jun 19, 2014 at 9:36 AM, Lo?c Hoguin wrote: > >> On 06/19/2014 03:29 PM, Miles Fidelman wrote: >> >>> Lo?c Hoguin wrote: >>> >>>> On 06/18/2014 10:22 PM, Kenneth Lundin wrote: >>>> >>>>> That is what I meant, you are using a more complex setup with Erlang in >>>>> order to get more features. So the comparision with other languages >>>>> "simple setup" is not fair. >>>>> >>>> >>>> The setup is more complex but the way we get there isn't. Have you >>>> read the getting started chapter[1]? The release part is smaller than >>>> it would take to explain "erl -run" or "erl -s": we don't have to >>>> write extra code for it, we don't have to manually setup paths, we >>>> don't have to deal with reltool, and so on. It's literally "create >>>> relx.config, put this in it, run make again". Bam you got a release. >>>> That part can't get any simpler. >>>> >>>> Erlang *is* more complex to use than many other languages (it is still >>>> simpler than C, C++ and the like though). Either you do things >>>> manually by downloading dependencies manually and such, or you use a >>>> build system like erlang.mk (or rebar) to automate things which >>>> requires you to create an OTP application. >>>> >>> >>> I think that's highly debatable. At least from my perspective, Erlang >>> ISN'T more complex than many other languages, and is perhaps simpler, >>> when you factor in the entire ecosystem required to do any kind of >>> serious work. >>> >> >> I didn't repeat but what I said was about getting started, and in >> particular in a web development setting, where pretty much every other >> platform just require you to drop a file in the right folder and you're >> done. >> >> Erlang is simpler than C for sure, and I don't know (nor care) about Java >> but I wouldn't be surprised if it was simpler too. Only those aren't really >> used for web development. (Some people do, but you're a lot more likely to >> find a PHP web developer than a C/Java one, at least in my experience.) >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > > * Mahesh Paolini-Subramanya > That > tall bald Indian guy..* > * Google+ > | Blog | Twitter > | LinkedIn > * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- *Mahesh Paolini-Subramanya That tall bald Indian guy..* *Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Jun 19 16:12:12 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 19 Jun 2014 10:12:12 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> Message-ID: <53A2EFBC.2060301@meetinghouse.net> Mahesh Paolini-Subramanya wrote: > "Complexity" is a remarkably loaded term - I'm fairly certain that > things that are complex for me (Getting anywhere via mass-transit in > Tokyo) are pretty trivial for others (e.g., Loic). Well, let's say "complex" in an engineering context, for starters. > Whats more, complexity of systems has nothing to do with the > complexity of the individual components involved (DNA is a bit of a > prime example here). Precisely. I'd venture that one gravitates toward Erlang when one is building systems and systems-of-systems with lots of distributed, moving parts (e.g., a telephone switching fabric). If one is building a single, stand-alone application, I expect Erlang might not be the "best" choice. > > That said, I would claim that erlang systems are more _comprehensible_ > than others. > Mind you, this does require some mastery of erlang, which is not as > much of a chicken-and-egg scenario as you might imagine. > > You know, that's a really good point, that highlights two broader issues: conceptual models, and tooling that maps onto conceptual models: - Sequential code is relatively easy to conceptualize and represent - well commented code can suffice as a representation, there are plenty of debugging and tracing tools for examining run-time behavior - Object oriented code lends itself to browsers and inspector - though execution flow can get pretty arcane (at one point, I worked on military simulators - think game engine - each vehicle was an object, but the actual work was done by 4 spaghetti coded threads that each ran 20 time a second - very ugly, and what led me to discover Erlang) - Actor formalism (i.e., Erlang) - very easy to conceptualize for applications where things naturally map onto independent processes (e.g., the above-mentioned simulator -- tanks and airplanes are a lot easier to model as processes than as objects) - but tools for visualizing, designing, debugging systems with lots of processes, and the interactions among them, are close to non-existent (a problem for Erlang, but also for anyone building highly concurrent, highly distributed systems) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From schintke@REDACTED Thu Jun 19 17:05:12 2014 From: schintke@REDACTED (Florian Schintke) Date: Thu, 19 Jun 2014 17:05:12 +0200 Subject: [erlang-questions] Intel Xeon Phi In-Reply-To: References: Message-ID: <20140619150512.GG15725@csr-pc9.zib.de> Hi, an Erlang VM runs per SMP unit. As the Xeon Phi has its own Linux running it builds its own SMP unit. You can start an Erlang VM on it and on your host machine and have two Erlang VMs that can communicate via distributed Erlang. Then you can easily have a process running in the Erlang VM running on the Xeon Phi that spawns processes, if you want, but there is no automatic mechanism which decides whether to spawn processes on the Xeon Phi or the host machine. They are different Erlang VMs like two computers connected with a network. Florian [semmit mondo] > Hi List, Is the Erlang runtime capable of spawning processes on a Xeon Phicoprocessor? Or is this piece of hardware too rare for Erlang to beable to take advatage of it? U. From josh.rubyist@REDACTED Thu Jun 19 17:15:23 2014 From: josh.rubyist@REDACTED (Josh Adams) Date: Thu, 19 Jun 2014 10:15:23 -0500 Subject: [erlang-questions] Intel Xeon Phi In-Reply-To: <20140619150512.GG15725@csr-pc9.zib.de> References: <20140619150512.GG15725@csr-pc9.zib.de> Message-ID: This article looks nice: http://dl.acm.org/citation.cfm?id=2505307 Wanting to see some benchmarks on Erlang performance on the xeon phi, but I haven't yet knuckled down and bought that paper (because every time I'm tempted to, I want to buy the digital library subscription, and then I don't). Anyone have any benchmarks that aren't behind a paywall? > Hi List, Is the Erlang runtime capable of spawning processes on a Xeon > Phicoprocessor? Or is this piece of hardware too rare for Erlang to beable > to take advatage of it? > -- Josh Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jun 19 17:20:57 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 19 Jun 2014 17:20:57 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2CA83.7030502@ninenines.eu> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A2CA83.7030502@ninenines.eu> Message-ID: On Thu, Jun 19, 2014 at 1:33 PM, Lo?c Hoguin wrote: > On 06/19/2014 01:06 PM, Joe Armstrong wrote: > >> You can - Here is an example of a single file cowboy server that computes >> fib(N) - >> >> [snip huge file] > > >> Put this in a file. chmod it to u+x and run it >> >> Then got to http://localhost:8124/fib?n=10 >> >> And fib(10) will be returned >> > > Joe, your one file example is longer than my many files getting started, > not to mention completely cryptic. I *explicitly* said at the end "With a small amount of refactoring this could be make just as simple as the node.js examples" This was a quick cut-and-paste job to show that it could be done - it was *never* intended an a beginners example. To make a beginners example - I'd move most of the code into the libraries and rename things fro clarity > The shebang up there isn't something you can just drop on people, you have > to explain it. Yes > You also have to say why you have an infinite receive Can be refactored out of the code > and how to stop the program. easy > Plus, doing this you'd also have to explain them that they have to > download 3 different projects manually and to put them in the appropriate > folder. > this is what something like npm should do > > And of course, the worst is that by taking this one file example, people > immediately get stuck. How do they add a second handler? I personally have > no idea how to go from that one handler escript to something bigger. > > read the rebar example at https://github.com/basho/rebar/blob/develop/bootstrap Actually bigger apps should not be built the same way as smaller apps, just because large apps need a particular structure, there is no reason why small apps need the same structure. > 2) make a packed escript that packs all the compiled code into a >> single file >> rebar is a good example of this >> > > That script takes an OTP application and bundles it into one escript. It > makes little difference with taking an OTP application and generating a > release, except the release is a lot more useful for servers. > > > Erlang was not designed to be complex - the primitives in Erlang >> (spawn_link, trap_exits, etc.) were designed to be as simple as possible >> and were intended to be called from library routines. >> > > I didn't say Erlang was designed to be complex. I'm saying running the > Erlang VM is of higher complexity than dropping a PHP file into a folder or > running nodejs myfile.js. And yes, that's true even if you use escripts. > > > To run the erlang VM I say $ erl -s .... To run node.js I say $ node ... I don't see why one is more complex than the other. Cheers /Joe -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jun 19 18:21:36 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Jun 2014 18:21:36 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A2CA83.7030502@ninenines.eu> Message-ID: <53A30E10.9070107@ninenines.eu> On 06/19/2014 05:20 PM, Joe Armstrong wrote: > I *explicitly* said at the end "With a small amount of refactoring this > could be > make just as simple as the node.js examples" > > This was a quick cut-and-paste job to show that it could be done - it > was *never* > intended an a beginners example. > > To make a beginners example - I'd move most of the code into the > libraries and rename > things fro clarity Right then we are definitely not talking about the same thing, because this part of the thread forked into Cowboy's getting started chapter territory, which is exactly the beginners first steps with Cowboy. I have no interest in a snippet as small as nodejs, because while technically more or less possible, it would not at all be representative of code people actually write. Confusing beginners with that kind of snippet is not something I see as any good. -- Lo?c Hoguin http://ninenines.eu From leonard.boyce@REDACTED Thu Jun 19 18:52:28 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Thu, 19 Jun 2014 12:52:28 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2EFBC.2060301@meetinghouse.net> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EFBC.2060301@meetinghouse.net> Message-ID: So with all the complexity issues being talked about would a basic 'app generator' along the lines of yeoman http://yeoman.io/learning/index.html not be a better fit? Maybe a binary which can set up the framework for an example application with the user having to answer a few questions. Trivial example (assumes name of simperl as binary); noobie@REDACTED$ ./simperl - Choose the application example type: 1) Web Server 2) Multi-server Ping-Pong Example > 1 - Choose the type of Web Server example 1) Simple "Hello World" web server 2) REST "Hello World" web server 3) .... > 1 Web Server installed and running. Go to http://localhost:12345/ To modify this server to print "Goodbye World" instead, edit file "simple_hello_world/src/simple_hello_world.erl" and use the command "./simperl recomplile simple_hello_world" For more information on how things actually work see: simple_hello_world/doc/README.md noobie@REDACTED$ By approaching it in this way you may achieve rapid 'satisfaction' and the ability to expose the user to anything you want with examples of differing complexity. Leonard On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman wrote: > Mahesh Paolini-Subramanya wrote: >> >> "Complexity" is a remarkably loaded term - I'm fairly certain that things >> that are complex for me (Getting anywhere via mass-transit in Tokyo) are >> pretty trivial for others (e.g., Loic). > > > Well, let's say "complex" in an engineering context, for starters. > >> Whats more, complexity of systems has nothing to do with the complexity of >> the individual components involved (DNA is a bit of a prime example here). > > > Precisely. I'd venture that one gravitates toward Erlang when one is > building systems and systems-of-systems with lots of distributed, moving > parts (e.g., a telephone switching fabric). If one is building a single, > stand-alone application, I expect Erlang might not be the "best" choice. > >> >> That said, I would claim that erlang systems are more _comprehensible_ >> than others. >> Mind you, this does require some mastery of erlang, which is not as much >> of a chicken-and-egg scenario as you might imagine. >> >> > > You know, that's a really good point, that highlights two broader issues: > conceptual models, and tooling that maps onto conceptual models: > > - Sequential code is relatively easy to conceptualize and represent - well > commented code can suffice as a representation, there are plenty of > debugging and tracing tools for examining run-time behavior > > - Object oriented code lends itself to browsers and inspector - though > execution flow can get pretty arcane (at one point, I worked on military > simulators - think game engine - each vehicle was an object, but the actual > work was done by 4 spaghetti coded threads that each ran 20 time a second - > very ugly, and what led me to discover Erlang) > > - Actor formalism (i.e., Erlang) - very easy to conceptualize for > applications where things naturally map onto independent processes (e.g., > the above-mentioned simulator -- tanks and airplanes are a lot easier to > model as processes than as objects) - but tools for visualizing, designing, > debugging systems with lots of processes, and the interactions among them, > are close to non-existent (a problem for Erlang, but also for anyone > building highly concurrent, highly distributed systems) > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From francesco@REDACTED Thu Jun 19 19:27:49 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Thu, 19 Jun 2014 18:27:49 +0100 Subject: [erlang-questions] Calls for Talks: Commercial Users of Functional Programming Message-ID: <53A31D95.1050101@erlang-solutions.com> It would be great to see Erlang represented at the CUFP workshop in Gothenburg September 4-6th. Deadline for submissions is June 27th, so still a few days to bang your heads together and come up with ideas. More info is available on the CUFP website: http://cufp.org/2014/call-for-presentations.html The annual CUFP workshop is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. Giving a CUFP Talk If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the workshop. We're looking for two kinds of talks: Experience reports are typically 25 minutes long, and aim to inform participants about how functional programming plays out in real-world applications, focusing especially on lessons learned and insights gained. Experience reports don't need to be highly technical; reflections on the commercial, management, or software engineering aspects are, if anything, more important. Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers. We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our mission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy. If you are interested in offering a talk, or nominating someone to do so, please submit your presentation before 27 June 2014 via the CUFP 2014 Presentation Submission Form You do not need to submit a paper, just a short proposal for your talk! There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more a discussion forum than a technical interchange. Nevertheless, presentations will be video taped and presenters will be expected to sign an ACM copyright release form. Note that we will need all presenters to register for the CUFP workshop and travel to Gothenburg at their own expense. -- Erlang Solutions Ltd. http://www.erlang-solutions.com From thomasl_erlang@REDACTED Thu Jun 19 19:37:53 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 19 Jun 2014 10:37:53 -0700 Subject: [erlang-questions] Calls for Talks: Commercial Users of Functional Programming In-Reply-To: <53A31D95.1050101@erlang-solutions.com> References: <53A31D95.1050101@erlang-solutions.com> Message-ID: <1403199473.32797.YahooMailNeo@web163604.mail.gq1.yahoo.com> For those not familiar with the SIGPLAN Anti-Harassment Policy, here are the guidelines. Welcome to Gothenburg and enjoy your safe conference! SIGPLAN Conference Anti-Harassment Policy The open exchange of ideas and the freedom of thought and expression are central to the aims and goals of SIGPLAN; these require an environment that recognizes the inherent worth of every person and group, that fosters dignity, understanding, and mutual respect, and that embraces diversity. For these reasons, SIGPLAN is dedicated to providing a harassment-free conference experience, and implements the?ACM policy against harassment. Conference participants violating these standards may be sanctioned or expelled from the conference, at the discretion of the conference organizers. Conference organizers are requested to report serious incidents to the SIGPLAN Vice Chair. ________________________________ A useful resource is the?Geek Feminism Wiki, which includes models for public announcements and guidance for conference staff. If you hear an inappropriate remark, intended or misjudged, this list of?comebacks?may prove useful. SIGPLAN Conference Anti-Harassment Policy | SIGPLAN Here are the SIGPLAN endorsed comebacks to inappropriate remarks: Prototype Comebacks?Edit "I don't think that sounds as funny as you want it to sound."Edit Preemptively destroys "but everyone thinks this is funny". "We're done."Edit End the line of discussion. May cause conversation participants to question where they crossed a line. "Who let you think it would be okay to say something like that?"Edit Preemptively quashes "I was only joking". "Wow, women X's are so rare/unusual": reply, "That's why it's so important that I exist"Edit Shift the dialogue from an othering to recognition. alternative: "Wow, women X's are so rare/unusual": reply, "Would you rather have a male for this? Do you also have any racial or religious preferences?"Edit deflection, though this may be contentious in its use. "Excuse me?" / "I'm sorry, I don't quite understand what you're trying to say. Could you state it more plainly?"Edit Chime in. Cause the speaker to reflect. Be prepared to follow up. "It sounds like you are implying . I'm sure you don't really think that. "Edit Exerts some social pressure against stating . "That was sexist."Edit Just saying it out loud is a good comeback. "That was sexist, and that is not acceptable here."?Edit If you are in a position of power, such as a boss or community leader, you can create, point to or enforce boundaries in response to an incident. "Hey dude, not cool."?Edit Simple vernacular disapproval of the action, rather than the person. ACM Anti-Harassment Policy The open exchange of ideas and the freedom of thought and expression are central to ACM?s aims and goals. These require an environment that recognizes the inherent worth of every person and group, that fosters dignity, understanding, and mutual respect, and that embraces diversity. For these reasons, ACM is dedicated to providing a harassment-free experience for participants at our events and in our programs. Harassment is unwelcome or hostile behavior, including speech that intimidates, creates discomfort, or interferes with a person's participation or opportunity for participation, in a conference, event or program. Harassment in any form, including but not limited to harassment based on alienage or citizenship, age, color, creed, disability, marital status, military status, national origin, pregnancy, childbirth- and pregnancy-related medical conditions, race, religion, sex, gender, veteran status, sexual orientation or any other status protected by laws in which the conference or program is being held, will not be tolerated. Harassment includes the use of abusive or degrading language,? intimidation, stalking, harassing photography or recording, inappropriate physical contact, sexual imagery and unwelcome sexual attention. A response that the participant was ?just joking,? or ?teasing,? or being ?playful,? will not be accepted. Individuals violating these standards may be sanctioned or excluded from further participation at the discretion of the organizers or responsible committee. Anti-Harassment Policy ? Association for Computing Machinery On Thursday, June 19, 2014 7:28 PM, Francesco Cesarini wrote: > > >It would be great to see Erlang represented at the CUFP workshop in >Gothenburg September 4-6th. Deadline for submissions is June 27th, so >still a few days to bang your heads together and come up with ideas. >More info is available on the CUFP website: >http://cufp.org/2014/call-for-presentations.html > >The annual CUFP workshop is a place where people can see how others are >using functional programming to solve real world problems; where >practitioners meet and collaborate; where language designers and users >can share ideas about the future of their favorite language; and where >one can learn practical techniques and approaches for putting functional >programming to work. > >Giving a CUFP Talk >If you have experience using functional languages in a practical >setting, we invite you to submit a proposal to give a talk at the >workshop. We're looking for two kinds of talks: > >Experience reports are typically 25 minutes long, and aim to inform >participants about how functional programming plays out in real-world >applications, focusing especially on lessons learned and insights >gained. Experience reports don't need to be highly technical; >reflections on the commercial, management, or software engineering >aspects are, if anything, more important. > >Technical talks are also 25 minutes long, and should focus on teaching >the audience something about a particular technique or methodology, from >the point of view of someone who has seen it play out in practice. These >talks could cover anything from techniques for building functional >concurrent applications, to managing dynamic reconfigurations, to design >recipes for using types effectively in large-scale applications. While >these talks will often be based on a particular language, they should be >accessible to a broad range of programmers. > >We strongly encourage submissions from people in communities that are >underrepresented in functional programming, including but not limited to >women; people of color; people in gender, sexual and romantic >minorities; people with disabilities; people residing in Asia, Africa, >or Latin America; and people who have never presented at a conference >before. We recognize that inclusion is an important part of our mission >to promote functional programming. So that CUFP can be a safe >environment in which participants openly exchange ideas, we abide by the >SIGPLAN Conference Anti-Harassment Policy. > >If you are interested in offering a talk, or nominating someone to do >so, please submit your presentation before 27 June 2014 via the > >CUFP 2014 Presentation Submission Form > >You do not need to submit a paper, just a short proposal for your talk! >There will be a short scribe's report of the presentations and >discussions but not of the details of individual talks, as the meeting >is intended to be more a discussion forum than a technical interchange. > >Nevertheless, presentations will be video taped and presenters will be >expected to sign an ACM copyright release form. > >Note that we will need all presenters to register for the CUFP workshop >and travel to Gothenburg at their own expense. > >-- >Erlang Solutions Ltd. >http://www.erlang-solutions.com > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Thu Jun 19 22:37:55 2014 From: ryankbrown@REDACTED (Ryan Brown) Date: Thu, 19 Jun 2014 14:37:55 -0600 Subject: [erlang-questions] Transform mnesia table into new table Message-ID: I have an escript that I can run to update the data in an existing mnesia table: #!/usr/bin/env escript %% -*- erlang -*- -include("record_defs.hrl"). main([NodeIn|_]) -> Node = list_to_atom(NodeIn), ok = migrate_record_schema(Node), halt(). migrate_record_schema(Node) -> MigrationFun = fun({ old_record, Id, Name, DateCreated, DateDeactivated, Password, Url }) -> { new_record, Id, Name, DateCreated, DateDeactivated, Password, Url, false } end, {atomic, ok} = rpc:call(Node, mnesia, transform_table, [old_record, MigrationFun, record_info(fields, new_record)]), ok. The problem I have is that when I deploy the code that uses this new record schema and update the schema, this new transformed data gets replicated to the other clustered nodes as well. So, what I was hoping to do was create a new table say new_record, that I place the transformed records into. The new code will reference that table. The yet-to-be-upgraded nodes will still continue to reference the old schema until they get the new code deployed. Is this possible without jumping through major hoops? Or, maybe I'm missing a simpler solution? Any help would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.rubyist@REDACTED Thu Jun 19 21:25:58 2014 From: josh.rubyist@REDACTED (Josh Adams) Date: Thu, 19 Jun 2014 14:25:58 -0500 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EFBC.2060301@meetinghouse.net> Message-ID: > > So with all the complexity issues being talked about would a basic > 'app generator' along the lines of yeoman > http://yeoman.io/learning/index.html not be a better fit? > I like everything about this idea to be honest. It took a while for me to really get down into Erlang as a beginner. People that haven't been an erlang beginner for a while might not remember so thoroughly. Anyway, seems good. -Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Thu Jun 19 23:41:23 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Thu, 19 Jun 2014 23:41:23 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: J David Eisenberg writes: > On Mon, Jun 16, 2014 at 6:26 PM, wrote: >> So this boils down to motivation to sustain through the learning curve and pureness >> of the fresh minds to avoid having to unlearn other paradigms. > > Other thoughts about this: > > 1) Graphics: An absolute necessity. "Hey, kids, let's output Fibonacci > numbers!" falls flat. "Hey, kids, let's draw this cool spiral (which > happens to use Fibonacci numbers)!" is much more appealing. As for > Erlang and graphics, there's Wings 3D, and I'm not sure how easy that > is to get into > The graphics toolkit does not have to be in Erlang - as long as we can control it from Erlang then it is fine. > 2) Elixir vs. Erlang: I'm going to vote for Erlang here. I like > Elixir, and I like its libraries that make general-purpose programming > easier. However, it *looks* like an imperative language, and that will > cause interference for those beginners who may have done some > JavaScript or Python (i.e., Raspberry Pi programmers). One advantage > of Erlang (or LFE or Clojure) is that it doesn't look anything like a > typical imperative language, so I'm not tempted to think in imperative > terms. Erlang's single assignment vs. Elixir's ability to rebind a > variable is another way that Erlang will "lead me not into > temptation." > Tricky - familiarity can work both ways. As I think more deeply about it, the traits of Erlang that really matter are concurrency and pattern matching - not the full functional programming paradigm. We can talk about reassignment as being Evil?, but since it is only for variables the damage is constrained. From the imperative bag of evilness I find that shared variables and objects are way more polluting for the mind. Erlang and Elixir structure programs around two things: modules and processes. The processes hold some state and it is easy to protect that state with a good API. Modules can abstract out the inner details of data structures and since functions do not have shared data it is easy to understand what is going on. Syntax does not make a language imperative. > 3) Existing materials for other languages: I'm very impressed by > http://www.bootstrapworld.org/ > I think that the style and theme of BootstrapWorld is spot on - lots to steal there! > 4) What do you really want to teach/Erlang's problem space. Erlang is > designed for solving problems of "fault-tolerant, concurrent, > distributed programming" -- are you teaching Erlang for those > properties, in which case you need to map them into the problem space > that young programmers might be interested in, or are you teaching it > as a general functional programming language? That's not the same as a > general-purpose programming language, of course. I have hinted at this before: I think there is an underlying programming style in Erlang which is more about concurrency and fail-fast that has a lot of mileage. That and the functional aspects can solve a lot of problems in an elegant manner. That's where I think the focus should be. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Thu Jun 19 23:47:17 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Thu, 19 Jun 2014 23:47:17 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: Hi Lee, What would you use as the first language? Erlang or Elixir? And why? Cheers, Torben Lee Sylvester writes: > My 5 cents? > > I started using Google Go, as I needed concurrency with lightweight processes for cloud applications development. Problem was, it was too immature. I enjoyed the language, but I found I had to do so much grunt work that it was tiring and the road to completion was too long. So, I looked into Erlang. Same concurrent goodness. Same lightweight processes. Much more mature. > > The first thing I did was read Learn You Some Erlang for Great Good. Very good book, but very verbose. Still, it was worth reading. However, while Learn You Some Erlang helped me understand the grammar and the context of development in Erlang, it was Erlang/OTP in Action that grounded it and gave me a solid understanding in how apps should be written in Erlang. > > It took me a week to learn enough to write my first app. It took two weeks for me to feel comfortable with the language and platform as a whole. Now, I feel like Erlang is how platforms should be built. > > Recently, I jumped onto the Elixir bandwagon. Elixir is very much like Erlang in many ways, but taken a step further, with a nicer syntax and some added goodness. I think Elixir is where I?ll stay for some time :-) > > Btw, writing concurrent, fault-tolerant and scalable apps in Erlang is crazy simple. I often laugh to myself when things just work and scale like I wanted them to, with so little effort. > > Cheers, > Lee > > > On 16 Jun 2014, at 20:56, Torben Hoffmann wrote: > >> >> Yuri Lukyanov writes: >> >>> I'm not a teacher at all and I don't pretend to be objective here. But >>> my and my colleagues' experiences with Erlang tell me that Erlang is >>> simple to learn. Most of us came to the current company with _zero_ >>> experience in Erlang or any other functional programming experiences. >>> I personally was a complete PHP guy. My first impression on Erlang was >>> "it's very different and hard to learn". But in two weeks we was able >>> to read and understand Erlang code and write simple stuff. >>> >>> My point is that Erlang is not hard-to-learn, but rather >>> hard-to-realize-it-is-easy-to-learn. It's easier than one can imagine. >>> Perhaps, that could be a statement to spread out. >>> >> What happened for you guys? >> How did you approach the learning? >> What problems did you look at? >> What motivated you to look at Erlang in the first place? >> >> All info on your transformation is interesting. >> >> Cheers, >> Torben >> >> >>> Just thinking aloud. >>> >>> >>> On Mon, Jun 16, 2014 at 11:51 AM, Torben Hoffmann >>> wrote: >>>> Hi, >>>> >>>> The wonderful thread on "Beginners tutorials" >>>> (http://erlang.org/pipermail/erlang-questions/2014-June/079485.html) that Joe started >>>> after the EUC last week has touched something in me and I want to get some feedback >>>> on my ideas. >>>> >>>> I think that Joe's original suggestion in the "Beginners tutorials" thread can do >>>> something with regards to easing people into Erlang, but it cannot be the only thing. >>>> >>>> I saw Garrett's wonderful talk at the EUC last week - Why the Cool Kid's Don't Use >>>> Erlang (http://www.erlang-factory.com/euc2014/garrett-smith) - and it suggested a >>>> number of things we, as a community, can do better. >>>> >>>> One thing that stood out in relation to this thread was HardToLearn. >>>> >>>> HardToLearn influences a lot of things, but it also drives the worry >>>> FindingDevelopers, which bad for the career prospects for all of us. >>>> See Garrett's talk (when online) and you will understand. >>>> >>>> Why is Erlang HardToLearn? >>>> >>>> One can point to documentation and say it is not optimal. >>>> One can ask for books on Erlang Concurrency Patterns as Joe did. >>>> >>>> But I feel there is a more fundamental problem that we need to address: >>>> how to think like an Erlanger. >>>> >>>> Erlang is a concurrent functional language with a unique failure model. >>>> More than 2 nines of the people being taught anything on programming will be exposed >>>> to procedural or object oriented languages with exceptions and be told that threads >>>> are hard (they are 'cause they will make you loose your hair). >>>> >>>> I think that a learning resource focused on teaching people the Erlang model from the >>>> ground up would be a great improvement. A clear narrative around how do we solve a >>>> problem the Erlang way. Teaching the basic constructs is not the problem. >>>> >>>> My initial target for such a learning resources would be young people in the higher >>>> grades of elementary school, say 12-15 years. Why? Because I want to influence them >>>> before their minds are totally corrupted by other programming models. >>>> >>>> I don't think we would have to dumb anything down in particular for this group - we >>>> just have to find a cool example and organise the learning around how to become so >>>> good that one can solve such a problem. >>>> Some sort of game will probably be the best candidate, say, some sort of Transport >>>> Tycoon clone?!?! >>>> >>>> And now for the controversial part of my idea: this should probably be done using >>>> Elixir plus something for the GUI. >>>> Yes, I said the other E word, so I'm ready to be stoned ;-) [1] >>>> >>>> Why Elixir? >>>> >>>> Programming Elixir requires the same understanding of the Erlang concurrency model in >>>> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame >>>> and misses the boat totally. >>>> >>>> So using Elixir would allow us to expose people to the Erlang model, which I think is >>>> the main point. The more people that uses the BEAM, the better for the >>>> FindingDevelopers problem. >>>> >>>> What is better about Elixir from a learning standpoint is, in my highly subjective >>>> opinion, that you can get started quite easily with the mix tool. >>>> >>>> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old >>>> son to have a look in the "Introducing Elixir" book and his initial reaction was >>>> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good >>>> thing! >>>> >>>> Given that I think games are awesome for teaching there needs to be some sort of GUI >>>> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it >>>> is functional, but other suggestions are most welcome. >>>> >>>> Am I on the right track to anything with this? >>>> Is there a need for such a learning resource? >>>> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into? >>>> >>>> Cheers, >>>> Torben >>>> >>>> [1] https://www.youtube.com/watch?v=SYkbqzWVHZI >>>> -- >>>> Torben Hoffmann >>>> CTO >>>> Erlang Solutions Ltd. >>>> Tel: +45 25 14 05 38 >>>> http://www.erlang-solutions.com >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- >> Torben Hoffmann >> CTO >> Erlang Solutions Ltd. >> Tel: +45 25 14 05 38 >> http://www.erlang-solutions.com >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Thu Jun 19 23:53:31 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Thu, 19 Jun 2014 23:53:31 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <1402930552.68297.YahooMailNeo@web163601.mail.gq1.yahoo.com> References: <20140616124733.GL51530@ferdair.local> <1402930552.68297.YahooMailNeo@web163601.mail.gq1.yahoo.com> Message-ID: I like the idea. Unfortunately they only have a Windows version, so I cannot check it out :-( Thomas Lindgren writes: > In the dark ages Ken Kahn demoed ToonTalk, which I thought was a pretty neat way of teaching concurrent programming (with actors) to kids. > > ToonTalk - Wikipedia, the free encyclopedia > > > ToonTalk - Wikipedia, the free encyclopedia > ToonTalk is a computer programming system intended to be programmed by children. The "Toon" part stands for cartoon. The system's presentation is in the form of animated characters, including robots that can be trained by example. It is one of the few successful implementations ou... > View on en.wikipedia.org Preview by Yahoo > > Or this:Computer scientists ask "What is ToonTalk?" > > Computer scientists ask "What is ToonTalk?" > The Computer Science behind > ToonTalk ToonTalk is an interpreter for a concurrent constraint > programming language. > View on www.toontalk.com Preview by Yahoo > > Best, > > Thomas > > > > On Monday, June 16, 2014 2:47 PM, Fred Hebert wrote: > > >> >> >>There's a lot to discuss in this thread (and Joe's one last week). This >>is a bit of a rambling from me, but yeah. >> >>On 06/16, Torben Hoffmann wrote: >>> Why is Erlang HardToLearn? >>> >> >>We should ask newcomers. When I started, Erlang was hard to learn for >>specific reasons: terminology, availability of information (we had the >>series of blog posts about an Erlang bank in OTP and the trapexit >>cookbooks, and that was most of it if you didn't feel like paying for a >>book) >> >>Since I've learned the language, the context changed in massive ways. >>LYSE is available, Cowboy has gained docs, Chicagoboss has a manual, >>more books have come around, more tutorials have been published, more >>talks have been made available. >> >>The problem isn't solved, but as a community, we shifted it to a new >>different area. Newcomers will have had the difficult pressure point >>somewhere else, and newcomers should therefore be able to tell us what >>*they* found hard, without having more experienced people contradicting >>them on many points -- We learned at a different time in a different >>context. >> >>We should ask people who have quit learning the language. Sometimes we >>will disagree, sometimes it will be due to their background of areas of >>interest, but there is a lot to for us to learn there. >> >>We should ask people who don't feel like learning it. We have pieces of >>data, such as people not liking the documentation, but we don't know >>*why* that is. Fixing the doc without fixing what's wrong is a bad idea, >>the same way premature optimization is. >> >> >>> how to think like an Erlanger. >>> >>> >>> I think that a learning resource focused on teaching people the Erlang model from the >>> ground up would be a great improvement. A clear narrative around how do we solve a >>> problem the Erlang way. Teaching the basic constructs is not the problem. >>> >> >>Architecture is a definitive place where that needs to happen. I >>remember fumbling around wondering "but what do I make a process?" -- >>not sure if it's still an issue. >> >>I remember (and still often encounter) the issue of algorithms and >>datastructure. Everything you've learned before tends to assume O(1) >>access to mutable memory and it's no longer true. But then again, the >>relevance of this depends who you want to teach to. People who already >>program, or people who don't program yet. >> >>> My initial target for such a learning resources would be young people in the higher >>> grades of elementary school, say 12-15 years. Why? Because I want to influence them >>> before their minds are totally corrupted by other programming models. >>> >> >>Ah, so you want to be the first one to corrupt their minds, then! >> >>Snark aside, if we want to teach children, we should reach out to >>organisms such as https://www.codeclub.org.uk/ (who do this *every >>day*). We should look at what it is they do, ask them, see what they >>recommend, and tell us what wouldn't work. >> >>We can also look at How To Design Programs >>(http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed >>to teach programming to new people. They show you how to animate rocket >>ships in the first chapter. Erlang books (mine included) tell you what >>an atom is and why you should care. That's okay, they're not meant for >>newcomers. >> >>Or we can try reinventing the wheel based on what we feel is really >>important, but what we feel is really important likely doesn't overlap >>super well to what is important to a teenager. There are people who >>dedicate their lives to working on that problem, they're the ones from >>whom we should be looking for for guidance. >> >>Many of us know Erlang, but few of us know how to teach. A lot of us >>have forgotten what it is like to not know how to program. >> >>> >>> What is better about Elixir from a learning standpoint is, in my highly subjective >>> opinion, that you can get started quite easily with the mix tool. >>> >> >>If we want to reach out to crowds who aren't familiar with programming >>at all, mix isn't gonna cut it either. Look at Scratch >>(http://scratch.mit.edu/), look at Logo, look at Racket's graphical >>language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html), >>look at Arduino's documentation >>(http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which >>looks like it has another great intro. >> >>We have a long way to go, whether Elixir or Erlang is being used. Most >>people still put Erlang's sweet spot into the 'server' area in Garrett's >>data. Do we have to make the person we're gonna teach to care about >>servers to have teaching Erlang worth their time? Because it looks like >>otherwise, we might as well teach them a language more adapted to what >>they care about, not one adapted to what we care about. >> >>If we plan on reaching out to the already-programmign crowd, then yes, a >>tool like Mix is useful. It would also be useful within Erlang for its >>community. Rebar templates aren't even that far from allowing a lot of >>that functionality, but the community hasn't banded together to do it. >> >>There are probably deep-rooted reasons for it -- many of us adopted >>Erlang when you managed dependencies by downloading them and checking >>them in your repo, used makefiles all the time, and whatnot. The stuff >>rebar or erlang.mk do is already convenient enough for a lot of us to >>have felt the pain eased away, at least to the extent where we're not >>compelled to help fix the problem anymore. The workarounds are nicer >>than what we had before, so workarounds it will be. Forever. >> >>The same is true for the documentation. They're mostly reference manuals, >>which by definition are to be used as a reference -- it is expected you >>know their content and are only looking up additional information, or >>data to help you recall what you already learned. They won't be good to >>learn (the tutorials are nicer, but who knows about them?), and none of >>the regulars will have any incentive to fix it. >> >>Anyway, that's a long rant enough. >> >>Regards, >>Fred. >> >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions >> >> >>_______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Thu Jun 19 23:57:16 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Thu, 19 Jun 2014 23:57:16 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> References: <20140616125952.GM51530@ferdair.local> <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> Message-ID: I am not going for fault tolerance - concurrency and a dash of functional programming are the things to focus on. The joy of having something fail fast and learn to program with that is something I strive to pass on to as many people as possible!! Cheers, Torben Jon Schneider writes: > I think to understand fault tolerance you also need some understanding of > business, customer service and the things that make a servers go offline > such as power failure and road diggings. > > Therefore I am pretty sure think this particular aspect is not something a > youngster is ever going to get. > > Jon -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Fri Jun 20 00:05:28 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 20 Jun 2014 00:05:28 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <20140616134413.GO51530@ferdair.local> References: <20140616125952.GM51530@ferdair.local> <5ec7cd6ea1a696f3c38d47de166ed99e.squirrel@mail.jschneider.net> <539EED6F.5020506@ninenines.eu> <20140616134413.GO51530@ferdair.local> Message-ID: Fred Hebert writes: > Or teach it through side-channels with examples. Here's a random idea, > probablu full of holes. > > Show them a bunch of castles with different things: heights for walls, > thickness for walls, number of walls, towers, drawbridges, moats, etc. > > - Which castle is the best? > - Which castle would protect you best against dragons? Against > catapults? Against knights? Sorcerers? > - Which castle would be the safest to be in? > - Why is Castle A safer than Castle B for X? > - There's an army of knights and catapults coming. How would you build a > castle to protect you against it? > - What do you do if the catapults break a wall or the drawbridge? > - Here's my castle, can you make it safer against sorcerers? > > Maybe there's a way through there to lead a discussion into topics like > redundancy, time to repair, and so on, without even needing to involve > any computers or their related terminology in the first place. > I think this is a brilliant way of discussing design. However, I think it is something that should come a bit down the road as it touches on aspects that are a bit too advanced for beginners, but I really like the idea of using appropriate side-channels that can re-use existing thinking and reasoning. > It may help to look at things such as Bloom's Taxonomy[1] into figuring out > what to teach, how to teach it, and how to evaluate it, if one really > wants to. > > [1]: http://en.wikipedia.org/wiki/Bloom%27s_taxonomy > Good model - that is worth having in mind. Thanks for the link! Cheers, Torben > > On 06/16, Lo?c Hoguin wrote: >> Don't assume clusters of servers. Even 4 year olds have experienced the >> annoyance of having a program crash. That's also what fault tolerance is >> about. >> >> On 06/16/2014 03:10 PM, Jon Schneider wrote: >> >I think to understand fault tolerance you also need some understanding of >> >business, customer service and the things that make a servers go offline >> >such as power failure and road diggings. >> > >> >Therefore I am pretty sure think this particular aspect is not something a >> >youngster is ever going to get. >> > >> >Jon >> > >> >_______________________________________________ >> >erlang-questions mailing list >> >erlang-questions@REDACTED >> >http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> -- >> Lo?c Hoguin > > >> http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Fri Jun 20 00:11:17 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 20 Jun 2014 00:11:17 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: +1 one on the nice collection of simple tasks that builds up to something bigger. That was how I structured the Java course I taught at the Technical University of Denmark. Lots of small game related tasks and finally a project period about doing a game. Lots of happy students. Cheers, Torben Ferenc Holzhauser writes: > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. That's a bit of a challenge considering > that Erlang is created to solve problems that are rather "industrial" and > most people "from outside" can't really relate to. If the audience is not > comfortable with understanding the problem itself then it is tricky to make > them understand/like the solution too. > > This we can see with many new people getting into Erlang: The problems they > are given are new and difficult to understand. So they often just go off > and eagerly try to solve all sort of issues they are familiar with (even > when they are not relevant in the particular case) before even trying to > understand what the real challenge is. Then they start complaining that > Erlang is not very good for some/many of those issues they are busy with. > > And other way around: people coming to Erlang with the right understanding > of the problem area it is made for find it amazingly simple to learn. > > Coming from the wrong (or right ?) background my imagination fails to come > up with these appealing challenges for the youngster target group, but I'm > sure many of you can do much better. > > Ferenc > > > On 16 June 2014 11:31, Miles Fidelman wrote: > >> Garrett Smith wrote: >> >>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>> wrote: >>> >>> -snip- >>> >>> I think that a learning resource focused on teaching people the Erlang >>>> model from the >>>> ground up would be a great improvement. A clear narrative around how do >>>> we solve a >>>> problem the Erlang way. Teaching the basic constructs is not the problem. >>>> >>>> My initial target for such a learning resources would be young people in >>>> the higher >>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>> influence them >>>> before their minds are totally corrupted by other programming models. >>>> >>>> I don't think we would have to dumb anything down in particular for this >>>> group - we >>>> just have to find a cool example and organise the learning around how to >>>> become so >>>> good that one can solve such a problem. >>>> Some sort of game will probably be the best candidate, say, some sort of >>>> Transport >>>> Tycoon clone?!?! >>>> >>> I don't have enough experience teaching programming to this age group >>> to provide anything more than a hunch. But I suspect that the Erlang >>> way, which is hard enough for very seasoned programmers to grok, might >>> be a bit ambitious for these young learners. >>> >>> I'm speaking in particular about the model that emerges when you >>> isolate processes. It changes everything: your approach to building >>> software (move from state oriented to activity oriented), error >>> handling (move from defensive measures to assertive/let-it-crash), >>> program structure (from monolith to system), and so on. The benefits >>> of this shift are hard to get across, in my experience anyway. I wish >>> it wasn't, or I wish I was better at communicating. >>> >>> >>> >> I'm with the folks who suggest that this group has fewer pre-conceptions >> to unlearn. >> >> It strikes me that the actor model is far more natural for certain classes >> of problems - network code, simulation, and gaming come to mind. It's >> simply conceptually easier to think in terms of LOTS of independent >> processes. >> >> Miles Fidelman >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Fri Jun 20 00:25:04 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 20 Jun 2014 00:25:04 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: Bob Ippolito writes: > On Monday, June 16, 2014, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > >> The most important thing here I believe is to have a nice collection of >>> simple tasks/problems that are appealing to the target audience and best >>> (easiest/nicest) solved in Erlang. >> >> Amen! >> The least relevant part of teaching kids programming is the syntax, or the >> choice of language - they don't, and won't, give a s**t about it. >> > > As someone who has been trying to teach programming, I find that syntax is > important in that syntax can get in the way. This is one of the reasons why > the current fashion is to use visual languages for beginners as the "Lego" > approach makes it impossible to violate syntax rules. > > Erlang might be the better choice as it has a simpler syntax with fewer > rules and surprises in store. > True, the language is simple. The difficulty lies in the tooling and the stuff around making things work. > >> As a simple thought experiment, just look at how you raised your kids in a >> multi-lingual environment (yes my American brethren, this is hard. Pretend >> :-) ) Notice how they - fluidly - bounce across languages, massacring >> every grammar rule ever, but quite happily making sure that you understand >> that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio >> odio la piselli, i don't wanna, where is my red truck?" >> Mind you, they will pick up the rules over time, but the key here is the >> importance of the problem at hand ("How To Avoid Eating Peas") - the more >> immediately relevant it is to the young 'uns, the more rapidly they will >> pick up the tools, the specifics of the language be damned. >> > > Human languages are different in that people can understand syntactically > invalid spoken word or even mixed languages (per your example). With code > you either write something that follows the rules and the computer > understands it, or you have to figure out which rules you violated. If the > tools are good and the rules are simple or at least consistent it might not > be so frustrating to pick them up over time by trial and error, but having > a few simple rules that are taught up-front might be even less frustrating > than that. > This sort of buries Java completely ;-) But that's not going to save the day for Erlang/Elixir. Simple, consistent rules are really important. On the consistency side the Elixir libraries has the upper hand - has to play more with the build tools in Elixir to gauge if it is easier to explain than Erlang's. Cheers, Torben > Cheers >> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >> ferenc.holzhauser@REDACTED> wrote: >> >> The most important thing here I believe is to have a nice collection of >> simple tasks/problems that are appealing to the target audience and best >> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >> that Erlang is created to solve problems that are rather "industrial" and >> most people "from outside" can't really relate to. If the audience is not >> comfortable with understanding the problem itself then it is tricky to make >> them understand/like the solution too. >> >> This we can see with many new people getting into Erlang: The problems >> they are given are new and difficult to understand. So they often just go >> off and eagerly try to solve all sort of issues they are familiar with >> (even when they are not relevant in the particular case) before even trying >> to understand what the real challenge is. Then they start complaining that >> Erlang is not very good for some/many of those issues they are busy with. >> >> And other way around: people coming to Erlang with the right understanding >> of the problem area it is made for find it amazingly simple to learn. >> >> Coming from the wrong (or right ?) background my imagination fails to come >> up with these appealing challenges for the youngster target group, but I'm >> sure many of you can do much better. >> >> Ferenc >> >> >> On 16 June 2014 11:31, Miles Fidelman wrote: >> >> Garrett Smith wrote: >> >> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >> wrote: >> >> -snip- >> >> I think that a learning resource focused on teaching people the Erlang >> model from the >> ground up would be a great improvement. A clear narrative around how do we >> solve a >> problem the Erlang way. Teaching the basic constructs is not the problem. >> >> My initial target for such a learning resources would be young people in >> the higher >> grades of elementary school, say 12-15 years. Why? Because I want to >> influence them >> before their minds are totally corrupted by other programming models. >> >> I don't think we would have to dumb anything down in particular for this >> group - we >> just have to find a cool example and organise the learning around how to >> become so >> good that one can solve such a problem. >> Some sort of game will probably be the best candidate, say, some sort of >> Transport >> Tycoon clone?!?! >> >> I don't have enough experience teaching programming to this age group >> to provide anything more than a hunch. But I suspect that the Erlang >> way, which is hard enough for very seasoned programmers to grok, might >> be a bit ambitious for these young learners. >> >> I'm speaking in particular about the model that emerges when you >> isolate processes. It changes everything: your approach to building >> software (move from state oriented to activity oriented), error >> handling (move from defensive measures to assertive/let-it-crash), >> program structure (from monolith to system), and so on. The benefits >> of this shift are hard to get across, in my experience anyway. I wish >> it wasn't, or I wish I was better at communicating. >> >> >> >> I'm with the folks who suggest that this group has fewer pre-conceptions >> to unlearn. >> >> It strikes me that the actor model is far more natural for certain classes >> of problems - network code, simulation, and gaming come to mind. It's >> simply conceptually easier to think in terms of LOTS of independent >> processes. >> >> Miles Fidelman >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. >> >> -- >> >> * Mahesh Paolini-Subramanya >> That >> tall bald Indian guy..* >> * Google+ >> | Blog | Twitter >> | LinkedIn >> * >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Fri Jun 20 00:43:08 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 20 Jun 2014 00:43:08 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> Message-ID: Again, using building blocks. Good example. Ferenc Holzhauser writes: > Robotics is really nice but in this case accessibility is even nicer. It is > great if kids can play after class too with interesting things without > having to put items of fairly significant value (for some) on their > wishlist. These days a > computer with internet access can be a fascinatingly accessible way of > creativity. An idea could be to make a simple game backend to compete with > their friends and fellow students (e.g. a 2d tank shooting game or > something). Eventually with chat and similar functions to add. Then the > teacher could make things go wrong on the server(s) that they'd need to fix > (distribute/scale/fail over) depending on their progress. You could lure > them into AI like things too if you fancy. I'm sure someone with the skills > (e.g. SVG/ezwebframe) and time could make some simple client "building > blocks" work for something like this. > > > On 16 June 2014 18:12, Tony Rogvall wrote: > >> >> On 16 jun 2014, at 13:55, Mark Nijhof >> wrote: >> >> +1 on this, this rings very true to home. But I also believe that it needs >> to return results quickly. I.e. building a game is great, but if they have >> to "code" for days before they see something happen then they loose >> interest (assumption). So preparing "building blocks" might be a good >> approach and have them first implement higher level stuff and then step by >> step dig deeper and implement the building blocks you prepared. >> >> An other exercise I planned is to program a drone (not sure about the >> language there yet) to fly an obstacle course. So they see it is not just >> something that happens on their iPads ;) >> >> You program drone in Erlang of course :-) >> >> https://github.com/tonyrog/edrone >> >> /Tony >> >> -Mark >> >> >> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >> mahesh@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. >>> >>> Amen! >>> The least relevant part of teaching kids programming is the syntax, or >>> the choice of language - they don't, and won't, give a s**t about it. >>> As a simple thought experiment, just look at how you raised your kids in >>> a multi-lingual environment (yes my American brethren, this is hard. >>> Pretend :-) ) Notice how they - fluidly - bounce across languages, >>> massacring every grammar rule ever, but quite happily making sure that you >>> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >>> odio odio odio la piselli, i don't wanna, where is my red truck?" >>> Mind you, they will pick up the rules over time, but the key here is the >>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>> immediately relevant it is to the young 'uns, the more rapidly they will >>> pick up the tools, the specifics of the language be damned. >>> >>> Cheers >>> >>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >>> ferenc.holzhauser@REDACTED> wrote: >>> >>>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>> that Erlang is created to solve problems that are rather "industrial" and >>>> most people "from outside" can't really relate to. If the audience is not >>>> comfortable with understanding the problem itself then it is tricky to make >>>> them understand/like the solution too. >>>> >>>> This we can see with many new people getting into Erlang: The problems >>>> they are given are new and difficult to understand. So they often just go >>>> off and eagerly try to solve all sort of issues they are familiar with >>>> (even when they are not relevant in the particular case) before even trying >>>> to understand what the real challenge is. Then they start complaining that >>>> Erlang is not very good for some/many of those issues they are busy with. >>>> >>>> And other way around: people coming to Erlang with the right >>>> understanding of the problem area it is made for find it amazingly simple >>>> to learn. >>>> >>>> Coming from the wrong (or right ?) background my imagination fails to >>>> come up with these appealing challenges for the youngster target group, but >>>> I'm sure many of you can do much better. >>>> >>>> Ferenc >>>> >>>> >>>> On 16 June 2014 11:31, Miles Fidelman >>>> wrote: >>>> >>>>> Garrett Smith wrote: >>>>> >>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>> wrote: >>>>>> >>>>>> -snip- >>>>>> >>>>>> I think that a learning resource focused on teaching people the >>>>>>> Erlang model from the >>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>> do we solve a >>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>> problem. >>>>>>> >>>>>>> My initial target for such a learning resources would be young people >>>>>>> in the higher >>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>> influence them >>>>>>> before their minds are totally corrupted by other programming models. >>>>>>> >>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>> this group - we >>>>>>> just have to find a cool example and organise the learning around how >>>>>>> to become so >>>>>>> good that one can solve such a problem. >>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>> of Transport >>>>>>> Tycoon clone?!?! >>>>>>> >>>>>> I don't have enough experience teaching programming to this age group >>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>> be a bit ambitious for these young learners. >>>>>> >>>>>> I'm speaking in particular about the model that emerges when you >>>>>> isolate processes. It changes everything: your approach to building >>>>>> software (move from state oriented to activity oriented), error >>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>> program structure (from monolith to system), and so on. The benefits >>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>> it wasn't, or I wish I was better at communicating. >>>>>> >>>>>> >>>>>> >>>>> I'm with the folks who suggest that this group has fewer >>>>> pre-conceptions to unlearn. >>>>> >>>>> It strikes me that the actor model is far more natural for certain >>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>> processes. >>>>> >>>>> Miles Fidelman >>>>> >>>>> >>>>> -- >>>>> In theory, there is no difference between theory and practice. >>>>> In practice, there is. .... Yogi Berra >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> >>> * Mahesh Paolini-Subramanya >>> That >>> tall bald Indian guy..* >>> * Google+ >>> | Blog | Twitter >>> | LinkedIn >>> * >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> "Installing applications can lead to corruption over time. Applications >> gradually write over each other's libraries, partial upgrades occur, user >> and system errors happen, and minute changes may be unnoticeable and >> difficult to fix" >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From steven.charles.davis@REDACTED Fri Jun 20 01:27:53 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 19 Jun 2014 16:27:53 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: Message-ID: <06d70b2a-765b-430a-9484-6056cb03f628@googlegroups.com> Eshell V6.0 (abort with ^G) 1> X = 1. 1 2> X. 1 3> X = 2. ** exception error: no match of right hand side value 2 4> X = 1. 1 5> Let us imagine that X always did equal 1, even before we made the statement "X = 1." Perhaps, only a child would understand this and work with it... Kids have an unbelievable capacity for imagining, and being creative. Even perhaps with the concept of "state space" I don't see a convincing resolution of the issue of state in computing so far. /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Jun 20 02:30:21 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 20 Jun 2014 12:30:21 +1200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2EAF3.6040602@meetinghouse.net> References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EAF3.6040602@meetinghouse.net> Message-ID: In another thread, Thomas Lindgren mentioned ToonTalk. From Ken Kahn's original paper about ToonTalk: Some of the design principles derived from good construction toys and video games include: 1. Make the initial experience simple and gradually increase complexity. 2. Encourage exploration and curiosity. 3. Provide and maintain appealing fantasies. 4. Continually challenge without frustrating. 5. Frequent use of animation and film techniques and principles (video games only). ... maybe the difficulty is not in the concepts per se but their lack of accessible metaphors. We got a bunch of bills recently, and it occurred to me that there's probably a good metaphor for Erlang 'receive' there: messages *arrive* at our house in some definite order, but we can look at the envelope and decide which one to open first. The HTMLisation of documentation has made it much much harder for me to comprehend. It's like the difference between learning UNIX programming from a jumbled set of man pages and learning UNIX programming from Stevens' book. What I personally need in dealing with something like rebar or cowboy is something that *starts* by explaining - purpose - models - metaphors I'm still wondering where the rebar manual *is* and why it wasn't in the release. I should also say that my experience of npm has not been positive. There was a program that I very much wanted to play with that was distributed that way. Step 1: install npm and get it to work in my environment. (a day later) Step 2: install the package. Step 3: contact developer to find out why that doesn't work. Step 4: install the package. Step 5: contact developer to find out why it still doesn't work. Step 6: install the package. Step 7: fish around inside the rubble to find a working piece. (npm was *supposed* to install it in a directly runnable way. It didn't.) Step 8: run the program. Step 9: oh, it's not finished yet. I'd like to thank Kennita Watson for the First and Second Laws of Examples: ONE. There must *BE* examples. Lots of them. TWO. The examples must WORK. For the user! From ok@REDACTED Fri Jun 20 03:03:51 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 20 Jun 2014 13:03:51 +1200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> Message-ID: <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> > Evgeny M writes: >> Recursion is hard in any language without pattern matching. I don't believe that. Decades ago I was using languages like Algol, Lisp, Pop-2, in all of which pattern matching was entirely absent yet recursion was easy. I'm reminded of Susan's classroom. I think it's in "The Thief of Time." The quote goes something like this: she hadn't told the children algebra was hard, so they never found out. From ok@REDACTED Fri Jun 20 04:56:39 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 20 Jun 2014 14:56:39 +1200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> On 17/06/2014, at 8:17 PM, Torben Hoffmann wrote: > > Staying on the visual track for a second; I had a look at the DRAKON editor > (http://drakon-editor.sourceforge.net/drakon-erlang/intro.html) which has > support for Erlang to generate code. Unfortunately it does not generate idiomatic > Erlang code and the Tcl UI feels a bit dated. One thing on that page hit me in the eye: * Recursion is not immediately visible. This fits into my general "why can't I *see* the structure?" feeling about many programming languages, notably Java and Python, but Erlang too. I often get the feeling that if you need diagrams to help you find your way around, there is something important missing from the textual notation. Maybe one day I will be wise enough to see it. One of the things I always liked about Scheme was named-let: (let (( ) ... ( )) ) Within the body, is visible as a function of n arguments. It's equivalent to (letrec (( (lambda ( ... ) ))) ( ... ) So it's really just defining and calling a local recursive function. The way it's normally used is as a loop, with calls to being tail calls. (Which in Scheme means it *is* a loop, with the tail calls just rebinding the arguments and jumping.) Perhaps some 'intention annotations' might help. Is a function - not supposed to be recursive (directly or indirectly) at all? - supposed to be tail recursive (directly or indirectly)? - supposed to be generally recursive (directly or indirectly)? - meant to terminate because some measure (which?) of some argument or combination of argument (which?) strictly decreases on each recursive call? If the compiler enforced such annotations, that could both help with debugging (if you meant something to be tail recursive but it wasn't, for example) and make it easier to read. Imagine something vaguely like -recursion(sort(List, Comparator), {general, length(List)}). I must say that I find the first_to_upper example at http://drakon-editor.sourceforge.net/drakon-erlang/seq.html radically unconvincing. Yes, the two-line version "requires the reader to unpack the code in his head", but the "visual" version is about 14 times the screen area and 9 times as many words, and everything I know about reading says that this is MORE effort for a human reader. It is certainly a great deal more work for a human *writer*, so non-trivial examples are probably not going to happen. Additionally, in the 21st century, the first_to_upper/1 example is unconvincing because it is *wrong*. A really convincing example would be one that gets title-casing right for Unicode. By the time I get to page 3, I'm going "oh NO, this is flawcharts!" And the absolute stone killer example is the quicksort algorithm on the 6th page, http://drakon-editor.sourceforge.net/drakon-erlang/silh.html It has 32 unreadable boxes and something that looks like a loop but isn't one. All to express qsort([]) -> []; qsort([X|Xs]) -> qsort([L||L <- Xs, L < X]) ++ [X] ++ qsort([H || H <- Xs, H >= X]). (Oh, it turns out that there is a comparator argument as well, which I hadn't noticed. "unreadable boxes", remember?) The proof of failure? When you blow the diagram up, you discover that the key partitioning step is a rather tricky bit of *verbatim* plain old Erlang including a fun. The recommended treatment of compound conditions in DRAKON-Erlang is an open enemy of algebraic thinking and abstraction. By the time you get to page 9, a deep irony strikes home. Functional programming is criticised several times for not having loops -- which is news to anyone who has used a comprehension -- but it turns out that DRAKON-Erlang does *nothing* to reveal the looping structure that *is* there (arguably implicitly) in Erlang code. The quicksort example emphasises trivial matters and almost succeeds in hiding the core recursions. You can't *see* that it is an instance of the divide-and-conquer paradigm. Also damning: DRAKON-Erlang as presented at that site offers nothing other than aggregation for structuring a module. (I find it curious that UML does not normally show any relationships between the methods of an object. Yet these relationships can be extremely important for understanding.) Leon Sterling, writing about Prolog, came up with the idea years ago that - you can often understand Prolog predicates as 'enrichments' of an underlying 'skeleton' - the 'shape' of that skeleton is typically driven by the shape of the principal data structure it operates on - if you TEACH a an algorithm by SHOWING the underlying skeleton, students will be able to SEE the pattern, but you can't expect them all to figure it out for themselves. The first insight there is precisely the "Why Functional Programming Matters" insight about why higher-order programming is useful, and the second insight is just Michael Jackson's JSP idea applied in a declarative context. The third insight came from his experience of teaching Prolog, but is arguably the later "teach Design Patterns" idea that was known as "teach algorithm schemas" before "Design Pattern" became a buzzword. The idea that "if you have a recursive data structure, then OF COURSE you have a recursive predicate/function to compute with it, and the structure of the code is usually easy to derive from the structure of the data" removes pretty much all of the mystery from recursion, should there be any and what there is of it. > Visual Erlang (https://github.com/esl/visual_erlang) is still in its infancy, but > adding extensions to fit the teaching purpose is not impossible. One can steal ideas > from DRAKON and other notations like SDL. Having looked at DRAKON, my opinion is that it has no ideas worth stealing. By the way, who says that an embedded system cannot do graphics? These days, when I pay at a parking building, I'm using an *embedded* system that has a colour screen. See http://store.earthlcd.com/Home/ezLCD for an example of a company boasting that their touch LCD products 'work.. with any micro-controller, including Arduino'. The prices on that page are within the reach of even a school. Right now I'm looking at www.trademe.co.nz and I'm seeing "2014 New Android Jelly Bean4.2.2 10.1 inch 1024*600 capacitive touch screen Dual Core Tablet 1G DDR3 RAM 16GB Flash BT WIFI Dual Cameras ... Mic Speaker" at "buy now, $180 + $15 shipping". So that's USD 170, or 125 Euros. I see that Erlang R14 is available for Android: http://www.burbas.se/artiklar/erlang-for-the-android-plattform/ There's also http://code.google.com/p/erlang4android/downloads/detail?name=Erlang4AndroidR16B.apk which offers "a small version of Erlang" adequate for running OTP applications. So what would it be like to have pupils working on something that was plainly and visibly distributed across a bunch of cheap tablets? From raould@REDACTED Fri Jun 20 06:59:37 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 19 Jun 2014 21:59:37 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EAF3.6040602@meetinghouse.net> Message-ID: so re: npm there seem to be 2 kinds of people in the world. 1 is the kind of person for whom things work and when you tell them it didn't work for you they look at you like you are dumb/crazy. 2nd is the kind of person who touches things that everybody else told them were the shiznit and when they do touch them, they go kablooey. being one of the 2nd types the fact that so many people seem to be in the 1st category drives me nuts all too often. :-} From cobus.carstens@REDACTED Fri Jun 20 08:59:36 2014 From: cobus.carstens@REDACTED (Cobus Carstens) Date: Thu, 19 Jun 2014 23:59:36 -0700 (PDT) Subject: [erlang-questions] gb_trees utility functions In-Reply-To: References: Message-ID: <4ed42eca-b91c-4fbe-a513-8a5173e111bf@googlegroups.com> Thanks, Siri. I'll do that. Regards, Cobus On Thursday, 19 June 2014 11:10:22 UTC+2, Siri Hansen wrote: > > Hi Cobus! > > We have had a look at your code, and we think that this is indeed > something that you could contribute to the gb_trees module (we do not want > a new module for this). A pull request is the way to go. Please follow > these guidelines: https://github.com/erlang/otp/wiki/submitting-patches. > > Please note that tests must be done using common_test > (stdlib/test/dict_SUITE.erl) and documentation must be added to > stdlib/doc/src/gb_trees.xml. > > Best Regards > /siri > > > 2014-04-22 20:42 GMT+02:00 Cobus Carstens >: > >> Hi all >> >> I wrote 4 utility functions[1] that allows searching a gb_tree for: >> - the smallest key greater than the specified one >> - the smallest key greater or equal to the specified one >> - the greatest key smaller than the specified one >> - the greatest key smaller or equal to the specified one. >> >> This is nothing special, but my question (mostly directed to the OTP >> people) is: Would this be something that I can contribute to the >> gb_trees module (or maybe a gb_trees_utils module)? Would a >> pull-request suffice? >> >> [1] For those interested, the implementation can be found at: >> https://github.com/cobusc/erlang_gb_trees_utils >> >> Regards, >> Cobus >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cobus.carstens@REDACTED Fri Jun 20 09:01:19 2014 From: cobus.carstens@REDACTED (Cobus Carstens) Date: Fri, 20 Jun 2014 00:01:19 -0700 (PDT) Subject: [erlang-questions] gb_trees utility functions In-Reply-To: <6B3427FC-7F37-4CFE-9D7D-53952E8B2BB3@gmail.com> References: <6B3427FC-7F37-4CFE-9D7D-53952E8B2BB3@gmail.com> Message-ID: Hi Anthony I may get a chance to look at this over the weekend and will definitely shout if I need help. :) Regards, Cobus On Thursday, 19 June 2014 11:50:18 UTC+2, Anthony Ramine wrote: > > Yay for stdlib additions! > > Cobus: if you need help with Git or contributing to the test suited and > whatnot, feel free to come on IRC where people (myself included) will be > very happy to help. > > -- > Anthony Ramine > > Le 19 juin 2014 ? 11:10, Siri Hansen > a > ?crit : > > Hi Cobus! > > We have had a look at your code, and we think that this is indeed > something that you could contribute to the gb_trees module (we do not want > a new module for this). A pull request is the way to go. Please follow > these guidelines: https://github.com/erlang/otp/wiki/submitting-patches. > > Please note that tests must be done using common_test > (stdlib/test/dict_SUITE.erl) and documentation must be added to > stdlib/doc/src/gb_trees.xml. > > Best Regards > /siri > > > 2014-04-22 20:42 GMT+02:00 Cobus Carstens >: > >> Hi all >> >> I wrote 4 utility functions[1] that allows searching a gb_tree for: >> - the smallest key greater than the specified one >> - the smallest key greater or equal to the specified one >> - the greatest key smaller than the specified one >> - the greatest key smaller or equal to the specified one. >> >> This is nothing special, but my question (mostly directed to the OTP >> people) is: Would this be something that I can contribute to the >> gb_trees module (or maybe a gb_trees_utils module)? Would a >> pull-request suffice? >> >> [1] For those interested, the implementation can be found at: >> https://github.com/cobusc/erlang_gb_trees_utils >> >> Regards, >> Cobus >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Fri Jun 20 09:22:10 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Fri, 20 Jun 2014 09:22:10 +0200 Subject: [erlang-questions] Erlang for youngsters References: <539EB979.40605@meetinghouse.net> Message-ID: This thread would be much more interesting without all the unproven conjectures that Elixir is obviously the better choice to teach to children. I disagree. Elixir is a much worse choice to teach to children, because its not a simple language anmore. There have been several people teaching Prolog and also Erlang to children. So far there is no experience teaching Elixir to the same group. Elixir is mainly appealing to either people comming from Ruby or just for pop culture value (as is Ruby itself). Why does anybody think this makes it mor suitable to teach to kids? Why talk about not corrupting them with OOP ideas when teaching them programming and at the same time corruping them with crufty Ruby like syntax i.e. the syntax of a OOP language? What advantage does metaprogramming have for teaching kids? Having syntax for rebinding variables? This is all cruft for teaching the actual things. Just picked this one mention to Elixir as an example: On 2014-06-16 12:29:32 +0000, Darach Ennis said: > A good introductory language is scratch (http://scratch.mit.edu/) I agree, so why not build something Scratch like on top of Erlang? > followed by Python (from about 7 years of age depending on the child, > python works very well, the strict syntax is a benefit too). Erlang has a strict syntax too so it would have the same advantage. [... more stuff I agree with detelted] > With a basic feel for logic, structure and feedback from programming > tools (with assistance) then Erlang would be a good next step. Still agree. > Torben is probably right with respect to age group by setting it > to mid high school level. I think much too old but maybe its right > Elixir, also, would probably be an easier language to teach and to learn > with fringe benefits (namely learning Elixir) for some of us... And the argument goes off the rails completely for me: WHY??? This is contradictory to what you said before about Python. Elixirs syntax is more barroque and why in the world is it easier to learn than Erlang syntax (except for Ruby programmers)?? Where is the proof? Proofs by pop culture not accepted. BTW what languages are *in* today won't matter for these kids because all pop culture languages will be *out* when those kids you teach them will be in their twenties. > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya > wrote: > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and > best (easiest/nicest) solved in Erlang.? > Amen! > The least relevant part of teaching kids programming is the syntax, or > the choice of language - they don't, and won't, give a s**t about it. ? > As a simple thought experiment, just look at how you raised your kids > in a multi-lingual environment (yes my American brethren, this is hard. > Pretend :-) ?) ?Notice how they - fluidly - bounce across languages, > massacring every grammar rule ever, but quite happily making sure that > you understand that "I amn't going to eat pea,????? ????????,????? > ????????, odio odio odio la piselli, i don't wanna, where is my red > truck?" > Mind you, they will pick up the rules over time, but the key here is > the importance of the problem at hand ("How To Avoid Eating Peas") - > the more immediately relevant it is to the young 'uns, the more rapidly > they will pick up the tools, the specifics of the language be damned. 100% agree! And BTW this is the Erlang channel, why would we work on our own demise by teaching all these kids Elixir?? How would this help the problems Garett was mentioning? Cheers, -- Peer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddosia@REDACTED Fri Jun 20 09:31:00 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Fri, 20 Jun 2014 00:31:00 -0700 (PDT) Subject: [erlang-questions] Style question: accessing record fields in a function clause pattern match? In-Reply-To: References: Message-ID: I am trying to stick to the rule: if match header longer then 80 chars then I move all the variables bindings to function body, so only necessary to proper matching parts will be left. On Tuesday, June 17, 2014 6:21:27 PM UTC+4, Roger Lipscombe wrote: > > I'm currently refactoring some code, and I've got something like this: > > handle_foo(#state { type = bar, id = Id }) -> whatever; > handle_foo(#state { type = baz, parent_id = ParentId }) -> whatever. > > ...and I'm wondering whether it's considered bad form to access record > fields at the same time as matching them in a function clause. I'm > matching on 'type', and accessing 'id' at the same time, I mean. > > Instead, should I consider something like the following? > > handle_foo(#state { type = bar }) -> > Id = State#state.id, > whatever; > handle_foo(#state { type = baz }) -> > ParentId = State#state.parent_id, > whatever. > > The first form makes it explicit that for different types, different > fields matter (which might be a smell by itself), but it gets hard to > see the match on 'type' once I'm accessing more than one or two > fields. > > I know this is stylistic, and there's no "right" answer; I just > wondered what other people tend to do? > > Or, more generally, do people prefer using pattern matching to access > record values, or plain-ol' Foo = State#state.foo expressions? > > Thanks, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Fri Jun 20 10:00:27 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 20 Jun 2014 09:00:27 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A2C146.8030104@jkemp.net> References: <53A220FA.1060407@ninenines.eu> <2340610.0den0akeT5@freedom> <53A2A4B6.3020203@ninenines.eu> <53A2A86C.1090302@llaisdy.com> <53A2C146.8030104@jkemp.net> Message-ID: On 19 June 2014 11:53, John Kemp wrote: > I try to regularly evaluate new languages and platforms to use, and I doubt > I'm the only person who does that. No, you're not the only person who does that. But I think you're massively underestimating the number of people who *don't* look at new languages and platforms; or the people who look at a new language or platform, hit one speed bump and give up on it. We can't do anything about the first group -- they've learned their one language and they're sticking to it -- but we can certainly make it easier for the second group to evaluate Erlang. How we do that is the tricky part, and I don't think there's a one-size-fits-all solution. Different people learn in different ways. I like to learn by taking a simple example, playing with it, taking it apart and seeing how it works, while dipping into the books, documentation and man pages occasionally. Others like to do a bunch of reading up, and _then_ go and play. Still others prefer watching videos to learn things -- personally I find it impossible to learn from a video -- but it works for a large number of people. From roger@REDACTED Fri Jun 20 10:02:29 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 20 Jun 2014 09:02:29 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <2720179.2JvfftKefp@jalapeno> References: <53A220FA.1060407@ninenines.eu> <2720179.2JvfftKefp@jalapeno> Message-ID: On 19 June 2014 11:57, zxq9 wrote: > Django users certainly don't. The Django documentation and the Python > documentation -- two non-trivial documentation projects if there ever were -- > are primary examples of how to speak directly to an open source community in > its own language while making things approachable without dumbing anything > down. Personally, I find the Python documentation completely unapproachable. Too many details, too few examples. From aseigo@REDACTED Fri Jun 20 11:01:26 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Fri, 20 Jun 2014 11:01:26 +0200 Subject: [erlang-questions] Web app back-ends In-Reply-To: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> References: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> Message-ID: <2842625.D4MMkT9eBg@freedom> On Wednesday, June 18, 2014 17:21:19 Lloyd R. Prentice wrote: > postgeSQL > - consider when: you want to use a battle-tested relational data store. battle-tested (aka reliable), yes. there are key/value stores that are also pretty reliable, however. the real benefit (imho) of pgsql is ACID properties combined with 'advanced' features such as stored procedures / triggers and custom data types. as for speed, it's a dead-heat with mysql in real-world work loads. this has been the case for a number of years now, and is generally acknowledged by the people working on the respective projects. however, providing ACID properties makes some action unavoidably slower than straight-up key/value stores that do not offer those properties. > - reject when: your data needs are more key-value oriented or free form/less > structured. these days, that isn't really accurate. others have pointed out that pgsql now has key/value storage (hstore) and this is getting better in every release. heck, it even has a json datatype these days. you can mix and match key/value data with structured data in the same table, which is pretty interesting. the real challenge with pgsql for larger applications imho is horizontal scalability. not many projects REALLY require that, but for those that do pgsql is not the best choice right now. replication is still a developing feature set within pgsql and perhaps the most promising solution is currently a third-party semi-fork called Postgres- XC: http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki i personally haven't used Postgres-XC in any sort of production env so i can't vouch for its completeness or how well it meets the claims its developers make, but it seems to be on a good track. (esp compared to the architecture of other solutions in use with pgsql databases) this is quite similar to how full text indexing ended up making its way into pgsql: first as third-party enhancements, then eventually (after several years) folded into pgsql proper. i expect horizontal scalability features to make their way into pgsql sometime in the next 5 years, probably based on this or another 3rd-party pgsql add-on. but right now these features are not part of pgsql itself and are still in-development. tl;dr -> horizontal scalability is probably the most significant weak point for pgsql right now. p.s. i've written non-trivial applications (inc one or two i'd actually call "enterprise" apps with a relatively staight face) -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aseigo@REDACTED Fri Jun 20 11:09:08 2014 From: aseigo@REDACTED (Aaron J. Seigo) Date: Fri, 20 Jun 2014 11:09:08 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> Message-ID: <1942907.82Il6dF9Oa@freedom> On Thursday, June 19, 2014 12:52:28 Leonard Boyce wrote: > So with all the complexity issues being talked about would a basic > 'app generator' along the lines of yeoman > http://yeoman.io/learning/index.html not be a better fit? +100 if the templates are written, or at least looked over, by some of the erlang gurus here that is a very nice way to implicitly pass on best practices to new developers. in another project i am involved with, it is obvious when someone has used the project generator: there is a certain consistency and adherence to coding norms / idioms that are otherwise unusual to see in code from new comers. -- Aaron J. Seigo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From darach@REDACTED Fri Jun 20 11:29:35 2014 From: darach@REDACTED (Darach Ennis) Date: Fri, 20 Jun 2014 10:29:35 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: Hi Peer, Its important for children to be polyglots IMHO. They can choose their one true language when they're 18. Until then they're polyglots, like it or not. ... At least in my house... Diversity is something they should recognise, value and leverage... Cheers, Darach. On 20 Jun 2014 08:23, "Peer Stritzinger" wrote: > This thread would be much more interesting without all the unproven > conjectures that Elixir is obviously the better choice to teach to children. > > > I disagree. Elixir is a much worse choice to teach to children, because > its not a simple language anmore. There have been several people > teaching Prolog and also Erlang to children. So far there is no > experience teaching Elixir to the same group. > > > Elixir is mainly appealing to either people comming from Ruby or just for > pop culture value (as is Ruby itself). > > > Why does anybody think this makes it mor suitable to teach to kids? Why > talk about not corrupting them with OOP ideas when teaching them > programming and at the same time corruping them with crufty Ruby like > syntax i.e. the syntax of a OOP language? > > > What advantage does metaprogramming have for teaching kids? > > > Having syntax for rebinding variables? > > > This is all cruft for teaching the actual things. > > > Just picked this one mention to Elixir as an example: > > > On 2014-06-16 12:29:32 +0000, Darach Ennis said: > > > A good introductory language is scratch (http://scratch.mit.edu/) > > > I agree, so why not build something Scratch like on top of Erlang? > > > followed by Python (from about 7 years of age depending on the child, > python works very well, the strict syntax is a benefit too). > > > Erlang has a strict syntax too so it would have the same advantage. > > > [... more stuff I agree with detelted] > > > With a basic feel for logic, structure and feedback from programming tools > (with assistance) then Erlang would be a good next step. > > > Still agree. > > > Torben is probably right with respect to age group by setting it > > to mid high school level. > > > I think much too old but maybe its right > > > Elixir, also, would probably be an easier language to teach and to learn > > with fringe benefits (namely learning Elixir) for some of us... > > > And the argument goes off the rails completely for me: > > > WHY??? > > > This is contradictory to what you said before about Python. Elixirs > syntax is more barroque and why in the world is it easier to learn than > Erlang syntax (except for Ruby programmers)?? > > > Where is the proof? > > > Proofs by pop culture not accepted. > > > BTW what languages are *in* today won't matter for these kids because all > pop culture languages will be *out* when those kids you teach them will be > in their twenties. > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. > > Amen! > > The least relevant part of teaching kids programming is the syntax, or the > choice of language - they don't, and won't, give a s**t about it. > > As a simple thought experiment, just look at how you raised your kids in a > multi-lingual environment (yes my American brethren, this is hard. Pretend > :-) ) Notice how they - fluidly - bounce across languages, massacring > every grammar rule ever, but quite happily making sure that you understand > that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio > odio la piselli, i don't wanna, where is my red truck?" > > Mind you, they will pick up the rules over time, but the key here is the > importance of the problem at hand ("How To Avoid Eating Peas") - the more > immediately relevant it is to the young 'uns, the more rapidly they will > pick up the tools, the specifics of the language be damned. > > > 100% agree! > > > And BTW this is the Erlang channel, why would we work on our own demise by > teaching all these kids Elixir?? How would this help the problems Garett > was mentioning? > > > Cheers, > > -- Peer > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.koener@REDACTED Fri Jun 20 12:01:40 2014 From: antoine.koener@REDACTED (Antoine Koener) Date: Fri, 20 Jun 2014 12:01:40 +0200 Subject: [erlang-questions] Web app back-ends In-Reply-To: <2842625.D4MMkT9eBg@freedom> References: <7069B06F-BE2C-4F4D-BAAA-9FAF52A1BEA3@writersglen.com> <2842625.D4MMkT9eBg@freedom> Message-ID: To add something to this thread that also exists but seems to be quite ignored: Take a look at https://github.com/ztmr/egtm which uses http://www.fisglobal.com/products-technologyplatforms-gtm. It's an ACID Schema less store engine (with M language as a really powerful 'stored procedure' engine). Extract from the website: The GT.M data model is a hierarchical associative memory (i.e., multi-dimensional array) that imposes no restrictions on the data types of the indexes and the content - the application logic can impose any schema, dictionary or data organization suited to its problem domain.* GT.M's compiler for the standard M (also known as MUMPS) scripting language implements full support for ACID (Atomic, Consistent, Isolated, Durable) transactions, using optimistic concurrency control and software transactional memory (STM) that resolves the common mismatch between databases and programming languages. Its unique ability to create and deploy logical multi-site configurations of applications provides unrivaled continuity of business in the face of not just unplanned events, but also planned events, including planned events that include changes to application logic and schema. Worldwide, GT.M is used in multiple industries, including finance, health care, transportation, manufacturing and others. GT.M supplies the processing power to the FIS Profile? enterprise banking application. And about the proven stability of this tool, you can look at http://www.fisglobal.com/products-technologyplatforms-gtm-historyofgtm On Fri, Jun 20, 2014 at 11:01 AM, Aaron J. Seigo wrote: > On Wednesday, June 18, 2014 17:21:19 Lloyd R. Prentice wrote: > > postgeSQL > > - consider when: you want to use a battle-tested relational data store. > > battle-tested (aka reliable), yes. there are key/value stores that are also > pretty reliable, however. > > the real benefit (imho) of pgsql is ACID properties combined with > 'advanced' > features such as stored procedures / triggers and custom data types. > > as for speed, it's a dead-heat with mysql in real-world work loads. this > has > been the case for a number of years now, and is generally acknowledged by > the > people working on the respective projects. > > however, providing ACID properties makes some action unavoidably slower > than > straight-up key/value stores that do not offer those properties. > > > - reject when: your data needs are more key-value oriented or free > form/less > > structured. > > these days, that isn't really accurate. others have pointed out that pgsql > now > has key/value storage (hstore) and this is getting better in every release. > heck, it even has a json datatype these days. you can mix and match > key/value > data with structured data in the same table, which is pretty interesting. > > the real challenge with pgsql for larger applications imho is horizontal > scalability. not many projects REALLY require that, but for those that do > pgsql is not the best choice right now. > > replication is still a developing feature set within pgsql and perhaps the > most promising solution is currently a third-party semi-fork called > Postgres- > XC: > > http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki > > i personally haven't used Postgres-XC in any sort of production env so i > can't > vouch for its completeness or how well it meets the claims its developers > make, but it seems to be on a good track. (esp compared to the > architecture of > other solutions in use with pgsql databases) > > this is quite similar to how full text indexing ended up making its way > into > pgsql: first as third-party enhancements, then eventually (after several > years) > folded into pgsql proper. i expect horizontal scalability features to make > their way into pgsql sometime in the next 5 years, probably based on this > or > another 3rd-party pgsql add-on. but right now these features are not part > of > pgsql itself and are still in-development. > > tl;dr -> horizontal scalability is probably the most significant weak > point for > pgsql right now. > > p.s. i've written non-trivial applications (inc one or two i'd actually > call > "enterprise" apps with a relatively staight face) > > -- > Aaron J. Seigo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ferenc.holzhauser@REDACTED Fri Jun 20 12:09:15 2014 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Fri, 20 Jun 2014 12:09:15 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: Hi, I think this is when enthusiast and committed people are only trying to help and find entry points to learning/teaching Erlang based on their own experience and interest. Nothing wrong with that at this (brainstorm) stage of the discussion indeed. It should only be appreciated. Important thing to consider in my opinion is the distraction factor of these accessibility/coolness helpers from the original goal of teaching Erlang. e.g. you probably don't want to start your class with giving the youngsters a LEGO Mindstorm kit to build a robot that they'll eventually program in Erlang. You won't get there. For youngsters (and I bet most adults) the fun factor of doing that is immensely greater than some weird programming language some guy want to teach them. They can get a simple GUI thing from the internet anyway that makes their robot move the way they want. It is quite obvious that since Erlang does not really come with these cool things, we'll need to borrow other technologies (as suggested by many) to make it look more interesting. These however should be abstracted away as much as possible in a way that students will not have the slightest temptation during the class to look into those. Like building blocks indeed. Ferenc On 20 June 2014 09:22, Peer Stritzinger wrote: > This thread would be much more interesting without all the unproven > conjectures that Elixir is obviously the better choice to teach to children. > > > I disagree. Elixir is a much worse choice to teach to children, because > its not a simple language anmore. There have been several people > teaching Prolog and also Erlang to children. So far there is no > experience teaching Elixir to the same group. > > > Elixir is mainly appealing to either people comming from Ruby or just for > pop culture value (as is Ruby itself). > > > Why does anybody think this makes it mor suitable to teach to kids? Why > talk about not corrupting them with OOP ideas when teaching them > programming and at the same time corruping them with crufty Ruby like > syntax i.e. the syntax of a OOP language? > > > What advantage does metaprogramming have for teaching kids? > > > Having syntax for rebinding variables? > > > This is all cruft for teaching the actual things. > > > Just picked this one mention to Elixir as an example: > > > On 2014-06-16 12:29:32 +0000, Darach Ennis said: > > > A good introductory language is scratch (http://scratch.mit.edu/) > > > I agree, so why not build something Scratch like on top of Erlang? > > > followed by Python (from about 7 years of age depending on the child, > python works very well, the strict syntax is a benefit too). > > > Erlang has a strict syntax too so it would have the same advantage. > > > [... more stuff I agree with detelted] > > > With a basic feel for logic, structure and feedback from programming tools > (with assistance) then Erlang would be a good next step. > > > Still agree. > > > Torben is probably right with respect to age group by setting it > > to mid high school level. > > > I think much too old but maybe its right > > > Elixir, also, would probably be an easier language to teach and to learn > > with fringe benefits (namely learning Elixir) for some of us... > > > And the argument goes off the rails completely for me: > > > WHY??? > > > This is contradictory to what you said before about Python. Elixirs > syntax is more barroque and why in the world is it easier to learn than > Erlang syntax (except for Ruby programmers)?? > > > Where is the proof? > > > Proofs by pop culture not accepted. > > > BTW what languages are *in* today won't matter for these kids because all > pop culture languages will be *out* when those kids you teach them will be > in their twenties. > > > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < > mahesh@REDACTED> wrote: > > The most important thing here I believe is to have a nice collection of > simple tasks/problems that are appealing to the target audience and best > (easiest/nicest) solved in Erlang. > > Amen! > > The least relevant part of teaching kids programming is the syntax, or the > choice of language - they don't, and won't, give a s**t about it. > > As a simple thought experiment, just look at how you raised your kids in a > multi-lingual environment (yes my American brethren, this is hard. Pretend > :-) ) Notice how they - fluidly - bounce across languages, massacring > every grammar rule ever, but quite happily making sure that you understand > that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio > odio la piselli, i don't wanna, where is my red truck?" > > Mind you, they will pick up the rules over time, but the key here is the > importance of the problem at hand ("How To Avoid Eating Peas") - the more > immediately relevant it is to the young 'uns, the more rapidly they will > pick up the tools, the specifics of the language be damned. > > > 100% agree! > > > And BTW this is the Erlang channel, why would we work on our own demise by > teaching all these kids Elixir?? How would this help the problems Garett > was mentioning? > > > Cheers, > > -- Peer > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Fri Jun 20 12:28:47 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Fri, 20 Jun 2014 12:28:47 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: > > This thread would be much more interesting without all the *unproven > conjectures* that Elixir is obviously the better choice to teach to > children. > Peer, why not hold your e-mails to the same criteria you expect from the whole thread? Btw, a conjecture is by definition unproven. > I disagree. *Elixir is a much worse choice to teach to children*, > because its not a simple language anmore. > Conjecture. > There have been several people teaching Prolog and also Erlang to > children. So far there is no experience teaching Elixir to the same group. > Experience comes with time and trying. If nobody tries, we will never know. Also if you are saying Elixir is "just Ruby" then why not count all the initiatives that actually teach Ruby to children in its favor? * http://ruby4kids.com/ruby4kids * http://www.kidsruby.com I have been to Ruby conferences where we had rooms full of children being taught Ruby. Or should they all be considered the devil's work and the teachers burned at the stake? > Elixir is mainly appealing to either people comming from Ruby or just for > pop culture value (as is Ruby itself). > Conjecture(s). > What advantage does metaprogramming have for teaching kids? > Yes, I bet the second chapter of a future "Elixir for Kids" book is about meta-programming. ======== Note I am not saying at any point that Elixir is better or worse. I would be glad to see people trying and kids playing with it. I won't mind whatever language my kid chooses when learning to program, I'll just be happy he's doing it. I got really interested in programming with ActionScript because at the time I was playing with creating animations in Macromedia Flash and then I found out I could really do a lot of interesting stuff by using a programming language instead of relying on the GUI. I didn't care if the language was functional, OO, the syntax it used for defining functions, or whatever. The worst we could do to future programmers is to actually ingrain the idea there is one true solution in software. -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Fri Jun 20 13:00:23 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Fri, 20 Jun 2014 15:00:23 +0400 Subject: [erlang-questions] Crypto AES data block size Message-ID: Hi! I need to encrypt some data with ads_cbc_128, and I do like: crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, <<"96E85A7E0A4A5779">>, <<"id=14&bid=00.004300&clickUrl= http://duckduckgo.com &pid=3101&source=100&search-id=42&search-date=00:00:00">>). ** exception error: bad argument in function crypto:aes_cbc_crypt/4 called as crypto:aes_cbc_crypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, <<"96E85A7E0A4A5779">>, <<"id=14&bid=00.004300&clickUrl= http://duckduckgo.com &pid=3101&source=100&search-id=42&search-date=00:00:00">>, true) seems like the size of data should be the equal the power on 2, and then I do: crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, <<"96E85A7E0A4A5779">>, <<"id=14&bid=00.004300&clickUrl= http://duckduckgo.com&pid=3101&source=100&search-id=42&search-date=00:00:00", 0:24/unit:8>>). <<87,187,244,217,66,251,202,118,238,90,226,245,209,213, 158,166,203,46,8,30,113,122,172,204,163,50,193,34,243, ...>> Is there any way, don't fill the binary by zeros? How properly I should do this? -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 914 8 820 815 -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Fri Jun 20 13:51:28 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Fri, 20 Jun 2014 13:51:28 +0200 Subject: [erlang-questions] Erlang for youngsters References: <539EB979.40605@meetinghouse.net> Message-ID: Oh I fully admit I just wrote conjectures myself. Thats what I intended to. Also I don't say that the Elixir community should try out teaching Elixir to children. I just don't see any value for the Erlang community in this and I personally have the opinion that Erlang is easier to learn as first language than Elixir. The thread started triggered by Garetts talk about what needs to be improved about Erlang and its community. To get more inflow into the Erlang community one way was suggested be to teach kids Erlang or something more kid friendly based on Erlang. Then all kinds of opinion is stated that we should teach kids Elixir because somehow people think its clear to be easier learnt by children than Erlang which kind of irks me because I totally don't get why that shoud be true. But somehow its thought "obvious". So moving back to the initial questions Garett looked at in his talk. If teaching Elixir to kids is the solution to rescue the Erlang community, can anyone please explain to me how that is going to work out for Erlang? For me its say, ok Erlang is screwed anyway and we should just give up and hand over anything to Elixir. Which probably wouldn't do so well if Erlang dies off and the VM is no longer actively developed. Fortunately this is not going to happen soon since Ericson and a bunch of others are busy making money from using Erlang. But what does this make of Garetts findings? Look at them, shrug and teach kids Elixir? Maybe one of the problems of the Erlang community is that we have low self esteem? If all solutions we can think of is moving away from Erlang. On 2014-06-20 10:28:47 +0000, Jos? Valim said: > This thread would be much more interesting without all the unproven > conjectures that Elixir is obviously the better choice to teach to > children. > Peer, why not hold your e-mails to the same criteria you expect from > the whole thread? Btw, a conjecture is by definition unproven. > I disagree.? Elixir is a much worse choice to teach to children, > because its not a simple language anmore. > Conjecture. > No not a conjecure even: opinion I would rather say, clearly indicated > by the intro "I disagree" > Experience comes with time and trying. If nobody tries, we will never know. By all means do! > Also if you are saying Elixir is "just Ruby" then why not count all the > initiatives that actually teach Ruby to children in its favor? Didn' say "Elixir is just Ruby" and won't ever because it clearly isn't. I said I see it easier to learn for someone comming from a Ruby background. > > *?http://ruby4kids.com/ruby4kids > * http://www.kidsruby.com > > I have been to Ruby conferences where we had rooms full of children > being taught Ruby. Or should they all be considered the devil's work > and the teachers burned at the stake? Of course not and I don't see what this has to do with the discussion. Except ask ourself: where are those rooms full of children at the Erlang conferences? > Elixir is mainly appealing to either people comming from Ruby or just > for pop culture value (as is Ruby itself). > Conjecture(s).? No, opinion. > What advantage does metaprogramming have for teaching kids? > Yes, I bet the second chapter of a future "Elixir for Kids" book is > about meta-programming. Well besides the different syntax, metaprogramming is whats sold as one Elixirs advantages isn't it? So if we ignore metaprogramming because it woun't be taught in this "Elixir for Kids" book all that remains as difference is the syntax. So the question is which syntax is easier to teach to someone with no background in other programming language syntax and why do people think Elixirs is easier for kids than Erlang? > ======== > > Note I am not saying at any point that Elixir is better or worse. I > would be glad to see people trying and kids playing with it. > > I won't mind whatever language my kid chooses when learning to program, > I'll just be happy he's doing it. I got really interested in > programming with ActionScript because at the time I was playing with > creating animations in Macromedia Flash and then I found out I could > really do a lot of interesting stuff by using a programming language > instead of relying on the GUI. I didn't care if the language was > functional, OO, the syntax it used for defining functions, or whatever. > > The worst we could do to future programmers is to actually ingrain the > idea there is one true solution in software. There we definitely agree. Its hypothetical anyway because who in the Erlang community would actually build this Erlang for Kids thing? Who wants to put in the resources? Where is our Lifelong Kindergarden with Erlang MIT Media lab like thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Fri Jun 20 14:54:38 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Fri, 20 Jun 2014 08:54:38 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <1942907.82Il6dF9Oa@freedom> References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> Message-ID: On Fri, Jun 20, 2014 at 5:09 AM, Aaron J. Seigo wrote: > On Thursday, June 19, 2014 12:52:28 Leonard Boyce wrote: >> So with all the complexity issues being talked about would a basic >> 'app generator' along the lines of yeoman >> http://yeoman.io/learning/index.html not be a better fit? > > +100 > > if the templates are written, or at least looked over, by some of the erlang > gurus here that is a very nice way to implicitly pass on best practices to new > developers. I was not really thinking about the proposed 'binary' as being a workhorse app generator, but that's not a bad idea. Now that I think about it I was probably envisioning something along the lines of a 'erlang by example' app which would allow the new user to be introduced to the Erlang language and concepts in an simple interactive format. Begin with immediate satisfaction, throw in a gentle introduction to syntax via line-by-line explanations of the basic examples, all the while moving on to more complex paradigms and code, and all the while exposing targeted links to in-depth information on the topics being examined. I believe that the more complexity issues that can be solved through simple interfaces, the easier it is for someone new to Erlang to focus on both learning the language and architecture best practices. I would not class myself as an Erlang expert by any means, although I use it every day for our entire stack, but I can speak to the frustration of developers approaching the language for the first time as I currently 'teaching' Erlang to some of my team who specialize in JavaScript, but are proficient enough to write code of reasonable quality in Java, PHP, Python, C# etc I've had them work through LYSE and sections of Joe's book and now I have them writing a simple FTP client to support one of our APIs, but every day I hear their frustration. A few examples below 1) "The syntax is just too weird, I *hate* commas and semi-colons. Why use a period and not braces?" 2) "What the hell is with the crazy 'defacto' indentation. I don't use or want to learn to use emacs, I'm perfectly happy with Sublime." 3) "TDD is extremely painful. What should I be writing tests for?" 4) "Why is there no package manager? I need a library for X, where can I find it? Which one do I use?" When they do find something, invariably the code has no tests and very little documentation, or maybe there are multiple options and no clear 'leader'. *or* there is no library for what they need 5) "No unicode aware/safe string library? wtf? Lists of integers? Binaries? Why in deities name does it have to be so convoluted?" 6) "Configuration files for rebar et al. just seem weird and sorta 'black magic'. dependency handling, starting of applications etc" 7) "Dialyzer is dog slow" 8) "What's up with the documentation organization? Why do I have to use google to be able to find anything in the official docs? Navigating the docs is crazy, I feel like it's still 1998" > in another project i am involved with, it is obvious when someone has used the > project generator: there is a certain consistency and adherence to coding > norms / idioms that are otherwise unusual to see in code from new comers. By the way Aaron, thanks for all the great work on KDE, I benefit from it daily. > -- > Aaron J. Seigo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From essen@REDACTED Fri Jun 20 15:06:25 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 20 Jun 2014 15:06:25 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> Message-ID: <53A431D1.8080906@ninenines.eu> I mean what. On 06/20/2014 02:54 PM, Leonard Boyce wrote: > 2) "What the hell is with the crazy 'defacto' indentation. I don't use > or want to learn to use emacs, I'm perfectly happy with Sublime." Why the hell are they not using Sublime? What's this 'defacto' indentation thing you mention? Most people write Erlang in their favorite editor. I use vim without any plugins myself. > 3) "TDD is extremely painful. What should I be writing tests for?" If it's painful then they're not doing it right. They should write tests for exactly the things they test manually. Doesn't need to be more than that at the beginning, tests can get added over time. > 5) "No unicode aware/safe string library? wtf? Lists of integers? > Binaries? Why in deities name does it have to be so convoluted?" I'm not sure why they would say that. It's not like JS has good Unicode support either. Erlang has a number of ICU bindings available if you do need Unicode though. > 7) "Dialyzer is dog slow" Is it? Are they rebuilding the PLT all the time? It never takes more than 10s to dialyze for me on the bigger projects (usually < 2s though). Much faster than running tests (especially running tests by hand if that's what they'd prefer doing). > 8) "What's up with the documentation organization? Why do I have to > use google to be able to find anything in the official docs? > Navigating the docs is crazy, I feel like it's still 1998" ??? http://www.erlang.org/erldoc It sounds a lot like you/they're making their life harder than it should be. -- Lo?c Hoguin http://ninenines.eu From john@REDACTED Fri Jun 20 15:12:00 2014 From: john@REDACTED (John Kemp) Date: Fri, 20 Jun 2014 09:12:00 -0400 Subject: [erlang-questions] Crypto AES data block size In-Reply-To: References: Message-ID: <53A43320.5040604@jkemp.net> On 06/20/2014 07:00 AM, Alexander Petrovsky wrote: > Hi! > > I need to encrypt some data with ads_cbc_128, and I do like: > > crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, > <<"96E85A7E0A4A5779">>, > <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com&pid=3101&source=100&search-id=42&search-date=00:00:00">>). > ** exception error: bad argument > in function crypto:aes_cbc_crypt/4 > called as > crypto:aes_cbc_crypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, > <<"96E85A7E0A4A5779">>, > > <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com&pid=3101&source=100&search-id=42&search-date=00:00:00">>, > true) > > seems like the size of data should be the equal the power on 2, and then > I do: > > crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, > <<"96E85A7E0A4A5779">>, > <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com&pid=3101&source=100&search-id=42&search-date=00:00:00", > 0:24/unit:8>>). > <<87,187,244,217,66,251,202,118,238,90,226,245,209,213, > 158,166,203,46,8,30,113,122,172,204,163,50,193,34,243, > ...>> > > Is there any way, don't fill the binary by zeros? The crypto:aes_cbc_128_encrypt API requires data be padded to a multiple of 16 bytes (as it says in the documentation - for example: http://www.erlang.org/documentation/doc-5.8.3/lib/crypto-2.0.2.1/doc/html/crypto.html#aes_cbc_128_encrypt-3). How properly I should > do this? https://github.com/spawngrid/cowboy_session/blob/master/src/cowboy_session_secure.erl shows what looks like a good example of how to do the padding more generally than in your example. - johnk > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 914 8 820 815 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From g@REDACTED Fri Jun 20 15:26:28 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 20 Jun 2014 08:26:28 -0500 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: This feels healthy to me. I would like to test this, personally. I think we can all learn from trying to teach -- first hand experience is better than... what was that word again? Conject... I'll see if the Chicago User Group can put together a meeting specifically to look at this topic. While it's not kids in the room, our community in Chicago is very thoughtful and very polyglot. We'll get some data. I have a nine year old whose life exists almost exclusively of Minecraft. It's disturbing. But I think I can get him to learn some programming skills through this. I'll be interested to see what he thinks of this stuff. Somehow I see him getting scarred for life, but I'll at least learn something from it. But back to this topic of languages... Elixir and its community represent a great opportunity to learn. I agree whole heartedly with Peer that Erlang itself should take important steps to improve its rate of adoption. I agree that we should not concede usability, grokability, awesomeness to Elixir. But Darach's point on diversity trumps all of this. IMO we need to try stuff, even if that stuff is wrong. Rejecting something is just as valuable as accepting something, assuming you understand clearly why you reject. I'll personally be crushed if "def ... end" turns out to be more understandable for young learners. Crushed. But I don't see the harm in measuring. On Fri, Jun 20, 2014 at 6:51 AM, Peer Stritzinger wrote: > Oh I fully admit I just wrote conjectures myself. Thats what I intended to. > > > Also I don't say that the Elixir community should try out teaching Elixir to > children. > > > I just don't see any value for the Erlang community in this and I personally > have the opinion that Erlang is easier to learn as first language than > Elixir. The thread started triggered by Garetts talk about what needs to > be improved about Erlang and its community. > > > To get more inflow into the Erlang community one way was suggested be to > teach kids Erlang or something more kid friendly based on Erlang. > > > Then all kinds of opinion is stated that we should teach kids Elixir because > somehow people think its clear to be easier learnt by children than Erlang > which kind of irks me because I totally don't get why that shoud be true. > But somehow its thought "obvious". > > > So moving back to the initial questions Garett looked at in his talk. > > > If teaching Elixir to kids is the solution to rescue the Erlang community, > can anyone please explain to me how that is going to work out for Erlang? > For me its say, ok Erlang is screwed anyway and we should just give up and > hand over anything to Elixir. Which probably wouldn't do so well if Erlang > dies off and the VM is no longer actively developed. > > > Fortunately this is not going to happen soon since Ericson and a bunch of > others are busy making money from using Erlang. > > > But what does this make of Garetts findings? > > > Look at them, shrug and teach kids Elixir? > > > Maybe one of the problems of the Erlang community is that we have low self > esteem? If all solutions we can think of is moving away from Erlang. > > > On 2014-06-20 10:28:47 +0000, Jos? Valim said: > > > This thread would be much more interesting without all the unproven > conjectures that Elixir is obviously the better choice to teach to children. > > Peer, why not hold your e-mails to the same criteria you expect from the > whole thread? Btw, a conjecture is by definition unproven. > > I disagree. Elixir is a much worse choice to teach to children, because its > not a simple language anmore. > > Conjecture. > > > No not a conjecure even: opinion I would rather say, clearly indicated by > the intro "I disagree" > > > Experience comes with time and trying. If nobody tries, we will never know. > > > By all means do! > > > Also if you are saying Elixir is "just Ruby" then why not count all the > initiatives that actually teach Ruby to children in its favor? > > > Didn' say "Elixir is just Ruby" and won't ever because it clearly isn't. > > > I said I see it easier to learn for someone comming from a Ruby background. > > > > * http://ruby4kids.com/ruby4kids > > * http://www.kidsruby.com > > > I have been to Ruby conferences where we had rooms full of children being > taught Ruby. Or should they all be considered the devil's work and the > teachers burned at the stake? > > > Of course not and I don't see what this has to do with the discussion. > > > Except ask ourself: where are those rooms full of children at the Erlang > conferences? > > > Elixir is mainly appealing to either people comming from Ruby or just for > pop culture value (as is Ruby itself). > > Conjecture(s). > > > No, opinion. > > > What advantage does metaprogramming have for teaching kids? > > Yes, I bet the second chapter of a future "Elixir for Kids" book is about > meta-programming. > > > Well besides the different syntax, metaprogramming is whats sold as one > Elixirs advantages isn't it? > > > So if we ignore metaprogramming because it woun't be taught in this "Elixir > for Kids" book all that remains as difference is the syntax. > > > So the question is which syntax is easier to teach to someone with no > background in other programming language syntax and why do people think > Elixirs is easier for kids than Erlang? > > > ======== > > > Note I am not saying at any point that Elixir is better or worse. I would be > glad to see people trying and kids playing with it. > > > I won't mind whatever language my kid chooses when learning to program, I'll > just be happy he's doing it. I got really interested in programming with > ActionScript because at the time I was playing with creating animations in > Macromedia Flash and then I found out I could really do a lot of interesting > stuff by using a programming language instead of relying on the GUI. I > didn't care if the language was functional, OO, the syntax it used for > defining functions, or whatever. > > > The worst we could do to future programmers is to actually ingrain the idea > there is one true solution in software. > > > There we definitely agree. > > > Its hypothetical anyway because who in the Erlang community would actually > build this Erlang for Kids thing? Who wants to put in the resources? Where > is our Lifelong Kindergarden with Erlang MIT Media lab like thing? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From askjuise@REDACTED Fri Jun 20 15:37:51 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Fri, 20 Jun 2014 17:37:51 +0400 Subject: [erlang-questions] Crypto AES data block size In-Reply-To: <53A43320.5040604@jkemp.net> References: <53A43320.5040604@jkemp.net> Message-ID: John, thanks it's very helpful. 2014-06-20 17:12 GMT+04:00 John Kemp : > On 06/20/2014 07:00 AM, Alexander Petrovsky wrote: > >> Hi! >> >> I need to encrypt some data with ads_cbc_128, and I do like: >> >> crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, >> <<"96E85A7E0A4A5779">>, >> <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com >> &pid=3101&source=100&search-id=42&search-date=00:00:00">>). >> ** exception error: bad argument >> in function crypto:aes_cbc_crypt/4 >> called as >> crypto:aes_cbc_crypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, >> <<"96E85A7E0A4A5779">>, >> >> <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com >> &pid=3101&source=100&search-id=42&search-date=00:00:00">>, >> true) >> >> seems like the size of data should be the equal the power on 2, and then >> I do: >> >> crypto:aes_cbc_128_encrypt(<<"B3E80545C3C9968096E85A7E0A4A5779">>, >> <<"96E85A7E0A4A5779">>, >> <<"id=14&bid=00.004300&clickUrl=http://duckduckgo.com >> &pid=3101&source=100&search-id=42&search-date=00:00:00", >> 0:24/unit:8>>). >> <<87,187,244,217,66,251,202,118,238,90,226,245,209,213, >> 158,166,203,46,8,30,113,122,172,204,163,50,193,34,243, >> ...>> >> >> Is there any way, don't fill the binary by zeros? >> > > The crypto:aes_cbc_128_encrypt API requires data be padded to a multiple > of 16 bytes (as it says in the documentation - for example: > http://www.erlang.org/documentation/doc-5.8.3/lib/crypto-2.0.2.1/doc/html/ > crypto.html#aes_cbc_128_encrypt-3). > > > How properly I should > >> do this? >> > > https://github.com/spawngrid/cowboy_session/blob/master/ > src/cowboy_session_secure.erl shows what looks like a good example of how > to do the padding more generally than in your example. > > - johnk > >> >> >> -- >> ?????????? ????????? / Alexander Petrovsky, >> >> Skype: askjuise >> Phone: +7 914 8 820 815 >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 914 8 820 815 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Fri Jun 20 15:55:29 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Fri, 20 Jun 2014 09:55:29 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A431D1.8080906@ninenines.eu> References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> Message-ID: "What Lo?c said". I mean, people have been arguing about Syntax since lord knows when, and its never going to stop. e.g., Why does Lo?c have that stupid "two dots" thing on his name anyhow? Whats wrong with a good old "i"? The french are sooo . Syntax is not semantics - this is a pretty hard lesson to learn (not so strangely enough, people that speak more than one language tend to freak out less about this). Cheers On Fri, Jun 20, 2014 at 9:06 AM, Lo?c Hoguin wrote: > I mean what. > > > On 06/20/2014 02:54 PM, Leonard Boyce wrote: > >> 2) "What the hell is with the crazy 'defacto' indentation. I don't use >> or want to learn to use emacs, I'm perfectly happy with Sublime." >> > > Why the hell are they not using Sublime? What's this 'defacto' indentation > thing you mention? Most people write Erlang in their favorite editor. I use > vim without any plugins myself. > > > 3) "TDD is extremely painful. What should I be writing tests for?" >> > > If it's painful then they're not doing it right. They should write tests > for exactly the things they test manually. Doesn't need to be more than > that at the beginning, tests can get added over time. > > > 5) "No unicode aware/safe string library? wtf? Lists of integers? >> Binaries? Why in deities name does it have to be so convoluted?" >> > > I'm not sure why they would say that. It's not like JS has good Unicode > support either. Erlang has a number of ICU bindings available if you do > need Unicode though. > > > 7) "Dialyzer is dog slow" >> > > Is it? Are they rebuilding the PLT all the time? It never takes more than > 10s to dialyze for me on the bigger projects (usually < 2s though). Much > faster than running tests (especially running tests by hand if that's what > they'd prefer doing). > > > 8) "What's up with the documentation organization? Why do I have to >> use google to be able to find anything in the official docs? >> Navigating the docs is crazy, I feel like it's still 1998" >> > > ??? > > http://www.erlang.org/erldoc > > It sounds a lot like you/they're making their life harder than it should > be. > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Mahesh Paolini-Subramanya That tall bald Indian guy..* *Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri Jun 20 16:17:10 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 20 Jun 2014 15:17:10 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: <53A44266.4090903@llaisdy.com> > I have a nine year old whose life exists almost exclusively of > Minecraft. It's disturbing. ... Same here. I've tried to promote Minetest (C++ & Lua, better design, open-source and consequently better community), but to no avail. > I'll personally be crushed if "def ... end" turns out to be more > understandable for young learners. A study would be interesting that compared word-like terms to symbolic terms in programming languages that are otherwise identical, e.g., "do <...> end" vs "-> <...> ." A word-heavy PL would obviously better suit an imperative style "do this then do that", a symbol heavy PL more like maths. This would probably be reflected in which children prefer which PL. However, you'd have to find a neutral, non-leading way to present the PLs. Ivan On 20/06/2014 14:26, Garrett Smith wrote: > This feels healthy to me. > > I would like to test this, personally. I think we can all learn from > trying to teach -- first hand experience is better than... what was > that word again? Conject... > > I'll see if the Chicago User Group can put together a meeting > specifically to look at this topic. While it's not kids in the room, > our community in Chicago is very thoughtful and very polyglot. We'll > get some data. > > I have a nine year old whose life exists almost exclusively of > Minecraft. It's disturbing. But I think I can get him to learn some > programming skills through this. I'll be interested to see what he > thinks of this stuff. Somehow I see him getting scarred for life, but > I'll at least learn something from it. > > But back to this topic of languages... Elixir and its community > represent a great opportunity to learn. I agree whole heartedly with > Peer that Erlang itself should take important steps to improve its > rate of adoption. I agree that we should not concede usability, > grokability, awesomeness to Elixir. But Darach's point on diversity > trumps all of this. IMO we need to try stuff, even if that stuff is > wrong. Rejecting something is just as valuable as accepting something, > assuming you understand clearly why you reject. > > I'll personally be crushed if "def ... end" turns out to be more > understandable for young learners. Crushed. But I don't see the harm > in measuring. > > On Fri, Jun 20, 2014 at 6:51 AM, Peer Stritzinger wrote: >> Oh I fully admit I just wrote conjectures myself. Thats what I intended to. >> >> >> Also I don't say that the Elixir community should try out teaching Elixir to >> children. >> >> >> I just don't see any value for the Erlang community in this and I personally >> have the opinion that Erlang is easier to learn as first language than >> Elixir. The thread started triggered by Garetts talk about what needs to >> be improved about Erlang and its community. >> >> >> To get more inflow into the Erlang community one way was suggested be to >> teach kids Erlang or something more kid friendly based on Erlang. >> >> >> Then all kinds of opinion is stated that we should teach kids Elixir because >> somehow people think its clear to be easier learnt by children than Erlang >> which kind of irks me because I totally don't get why that shoud be true. >> But somehow its thought "obvious". >> >> >> So moving back to the initial questions Garett looked at in his talk. >> >> >> If teaching Elixir to kids is the solution to rescue the Erlang community, >> can anyone please explain to me how that is going to work out for Erlang? >> For me its say, ok Erlang is screwed anyway and we should just give up and >> hand over anything to Elixir. Which probably wouldn't do so well if Erlang >> dies off and the VM is no longer actively developed. >> >> >> Fortunately this is not going to happen soon since Ericson and a bunch of >> others are busy making money from using Erlang. >> >> >> But what does this make of Garetts findings? >> >> >> Look at them, shrug and teach kids Elixir? >> >> >> Maybe one of the problems of the Erlang community is that we have low self >> esteem? If all solutions we can think of is moving away from Erlang. >> >> >> On 2014-06-20 10:28:47 +0000, Jos? Valim said: >> >> >> This thread would be much more interesting without all the unproven >> conjectures that Elixir is obviously the better choice to teach to children. >> >> Peer, why not hold your e-mails to the same criteria you expect from the >> whole thread? Btw, a conjecture is by definition unproven. >> >> I disagree. Elixir is a much worse choice to teach to children, because its >> not a simple language anmore. >> >> Conjecture. >> >> >> No not a conjecure even: opinion I would rather say, clearly indicated by >> the intro "I disagree" >> >> >> Experience comes with time and trying. If nobody tries, we will never know. >> >> >> By all means do! >> >> >> Also if you are saying Elixir is "just Ruby" then why not count all the >> initiatives that actually teach Ruby to children in its favor? >> >> >> Didn' say "Elixir is just Ruby" and won't ever because it clearly isn't. >> >> >> I said I see it easier to learn for someone comming from a Ruby background. >> >> >> >> * http://ruby4kids.com/ruby4kids >> >> * http://www.kidsruby.com >> >> >> I have been to Ruby conferences where we had rooms full of children being >> taught Ruby. Or should they all be considered the devil's work and the >> teachers burned at the stake? >> >> >> Of course not and I don't see what this has to do with the discussion. >> >> >> Except ask ourself: where are those rooms full of children at the Erlang >> conferences? >> >> >> Elixir is mainly appealing to either people comming from Ruby or just for >> pop culture value (as is Ruby itself). >> >> Conjecture(s). >> >> >> No, opinion. >> >> >> What advantage does metaprogramming have for teaching kids? >> >> Yes, I bet the second chapter of a future "Elixir for Kids" book is about >> meta-programming. >> >> >> Well besides the different syntax, metaprogramming is whats sold as one >> Elixirs advantages isn't it? >> >> >> So if we ignore metaprogramming because it woun't be taught in this "Elixir >> for Kids" book all that remains as difference is the syntax. >> >> >> So the question is which syntax is easier to teach to someone with no >> background in other programming language syntax and why do people think >> Elixirs is easier for kids than Erlang? >> >> >> ======== >> >> >> Note I am not saying at any point that Elixir is better or worse. I would be >> glad to see people trying and kids playing with it. >> >> >> I won't mind whatever language my kid chooses when learning to program, I'll >> just be happy he's doing it. I got really interested in programming with >> ActionScript because at the time I was playing with creating animations in >> Macromedia Flash and then I found out I could really do a lot of interesting >> stuff by using a programming language instead of relying on the GUI. I >> didn't care if the language was functional, OO, the syntax it used for >> defining functions, or whatever. >> >> >> The worst we could do to future programmers is to actually ingrain the idea >> there is one true solution in software. >> >> >> There we definitely agree. >> >> >> Its hypothetical anyway because who in the Erlang community would actually >> build this Erlang for Kids thing? Who wants to put in the resources? Where >> is our Lifelong Kindergarden with Erlang MIT Media lab like thing? >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From peerst@REDACTED Fri Jun 20 16:23:39 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Fri, 20 Jun 2014 16:23:39 +0200 Subject: [erlang-questions] Erlang for youngsters References: <539EB979.40605@meetinghouse.net> Message-ID: On 2014-06-20 11:51:28 +0000, Peer Stritzinger said: > Also I don't say that the Elixir community should try out teaching > Elixir to children. Sorry typo: this should read: "Also I don't say that the Elixir community shouldn't try out teaching Elixir to children." From jose.valim@REDACTED Fri Jun 20 16:25:41 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Fri, 20 Jun 2014 16:25:41 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: > > I just don't see any value for the Erlang community in this [teaching > Elixir to kids] > So basically you are saying that you don't see any value in: * teaching developers/kids a language that runs on the same VM as Erlang * teaching developers/kids a language that uses the same concurrency mechanisms, processes and distribution abstraction as Erlang * teaching a language that is functional and promotes immutability as Erlang For me teaching any language that promotes any of the three example bullets above brings value to Erlang. > To get more inflow into the Erlang community one way was suggested be to > teach kids Erlang or something more kid friendly based on Erlang. > Teaching Erlang to kids is not going to increase the inflow into the Erlang community unless it is a HUGE effort that requires an incredible amount of time in the long-term. How many children would have to be taught so in 5 years time they become an active part of the community? How many developer-hours would that whole effort require? Teaching programming to kids is a goal in itself. In his talk Garrett raised many other points that could be more effective in increasing the inflow into the Erlang community. > Well besides the different syntax, metaprogramming is whats sold as one > Elixirs advantages isn't it? > Meta-programming is an advanced feature of the language. We don't talk about it in the Getting Started guide. And even in the Programming Elixir book, it is only discussed in the last sections. > So if we ignore metaprogramming because it woun't be taught in this > "Elixir for Kids" book all that remains as difference is the syntax. > We also have an excellent focus on tooling and on documentation both which are very helpful when learning a language. But, of course, those points are always dismissed even though it is clearly stated in the project home page. Instead of claiming Ruby for being the result of a pop culture, we should actually ask ourselves what were their efforts and how did they get to the point where they can have a room full of kids at events learning how to program. We should ask how can both Elixir and Erlang community *be together* in tackling this (and LFE and ...). More people, more time, more energy! If Elixir is good at attracting Rubyists, maybe we can get the attention of some that were involved in those teaching projects to give us some pointers? Do you want to help the community grow? Do what Katie said: "embrace diversity", don't actively fight against it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Fri Jun 20 16:39:27 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Fri, 20 Jun 2014 16:39:27 +0200 Subject: [erlang-questions] node.js vs erlang References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> Message-ID: On 2014-06-20 12:54:38 +0000, Leonard Boyce said: > 3) "TDD is extremely painful. What should I be writing tests for?" TDD is by no means mandated by Erlang, this is a matter of taste and required quality. With Erlang you can do (as in any other language): write you tests first and do TDD Write your tests last. Write property based tests which rule them all. And even in the extreme: write no tests at all. Not really recommending this but you'd still get more stable software if you don't really test it at all and just run it. Many here have these quickly hacked together prototypes that amazingly run without problems non-stop since a year. > 6) "Configuration files for rebar et al. just seem weird and sorta > 'black magic'. dependency handling, starting of applications etc" Rebar is not mandatory at all ... I'm using Erlang since 2007 and never did anything real with rebar. If you don't like it don't use it. > 7) "Dialyzer is dog slow" Dialyzer is not that slow if used properly (and gotten faster recently), and you don't have to dialyze on each make. And if you still hate it: its also optional. Cheers, -- Peer From leonard.boyce@REDACTED Fri Jun 20 16:47:46 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Fri, 20 Jun 2014 10:47:46 -0400 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A431D1.8080906@ninenines.eu> References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> Message-ID: On Fri, Jun 20, 2014 at 9:06 AM, Lo?c Hoguin wrote: > I mean what. It's not a holy war :) This thread has been going for quite a while and unfortunately for a time warped into a 'cowboy complexity criticism thread'. All I'm trying to do is add to the conversation by providing anecdotal evidence on pain points for those new to Erlang. I believe there is always value in examining the opinions and statements of others as they allow us to find ways to possibly improve. > On 06/20/2014 02:54 PM, Leonard Boyce wrote: >> >> 2) "What the hell is with the crazy 'defacto' indentation. I don't use >> or want to learn to use emacs, I'm perfectly happy with Sublime." > > > Why the hell are they not using Sublime? What's this 'defacto' indentation > thing you mention? Most people write Erlang in their favorite editor. I use > vim without any plugins myself. They are using Sublime as that's their editor of choice. When I started learning Erlang I was informed that the 'defacto' standard for indentation is the indentation used by elang mode for emacs as this was the primary erlang editor. Maybe I was misinformed, but that became our coding standard. Others developers use emacs or ElrIDE (which uses the same indentation as emacs). No other 'popular' editor correctly supports the 'emacs style' indentation for Erlang. Maybe it's just me but I like consistency and my mind is 'trained' to match this indentation format. >> 3) "TDD is extremely painful. What should I be writing tests for?" > > > If it's painful then they're not doing it right. They should write tests for > exactly the things they test manually. Doesn't need to be more than that at > the beginning, tests can get added over time. Thank you. This is something which is not really covered as an "Erlang best practice" in anything I've seen to date. My guys want to write tests for every possible return from every single function. I'm even seeing tests which are actually testing returns from OTP function calls. If anyone knows of any resources for "Best Practices" for erlang testing I'd appreciate their sharing. >> 5) "No unicode aware/safe string library? wtf? Lists of integers? >> Binaries? Why in deities name does it have to be so convoluted?" > > > I'm not sure why they would say that. It's not like JS has good Unicode > support either. Erlang has a number of ICU bindings available if you do need > Unicode though. Again, they're learning and it's a process. In our main project we use the "ux" library. But I understand their befuddlement. It just "seems" like something a language should include. Seeing the movement over the versions with unicode support I guess that eventually it may exist. >> 7) "Dialyzer is dog slow" > > > Is it? Are they rebuilding the PLT all the time? It never takes more than > 10s to dialyze for me on the bigger projects (usually < 2s though). Much > faster than running tests (especially running tests by hand if that's what > they'd prefer doing). Confession time, I just blindly believed that when I was told. Turns out they missed reading the "0." in seconds in the timer. His simple build time was 0m0.45 On the other hand, your pointing this out led me to investigate our main project makefile. Here it currently takes ~ 15 minutes to run and basically uses 100% memory and forces swapping. Maybe someone smarter can point out the error as I certainly cannot see it :( ### snip from Makefile (assume correctly tab indented) ## Dialyzer DEPSOLVER_PLT=.depsolver_plt OTP_PLT=.otp_plt .PHONY: dialyzer $(DEPSOLVER_PLT): -dialyzer --output_plt $(OTP_PLT) --build_plt \ --apps erts kernel stdlib crypto public_key mnesia ssl xmerl inets -dialyzer --output_plt $(DEPSOLVER_PLT) --build_plt \ --apps -r deps dialyzer: $(DEPSOLVER_PLT) nice -19 \ dialyzer apps/*/ebin/ --plts $(OTP_PLT) $(DEPSOLVER_PLT) \ -Wrace_conditions \ -Wunmatched_returns \ -Wno_improper_lists ### end snip >> 8) "What's up with the documentation organization? Why do I have to >> use google to be able to find anything in the official docs? >> Navigating the docs is crazy, I feel like it's still 1998" > > > ??? > > http://www.erlang.org/erldoc And yet the 1st documentation link on http://www.erlang.org/doc.html (the title "Erlang/OTP documentation") is to the *non* searchable version http://www.erlang.org/doc/. Yes, right in that paragraph is a link to the searchable version, but if they already have the link to what they're looking for, why would they even bother reading that paragraph. Additionally, google search results invariably link to the *non* searchable documentation. Maybe changing the link on the paragraph title and explicitly listing links to both types of documentation in the paragraph body would prevent this 'mistake'. I know I made that mistake myself. I was totally unaware the searchable docs existed. > It sounds a lot like you/they're making their life harder than it should be. That could well be the case, and this is why I believe such discussions are useful as I want to make life easier for all. Thanks for the response, Leonard > -- > Lo?c Hoguin > http://ninenines.eu From jesper.louis.andersen@REDACTED Fri Jun 20 16:52:29 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 20 Jun 2014 16:52:29 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> Message-ID: On Fri, Jun 20, 2014 at 4:47 PM, Leonard Boyce wrote: > They are using Sublime as that's their editor of choice. > When I started learning Erlang I was informed that the 'defacto' > standard for indentation is the indentation used by elang mode for > emacs as this was the primary erlang editor. Maybe I was misinformed, > but that became our coding standard. > There is no preferred indentation style for Erlang programs. I've seen god knows everything out there. The language is parsed by an LALR(1) grammar, so identation doesn't matter for scoping either. I tend to indent code for readability. Some times, another indentation style than the mandated one is far more readable. So even when using emacs, I break the rules now and then. I don't really see that as a problem. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jun 20 17:10:01 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 20 Jun 2014 17:10:01 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> Message-ID: <53A44EC9.80403@ninenines.eu> On 06/20/2014 04:47 PM, Leonard Boyce wrote: > On Fri, Jun 20, 2014 at 9:06 AM, Lo?c Hoguin wrote: >> I mean what. > > It's not a holy war :) That was just my reaction, sorry. A more polite kind of "What the .. are they doing?". I feel I should write a detailed explanation of my workflow somewhere. Too often do I read people having too many issues than they should. My workflow isn't perfect by any means, but it probably wouldn't hurt to put it into words. (rebar users be damned though, because I don't use it.) > They are using Sublime as that's their editor of choice. > When I started learning Erlang I was informed that the 'defacto' > standard for indentation is the indentation used by elang mode for > emacs as this was the primary erlang editor. Maybe I was misinformed, > but that became our coding standard. Others developers use emacs or > ElrIDE (which uses the same indentation as emacs). No other 'popular' > editor correctly supports the 'emacs style' indentation for Erlang. > Maybe it's just me but I like consistency and my mind is 'trained' to > match this indentation format. The standard is "indent the same as the code around your change". True not only for third party projects but also for OTP code. > Thank you. This is something which is not really covered as an "Erlang > best practice" in anything I've seen to date. My guys want to write > tests for every possible return from every single function. I'm even > seeing tests which are actually testing returns from OTP function > calls. If you really want to test all possible cases you should take a look at property based testing, but beware of the learning curve. > Maybe someone smarter can point out the error as I certainly cannot see it :( I do not see it, but if I had to guess I'd say it generates the PLT every time. By the way, shameless plug if you like makefiles: https://github.com/extend/erlang.mk > And yet the 1st documentation link on http://www.erlang.org/doc.html > (the title "Erlang/OTP documentation") is to the *non* searchable > version http://www.erlang.org/doc/. > Yes, right in that paragraph is a link to the searchable version, but > if they already have the link to what they're looking for, why would > they even bother reading that paragraph. I am not disagreeing with you there, switching the links out would definitely be better. -- Lo?c Hoguin http://ninenines.eu From peerst@REDACTED Fri Jun 20 17:37:50 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Fri, 20 Jun 2014 17:37:50 +0200 Subject: [erlang-questions] Erlang for youngsters References: <539EB979.40605@meetinghouse.net> Message-ID: On 2014-06-20 14:25:41 +0000, Jos? Valim said: > I just don't see any value for the Erlang community in this [teaching > Elixir to kids] > So basically you are saying that you don't see any value in: > > * teaching developers/kids a language that runs on the same VM as Erlang > > * teaching developers/kids a language that uses the same concurrency > mechanisms, processes and distribution abstraction as Erlang > > * teaching a language that is functional and promotes immutability as Erlang > ? > For me teaching any language that promotes any of the three example > bullets above brings value to Erlang. > To get more inflow into the Erlang community one way was suggested be > to teach kids Erlang or something more kid friendly based on Erlang. No thats not what I'm saying at all. I see value in all that in itself. I just don't see it that it helps Erlang in any way. Since I suppose you see Elixir as better than Erlang, why would all those Elixir programmers come to Erlang suddenly. Of course it helps the Elixir community to teach Elixir. At best it doesn't hurt Erlang, but it certainly doesn't help it. That doesn mean it isn't a goal itself. All I say is that we don't help Erlang with it. We have a bunch of languages that run on BEAM, well not a problem, diversity is good etc. Not arguing against hit having now implemented one myself. But this has nothing to do with my argument, that teaching Elixir to kids doesn't solve the problem Garett is talking about in Erlang. > We also have an excellent focus on tooling and on documentation both > which are very helpful when learning a language. But, of course, those > points are always dismissed even though it is clearly stated in the > project home page.? Good for you if your documentation and tooling sucks less, still doesn't make Erlangs documentation and tooling better. > Instead of claiming Ruby for being the result of a pop culture, we > should actually ask ourselves what were their efforts and how did they > get to the point where they can have a room full of kids at events > learning how to program. I was just togue in cheek half quoting Alan Kay: "all computer technology is pop culture" > We should ask how can both Elixir and Erlang community *be together* in > tackling this (and LFE and ...). More people, more time, more energy! > If Elixir is good at attracting Rubyists, maybe we can get the > attention of some that were involved in those teaching projects to give > us some pointers? > > Do you want to help the community grow? Do what Katie said: "embrace > diversity", don't actively fight against it. I'm all for diversity, thats why I'm a bit tired of the constant Elixir being better for everything droning (now even teaching kids) on the Erlang mailing list. Especially if one immediatly gets attacked when stating the opposite which I only did to find out why some here seems to think Elixir is better to teach kids ... doesn't help a common community at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Fri Jun 20 20:02:21 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 21 Jun 2014 03:02:21 +0900 Subject: [erlang-questions] Why (not) hot code loading Message-ID: <11896881.Ktyz5iOU4i@jalapeno> I've never had a situation where I've needed hot code loading, but a project that may be a good fit with this feature is looming (and may not be a good fit -- I have much to learn about this feature). Nearly all the advice I see on this is to avoid it in production, which seems highly ironic, since this feature was designed specifically to ease certain cases of production. The advice against using it mostly comes from tutorials, presentations and asides made by various speakers in talks I've seen. I don't have a canonical "don't use hot code loading" reference, but I have exactly zero references which urge the use of this feature and explain in depth how to integrate it with a release cycle. But someone worked a long time figuring out how to make this a part of the runtime, so... Is this feature: A) "Hard" to use because it is far outside the experience of the average Java- or web-developer-turned-Erlanger who tends to give talks about Erlang. B) "Hard" to use because it is actually hard: a technically complex feature for which little scaffolding is available for easy integration. C) Actually not very useful. D) People have been trained to accept maintenance downtime and believe that loadbalancers are the answer to everything? Most of the best tools I've ever used fell into category (A), so I wonder if that is the case with this feature. Some things I've really liked in environments like Guile fell into category (B), which was nice because after some thorough study something complex but understandable can be abstracted and made easy to use. I have a hard time believing that this feature actually falls into category (C), feeling it is much more likely that widespread acceptable of the (D) view simply obviates much deep thought on the utility of it in the first place -- especially since so much focus, even within the Erlang community these days, is on the web and not other areas. Can anyone provide some insight into this? I'd rather get some opinions now than spend time getting to the bottom of a relatively untaught feature only to find that it wasn't very useful. -Craig From mloftis@REDACTED Fri Jun 20 20:05:19 2014 From: mloftis@REDACTED (Michael Loftis) Date: Fri, 20 Jun 2014 11:05:19 -0700 Subject: [erlang-questions] Why (not) hot code loading In-Reply-To: <11896881.Ktyz5iOU4i@jalapeno> References: <11896881.Ktyz5iOU4i@jalapeno> Message-ID: A, B, D .... The actual concept is easy and works well...it gets hard because you're replacing a module which may or may not have in-flight messages, and which may (or may not) change it's interface to other modules. Thats where the hard bits come in, you really have to understand, appreciate, and have well defined APIs and behaviors thought out for upgrading or you may find yourself with odd bugs or just crashing the whole supervision tree. Hot code load is really great for internal bugfixes but gets much harder when you're making major changes. And thats also where there's a lack of tooling - getting dependencies properly reloaded/loaded if they change, that sort of thing. On Fri, Jun 20, 2014 at 11:02 AM, zxq9 wrote: > I've never had a situation where I've needed hot code loading, but a project > that may be a good fit with this feature is looming (and may not be a good fit > -- I have much to learn about this feature). Nearly all the advice I see on > this is to avoid it in production, which seems highly ironic, since this > feature was designed specifically to ease certain cases of production. > > The advice against using it mostly comes from tutorials, presentations and > asides made by various speakers in talks I've seen. I don't have a canonical > "don't use hot code loading" reference, but I have exactly zero references > which urge the use of this feature and explain in depth how to integrate it > with a release cycle. > > But someone worked a long time figuring out how to make this a part of the > runtime, so... > > Is this feature: > A) "Hard" to use because it is far outside the experience of the average Java- > or web-developer-turned-Erlanger who tends to give talks about Erlang. > B) "Hard" to use because it is actually hard: a technically complex feature > for which little scaffolding is available for easy integration. > C) Actually not very useful. > D) People have been trained to accept maintenance downtime and believe that > loadbalancers are the answer to everything? > > Most of the best tools I've ever used fell into category (A), so I wonder if > that is the case with this feature. Some things I've really liked in > environments like Guile fell into category (B), which was nice because after > some thorough study something complex but understandable can be abstracted and > made easy to use. I have a hard time believing that this feature actually > falls into category (C), feeling it is much more likely that widespread > acceptable of the (D) view simply obviates much deep thought on the utility of > it in the first place -- especially since so much focus, even within the > Erlang community these days, is on the web and not other areas. > > Can anyone provide some insight into this? I'd rather get some opinions now > than spend time getting to the bottom of a relatively untaught feature only to > find that it wasn't very useful. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From bob@REDACTED Fri Jun 20 20:12:41 2014 From: bob@REDACTED (Bob Ippolito) Date: Fri, 20 Jun 2014 11:12:41 -0700 Subject: [erlang-questions] Why (not) hot code loading In-Reply-To: <11896881.Ktyz5iOU4i@jalapeno> References: <11896881.Ktyz5iOU4i@jalapeno> Message-ID: We used it hot code reloading a lot at Mochi and found it quite useful for many of our incremental updates. The trouble is when you change too much about the messages or data types flowing through the system you will have to write a fair amount of code to gracefully handle the code change, so you might not want to use it for every upgrade. It's of course also not possible to upgrade the VM with hot code reloading. Folks who like to deploy updates with one type of sledgehammer simply can't choose hot code loading as it's not a general solution to the problem, so if you're going to teach or recommend just one way you wouldn't cover it. Your system should be able to handle a hard crash of a node anyway so a rolling restart to upgrade should work fine (but might not be very fast or efficient). On Fri, Jun 20, 2014 at 11:02 AM, zxq9 wrote: > I've never had a situation where I've needed hot code loading, but a > project > that may be a good fit with this feature is looming (and may not be a good > fit > -- I have much to learn about this feature). Nearly all the advice I see on > this is to avoid it in production, which seems highly ironic, since this > feature was designed specifically to ease certain cases of production. > > The advice against using it mostly comes from tutorials, presentations and > asides made by various speakers in talks I've seen. I don't have a > canonical > "don't use hot code loading" reference, but I have exactly zero references > which urge the use of this feature and explain in depth how to integrate it > with a release cycle. > > But someone worked a long time figuring out how to make this a part of the > runtime, so... > > Is this feature: > A) "Hard" to use because it is far outside the experience of the average > Java- > or web-developer-turned-Erlanger who tends to give talks about Erlang. > B) "Hard" to use because it is actually hard: a technically complex feature > for which little scaffolding is available for easy integration. > C) Actually not very useful. > D) People have been trained to accept maintenance downtime and believe that > loadbalancers are the answer to everything? > > Most of the best tools I've ever used fell into category (A), so I wonder > if > that is the case with this feature. Some things I've really liked in > environments like Guile fell into category (B), which was nice because > after > some thorough study something complex but understandable can be abstracted > and > made easy to use. I have a hard time believing that this feature actually > falls into category (C), feeling it is much more likely that widespread > acceptable of the (D) view simply obviates much deep thought on the > utility of > it in the first place -- especially since so much focus, even within the > Erlang community these days, is on the web and not other areas. > > Can anyone provide some insight into this? I'd rather get some opinions now > than spend time getting to the bottom of a relatively untaught feature > only to > find that it wasn't very useful. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallen@REDACTED Fri Jun 20 22:05:54 2014 From: mallen@REDACTED (Mark Allen) Date: Fri, 20 Jun 2014 15:05:54 -0500 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EFBC.2060301@meetinghouse.net> Message-ID: I know you probably hate top posting. Sorry. (Not sorry.) It's a little known feature but rebar does support templates for generating new OTP applications. For example: $ mkdir tmp; cd tmp $ rebar create-app appid=hello $ rebar create template=simplesrv srvid=hello_srv You can make your own rebar templates too, although the docs for doing so are not very obvious. This was the best I found on github (so far) https://github.com/mbbx6spp/rebar-templates Mark On 6/19/14 11:52 AM, "Leonard Boyce" wrote: >So with all the complexity issues being talked about would a basic >'app generator' along the lines of yeoman >http://yeoman.io/learning/index.html not be a better fit? > >Maybe a binary which can set up the framework for an example >application with the user having to answer a few questions. > >Trivial example (assumes name of simperl as binary); > >noobie@REDACTED$ ./simperl > >- Choose the application example type: >1) Web Server >2) Multi-server Ping-Pong Example >> 1 > >- Choose the type of Web Server example >1) Simple "Hello World" web server >2) REST "Hello World" web server >3) .... > >> 1 >Web Server installed and running. Go to http://localhost:12345/ > >To modify this server to print "Goodbye World" instead, edit file >"simple_hello_world/src/simple_hello_world.erl" >and use the command "./simperl recomplile simple_hello_world" > >For more information on how things actually work see: >simple_hello_world/doc/README.md > >noobie@REDACTED$ > >By approaching it in this way you may achieve rapid 'satisfaction' and >the ability to expose the user to anything you want with examples of >differing complexity. > >Leonard > >On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman > wrote: >> Mahesh Paolini-Subramanya wrote: >>> >>> "Complexity" is a remarkably loaded term - I'm fairly certain that >>>things >>> that are complex for me (Getting anywhere via mass-transit in Tokyo) >>>are >>> pretty trivial for others (e.g., Loic). >> >> >> Well, let's say "complex" in an engineering context, for starters. >> >>> Whats more, complexity of systems has nothing to do with the >>>complexity of >>> the individual components involved (DNA is a bit of a prime example >>>here). >> >> >> Precisely. I'd venture that one gravitates toward Erlang when one is >> building systems and systems-of-systems with lots of distributed, moving >> parts (e.g., a telephone switching fabric). If one is building a >>single, >> stand-alone application, I expect Erlang might not be the "best" choice. >> >>> >>> That said, I would claim that erlang systems are more _comprehensible_ >>> than others. >>> Mind you, this does require some mastery of erlang, which is not as >>>much >>> of a chicken-and-egg scenario as you might imagine. >>> >>> >> >> You know, that's a really good point, that highlights two broader >>issues: >> conceptual models, and tooling that maps onto conceptual models: >> >> - Sequential code is relatively easy to conceptualize and represent - >>well >> commented code can suffice as a representation, there are plenty of >> debugging and tracing tools for examining run-time behavior >> >> - Object oriented code lends itself to browsers and inspector - though >> execution flow can get pretty arcane (at one point, I worked on military >> simulators - think game engine - each vehicle was an object, but the >>actual >> work was done by 4 spaghetti coded threads that each ran 20 time a >>second - >> very ugly, and what led me to discover Erlang) >> >> - Actor formalism (i.e., Erlang) - very easy to conceptualize for >> applications where things naturally map onto independent processes >>(e.g., >> the above-mentioned simulator -- tanks and airplanes are a lot easier to >> model as processes than as objects) - but tools for visualizing, >>designing, >> debugging systems with lots of processes, and the interactions among >>them, >> are close to non-existent (a problem for Erlang, but also for anyone >> building highly concurrent, highly distributed systems) >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Fri Jun 20 22:43:24 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 20 Jun 2014 15:43:24 -0500 Subject: [erlang-questions] Why (not) hot code loading In-Reply-To: <11896881.Ktyz5iOU4i@jalapeno> References: <11896881.Ktyz5iOU4i@jalapeno> Message-ID: On Fri, Jun 20, 2014 at 1:02 PM, zxq9 wrote: > I've never had a situation where I've needed hot code loading, but a project > that may be a good fit with this feature is looming (and may not be a good fit > -- I have much to learn about this feature). Nearly all the advice I see on > this is to avoid it in production, which seems highly ironic, since this > feature was designed specifically to ease certain cases of production. I'm trying to imagine how disruptive a server restart would be to a telecom company. My guess is it might put them out of business if it happened too often. Or, if you're AT&T or other US carriers, it's fine. But most applications don't fall into this category. Given that it's a hard problem to begin with and that most applications don't really need this, I'm not surprised there isn't a well beaten path here. I've never had a situation where I've needed hot code loading either. But ad hoc code reloading for bug fixes -- and in particular to do that *reliably* (try this in e.g. in Java or Python, etc.) -- is extremely handy. Mark Allen, see, this is a *bottom post*. It's not hard. Do you see now nice the content flows? [1] Garrett [1] ;) From bob@REDACTED Fri Jun 20 23:04:38 2014 From: bob@REDACTED (Bob Ippolito) Date: Fri, 20 Jun 2014 14:04:38 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1831314.qTF9aCn5q6@freedom> <53A15595.2090000@ninenines.eu> <53A220FA.1060407@ninenines.eu> <53A2E5B7.1000300@meetinghouse.net> <53A2E757.3070803@ninenines.eu> <53A2EFBC.2060301@meetinghouse.net> Message-ID: mochiweb ships with a rebar template as well, that's how the "make app" target works. On Fri, Jun 20, 2014 at 1:05 PM, Mark Allen wrote: > I know you probably hate top posting. Sorry. (Not sorry.) > > It's a little known feature but rebar does support templates for > generating new OTP applications. > > For example: > > $ mkdir tmp; cd tmp > $ rebar create-app appid=hello > $ rebar create template=simplesrv srvid=hello_srv > > You can make your own rebar templates too, although the docs for doing so > are not very obvious. This was the best I found on github (so far) > > https://github.com/mbbx6spp/rebar-templates > > > Mark > > On 6/19/14 11:52 AM, "Leonard Boyce" wrote: > > >So with all the complexity issues being talked about would a basic > >'app generator' along the lines of yeoman > >http://yeoman.io/learning/index.html not be a better fit? > > > >Maybe a binary which can set up the framework for an example > >application with the user having to answer a few questions. > > > >Trivial example (assumes name of simperl as binary); > > > >noobie@REDACTED$ ./simperl > > > >- Choose the application example type: > >1) Web Server > >2) Multi-server Ping-Pong Example > >> 1 > > > >- Choose the type of Web Server example > >1) Simple "Hello World" web server > >2) REST "Hello World" web server > >3) .... > > > >> 1 > >Web Server installed and running. Go to http://localhost:12345/ > > > >To modify this server to print "Goodbye World" instead, edit file > >"simple_hello_world/src/simple_hello_world.erl" > >and use the command "./simperl recomplile simple_hello_world" > > > >For more information on how things actually work see: > >simple_hello_world/doc/README.md > > > >noobie@REDACTED$ > > > >By approaching it in this way you may achieve rapid 'satisfaction' and > >the ability to expose the user to anything you want with examples of > >differing complexity. > > > >Leonard > > > >On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman > > wrote: > >> Mahesh Paolini-Subramanya wrote: > >>> > >>> "Complexity" is a remarkably loaded term - I'm fairly certain that > >>>things > >>> that are complex for me (Getting anywhere via mass-transit in Tokyo) > >>>are > >>> pretty trivial for others (e.g., Loic). > >> > >> > >> Well, let's say "complex" in an engineering context, for starters. > >> > >>> Whats more, complexity of systems has nothing to do with the > >>>complexity of > >>> the individual components involved (DNA is a bit of a prime example > >>>here). > >> > >> > >> Precisely. I'd venture that one gravitates toward Erlang when one is > >> building systems and systems-of-systems with lots of distributed, moving > >> parts (e.g., a telephone switching fabric). If one is building a > >>single, > >> stand-alone application, I expect Erlang might not be the "best" choice. > >> > >>> > >>> That said, I would claim that erlang systems are more _comprehensible_ > >>> than others. > >>> Mind you, this does require some mastery of erlang, which is not as > >>>much > >>> of a chicken-and-egg scenario as you might imagine. > >>> > >>> > >> > >> You know, that's a really good point, that highlights two broader > >>issues: > >> conceptual models, and tooling that maps onto conceptual models: > >> > >> - Sequential code is relatively easy to conceptualize and represent - > >>well > >> commented code can suffice as a representation, there are plenty of > >> debugging and tracing tools for examining run-time behavior > >> > >> - Object oriented code lends itself to browsers and inspector - though > >> execution flow can get pretty arcane (at one point, I worked on military > >> simulators - think game engine - each vehicle was an object, but the > >>actual > >> work was done by 4 spaghetti coded threads that each ran 20 time a > >>second - > >> very ugly, and what led me to discover Erlang) > >> > >> - Actor formalism (i.e., Erlang) - very easy to conceptualize for > >> applications where things naturally map onto independent processes > >>(e.g., > >> the above-mentioned simulator -- tanks and airplanes are a lot easier to > >> model as processes than as objects) - but tools for visualizing, > >>designing, > >> debugging systems with lots of processes, and the interactions among > >>them, > >> are close to non-existent (a problem for Erlang, but also for anyone > >> building highly concurrent, highly distributed systems) > >> > >> > >> -- > >> In theory, there is no difference between theory and practice. > >> In practice, there is. .... Yogi Berra > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >_______________________________________________ > >erlang-questions mailing list > >erlang-questions@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Fri Jun 20 23:07:53 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 20 Jun 2014 23:07:53 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: As I started this fire let me try to set a few things straight. First off, the subject of this thread should have been "Erlang/Elixir for youngsters" as my original desire was to teach the Erlang way of doing things to youngsters. It can be done with Erlang or Elixir - if you are not coding the Erlang way in Elixir you are just wasting your time. The Erlang way = The Golden Trinity of Erlang = share nothing + fail fast + supervision. While syntax could be an issue that is not the top worry on my list. Having an easy to work with eco-system and consistent libraries are way more important when you want to teach things. This is where Elixir seems to have some advantages - should be proved by conducting a test! Secondly, the target demographic is important for a number of reasons. Getting an army of young people to discover the wonders of The Erlang Way? has huge benefits both short term and long term. Short term some of them will create something really cool and that will create a positive circle of getting more people attracted - even some older ones. Long term we get a lot of ambassadors, which will make it easier to get Erlang/Elixir into companies. One of the things that this thread has convinced me about is that if one can get them to do games with a GUI then the motivational factor should be in place - suitable building blocks should be in place to ensure a learning curve with lots of small successes, of course. Another benefit of doing games is that there is always a lot of interesting problems to solve - some of which are relevant for a lot of other domains. Frame that in the right way and then one can re-use or slightly tweak the material to be used for beginners of all ages. Learning should be fun, even when you are "old". Sorry if I have confused things with the badly chosen subject and imprecise statements. Cheers, Torben Jos? Valim writes: >> >> I just don't see any value for the Erlang community in this [teaching >> Elixir to kids] >> > So basically you are saying that you don't see any value in: > > * teaching developers/kids a language that runs on the same VM as Erlang > > * teaching developers/kids a language that uses the same concurrency > mechanisms, processes and distribution abstraction as Erlang > > * teaching a language that is functional and promotes immutability as Erlang > > For me teaching any language that promotes any of the three example bullets > above brings value to Erlang. > >> To get more inflow into the Erlang community one way was suggested be to >> teach kids Erlang or something more kid friendly based on Erlang. >> > Teaching Erlang to kids is not going to increase the inflow into the Erlang > community unless it is a HUGE effort that requires an incredible amount of > time in the long-term. How many children would have to be taught so in 5 > years time they become an active part of the community? How many > developer-hours would that whole effort require? > > Teaching programming to kids is a goal in itself. In his talk Garrett > raised many other points that could be more effective in increasing the > inflow into the Erlang community. > >> Well besides the different syntax, metaprogramming is whats sold as one >> Elixirs advantages isn't it? >> > Meta-programming is an advanced feature of the language. We don't talk > about it in the Getting Started guide. And even in the Programming Elixir > book, it is only discussed in the last sections. > >> So if we ignore metaprogramming because it woun't be taught in this >> "Elixir for Kids" book all that remains as difference is the syntax. >> > We also have an excellent focus on tooling and on documentation both which > are very helpful when learning a language. But, of course, those points are > always dismissed even though it is clearly stated in the project home page. > > Instead of claiming Ruby for being the result of a pop culture, we should > actually ask ourselves what were their efforts and how did they get to the > point where they can have a room full of kids at events learning how to > program. > > We should ask how can both Elixir and Erlang community *be together* in > tackling this (and LFE and ...). More people, more time, more energy! If > Elixir is good at attracting Rubyists, maybe we can get the attention of > some that were involved in those teaching projects to give us some pointers? > > Do you want to help the community grow? Do what Katie said: "embrace > diversity", don't actively fight against it. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From paulo.ferraz.oliveira@REDACTED Sat Jun 21 00:07:04 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Fri, 20 Jun 2014 23:07:04 +0100 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <53A44EC9.80403@ninenines.eu> References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> <53A44EC9.80403@ninenines.eu> Message-ID: "I feel I should write a detailed explanation of my workflow somewhere." +1 On 20 June 2014 16:10, Lo?c Hoguin wrote: > On 06/20/2014 04:47 PM, Leonard Boyce wrote: > >> On Fri, Jun 20, 2014 at 9:06 AM, Lo?c Hoguin wrote: >> >>> I mean what. >>> >> >> It's not a holy war :) >> > > That was just my reaction, sorry. A more polite kind of "What the .. are > they doing?". > > I feel I should write a detailed explanation of my workflow somewhere. Too > often do I read people having too many issues than they should. My workflow > isn't perfect by any means, but it probably wouldn't hurt to put it into > words. (rebar users be damned though, because I don't use it.) > > > They are using Sublime as that's their editor of choice. >> When I started learning Erlang I was informed that the 'defacto' >> standard for indentation is the indentation used by elang mode for >> emacs as this was the primary erlang editor. Maybe I was misinformed, >> but that became our coding standard. Others developers use emacs or >> ElrIDE (which uses the same indentation as emacs). No other 'popular' >> editor correctly supports the 'emacs style' indentation for Erlang. >> Maybe it's just me but I like consistency and my mind is 'trained' to >> match this indentation format. >> > > The standard is "indent the same as the code around your change". True not > only for third party projects but also for OTP code. > > > Thank you. This is something which is not really covered as an "Erlang >> best practice" in anything I've seen to date. My guys want to write >> tests for every possible return from every single function. I'm even >> seeing tests which are actually testing returns from OTP function >> calls. >> > > If you really want to test all possible cases you should take a look at > property based testing, but beware of the learning curve. > > > Maybe someone smarter can point out the error as I certainly cannot see >> it :( >> > > I do not see it, but if I had to guess I'd say it generates the PLT every > time. > > By the way, shameless plug if you like makefiles: > https://github.com/extend/erlang.mk > > > And yet the 1st documentation link on http://www.erlang.org/doc.html >> (the title "Erlang/OTP documentation") is to the *non* searchable >> version http://www.erlang.org/doc/. >> Yes, right in that paragraph is a link to the searchable version, but >> if they already have the link to what they're looking for, why would >> they even bother reading that paragraph. >> > > I am not disagreeing with you there, switching the links out would > definitely be better. > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.rubyist@REDACTED Sat Jun 21 00:17:53 2014 From: josh.rubyist@REDACTED (Josh Adams) Date: Fri, 20 Jun 2014 17:17:53 -0500 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> <53A44EC9.80403@ninenines.eu> Message-ID: > > "I feel I should write a detailed explanation of my workflow somewhere." > Maybe this would be good to submit to howistart? http://howistart.org/ https://github.com/howistart/howistart -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Jun 21 00:29:09 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 21 Jun 2014 00:29:09 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: <53A4B5B5.7000400@ninenines.eu> On 06/20/2014 11:07 PM, Torben Hoffmann wrote: > The Erlang way = The Golden Trinity of Erlang = share nothing + fail fast + > supervision. I wouldn't say Elixir "fails fast". Rebinding by default is a *terrible* choice for that. > Having an easy to work with eco-system and consistent libraries are way more > important when you want to teach things. Wishful thinking about consistent libraries. English is probably the best counter example of that, it's full of special cases. Doesn't stop anyone. Another example could be PHP which is not consistent at all and yet really easy to learn. You need exactly two things to learn: a feedback loop, and motivation. The former needs to be at a different pace depending on the person and the thing being learnt. You need one more thing to teach *kids*: don't treat them like kids. Consider them equal to you and your peers and respect them. > Sorry if I have confused things with the badly chosen subject and imprecise > statements. I'm not surprised by Peer's reaction at all. So far to me this is really a thread about you wanting to teach kids Elixir. I've avoided it so far because every time I say something negative about Elixir, people's feelings get hurt. -- Lo?c Hoguin http://ninenines.eu From mark.nijhof@REDACTED Sat Jun 21 00:32:15 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 21 Jun 2014 00:32:15 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <53A4B5B5.7000400@ninenines.eu> References: <539EB979.40605@meetinghouse.net> <53A4B5B5.7000400@ninenines.eu> Message-ID: > You need one more thing to teach *kids*: don't treat them like kids. > Consider them equal to you and your peers and respect them. This! -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Jun 21 00:34:40 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 21 Jun 2014 00:34:40 +0200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> <53A44EC9.80403@ninenines.eu> Message-ID: <53A4B700.6000800@ninenines.eu> I have no intention to write a tutorial. Just a series of steps categorized by situation. "create a library", "create an app", "prototype", "general maintenance", "fixing bugs", "handling PRs", "deploying" etc. On 06/21/2014 12:17 AM, Josh Adams wrote: > "I feel I should write a detailed explanation of my workflow somewhere." > > Maybe this would be good to submit to howistart? > > http://howistart.org/ > https://github.com/howistart/howistart -- Lo?c Hoguin http://ninenines.eu From zxq9@REDACTED Sat Jun 21 01:30:21 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 21 Jun 2014 08:30:21 +0900 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <53A4B5B5.7000400@ninenines.eu> Message-ID: <1984853.cBX6sWDVXK@jalapeno> On Saturday 21 June 2014 00:32:15 Mark Nijhof wrote: > > You need one more thing to teach *kids*: don't treat them like kids. > > Consider them equal to you and your peers and respect them. > > This! Most important part of the discussion has been reached. You can't force a kid to understand anything, and you can't force a kid to want to understand anything. You're best hope is to get them interested in something on their own terms. Once they want to know something, find it gives them power, becomes part of their internal goal set -- you'd be hard pressed to prevent a child from acquiring knowledge, even if you forbid it (maybe especially if you forbid it). Its almost like... they are people or something. I believe in the idea of teaching by simplified abstraction, and then successive replacement of any current concept model by more complex and accurate models. Nothing about this is specific to children. Abstracting away the confusing bits is different from developing a "child friendly" version of a course of study. In particular, the kids you'd really hope get interested in this stuff are the very ones that would subconsciously reject the "child safe" version of whatever cirricula you hope to convey. (The idea that interest is a prerequisit to non-trivial intellectual pursuits does not sit well with some people; because it follows that most people (not just kids) aren't going to understand most things, especially programming, because most people aren't interested and therefore will forever remain unsuited to such study.) From zxq9@REDACTED Sat Jun 21 01:58:25 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 21 Jun 2014 08:58:25 +0900 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <2720179.2JvfftKefp@jalapeno> Message-ID: <1899380.1Z2M3BliFt@jalapeno> On Friday 20 June 2014 09:02:29 Roger Lipscombe wrote: > On 19 June 2014 11:57, zxq9 wrote: > > Django users certainly don't. The Django documentation and the Python > > documentation -- two non-trivial documentation projects if there ever were > > -- are primary examples of how to speak directly to an open source > > community in its own language while making things approachable without > > dumbing anything down. > > Personally, I find the Python documentation completely unapproachable. > Too many details, too few examples. I've never heard that, but you can hardly be the only one to feel that way. In your opinion, how does it compare to the Ruby or Perl documentation? Django? I highlight the Python docs because they provide a complete tutorial and then pass to the library reference. The tutorial is much more decomposable than most (its not a walk-through of developing a complete project), and its surprisingly complete with regard to feature coverage. You're right that the Python docs do not include many (any?) examples of complete projects (outside of the package/distribution section), but I believe they provide sufficient examples of specific features in isolation to be useful. This seems to be the exact thing you dislike about them. They have proven useful enough, anyway, that someone totally new to Python can jump into the code of an existing project and start learning on the fly. It worked for me (I understand this is a dangerous phrase, though). Note the Python docs do not teach OOP or FP. I don't think the Erlang docs should, either. Perhaps its that complete application-package type examples tend to occur in framework project documentation, not in language documentation. So, for example, after skimming over the Python tutorial one can work through the Django tutorial and publish a simple application from that. From there they tweak and modify and, viola!, have a trivial thingy running that does what they like. But from there, of course, they run into some serious issues. ORMs simply don't work well for non-trivial cases. The excited coder now is forced to learn more about Python and to return to the docs, but this time to the library reference, not the tutorial. At some point he must understand more about the database bindings that are letting him talk to Postgres, and he finds relative uniformity among the Django, Python and psycopg2 docs (we can learn a lot from this detail, I think). Ultimately he must learn about Postgres itself, and that means learning about relational concepts if he didn't know them already -- and the Postgres docs fill the gap remarkably well. This is a confluence of docs from totally different projects written at an appropriate level for their purpose. I can't imagine the core Erlang docs ever being so comprehensive without an absolutely staggering amount of effort. Few people start with an initial goal of learning Ruby; they start with a desire to use Rails or work on Puppet or something else -- Ruby is an artifact of implementation. Few people (who get very far) start with an initial goal of learning Python, either; most start with a desire to use [any killer app in Python], and wind up learning a lot about Python along the way. I suppose the key is to find that killer project everyone wants to work on or killer framework everyone wants to use -- write it in Erlang, and diligently garden the docs of that other project. -Craig (Sorry for the long message. This turned out to be part live brainstorm and I don't have enough time to shorten it just now.) From steven.charles.davis@REDACTED Sat Jun 21 02:58:39 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 20 Jun 2014 17:58:39 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> Message-ID: It's not hard... but can be extremely expensive if it builds a call stack (e.g. Java)... On Thursday, June 19, 2014 8:32:59 PM UTC-5, Richard A. O'Keefe wrote: > > > Evgeny M writes: > >> Recursion is hard in any language without pattern matching. > > I don't believe that. Decades ago I was using languages like Algol, > Lisp, Pop-2, in all of which pattern matching was entirely absent > yet recursion was easy. > > I'm reminded of Susan's classroom. I think it's in "The Thief of Time." > The quote goes something like this: > she hadn't told the children algebra was hard, > so they never found out. > > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sat Jun 21 03:01:31 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 20 Jun 2014 18:01:31 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <53A4B5B5.7000400@ninenines.eu> Message-ID: <5b7a38c9-ffda-4c63-915b-900f28fd7a6c@googlegroups.com> +1 Long time ago I was trained as a science journalist; the key writing guide was: Always write with the idea that your target audience is very intelligent, but knows absolutely nothing about the subject you are talking about. On Friday, June 20, 2014 5:32:23 PM UTC-5, Mark Nijhof wrote: > > > >> You need one more thing to teach *kids*: don't treat them like kids. >> Consider them equal to you and your peers and respect them. > > > This! > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Jun 21 03:25:40 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Fri, 20 Jun 2014 21:25:40 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> Message-ID: <53A4DF14.60209@meetinghouse.net> On Thursday, June 19, 2014 8:32:59 PM UTC-5, Richard A. O'Keefe wrote: > > > Evgeny M writes: > >> Recursion is hard in any language without pattern matching. > > I don't believe that. Decades ago I was using languages like Algol, > Lisp, Pop-2, in all of which pattern matching was entirely absent > yet recursion was easy. > > I'm reminded of Susan's classroom. I think it's in "The Thief of > Time." > The quote goes something like this: > she hadn't told the children algebra was hard, > so they never found out. > Whoa that brings me back. The first program I ever wrote was a general purpose solution to the Tower of Hanoi (generate sequence of moves for a stack of n disks). A problem that's trivial if you understand recursion. But... I was writing in Basic.... early Basic - no subroutine capabilities, global variables only. Somehow I ended up building a stack mechanism, and implementing some form of recursion in it. A lot of muddling toward a solution. Learned a lot. Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From raould@REDACTED Sat Jun 21 07:22:50 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 20 Jun 2014 22:22:50 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <1899380.1Z2M3BliFt@jalapeno> References: <2720179.2JvfftKefp@jalapeno> <1899380.1Z2M3BliFt@jalapeno> Message-ID: i for one have a strong dislike for the django docs. very strong. From zxq9@REDACTED Sat Jun 21 07:50:07 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 21 Jun 2014 14:50:07 +0900 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <1899380.1Z2M3BliFt@jalapeno> Message-ID: <1567668.L9TW3cJVpr@jalapeno> On Friday 20 June 2014 22:22:50 Raoul Duke wrote: > i for one have a strong dislike for the django docs. > > very strong. Care to elaborate? Unqualified derision does not express anything useful about what you (would) like. From n.oxyde@REDACTED Sat Jun 21 12:40:27 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 21 Jun 2014 12:40:27 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <53A4DF14.60209@meetinghouse.net> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <53A4DF14.60209@meetinghouse.net> Message-ID: I?m surprised no one mentioned Alligator Eggs yet. An introduction to untyped lambda calculus: http://worrydream.com/AlligatorEggs/ -- Anthony Ramine Le 21 juin 2014 ? 03:25, Miles Fidelman a ?crit : > Whoa that brings me back. From tim@REDACTED Sat Jun 21 12:44:55 2014 From: tim@REDACTED (Timothy Das) Date: Sat, 21 Jun 2014 06:44:55 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <53A4DF14.60209@meetinghouse.net> Message-ID: <531CCFD0-AC11-4EAB-A19D-5E45FBDA2399@chango.com> Hello Tim spurway is no longer using this address. Please remove this email from the thread Thanks Sent from my iPhone > On Jun 21, 2014, at 6:40 AM, Anthony Ramine wrote: > > I?m surprised no one mentioned Alligator Eggs yet. > > An introduction to untyped lambda calculus: > > http://worrydream.com/AlligatorEggs/ > > -- > Anthony Ramine > >> Le 21 juin 2014 ? 03:25, Miles Fidelman a ?crit : >> >> Whoa that brings me back. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From zxq9@REDACTED Sat Jun 21 13:33:54 2014 From: zxq9@REDACTED (zxq9) Date: Sat, 21 Jun 2014 20:33:54 +0900 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <53A4DF14.60209@meetinghouse.net> Message-ID: <13141214.NQ9m5JjLfC@jalapeno> On Saturday 21 June 2014 12:40:27 Anthony Ramine wrote: > I?m surprised no one mentioned Alligator Eggs yet. > > An introduction to untyped lambda calculus: > > http://worrydream.com/AlligatorEggs/ This is probably something everyone around here but me has seen a hundred times, so thanks for the link! What a fun little resource. It gives me ideas about puzzles for my kids that hadn't occurred to me before. -Craig From fhamilton@REDACTED Sat Jun 21 14:39:44 2014 From: fhamilton@REDACTED (Felix Hamilton) Date: Sat, 21 Jun 2014 05:39:44 -0700 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <13141214.NQ9m5JjLfC@jalapeno> References: <53A4DF14.60209@meetinghouse.net> <13141214.NQ9m5JjLfC@jalapeno> Message-ID: Look, I wasnt going to contribute to this particular discussion, but several youngsters of my acquaintance have enjoyed https://codecombat.com/ An Erlang version with similar functionality and perhaps an extended challenge set would be quite excellent, and map well to some of the other suggestions in this thread. ;-) On Sat, Jun 21, 2014 at 4:33 AM, zxq9 wrote: > On Saturday 21 June 2014 12:40:27 Anthony Ramine wrote: > > I?m surprised no one mentioned Alligator Eggs yet. > > > > An introduction to untyped lambda calculus: > > > > http://worrydream.com/AlligatorEggs/ > > This is probably something everyone around here but me has seen a hundred > times, so thanks for the link! > > What a fun little resource. It gives me ideas about puzzles for my kids > that > hadn't occurred to me before. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jun 21 14:40:56 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 21 Jun 2014 16:40:56 +0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? Message-ID: I'm doing very CPU bound task: video transcoding. What is better to use: dirty NIF or driver async? Is it correct to ask "what is better" in this case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Jun 21 15:00:31 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 21 Jun 2014 09:00:31 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <13141214.NQ9m5JjLfC@jalapeno> References: <53A4DF14.60209@meetinghouse.net> <13141214.NQ9m5JjLfC@jalapeno> Message-ID: <53A581EF.7070107@meetinghouse.net> zxq9 wrote: > On Saturday 21 June 2014 12:40:27 Anthony Ramine wrote: >> I?m surprised no one mentioned Alligator Eggs yet. >> >> An introduction to untyped lambda calculus: >> >> http://worrydream.com/AlligatorEggs/ > This is probably something everyone around here but me has seen a hundred > times, so thanks for the link! > > What a fun little resource. It gives me ideas about puzzles for my kids that > hadn't occurred to me before. > > New to me as well, and I'm on LOTS of educational computing lists. Thanks Anthony! Miles Fideman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From vinoski@REDACTED Sat Jun 21 15:34:47 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 21 Jun 2014 09:34:47 -0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: On Sat, Jun 21, 2014 at 8:40 AM, Max Lapshin wrote: > I'm doing very CPU bound task: video transcoding. > > > What is better to use: dirty NIF or driver async? > > Is it correct to ask "what is better" in this case? > IMO dirty NIFs are much easier to write, but there are other factors to consider. If you're going to have a number of concurrent Erlang processes running dirty native code, then you need to watch out for occupying all the dirty CPU scheduler threads such that your dirty jobs queue up faster than they can be processed. By default you get one dirty CPU scheduler thread per regular scheduler thread, and the number of dirty CPU scheduler threads may not exceed the number of regular scheduler threads (i.e, if you reduce the number of regular scheduler threads online at runtime, the number of dirty CPU scheduler threads online is likewise reduced). So if you plan to have a lot of video transcoding jobs running concurrently, where "a lot" is a number much larger than the number of scheduler threads, it might be better to use the async thread pool since you can easily make it as large as you want. Note that a dirty NIF can cooperatively yield a dirty scheduler thread by calling enif_schedule_dirty_nif() again, as that allows the dirty scheduler thread to reenter the emulator and dequeue a new job, but this still doesn't solve the problem of having too many jobs competing for dirty CPU scheduler thread resources. A nice thing about dirty NIFs is they're based on the normal Erlang process model, where a regular process runs native code on a dirty scheduler thread. Drivers and the async pool do not follow this model, which is part of the reason that sometime in the future, the async thread pool and drivers could go away, all in favor of native processes. None of this will happen prior to Erlang 19 at the earliest, but still, it's perhaps something to consider. And one other caveat: the dirty NIF API is experimental in 17.x and is subject to change. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Sat Jun 21 16:42:53 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Sat, 21 Jun 2014 15:42:53 +0100 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: Hi Max, depending on the communication patterns you have between your Erlang and C code, I wouldn't rule out the simple external port approach. It has the benefit of not polluting your Erlang VM with problems ;-) and is probably the easiest to implement. Robby On Jun 21, 2014 1:40 PM, "Max Lapshin" wrote: > I'm doing very CPU bound task: video transcoding. > > > What is better to use: dirty NIF or driver async? > > Is it correct to ask "what is better" in this case? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jun 21 18:23:16 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 21 Jun 2014 20:23:16 +0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: No, external port is not an easy thing. I've tried to do so, but stopped: too many work is done in C around packing/unpacking logic and commands. It is much easier to write small C code in C and wrapper in erlang: video is decoded to plain binaries, then coded back into binaries. Everything is running in a separate node. So transcoder node is a separate unix process with all it's threads. Different streams are transcoded in different processes. Steve, thanks for the explanation. I didn't knew how many dirty threads are there. There is flag: CPU or IO bound nif. How does this flag affects scheduling? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sat Jun 21 21:21:08 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 21 Jun 2014 15:21:08 -0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: On Sat, Jun 21, 2014 at 12:23 PM, Max Lapshin wrote: > No, external port is not an easy thing. > > I've tried to do so, but stopped: too many work is done in C around > packing/unpacking logic and commands. It is much easier to write small C > code in C and wrapper in erlang: video is decoded to plain binaries, then > coded back into binaries. > > Everything is running in a separate node. So transcoder node is a separate > unix process with all it's threads. Different streams are transcoded in > different processes. > > Steve, thanks for the explanation. I didn't knew how many dirty threads > are there. There is flag: CPU or IO bound nif. How does this flag affects > scheduling? > If you specify CPU-bound, the job is run on a dirty CPU scheduler; if I/O-bound, the job is run on a dirty I/O scheduler. The dirty CPU and dirty I/O schedulers reside in different pools. The number of dirty I/O schedulers is 10 by default, same as the number of threads in the async pool. You can change it via the +SDio option to erl (the explanation of which unfortunately appears to be missing from the erl man page, I'll submit a patch for that). The number of dirty CPU schedulers is aligned with the number of regular scheduler threads to prevent them from having too much of an impact on the regular schedulers. The number of dirty I/O schedulers can be larger, but that assumes those threads are I/O-bound and are thus not that busy.The submission of jobs to the dirty CPU threads vs dirty I/O threads is entirely up to the NIF developer; the code those two sets of threads run inside the emulator is the same as far as NIF execution goes. A developer could send dirty CPU jobs to the dirty I/O schedulers and vice versa; the runtime does nothing to try to govern or prevent this. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Jun 21 22:26:01 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Jun 2014 00:26:01 +0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: So, it is only required from runtime to notify about socket events, and drivers will not be required anymore =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alcosholik@REDACTED Sun Jun 22 00:43:49 2014 From: alcosholik@REDACTED (Alexei Sholik) Date: Sun, 22 Jun 2014 01:43:49 +0300 Subject: [erlang-questions] Go vs Erlang for distribution Message-ID: Hi, Let me say from the beginning that this is not meant as a flame post. I'm genuinely interested in some issues related to Erlang's adoption and how people outside of its community see its fitness for the domain where the insiders know it shines ? building distributed systems. My questions have been prompted by the apparent appeal of Go as a suitable tool for that exact domain. I have noticed the appeal being expressed both outside and _inside_ Erlang community (will explain soon). The reason for my asking on this particular list is twofold: 1. After discovering Erlang (not just the language, but in the wider sense: Erlang VM, OTP, its founding principles) I see it as a great fit for building distributed systems that can survive and auto-recover from various kinds of failures. It has also been proven over the years of being used in production. Erlang experts are the kind of people to go to when looking for an advice in this area. 2. In his recent talk at EUC Garrett Smith showed us an interesting slide[1] where Go appears to be one of the primary alternatives to Erlang, as chosen by _Erlang programmers themselves_. To me this implies that Erlang programmers have found in Go some of the principles Erlang builds upon, the fact I'm going to dispute below. [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large So now comes the question: what do Erlang programmers think about Go stealing some of the mindshare (and job-share) in the area of building distributed systems? Why would if be a good option? Or not an option at all? Just professional opinions based on your experience with Erlang please. Let me explain what suggests Go might be a viable alternative: * the slide mentioned above * Go has been used for teaching distributed systems at the Carnegie Mellon University since 2011. (Go 1 was release in early 2012) See this blog from the teacher: http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html * increased activity on projects such as libswarm[2], libchan[3], there are more. [2]: https://github.com/docker/libswarm [3]: https://github.com/docker/libchan If you haven't been keeping up with Go, here's a brief overview of its principles: * imperative, statically typed, garbage collected, lower level than scripting languages, but higher level than C * builtin concurrency with lightweight processes (called goroutines) which are scheduled cooperatively * single address space for all goroutines (modifying shared data is discouraged, but possible); hence no isolation * goroutines have no identity, communication between them is only possible through channels; hence no ability to monitor or link to goroutines, so no supervision * writing to a channel is always synchronous; it is possible to make a buffered channel, but once the buffer is full, the next goroutine trying to write to it will block * all errors must be handled explicitly; can be done at goroutine level by setting up a catch-all handler. But crashing in the catch-call handler will crash the goroutine. And crashing a goroutine crashes the whole program. No Erlang-style "let it crash" or "let someone else handle errors" >From this short survey Go looks more like the ultimate antagonist to Erlang, or at least its philosophy. What could justify its being chosen as an _alternative_ to Erlang? Sorry if it turned out a bit too long. Ultimately, I'm curious about the reasons Go appears in a huge font on Garrett's slide. Also, finding out why Go has seen a tremendous growth in just 2 years since initial stable release and is already seen as a good fit for tasks Erlang is considered the best tool in these circles might shed some light on which steps Erlang community could take to increase the awareness about its merits (especially in the light of a few recent threads on this list). This ended up rather convoluted, I know. If it was the wrong place to bring up this topic, I apologize. Feel free to ignore this thread in that case. Thanks for reading this far. -- Best regards Alexei Sholik -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Sun Jun 22 02:57:16 2014 From: zxq9@REDACTED (zxq9) Date: Sun, 22 Jun 2014 09:57:16 +0900 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: <1541116.OTeGbQ0VmZ@jalapeno> On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote: > 2. In his recent talk at EUC Garrett Smith showed us an interesting > slide[1] where Go appears to be one of the primary alternatives to Erlang, > as chosen by _Erlang programmers themselves_. To me this implies that > Erlang programmers have found in Go some of the principles Erlang builds > upon, the fact I'm going to dispute below. I don't see that at all. There are Python, Common Lisp, OpenCL and D frameworks that go a lot further toward emulating a distributed machine than anything I've seen in Go. But they are external things, just like any framework for distributed computing in Go would be. The syntax surrounding its use would be the responsibility of that platform/library, and not really have any inherently Go specific about it. > So now comes the question: what do Erlang programmers think about Go > stealing some of the mindshare (and job-share) in the area of building > distributed systems? Why would if be a good option? Or not an option at > all? Just professional opinions based on your experience with Erlang please. An inflammatory question if there ever was. ;-) Go is not, in my opinion, as compelling as Algol 68, D, Guile, Python or even Ada for any particular problem domain. Neither was Java. And this is where the historical parallel resides. Google is a huge company that is spending a *lot* of effort in an attempt to prevent yet another of their expensive toys winding up in the rubbish bin of digital history. Sun went to the exactly the same effort -- to hype a language and pet VM. Their focus on marketing (as opposed to technology) was so complete that it successfully warped our vocabulary about "objects" to meet their product while doing nothing to make their product advance the state of the art. That the industry and academia largely went along with this says more about human nature than technology. Google, able to control a large percentage of what the majority of us see and hear, may be capable of the same trick. I don't see Go as offering anything new. At all. Erlang is a decent language, but as you noted, that's not the real magic as its more an artifact of the history of the platform's implementation than anything else. The important thing is the platform and the complete way in which it embraces the Alan Kay sense of "objects" (and that term being so loaded and meaningless now, has been avoided in favor of "processes"). The Erlang platform is better because it requires that I do less work to get that sort of functionality. It emulates a distributed machine in a world where the hardware market has been pushed toward One Arch to Rule Them All. And that means that Go is yet another Algol descendant that I would be forced to learn for very little gain. Go doesn't have anything new to teach me about problem decomposition, expression of my intuitions about process, or formalization of either. Erlang's platform, on the other hand, enables a radically different way of thinking about these things. This is probably the most important thing I can say about a language or platform. This is an older, but quite interesting, article: http://cowlark.com/2009-11-15-go/ Anyway, I hope people who find Go a comfortable sytnax to write their Algol programs in use it to great effect. I'll adapt to that whenever I wind up working on something I care about that is already written in Go -- just like I have with Ruby, C++, D, Perl, etc. Placing too much emphasis on the difference is, in my opinion, a waste of effort -- because it doesn't help me get work done. From garry@REDACTED Sun Jun 22 03:32:46 2014 From: garry@REDACTED (Garry Hodgson) Date: Sat, 21 Jun 2014 21:32:46 -0400 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: <53A6323E.6020202@research.att.com> for me personally, i don't see Go as an alternative to erlang, or python, or any of the higher level languages i've become accustomed to. but i do see it as a potential alternative to C for cases where i need to do low level, performance critical stuff. On 06/21/2014 06:43 PM, Alexei Sholik wrote: > Hi, > > Let me say from the beginning that this is not meant as a flame post. > I'm genuinely interested in some issues related to Erlang's adoption > and how people outside of its community see its fitness for the domain > where the insiders know it shines -- building distributed systems. > > My questions have been prompted by the apparent appeal of Go as a > suitable tool for that exact domain. I have noticed the appeal being > expressed both outside and _inside_ Erlang community (will explain soon). > > The reason for my asking on this particular list is twofold: > > 1. After discovering Erlang (not just the language, but in the wider > sense: Erlang VM, OTP, its founding principles) I see it as a great > fit for building distributed systems that can survive and auto-recover > from various kinds of failures. It has also been proven over the years > of being used in production. Erlang experts are the kind of people to > go to when looking for an advice in this area. > > 2. In his recent talk at EUC Garrett Smith showed us an interesting > slide[1] where Go appears to be one of the primary alternatives to > Erlang, as chosen by _Erlang programmers themselves_. To me this > implies that Erlang programmers have found in Go some of the > principles Erlang builds upon, the fact I'm going to dispute below. > > [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large > > So now comes the question: what do Erlang programmers think about Go > stealing some of the mindshare (and job-share) in the area of building > distributed systems? Why would if be a good option? Or not an option > at all? Just professional opinions based on your experience with > Erlang please. > > Let me explain what suggests Go might be a viable alternative: > > * the slide mentioned above > * Go has been used for teaching distributed systems at the Carnegie > Mellon University since 2011. (Go 1 was release in early 2012) See > this blog from the teacher: > http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html > * increased activity on projects such as libswarm[2], libchan[3], > there are more. > > [2]: https://github.com/docker/libswarm > [3]: https://github.com/docker/libchan > > If you haven't been keeping up with Go, here's a brief overview of its > principles: > > * imperative, statically typed, garbage collected, lower level than > scripting languages, but higher level than C > * builtin concurrency with lightweight processes (called goroutines) > which are scheduled cooperatively > * single address space for all goroutines (modifying shared data is > discouraged, but possible); hence no isolation > * goroutines have no identity, communication between them is only > possible through channels; hence no ability to monitor or link to > goroutines, so no supervision > * writing to a channel is always synchronous; it is possible to make > a buffered channel, but once the buffer is full, the next goroutine > trying to write to it will block > * all errors must be handled explicitly; can be done at goroutine > level by setting up a catch-all handler. But crashing in the > catch-call handler will crash the goroutine. And crashing a goroutine > crashes the whole program. No Erlang-style "let it crash" or "let > someone else handle errors" > > From this short survey Go looks more like the ultimate antagonist to > Erlang, or at least its philosophy. What could justify its being > chosen as an _alternative_ to Erlang? > > Sorry if it turned out a bit too long. Ultimately, I'm curious about > the reasons Go appears in a huge font on Garrett's slide. Also, > finding out why Go has seen a tremendous growth in just 2 years since > initial stable release and is already seen as a good fit for tasks > Erlang is considered the best tool in these circles might shed some > light on which steps Erlang community could take to increase the > awareness about its merits (especially in the light of a few recent > threads on this list). > > This ended up rather convoluted, I know. If it was the wrong place to > bring up this topic, I apologize. Feel free to ignore this thread in > that case. > > Thanks for reading this far. > > -- > Best regards > Alexei Sholik > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Garry Hodgson AT&T Chief Security Office (CSO) "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited." -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Sun Jun 22 03:52:45 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Sat, 21 Jun 2014 18:52:45 -0700 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: <1541116.OTeGbQ0VmZ@jalapeno> References: <1541116.OTeGbQ0VmZ@jalapeno> Message-ID: For the average developer I see day-to-day coming from C or python or java or node, Go seems to tick many of the boxes: clean, immediately graspable, new, well-marketed, comes from famous unix people famous for good unix things, fast(er) for many use cases, and is said to handle that brand new 'concurrency' problem that everyone's started to talk about and put on their resumes. Erlang and Go don't really play in the same space, in my opinion, so I'm not all that worried that Erlang is going to vanish under a wave of Go. Go's foibles around error handling, ecosystem, and tooling, and a roll-your-own channel model, will tend to mean Go's sweet spot is small tools that stay small; but it's solid in that area owing to the slightly more modern type system and safety features. Erlang's foibles around skill curve, ecosystem complexity, and gaining the ability to reason effectively means it's not great for the small, but kicks ass in the huge where the OTP and actor tax are offset by the radical advantages they convey in the ability to debug and reason about behavior. Maybe one day a better, more comprehensible functional language and ecosystem revolving around the actor model comes out and Erlang fades. Could be Valim. Way more likely Valim than Pike. F. On Sat, Jun 21, 2014 at 5:57 PM, zxq9 wrote: > On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote: > > 2. In his recent talk at EUC Garrett Smith showed us an interesting > > slide[1] where Go appears to be one of the primary alternatives to > Erlang, > > as chosen by _Erlang programmers themselves_. To me this implies that > > Erlang programmers have found in Go some of the principles Erlang builds > > upon, the fact I'm going to dispute below. > > I don't see that at all. There are Python, Common Lisp, OpenCL and D > frameworks that go a lot further toward emulating a distributed machine > than > anything I've seen in Go. But they are external things, just like any > framework for distributed computing in Go would be. The syntax surrounding > its > use would be the responsibility of that platform/library, and not really > have > any inherently Go specific about it. > > > So now comes the question: what do Erlang programmers think about Go > > stealing some of the mindshare (and job-share) in the area of building > > distributed systems? Why would if be a good option? Or not an option at > > all? Just professional opinions based on your experience with Erlang > please. > > An inflammatory question if there ever was. ;-) > > Go is not, in my opinion, as compelling as Algol 68, D, Guile, Python or > even > Ada for any particular problem domain. Neither was Java. And this is where > the > historical parallel resides. > > Google is a huge company that is spending a *lot* of effort in an attempt > to > prevent yet another of their expensive toys winding up in the rubbish bin > of > digital history. > > Sun went to the exactly the same effort -- to hype a language and pet VM. > Their focus on marketing (as opposed to technology) was so complete that it > successfully warped our vocabulary about "objects" to meet their product > while > doing nothing to make their product advance the state of the art. That the > industry and academia largely went along with this says more about human > nature than technology. > > Google, able to control a large percentage of what the majority of us see > and > hear, may be capable of the same trick. > > I don't see Go as offering anything new. At all. Erlang is a decent > language, > but as you noted, that's not the real magic as its more an artifact of the > history of the platform's implementation than anything else. The important > thing is the platform and the complete way in which it embraces the Alan > Kay > sense of "objects" (and that term being so loaded and meaningless now, has > been avoided in favor of "processes"). The Erlang platform is better > because > it requires that I do less work to get that sort of functionality. It > emulates > a distributed machine in a world where the hardware market has been pushed > toward One Arch to Rule Them All. > > And that means that Go is yet another Algol descendant that I would be > forced > to learn for very little gain. Go doesn't have anything new to teach me > about > problem decomposition, expression of my intuitions about process, or > formalization of either. Erlang's platform, on the other hand, enables a > radically different way of thinking about these things. This is probably > the > most important thing I can say about a language or platform. > > This is an older, but quite interesting, article: > http://cowlark.com/2009-11-15-go/ > > Anyway, I hope people who find Go a comfortable sytnax to write their Algol > programs in use it to great effect. I'll adapt to that whenever I wind up > working on something I care about that is already written in Go -- just > like I > have with Ruby, C++, D, Perl, etc. Placing too much emphasis on the > difference > is, in my opinion, a waste of effort -- because it doesn't help me get work > done. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sun Jun 22 04:07:12 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 21 Jun 2014 22:07:12 -0400 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: <1541116.OTeGbQ0VmZ@jalapeno> References: <1541116.OTeGbQ0VmZ@jalapeno> Message-ID: <53A63A50.5070205@meetinghouse.net> One quibble - see below: zxq9 wrote: > On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote: >> 2. In his recent talk at EUC Garrett Smith showed us an interesting >> slide[1] where Go appears to be one of the primary alternatives to Erlang, >> as chosen by _Erlang programmers themselves_. To me this implies that >> Erlang programmers have found in Go some of the principles Erlang builds >> upon, the fact I'm going to dispute below. > > I don't see Go as offering anything new. At all. Erlang is a decent language, > but as you noted, that's not the real magic as its more an artifact of the > history of the platform's implementation than anything else. The important > thing is the platform and the complete way in which it embraces the Alan Kay > sense of "objects" (and that term being so loaded and meaningless now, has > been avoided in favor of "processes"). I see Erlang as an implementation of the Actor model, a la Carl Hewitt - which developed in parallel with Alan Kay's work, and influenced it (and both were influenced by Simula). Smalltalk-72 included message-passing concurrency of sorts, but that pretty much went away in later versions of Smalltalk (messages remained, but multiple threads of execution kind of went away). There's a very interesting discussion of this in the archives of the fonc email list - starting at http://vpri.org/mailman/private/fonc/2013/003975.html (which builds on Alan's "Early History of Smalltalk" paper - http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From zxq9@REDACTED Sun Jun 22 04:26:15 2014 From: zxq9@REDACTED (zxq9) Date: Sun, 22 Jun 2014 11:26:15 +0900 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: <53A63A50.5070205@meetinghouse.net> References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> Message-ID: <155962608.HcHVWDN8GL@jalapeno> On Saturday 21 June 2014 22:07:12 Miles Fidelman wrote: > One quibble - see below: > > zxq9 wrote: > > On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote: > >> 2. In his recent talk at EUC Garrett Smith showed us an interesting > >> > >> slide[1] where Go appears to be one of the primary alternatives to > >> Erlang, > >> as chosen by _Erlang programmers themselves_. To me this implies that > >> Erlang programmers have found in Go some of the principles Erlang builds > >> upon, the fact I'm going to dispute below. > > > > > I don't see Go as offering anything new. At all. Erlang is a decent > > language, but as you noted, that's not the real magic as its more an > > artifact of the history of the platform's implementation than anything > > else. The important thing is the platform and the complete way in which > > it embraces the Alan Kay sense of "objects" (and that term being so > > loaded and meaningless now, has been avoided in favor of "processes"). > > I see Erlang as an implementation of the Actor model, a la Carl Hewitt - > which developed in parallel with Alan Kay's work, and influenced it (and > both were influenced by Simula). Smalltalk-72 included message-passing > concurrency of sorts, but that pretty much went away in later versions > of Smalltalk (messages remained, but multiple threads of execution kind > of went away). > > There's a very interesting discussion of this in the archives of the > fonc email list - starting at > http://vpri.org/mailman/private/fonc/2013/003975.html (which builds on > Alan's "Early History of Smalltalk" paper - > http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html). Unfortunately the fonc list archive at vpri is behind a password wall, so I'll just have to accept ignorance of the discussion. The other link, however, is open and skimming through it, an excellent organization of many of the points I've heard Alan Kay and a few other folks make throughout the years. The chronological arrangement of the essay, however, makes the ideas into a story -- an exciting one to my inner nerd. Thanks for the references. One thing I enjoy about the archives of this list are the frequency and quality of external references. Quite regularly a reference tossed out in a peripheral discussion such as this one leads me to a new way of thinking about a core concept that is useful in Erlang (it helps that a lot of the otherwise esoteric stuff is quite trivial and well documented on this platform). -Craig From g@REDACTED Sun Jun 22 04:27:30 2014 From: g@REDACTED (Garrett Smith) Date: Sat, 21 Jun 2014 21:27:30 -0500 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: On Sat, Jun 21, 2014 at 5:43 PM, Alexei Sholik wrote: > Hi, -snip- > 2. In his recent talk at EUC Garrett Smith showed us an interesting > slide[1] where Go appears to be one of the primary alternatives to Erlang, > as chosen by _Erlang programmers themselves_. To me this implies that Erlang > programmers have found in Go some of the principles Erlang builds upon, the > fact I'm going to dispute below. > > [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large > > So now comes the question: what do Erlang programmers think about Go > stealing some of the mindshare (and job-share) in the area of building > distributed systems? Why would if be a good option? Or not an option at all? > Just professional opinions based on your experience with Erlang please. The question that people answered was: What languages or frameworks would you consider as alternatives to Erlang? This seems straight forward enough, but each answer was in narrative/text format, so there was usually some context. Often "alternative" was interpreted to mean something closer to "complement". Users of Erlang and Go are generally well aware of the extreme differences as a language and platform. Go is thought of as a more OS/posix friendly language that offers some concurrency features. So it's an alternative in cases where performance and systems programming/integration is important. It's not a drop-in replacement for Erlang, of course. Respondents frequently cited golang.org as a motivation for adoption, or at least their comfort level. It seems there's some inspiration there in the way Go is marketed/communicated. My personal takeaway is that the Erlang community and Ericsson might look closely at the way Google presents and supports Go. I have no idea what specifically would come from this, but I plan on spending some time on this in the near future. So, one last observation. Let's be careful not to over read this survey. It's provocative, fine. But my hope was that we could measure a little and then do a little, then rinse and repeat. And indeed there are a number of practical steps that people are talking about that have emerged from this work. But let's be aware that, for some, these topics can serve as emotional and cathartic outlets with little chance of improving Erlang or its adoption. I'm not suggesting this is happening - just that it might. Because then people will start yelling at me off list for stirring all this up. Seriously, I can sense them leering from the shadows. Garrett From samuelrivas@REDACTED Sun Jun 22 13:16:02 2014 From: samuelrivas@REDACTED (Samuel) Date: Sun, 22 Jun 2014 13:16:02 +0200 Subject: [erlang-questions] Why (not) hot code loading In-Reply-To: <11896881.Ktyz5iOU4i@jalapeno> References: <11896881.Ktyz5iOU4i@jalapeno> Message-ID: Some systems I worked (and still work) with use hot code loading in production for upgrades and hot-patching. I have never found technical issues in that functionality per-se; that is, I believe is solid and works as advertised. However it typically implies many side difficulties which probably fall into your B category. There are many things to take into account when doing hot upgrades in production. Apart from the already mentioned issues with changes in data models and APIs, the effects of purging code are sometimes very difficult to predict; testing is not easy as the production system will have a very long living internal state that is somewhat complex to reproduce in testing environments; etc, etc. So, in general, if you could avoid production hot code loading in favour of more predictable ways of upgrading your systems, like rolling upgrades, it is likely that you can avoid a large class of issues and technicalities that are hard to solve. So if I were to advice you against using it it wouldn't be because it were a crappy feature or I didn't understand it, it is more because, for most application domains, it buys you very little at a non-negligible cost. If you manage to find a problem where other techniques are actually more costly than hot-upgrading your production systems then you could use it at your advantage. Best On 20 June 2014 20:02, zxq9 wrote: > I've never had a situation where I've needed hot code loading, but a project > that may be a good fit with this feature is looming (and may not be a good fit > -- I have much to learn about this feature). Nearly all the advice I see on > this is to avoid it in production, which seems highly ironic, since this > feature was designed specifically to ease certain cases of production. > > The advice against using it mostly comes from tutorials, presentations and > asides made by various speakers in talks I've seen. I don't have a canonical > "don't use hot code loading" reference, but I have exactly zero references > which urge the use of this feature and explain in depth how to integrate it > with a release cycle. > > But someone worked a long time figuring out how to make this a part of the > runtime, so... > > Is this feature: > A) "Hard" to use because it is far outside the experience of the average Java- > or web-developer-turned-Erlanger who tends to give talks about Erlang. > B) "Hard" to use because it is actually hard: a technically complex feature > for which little scaffolding is available for easy integration. > C) Actually not very useful. > D) People have been trained to accept maintenance downtime and believe that > loadbalancers are the answer to everything? > > Most of the best tools I've ever used fell into category (A), so I wonder if > that is the case with this feature. Some things I've really liked in > environments like Guile fell into category (B), which was nice because after > some thorough study something complex but understandable can be abstracted and > made easy to use. I have a hard time believing that this feature actually > falls into category (C), feeling it is much more likely that widespread > acceptable of the (D) view simply obviates much deep thought on the utility of > it in the first place -- especially since so much focus, even within the > Erlang community these days, is on the web and not other areas. > > Can anyone provide some insight into this? I'd rather get some opinions now > than spend time getting to the bottom of a relatively untaught feature only to > find that it wasn't very useful. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Samuel From musicdenotation@REDACTED Sun Jun 22 10:49:34 2014 From: musicdenotation@REDACTED (musicdenotation@REDACTED) Date: Sun, 22 Jun 2014 15:49:34 +0700 Subject: [erlang-questions] License change Message-ID: <9D551211-8590-4FA5-8FEA-D8D1559396A1@gmail.com> In December 2013 I asked to change Erlang's license to MPL 2.0, and the response was that there was a plan to change the license. Why hasn't the license changed yet? Did the answerer lie? From dmkolesnikov@REDACTED Sun Jun 22 16:41:52 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sun, 22 Jun 2014 17:41:52 +0300 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: Message-ID: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> Hello Max, Are you mixing C ports and C nodes here? I do agree that C node requires extra effort to handle message marshalling but C port is pure I/O, each port is executed by dedicated OS process. http://www.erlang.org/doc/tutorial/c_port.html Would it make sense to you use it? - Dmitry On 21 Jun 2014, at 19:23, Max Lapshin wrote: > No, external port is not an easy thing. > > I've tried to do so, but stopped: too many work is done in C around packing/unpacking logic and commands. It is much easier to write small C code in C and wrapper in erlang: video is decoded to plain binaries, then coded back into binaries. > > Everything is running in a separate node. So transcoder node is a separate unix process with all it's threads. Different streams are transcoded in different processes. > > Steve, thanks for the explanation. I didn't knew how many dirty threads are there. There is flag: CPU or IO bound nif. How does this flag affects scheduling? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Sun Jun 22 18:24:46 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 22 Jun 2014 20:24:46 +0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> References: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> Message-ID: Dmitry, I'm using slave:start for spawning separate Erlang process for each transcoder and use nif (now with dirty schedulers) for running decode/encode. C port and c node are both very inconvenient, because they require lot of marshalling/demarshalling. Also it is impossible to run erlang between different parts of C job. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail@REDACTED Sun Jun 22 18:27:02 2014 From: mail@REDACTED (Alexander Alexeev) Date: Sun, 22 Jun 2014 20:27:02 +0400 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released In-Reply-To: References: Message-ID: <20140622202702.48cc7642@fujitsu> Looks great! I wonder, 1. Are there any limits on number of keys, database size, etc? 2. What made you create your own database engine? Is it something wrong with HanoiDB? On Wed, 18 Jun 2014 00:14:15 +0200 Benoit Chesneau wrote: > I just released the version 0.2.0 which add unit-testing and contains > some fixes: > > https://wiki.refuge.io/display/COWDB/Changelog#Changelog-0.2.0-2014/06/17 > > Enjoy! > > - benoit > > > On Tue, Jun 17, 2014 at 1:04 AM, Benoit Chesneau > wrote: > > > Hi all, > > > > I presented it rapidly during the EUC and it took some time to > > finish some feature but here the first release of cowdb: > > > > http://cowdb.org > > > > Cowdb implements an indexed, key/value storage engine in #Erlang. > > The primary index is an append-only btree implemented using CBT a > > btree library extracted from Apache #CouchDB. > > > > Main features are: > > > > - Append-Only b-tree using COW > > - Read/Write can happen independently > > - Put/Get/Delete/Fold operations > > - support transactions with transaction functions > > - Transaction log > > - Snapshotting support > > - Automatic compaction > > > > Enjoy!? > > > > - benoit > > -- Best regards, Alexander Alexeev http://eax.me/ From jay@REDACTED Sun Jun 22 20:06:39 2014 From: jay@REDACTED (Jay Nelson) Date: Sun, 22 Jun 2014 11:06:39 -0700 Subject: [erlang-questions] Dictionary strategy of last value wins Message-ID: I?m implementing a library using dictionaries and I?ve noticed that all the dictionary alternatives use imperative-style initialization semantics. Proplists were introduced to allow efficient shadowing of environments and defaults. Pushing a value on the front of a proplist makes the first value encountered be the current value. You can then pop contexts and reveal the older values efficiently in a functional programming style. Dictionaries use hash-like semantics of last value wins in an imperative assignment that clobbers old values (and loses them forever) thus making them non-functional and non-persistent. I assume initialization of dictionaries are kept imperative for consistency / efficiency, but it makes the two styles of initialization incompatible (but keeps the internal semantics of each datatype consistent). The recommended technique for maps is to set a default dictionary and then the shadowing dictionary and merge them. I guess this leads to a functional style of a stack of maps for shadowing contexts, but this approach is only recommended as overcoming default initialization. In recent code, I?ve had to use different semantics for defaulted values vs user-specified values and having a dictionary meant I couldn?t tell whether the current value was an implicit default or an explicit choice after the initialization phase had completed. Do others build proplists and then reverse them when initializing a dictionary? (This seems very imperative, having to maintain your own data versions: proplist and dictionary init list, especially if you want shadowing semantics and need to go back to the source context and initialize subsequent dictionaries). Or do you maintain a stack of dictionaries and do a cascading search until a value is found? This approach allows context labeling and thus you could know if a value was explicit or implicitly defaulted. Or do you just change to an imperative style for your code when you start thinking with dictionaries (or have you not noticed the difference)? My new library is supposed to allow selection of implementation without change to the higher-level logic. I suppose I am going to have to provide ?proplist (functional)? and ?last wins (imperative)? options for initialization of the underlying implementation (and do proper initialization in all cases). My current approach is to stick with a functional style of programming and use proplist semantics on initialization of my object wrappers around dictionaries (dict, orddict, vbisect; maps in future; possibly will add proplists and records as options as well, and I suppose arrays could be used). The current overhead expense is that I have to scan the init list while constructing the dictionary doing lookups to see if a value is already set and skip it in the case of an earlier definition (I also do this because I sometimes need to validate the datatypes to ensure that constructed dictionaries use legal types on all input ? I could switch to a faster initialization in cases where datatype doesn?t matter by reversing the list, assuming the list size is never ginormous). jay From bob@REDACTED Sun Jun 22 20:16:44 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 22 Jun 2014 11:16:44 -0700 Subject: [erlang-questions] Dictionary strategy of last value wins In-Reply-To: References: Message-ID: If you do want to keep a full history of inserts, couldn't you use a dict(K, [V])? Sure, you'd have to write a few functions, since dict:append/3 doesn't have the desired semantics, but such functions are straightforward to write. prepend(K, V, D) -> dict:update(K, fun (Vs) -> [V | Vs] end, [V], D). On Sun, Jun 22, 2014 at 11:06 AM, Jay Nelson wrote: > I?m implementing a library using dictionaries and I?ve noticed that all the > dictionary alternatives use imperative-style initialization semantics. > Proplists were > introduced to allow efficient shadowing of environments and defaults. > Pushing a value on the front of a proplist makes the first value > encountered > be the current value. You can then pop contexts and reveal the older values > efficiently in a functional programming style. > > Dictionaries use hash-like semantics of last value wins in an imperative > assignment that clobbers old values (and loses them forever) thus making > them non-functional and non-persistent. I assume initialization of > dictionaries > are kept imperative for consistency / efficiency, but it makes the two > styles > of initialization incompatible (but keeps the internal semantics of each > datatype consistent). > > The recommended technique for maps is to set a default dictionary and > then the shadowing dictionary and merge them. I guess this leads to a > functional style of a stack of maps for shadowing contexts, but this > approach > is only recommended as overcoming default initialization. In recent code, > I?ve had to use different semantics for defaulted values vs user-specified > values and having a dictionary meant I couldn?t tell whether the current > value was an implicit default or an explicit choice after the > initialization > phase had completed. > > Do others build proplists and then reverse them when initializing a > dictionary? > (This seems very imperative, having to maintain your own data versions: > proplist and dictionary init list, especially if you want shadowing > semantics > and need to go back to the source context and initialize subsequent > dictionaries). > > Or do you maintain a stack of dictionaries and do a cascading search until > a value is found? This approach allows context labeling and thus you could > know if a value was explicit or implicitly defaulted. > > Or do you just change to an imperative style for your code when you start > thinking with dictionaries (or have you not noticed the difference)? > > My new library is supposed to allow selection of implementation without > change to the higher-level logic. I suppose I am going to have to provide > ?proplist (functional)? and ?last wins (imperative)? options for > initialization > of the underlying implementation (and do proper initialization in all > cases). > > My current approach is to stick with a functional style of programming > and use proplist semantics on initialization of my object wrappers around > dictionaries (dict, orddict, vbisect; maps in future; possibly will add > proplists and records as options as well, and I suppose arrays could > be used). The current overhead expense is that I have to scan the init > list while constructing the dictionary doing lookups to see if a value is > already set and skip it in the case of an earlier definition (I also do > this > because I sometimes need to validate the datatypes to ensure that > constructed dictionaries use legal types on all input ? I could switch > to a faster initialization in cases where datatype doesn?t matter by > reversing the list, assuming the list size is never ginormous). > > jay > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sun Jun 22 23:02:58 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 22 Jun 2014 14:02:58 -0700 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: <1403470978.22145.131673469.08CF9B0A@webmail.messagingengine.com> I wrote a post about this recently because I found the idea of Go being an alternative to be ludicrous, especially after working with Go: [1]http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/ -- Tristan Sloughter tristan.sloughter@REDACTED On Sat, Jun 21, 2014, at 03:43 PM, Alexei Sholik wrote: Hi, Let me say from the beginning that this is not meant as a flame post. I'm genuinely interested in some issues related to Erlang's adoption and how people outside of its community see its fitness for the domain where the insiders know it shines ? building distributed systems. My questions have been prompted by the apparent appeal of Go as a suitable tool for that exact domain. I have noticed the appeal being expressed both outside and _inside_ Erlang community (will explain soon). The reason for my asking on this particular list is twofold: 1. After discovering Erlang (not just the language, but in the wider sense: Erlang VM, OTP, its founding principles) I see it as a great fit for building distributed systems that can survive and auto-recover from various kinds of failures. It has also been proven over the years of being used in production. Erlang experts are the kind of people to go to when looking for an advice in this area. 2. In his recent talk at EUC Garrett Smith showed us an interesting slide[1] where Go appears to be one of the primary alternatives to Erlang, as chosen by _Erlang programmers themselves_. To me this implies that Erlang programmers have found in Go some of the principles Erlang builds upon, the fact I'm going to dispute below. [1]: [2]https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large So now comes the question: what do Erlang programmers think about Go stealing some of the mindshare (and job-share) in the area of building distributed systems? Why would if be a good option? Or not an option at all? Just professional opinions based on your experience with Erlang please. Let me explain what suggests Go might be a viable alternative: * the slide mentioned above * Go has been used for teaching distributed systems at the Carnegie Mellon University since 2011. (Go 1 was release in early 2012) See this blog from the teacher: [3]http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-i n-go.html * increased activity on projects such as libswarm[2], libchan[3], there are more. [2]: [4]https://github.com/docker/libswarm [3]: [5]https://github.com/docker/libchan If you haven't been keeping up with Go, here's a brief overview of its principles: * imperative, statically typed, garbage collected, lower level than scripting languages, but higher level than C * builtin concurrency with lightweight processes (called goroutines) which are scheduled cooperatively * single address space for all goroutines (modifying shared data is discouraged, but possible); hence no isolation * goroutines have no identity, communication between them is only possible through channels; hence no ability to monitor or link to goroutines, so no supervision * writing to a channel is always synchronous; it is possible to make a buffered channel, but once the buffer is full, the next goroutine trying to write to it will block * all errors must be handled explicitly; can be done at goroutine level by setting up a catch-all handler. But crashing in the catch-call handler will crash the goroutine. And crashing a goroutine crashes the whole program. No Erlang-style "let it crash" or "let someone else handle errors" >From this short survey Go looks more like the ultimate antagonist to Erlang, or at least its philosophy. What could justify its being chosen as an _alternative_ to Erlang? Sorry if it turned out a bit too long. Ultimately, I'm curious about the reasons Go appears in a huge font on Garrett's slide. Also, finding out why Go has seen a tremendous growth in just 2 years since initial stable release and is already seen as a good fit for tasks Erlang is considered the best tool in these circles might shed some light on which steps Erlang community could take to increase the awareness about its merits (especially in the light of a few recent threads on this list). This ended up rather convoluted, I know. If it was the wrong place to bring up this topic, I apologize. Feel free to ignore this thread in that case. Thanks for reading this far. -- Best regards Alexei Sholik _______________________________________________ erlang-questions mailing list [6]erlang-questions@REDACTED [7]http://erlang.org/mailman/listinfo/erlang-questions References 1. http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/ 2. https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large 3. http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html 4. https://github.com/docker/libswarm 5. https://github.com/docker/libchan 6. mailto:erlang-questions@REDACTED 7. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan@REDACTED Sun Jun 22 23:54:24 2014 From: duncan@REDACTED (Duncan McGreggor) Date: Sun, 22 Jun 2014 14:54:24 -0700 Subject: [erlang-questions] License change In-Reply-To: <9D551211-8590-4FA5-8FEA-D8D1559396A1@gmail.com> References: <9D551211-8590-4FA5-8FEA-D8D1559396A1@gmail.com> Message-ID: Changing licenses for open source projects is an incredibly cumbersome process -- it takes a great deal of time. The kicker is, that to accord by most open source licenses, one must contact every contributor who has ever had patches committed. One is legally bound to be able to produce evidence that all reasonable means were attempted to contact everyone, in the event that some don't respond. (This is one of the reasons that some open source projects opt to put copyright in the care of foundations or supporting companies, so that changes need only be agreed upon by a smaller/governing group and not everyone in the history of the project.) An update was given at the EUC that a successful "trial run" was done a few months back, where many folks were contacted to see if there were any objections to a license change. No serious objections (if any) were mentioned at the conference, and it sounded like they were going to start working on the "real thing" soon (or already had?). Again, this will take time because *everyone* has to respond (and extensive documentation of the process has to take place in the event that not everyone does). I'm sure members of the OTP Team have more (and more accurate!) details ... OTP Team: I forget which license has been agreed upon. Was it Apache 2.0? Hope this puts you at ease :-) d P.S. In general, it's probably a good idea to find out what is involved in a given process before intimating that those involved in it might be lying ;-) One might also get more/better responses from others ... On Sun, Jun 22, 2014 at 1:49 AM, wrote: > In December 2013 I asked to change Erlang's license to MPL 2.0, and the > response was that there was a plan to change the license. Why hasn't the > license changed yet? Did the answerer lie? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Sun Jun 22 23:58:34 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Sun, 22 Jun 2014 23:58:34 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> Message-ID: On 2014-06-22 02:07:12 +0000, Miles Fidelman said: > I see Erlang as an implementation of the Actor model, a la Carl Hewitt - This crops up again and again but still isn't true. Erlang does *not* implement Actors but processes with links/monitors mailboxes and messages, which are not equivalent to actors. Processes: sequence of function calls interspresed with (selective) receives that pick out someting out of the mailbox. Actor: has to handle every message immediately, the actions a message triggers are happening concurrently, nothing longer running or sequential allowed. Hewitt says himself that Erlang does not implement Actors: http://arxiv.org/pdf/1008.1459.pdf He picks on different things like "silent process failure" instead of exceptions (which don't make much sense for somone familiar with Erlang) and that Actors seem to be garbage collected if they are "unneded" probably no longer referenced from the outside and Erlang needs "internal termination". Hewitt writes mostly what he finds lacking but on the other hand I find the process with mailbox, selective receive and links/monitors (not ver silent ;-) more powerful that simple Actors. Also as aside from what I've heard Erlangs creators didn't look at Actors when creating. Cheers, -- Peer From paul.joseph.davis@REDACTED Sun Jun 22 23:59:55 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sun, 22 Jun 2014 16:59:55 -0500 Subject: [erlang-questions] License change In-Reply-To: References: <9D551211-8590-4FA5-8FEA-D8D1559396A1@gmail.com> Message-ID: On Sun, Jun 22, 2014 at 4:54 PM, Duncan McGreggor wrote: > Changing licenses for open source projects is an incredibly cumbersome > process -- it takes a great deal of time. The kicker is, that to accord by > most open source licenses, one must contact every contributor who has ever > had patches committed. One is legally bound to be able to produce evidence > that all reasonable means were attempted to contact everyone, in the event > that some don't respond. (This is one of the reasons that some open source > projects opt to put copyright in the care of foundations or supporting > companies, so that changes need only be agreed upon by a smaller/governing > group and not everyone in the history of the project.) > > An update was given at the EUC that a successful "trial run" was done a few > months back, where many folks were contacted to see if there were any > objections to a license change. No serious objections (if any) were > mentioned at the conference, and it sounded like they were going to start > working on the "real thing" soon (or already had?). Again, this will take > time because *everyone* has to respond (and extensive documentation of the > process has to take place in the event that not everyone does). > > I'm sure members of the OTP Team have more (and more accurate!) details ... > > OTP Team: I forget which license has been agreed upon. Was it Apache 2.0? > Yep, they said ASL 2.0 at EUC 2014. > Hope this puts you at ease :-) > > d > > P.S. In general, it's probably a good idea to find out what is involved in a > given process before intimating that those involved in it might be lying ;-) > One might also get more/better responses from others ... > > > > On Sun, Jun 22, 2014 at 1:49 AM, wrote: >> >> In December 2013 I asked to change Erlang's license to MPL 2.0, and the >> response was that there was a plan to change the license. Why hasn't the >> license changed yet? Did the answerer lie? >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From rvirding@REDACTED Mon Jun 23 02:27:28 2014 From: rvirding@REDACTED (Robert Virding) Date: Mon, 23 Jun 2014 02:27:28 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> Message-ID: We had never heard of the actor model, at least I hadn't. We had other inputs, amongst others Eripascal which an internal Ericsson version of Pascal which had processes and messages. Hewitt got a lot of things wrong in his description of Erlang. Robert On 22 June 2014 23:58, Peer Stritzinger wrote: > On 2014-06-22 02:07:12 +0000, Miles Fidelman said: > >> I see Erlang as an implementation of the Actor model, a la Carl Hewitt - >> > > This crops up again and again but still isn't true. > > Erlang does *not* implement Actors but processes with links/monitors > mailboxes and messages, which are not equivalent to actors. > > Processes: sequence of function calls interspresed with (selective) > receives that pick out someting out of the mailbox. > > Actor: has to handle every message immediately, the actions a message > triggers are happening concurrently, nothing longer running or sequential > allowed. > > Hewitt says himself that Erlang does not implement Actors: > http://arxiv.org/pdf/1008.1459.pdf > > He picks on different things like "silent process failure" instead of > exceptions (which don't make much sense for somone familiar with Erlang) > and that Actors seem to be garbage collected if they are "unneded" probably > no longer referenced from the outside and Erlang needs "internal > termination". > > Hewitt writes mostly what he finds lacking but on the other hand I find > the process with mailbox, selective receive and links/monitors (not ver > silent ;-) more powerful that simple Actors. > > Also as aside from what I've heard Erlangs creators didn't look at Actors > when creating. > > Cheers, > -- Peer > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Mon Jun 23 02:31:55 2014 From: rvirding@REDACTED (Robert Virding) Date: Mon, 23 Jun 2014 02:31:55 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> Message-ID: And of course OSes which embody a lot of the ideas we were after, but in such a way that they were/are way to heavy for what we were after. In many ways an Erlang system does have an OS feeling about it. At least I think so. Robert On 23 June 2014 02:27, Robert Virding wrote: > We had never heard of the actor model, at least I hadn't. We had other > inputs, amongst others Eripascal which an internal Ericsson version of > Pascal which had processes and messages. > > Hewitt got a lot of things wrong in his description of Erlang. > > Robert > > > > On 22 June 2014 23:58, Peer Stritzinger wrote: > >> On 2014-06-22 02:07:12 +0000, Miles Fidelman said: >> >>> I see Erlang as an implementation of the Actor model, a la Carl Hewitt - >>> >> >> This crops up again and again but still isn't true. >> >> Erlang does *not* implement Actors but processes with links/monitors >> mailboxes and messages, which are not equivalent to actors. >> >> Processes: sequence of function calls interspresed with (selective) >> receives that pick out someting out of the mailbox. >> >> Actor: has to handle every message immediately, the actions a message >> triggers are happening concurrently, nothing longer running or sequential >> allowed. >> >> Hewitt says himself that Erlang does not implement Actors: >> http://arxiv.org/pdf/1008.1459.pdf >> >> He picks on different things like "silent process failure" instead of >> exceptions (which don't make much sense for somone familiar with Erlang) >> and that Actors seem to be garbage collected if they are "unneded" probably >> no longer referenced from the outside and Erlang needs "internal >> termination". >> >> Hewitt writes mostly what he finds lacking but on the other hand I find >> the process with mailbox, selective receive and links/monitors (not ver >> silent ;-) more powerful that simple Actors. >> >> Also as aside from what I've heard Erlangs creators didn't look at Actors >> when creating. >> >> Cheers, >> -- Peer >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngocdaothanh@REDACTED Mon Jun 23 04:22:36 2014 From: ngocdaothanh@REDACTED (Ngoc Dao) Date: Mon, 23 Jun 2014 11:22:36 +0900 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> Message-ID: > In many ways an Erlang system does have an OS feeling about it. At least I think so. I think so, too: http://www.slideshare.net/ngocdaothanh/cloud-erlang On Mon, Jun 23, 2014 at 9:31 AM, Robert Virding wrote: > And of course OSes which embody a lot of the ideas we were after, but in > such a way that they were/are way to heavy for what we were after. In many > ways an Erlang system does have an OS feeling about it. At least I think so. > > Robert > > > On 23 June 2014 02:27, Robert Virding wrote: > >> We had never heard of the actor model, at least I hadn't. We had other >> inputs, amongst others Eripascal which an internal Ericsson version of >> Pascal which had processes and messages. >> >> Hewitt got a lot of things wrong in his description of Erlang. >> >> Robert >> >> >> >> On 22 June 2014 23:58, Peer Stritzinger wrote: >> >>> On 2014-06-22 02:07:12 +0000, Miles Fidelman said: >>> >>>> I see Erlang as an implementation of the Actor model, a la Carl Hewitt - >>>> >>> >>> This crops up again and again but still isn't true. >>> >>> Erlang does *not* implement Actors but processes with links/monitors >>> mailboxes and messages, which are not equivalent to actors. >>> >>> Processes: sequence of function calls interspresed with (selective) >>> receives that pick out someting out of the mailbox. >>> >>> Actor: has to handle every message immediately, the actions a message >>> triggers are happening concurrently, nothing longer running or sequential >>> allowed. >>> >>> Hewitt says himself that Erlang does not implement Actors: >>> http://arxiv.org/pdf/1008.1459.pdf >>> >>> He picks on different things like "silent process failure" instead of >>> exceptions (which don't make much sense for somone familiar with Erlang) >>> and that Actors seem to be garbage collected if they are "unneded" probably >>> no longer referenced from the outside and Erlang needs "internal >>> termination". >>> >>> Hewitt writes mostly what he finds lacking but on the other hand I find >>> the process with mailbox, selective receive and links/monitors (not ver >>> silent ;-) more powerful that simple Actors. >>> >>> Also as aside from what I've heard Erlangs creators didn't look at >>> Actors when creating. >>> >>> Cheers, >>> -- Peer >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Mon Jun 23 04:40:53 2014 From: zxq9@REDACTED (zxq9) Date: Mon, 23 Jun 2014 11:40:53 +0900 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: Message-ID: <2435915.1FFjRGMdE2@jalapeno> On Monday 23 June 2014 11:22:36 Ngoc Dao wrote: > > In many ways an Erlang system does have an OS feeling about it. At least > > I think so. > > I think so, too: > http://www.slideshare.net/ngocdaothanh/cloud-erlang I enjoyed the abbreviated cut-down (once I got over the use of the empty, warped, buzzsound term "cloud"... its necessary to attract attention from a certain type of party, but they aren't the sort who are really going to embrace what you have to say). Its a good reference to explain why Erlang implies a lot more than just a language. Much better, I think, to do like you've done here and treat Erlang/OTP as a system that supports a very different model of computation than most folks are accustomed to than to start them on the language syntax first. Actually, quite a few interesting early attempts at explaining Erlang as a system up-front have come out over the last few threads. Most of this stuff is unpolished, but represents a lot of effort in a good direction. From ok@REDACTED Mon Jun 23 06:24:56 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 23 Jun 2014 16:24:56 +1200 Subject: [erlang-questions] node.js vs erlang In-Reply-To: References: <53A2EFBC.2060301@meetinghouse.net> <1942907.82Il6dF9Oa@freedom> <53A431D1.8080906@ninenines.eu> Message-ID: On 21/06/2014, at 2:47 AM, Leonard Boyce wrote: > They are using Sublime as that's their editor of choice. > When I started learning Erlang I was informed that the 'defacto' > standard for indentation is the indentation used by elang mode for > emacs as this was the primary erlang editor. Maybe I was misinformed, > but that became our coding standard. Others developers use emacs or > ElrIDE (which uses the same indentation as emacs). No other 'popular' > editor correctly supports the 'emacs style' indentation for Erlang. > Maybe it's just me but I like consistency and my mind is 'trained' to > match this indentation format. So? The only time I let a text editor control my indentation is when slamming a drawer shut on my fingers just isn't enough. (*Help* my indentation, yes. *Control* it, no way.) You can get any indentation you want in any text editor you want. > Again, they're learning and it's a process. In our main project we use > the "ux" library. > But I understand their befuddlement. It just "seems" like something a > language should include. Hmm. Unicode is *appallingly* complex, and good library support for it is really important. There aren't actually a lot of languages that do a good job of it, it is *very* far from being something you can routinely assume for any programming language. In an ideal would, we *would* be able to, but in the real world, we can't *yet* take it for granted. > Seeing the movement over the versions with unicode support I guess > that eventually it may exist. Speaking as someone who has been trying to build reasonable support for another programming language, I think it's fair to say that Erlang is moving Unicodewards about as fast as we have any right to expect. The only thing that will change this is someone with deep pockets caring enough to fund more work than you would ever have imagined necessary. From ok@REDACTED Mon Jun 23 06:40:38 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 23 Jun 2014 16:40:38 +1200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> Message-ID: <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> On 21/06/2014, at 12:58 PM, Steve Davis wrote: > It's not hard... but can be extremely expensive if it builds a call stack (e.g. Java)... Presumably "It" here refers to "recursion". Extremely expensive compared to *what*? There are problems where you could naturally use either iteration or tail recursion, and it doesn't matter which one you use because they are the same thing. And there are problems that can be expressed simply using general recursion. For those problems, doing without it results in code that harder for people and worse for computers. There can be no problems that are easier with iteration than recursion, although there can be problems that are easier with particular *syntax*. If we are talking about "Erlang for youngsters", I wonder whether it might not be easier to teach the *use* of higher-order traversal functions than direct loops of any kind. I remember it being *amazing* how much you could get done in APL without a loop of your own in sight. From roger@REDACTED Mon Jun 23 09:28:06 2014 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 23 Jun 2014 08:28:06 +0100 Subject: [erlang-questions] Spawning slaves for separation Message-ID: On 22 June 2014 17:24, Max Lapshin wrote: > Dmitry, I'm using slave:start for spawning separate Erlang process for each > transcoder and use nif (now with dirty schedulers) for running > decode/encode. I'm considering a design like this for something we're doing. I have some questions about it. - Are you running one transcoder in each slave? - Are you finding the fact that each slave is a separate node is a resource problem? - What are you using to manage the slaves, particularly w.r.t. recovering from crashes in the NIF? - How are you communicating with the slave? My problem is probably different: rather than transcoding, we'll be running a scripting VM (for instance), which is lighter weight, so probably encourages sharing a slave among a number of VM instances. I was also wondering whether anything in the riak_core toolbox would help with this, and would appreciate relevant thoughts on the matter. Cheers, Roger. From garazdawi@REDACTED Mon Jun 23 09:50:06 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Mon, 23 Jun 2014 09:50:06 +0200 Subject: [erlang-questions] maps match specifications In-Reply-To: References: Message-ID: Hello! At the moment only the guards bifs operating on maps are supported in match-specs. i.e. you can do this: 1> Tid = ets:new(test,[]). 16400 2> ets:insert(Tid,[{#{ a => b },2},{a,3},{#{ a => b, c => d},4}]). true 4> ets:select(Tid,[{{'$1','$2'},[{'and',{is_map,'$1'},{'==',{map_size,'$1'},1}}],['$2']}]). [2] but not any work with the values within a map. Lukas On Wed, Jun 18, 2014 at 4:57 PM, Daniel Goertzen wrote: > Maps match specifications are not working for me (see below). I know they > were absent in the early maps branch, but I could not find anything saying > they are absent from R17. I suspect they are just absent, but thought I > would ask in case I've done something stupid or stumbled on a bug > > Thanks, > Dan. > > > 12> ets:fun2ms(fun({_,#{foo:=bar}}) -> true end). > ** exception error: no function clause matching > ms_transform:normalise({map,1,[{map_field_exact,1,{atom,1,foo},{atom,1,bar}}]}) > (ms_transform.erl, line 1063) > in function ms_transform:normalise_list/1 (ms_transform.erl, line > 1091) > in call from ms_transform:normalise_list/1 (ms_transform.erl, line > 1091) > in call from ms_transform:normalise/1 (ms_transform.erl, line 1081) > in call from ms_transform:normalise_list/1 (ms_transform.erl, line > 1091) > in call from ms_transform:normalise/1 (ms_transform.erl, line 1081) > in call from ms_transform:normalise/1 (ms_transform.erl, line 1079) > in call from ms_transform:transform_from_shell/3 (ms_transform.erl, > line 215) > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Mon Jun 23 11:46:35 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Mon, 23 Jun 2014 11:46:35 +0200 Subject: [erlang-questions] [ANN] cowdb 0.1.0 released In-Reply-To: <20140622202702.48cc7642@fujitsu> References: <20140622202702.48cc7642@fujitsu> Message-ID: On Sun, Jun 22, 2014 at 6:27 PM, Alexander Alexeev wrote: > Looks great! > > I wonder, > > 1. Are there any limits on number of keys, database size, etc? > Only OS limits apply. The number of keys and the size of a database file are not limited. > 2. What made you create your own database engine? Is it something wrong > with HanoiDB? > I wanted a simple index storage on top of the couchdb btree. It's not the faster one but it proved to be robust along the years. The btree code by itself exist as a standalone library: https://bitbucket.org/refugeio/cbt It already contains some optimizations compared to the version in use in apache couchdb. Cowdb by itself will be one of indexed storage used in one another project I expect to release in july. A new version of cowdb will be out at the end of the week. I still consider the usage of hanoidb as another storage, but I am a little worried about its lack of support (or apparent lack of support). I asked many time about its status and none answered. Someone told me it was not that stable but I did't try it hard enough myself to confirm or not. I hope i answered to your concerns. - benoit > > On Wed, 18 Jun 2014 00:14:15 +0200 > Benoit Chesneau wrote: > > > I just released the version 0.2.0 which add unit-testing and contains > > some fixes: > > > > > https://wiki.refuge.io/display/COWDB/Changelog#Changelog-0.2.0-2014/06/17 > > > > Enjoy! > > > > - benoit > > > > > > On Tue, Jun 17, 2014 at 1:04 AM, Benoit Chesneau > > wrote: > > > > > Hi all, > > > > > > I presented it rapidly during the EUC and it took some time to > > > finish some feature but here the first release of cowdb: > > > > > > http://cowdb.org > > > > > > Cowdb implements an indexed, key/value storage engine in #Erlang. > > > The primary index is an append-only btree implemented using CBT a > > > btree library extracted from Apache #CouchDB. > > > > > > Main features are: > > > > > > - Append-Only b-tree using COW > > > - Read/Write can happen independently > > > - Put/Get/Delete/Fold operations > > > - support transactions with transaction functions > > > - Transaction log > > > - Snapshotting support > > > - Automatic compaction > > > > > > Enjoy!? > > > > > > - benoit > > > > > > > -- > Best regards, > Alexander Alexeev > http://eax.me/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Jun 23 13:36:04 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 23 Jun 2014 15:36:04 +0400 Subject: [erlang-questions] Spawning slaves for separation In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 11:28 AM, Roger Lipscombe wrote: > > I'm considering a design like this for something we're doing. I have > some questions about it. > > - Are you running one transcoder in each slave? > Yes. > - Are you finding the fact that each slave is a separate node is a > resource problem? > No. Transcoding video is a very CPU consumptive task. One fast server can process 5-20 video streams at a moment. Not more. > - What are you using to manage the slaves, particularly w.r.t recovering > from crashes in the NIF? > When slave is dead, it is catched by monitoring process and it restarts this node. > - How are you communicating with the slave? > via erlang distribution. Bandwidth between nodes is not an issue, because CPU is a hardest limit in this task. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tty.erlang@REDACTED Mon Jun 23 13:38:39 2014 From: tty.erlang@REDACTED (T Ty) Date: Mon, 23 Jun 2014 12:38:39 +0100 Subject: [erlang-questions] Spawning slaves for separation In-Reply-To: References: Message-ID: When the slave node crashes do you have to do anything special as part of clean-up ? I'm just wondering why not spin the slave node up using -heart and have it auto-restart. Thanks On Mon, Jun 23, 2014 at 12:36 PM, Max Lapshin wrote: > > On Mon, Jun 23, 2014 at 11:28 AM, Roger Lipscombe > wrote: > >> >> I'm considering a design like this for something we're doing. I have >> some questions about it. >> >> - Are you running one transcoder in each slave? >> > > Yes. > > >> - Are you finding the fact that each slave is a separate node is a >> resource problem? >> > > No. Transcoding video is a very CPU consumptive task. One fast server can > process 5-20 video streams at a moment. Not more. > > > >> - What are you using to manage the slaves, particularly w.r.t recovering >> from crashes in the NIF? >> > > When slave is dead, it is catched by monitoring process and it restarts > this node. > > > >> - How are you communicating with the slave? >> > > via erlang distribution. Bandwidth between nodes is not an issue, because > CPU is a hardest limit in this task. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psidrinal@REDACTED Mon Jun 23 13:43:11 2014 From: psidrinal@REDACTED (Raphael Korsoski) Date: Mon, 23 Jun 2014 13:43:11 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <2435915.1FFjRGMdE2@jalapeno> References: <2435915.1FFjRGMdE2@jalapeno> Message-ID: My ?.2, as a computer scientist (categories for the win) and an Erlang coder: There are certainly formal differences between Erlang-style concurrency and the many different Actor Models that have appeared in the literature (cf. A?-calculus). The runtime doesn't use a reduced set of communication primitives as a foundational concept, such as in the pi-calculus formulations of Actor Models. I haven't seen any proof of the fairness/progress property for Erlang, either. On the other hand, it is more or less trivial to _implement_ models of Actors in Erlang, whichever of the many proposed semantics for actors you choose. Although I have never completed the exercise, I believe quite strongly that you could also fully embed Erlang's style of concurrency in both abstract actor models and operational (process calculi) implementations of those, with relatively simple, or even trivial, translations; eg selective receive as a set of actors with a receptionist. I'd go so far as to say that Erlang and the Actor Model are in the same programming paradigm, but with different axioms in their semantics-- although that's of course conjecture without (large, tedious) proof.... In my opinion, strictly separating Erlang-style concurrency and the Actor model is only of academic interest; unless you are implementing, say, an Erlang runtime of course. The differences are certainly relevant to category theorists, language theorists, mathematicians working in the Curry-Howard domain and so forth, but for the general programmer the differences are more or less implementation details ("up-to the usual nonsense"). By contrast, although it is just as relevant, we generally don't discern between object-oriented models that allow either contra- or covariant inheritance (or both). Should we really distinguish process-oriented models by the semantics of the "becomes" relation? /// Raphael On Mon, Jun 23, 2014 at 4:40 AM, zxq9 wrote: > On Monday 23 June 2014 11:22:36 Ngoc Dao wrote: > > > In many ways an Erlang system does have an OS feeling about it. At > least > > > > I think so. > > > > I think so, too: > > http://www.slideshare.net/ngocdaothanh/cloud-erlang > > I enjoyed the abbreviated cut-down (once I got over the use of the empty, > warped, buzzsound term "cloud"... its necessary to attract attention from a > certain type of party, but they aren't the sort who are really going to > embrace what you have to say). Its a good reference to explain why Erlang > implies a lot more than just a language. Much better, I think, to do like > you've done here and treat Erlang/OTP as a system that supports a very > different model of computation than most folks are accustomed to than to > start > them on the language syntax first. > > Actually, quite a few interesting early attempts at explaining Erlang as a > system up-front have come out over the last few threads. Most of this > stuff is > unpolished, but represents a lot of effort in a good direction. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.vysniauskas@REDACTED Mon Jun 23 14:17:12 2014 From: i.vysniauskas@REDACTED (=?UTF-8?Q?Ignas_Vy=C5=A1niauskas?=) Date: Mon, 23 Jun 2014 15:17:12 +0300 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <2435915.1FFjRGMdE2@jalapeno> Message-ID: On Mon, Jun 23, 2014 at 2:43 PM, Raphael Korsoski wrote: > I'd go so far as to say that Erlang and the Actor Model are in the same > programming paradigm, but with different axioms in their semantics-- > although that's of course conjecture without (large, tedious) proof.... > > In my opinion, strictly separating Erlang-style concurrency and the Actor > model is only of academic interest; unless you are implementing, say, an > Erlang runtime of course. The differences are certainly relevant to category > theorists, language theorists, mathematicians working in the Curry-Howard > domain and so forth, but for the general programmer the differences are more > or less implementation details ("up-to the usual nonsense"). I agree with you in the general spirit of "formally it doesn't matter much because it's mostly the same thing." However, there is one crucial thing in Erlang which, on the positive side makes it a very practical tool, and on the negative side makes it very hard to talk about formal semantics and prove things like progress. This is the availability of the `receiver .. after ..` primitive. Allowing local-timing-based behaviour in processes usually means that you need some very strong global fairness assumptions in order to do any kind of formal proofs. I don't see how one could obtain a (useful) representation of Erlang semantics in any of the usual process calculi without ignoring this fact. It would be interesting to find out if anyone ever did something similar formally. -- Ignas From max.lapshin@REDACTED Mon Jun 23 15:03:48 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 23 Jun 2014 17:03:48 +0400 Subject: [erlang-questions] Spawning slaves for separation In-Reply-To: References: Message-ID: I don't need heart, because if slave node dies, I need to handle it in live stream. It will be considered as a regular source failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Jun 23 15:13:16 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 23 Jun 2014 14:13:16 +0100 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" Message-ID: <53A827EC.40000@llaisdy.com> Dear All I have an erlang release (packaged using rebar) running on a server. After a bit of maintenance and stopping and starting, I notice I can't attach to the running release: $ ./bin/appnode attach No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such device or address The pipe directory exists, containing files erlang.pipe.123.r and erlang.pipe.123.w. File permissions look ok. I can ping the node. The release is running normally. I have tried $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 and that has the same result. (the version of erts is quite old). I have googled around the interwebs. Can anyone suggset some ideas for why this is happening and, mainly, how I can attach? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From dmkolesnikov@REDACTED Mon Jun 23 15:24:34 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 23 Jun 2014 16:24:34 +0300 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: <53A827EC.40000@llaisdy.com> References: <53A827EC.40000@llaisdy.com> Message-ID: <64B2A208-6B50-4F80-8E07-0F96B3DA169A@gmail.com> Hello, Try to attach with absolute path E.g. /usr/local/myapp/bin/myapp This is common issue IF you mix relative and absolute path Best Regards, Dmitry >-|-|-(*> > On 23 Jun 2014, at 16:13, Ivan Uemlianin wrote: > > Dear All > > I have an erlang release (packaged using rebar) running on a server. After a bit of maintenance and stopping and starting, I notice I can't attach to the running release: > > $ ./bin/appnode attach > No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such device or address > > The pipe directory exists, containing files erlang.pipe.123.r and erlang.pipe.123.w. File permissions look ok. I can ping the node. The release is running normally. > > I have tried > > $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 > > and that has the same result. (the version of erts is quite old). > > I have googled around the interwebs. > > Can anyone suggset some ideas for why this is happening and, mainly, how I can attach? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From alcosholik@REDACTED Mon Jun 23 15:34:15 2014 From: alcosholik@REDACTED (Alexei Sholik) Date: Mon, 23 Jun 2014 16:34:15 +0300 Subject: [erlang-questions] Go vs Erlang for distribution Message-ID: Thank you all for the answers! I personally agree that Go would be most suitable as a complement to Erlang, not as a primary tool for building reliable systems. However, that goes in disagreement to Go authors which have claimed its design to be tailored to building large-scale projects. One little nitpick I have is about zxq9's first reply which mentions: Google is a huge company that is spending a *lot* of effort in an attempt to > prevent yet another of their expensive toys winding up in the rubbish bin > of > digital history. > I have been following the Go community (not too closely) since 2012 and I haven't seen any indications of Google pouring monetary or marketing resources into promoting Go. Obviously, it has been paying salaries to the core team (of some ~5-8 members), but apart from that, unless it is also paying blog authors and companies to adopt Go, it is fair to say that most of the praise Go is continuously receiving comes from the word-of-mouth and talks given by its authors. TL;DR: there is no massive campaign carried out by Google to promote Go like Sun did with Java or MS with C#. This is already offtopic, but I feel I had to point that out. Getting back on Erlang track, I'd like to thank you all again for the answers. My curiosity has been satisfied, so I'm not going to trouble you with any more Go-related discussions. Cheers! Alex On Mon, Jun 23, 2014 at 12:02 AM, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > I wrote a post about this recently because I found the idea of Go being > an alternative to be ludicrous, especially after working with Go: > http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/ > > -- > Tristan Sloughter > tristan.sloughter@REDACTED > > > > On Sat, Jun 21, 2014, at 03:43 PM, Alexei Sholik wrote: > > Hi, > > Let me say from the beginning that this is not meant as a flame post. I'm > genuinely interested in some issues related to Erlang's adoption and how > people outside of its community see its fitness for the domain where the > insiders know it shines ? building distributed systems. > > My questions have been prompted by the apparent appeal of Go as a > suitable tool for that exact domain. I have noticed the appeal being > expressed both outside and _inside_ Erlang community (will explain soon). > > The reason for my asking on this particular list is twofold: > > 1. After discovering Erlang (not just the language, but in the wider > sense: Erlang VM, OTP, its founding principles) I see it as a great fit for > building distributed systems that can survive and auto-recover from various > kinds of failures. It has also been proven over the years of being used in > production. Erlang experts are the kind of people to go to when looking for > an advice in this area. > > 2. In his recent talk at EUC Garrett Smith showed us an interesting > slide[1] where Go appears to be one of the primary alternatives to Erlang, > as chosen by _Erlang programmers themselves_. To me this implies that > Erlang programmers have found in Go some of the principles Erlang builds > upon, the fact I'm going to dispute below. > > [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large > > So now comes the question: what do Erlang programmers think about Go > stealing some of the mindshare (and job-share) in the area of building > distributed systems? Why would if be a good option? Or not an option at > all? Just professional opinions based on your experience with Erlang please. > > Let me explain what suggests Go might be a viable alternative: > > * the slide mentioned above > * Go has been used for teaching distributed systems at the Carnegie > Mellon University since 2011. (Go 1 was release in early 2012) See this > blog from the teacher: > http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html > * increased activity on projects such as libswarm[2], libchan[3], > there are more. > > [2]: https://github.com/docker/libswarm > [3]: https://github.com/docker/libchan > > If you haven't been keeping up with Go, here's a brief overview of its > principles: > > * imperative, statically typed, garbage collected, lower level than > scripting languages, but higher level than C > * builtin concurrency with lightweight processes (called goroutines) > which are scheduled cooperatively > * single address space for all goroutines (modifying shared data is > discouraged, but possible); hence no isolation > * goroutines have no identity, communication between them is only > possible through channels; hence no ability to monitor or link to > goroutines, so no supervision > * writing to a channel is always synchronous; it is possible to make a > buffered channel, but once the buffer is full, the next goroutine trying to > write to it will block > * all errors must be handled explicitly; can be done at goroutine level > by setting up a catch-all handler. But crashing in the catch-call handler > will crash the goroutine. And crashing a goroutine crashes the whole > program. No Erlang-style "let it crash" or "let someone else handle errors" > > From this short survey Go looks more like the ultimate antagonist to > Erlang, or at least its philosophy. What could justify its being chosen as > an _alternative_ to Erlang? > > Sorry if it turned out a bit too long. Ultimately, I'm curious about the > reasons Go appears in a huge font on Garrett's slide. Also, finding out why > Go has seen a tremendous growth in just 2 years since initial stable > release and is already seen as a good fit for tasks Erlang is considered > the best tool in these circles might shed some light on which steps Erlang > community could take to increase the awareness about its merits (especially > in the light of a few recent threads on this list). > > This ended up rather convoluted, I know. If it was the wrong place to > bring up this topic, I apologize. Feel free to ignore this thread in that > case. > > Thanks for reading this far. > > -- > Best regards > Alexei Sholik > *_______________________________________________* > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- Best regards Alexei Sholik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Jun 23 15:43:02 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 23 Jun 2014 14:43:02 +0100 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: <64B2A208-6B50-4F80-8E07-0F96B3DA169A@gmail.com> References: <53A827EC.40000@llaisdy.com> <64B2A208-6B50-4F80-8E07-0F96B3DA169A@gmail.com> Message-ID: <53A82EE6.1060404@llaisdy.com> Dear Dmitry Thanks for your help! No luck however -- same result :( Ivan On 23/06/2014 14:24, Dmitry Kolesnikov wrote: > Hello, > > Try to attach with absolute path > E.g. /usr/local/myapp/bin/myapp > > This is common issue IF you mix relative and absolute path > > Best Regards, > Dmitry >> -|-|-(*> > >> On 23 Jun 2014, at 16:13, Ivan Uemlianin wrote: >> >> Dear All >> >> I have an erlang release (packaged using rebar) running on a server. After a bit of maintenance and stopping and starting, I notice I can't attach to the running release: >> >> $ ./bin/appnode attach >> No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such device or address >> >> The pipe directory exists, containing files erlang.pipe.123.r and erlang.pipe.123.w. File permissions look ok. I can ping the node. The release is running normally. >> >> I have tried >> >> $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 >> >> and that has the same result. (the version of erts is quite old). >> >> I have googled around the interwebs. >> >> Can anyone suggset some ideas for why this is happening and, mainly, how I can attach? >> >> With thanks and best wishes >> >> Ivan >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From roger@REDACTED Mon Jun 23 15:49:19 2014 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 23 Jun 2014 14:49:19 +0100 Subject: [erlang-questions] Deriving records from one another? Message-ID: I'm probably thinking too OO by calling it "deriving", but here's the problem: OTP handlers (gen_server, etc.) take a State parameter. You can stick anything in here, but generally I've been using a #state record, and keeping a bunch of values in it. Now I'd like to actually start representing *state* with the State[1]. That is, I'd like to be able to match on #init, #ready, #expecting_key, #whatever records. This will hopefully make the code easier to read, and means that my record doesn't have to contain fields for stuff that's not relevant in the given state. However, some of the fields *are* shared between states, so my question is (in OO terms) how do I derive record types from each-other? I've thought about using a tuple: {Shared, State} when Shared :: #shared{}, State :: #init{} | #etc{} That might be hard to read in matches, though, maybe. I've thought about using a container record: -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }). Are there any good solutions[2] to this problem? Or are there better ways to do what I'm trying to do? Cheers, Roger. [1] No, I don't think that gen_fsm is the answer at this point. Interesting suggestion, though, thanks. [2] Still on R16, so I can't use maps, but I'm still interested in how they might help, if at all. From dmkolesnikov@REDACTED Mon Jun 23 16:06:14 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 23 Jun 2014 17:06:14 +0300 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: Hello, Yes, the composition (nested records) is one way to solve the issue. I would not use two records #shared{} and #inner{} > -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }). I would compose #shared{} record directly into state. > -record(state { shared :: #shared{}, field1, field2, ...}). you might want to isolate all #shared{} specific code to dedicated module so that all process will re-use same code base. Best Regards, Dmitry On 23 Jun 2014, at 16:49, Roger Lipscombe wrote: > I'm probably thinking too OO by calling it "deriving", but here's the problem: > > OTP handlers (gen_server, etc.) take a State parameter. You can stick > anything in here, but generally I've been using a #state record, and > keeping a bunch of values in it. > > Now I'd like to actually start representing *state* with the State[1]. > That is, I'd like to be able to match on #init, #ready, > #expecting_key, #whatever records. This will hopefully make the code > easier to read, and means that my record doesn't have to contain > fields for stuff that's not relevant in the given state. > > However, some of the fields *are* shared between states, so my > question is (in OO terms) how do I derive record types from > each-other? > > I've thought about using a tuple: {Shared, State} when Shared :: > #shared{}, State :: #init{} | #etc{} > That might be hard to read in matches, though, maybe. > > I've thought about using a container record: > -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }). > > Are there any good solutions[2] to this problem? Or are there better > ways to do what I'm trying to do? > > Cheers, > Roger. > > [1] No, I don't think that gen_fsm is the answer at this point. > Interesting suggestion, though, thanks. > [2] Still on R16, so I can't use maps, but I'm still interested in how > they might help, if at all. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Mon Jun 23 16:08:02 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 23 Jun 2014 09:08:02 -0500 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 8:49 AM, Roger Lipscombe wrote: > I'm probably thinking too OO by calling it "deriving", but here's the problem: > > OTP handlers (gen_server, etc.) take a State parameter. You can stick > anything in here, but generally I've been using a #state record, and > keeping a bunch of values in it. > > Now I'd like to actually start representing *state* with the State[1]. > That is, I'd like to be able to match on #init, #ready, > #expecting_key, #whatever records. This will hopefully make the code > easier to read, and means that my record doesn't have to contain > fields for stuff that's not relevant in the given state. > > However, some of the fields *are* shared between states, so my > question is (in OO terms) how do I derive record types from > each-other? > > I've thought about using a tuple: {Shared, State} when Shared :: > #shared{}, State :: #init{} | #etc{} > That might be hard to read in matches, though, maybe. > > I've thought about using a container record: > -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }). > > Are there any good solutions[2] to this problem? Or are there better > ways to do what I'm trying to do? How many fields are actually shared? Is it really a problem to just duplicate the values? I've managed some pretty complex state in the past but it never occurred to me to use separate records. I would tend to use a single record field to represent this "lifecycle" state (I think that's what you're describing) and just load the record up with whatever fields are needed for all of the various lifecycle states. If your motivation here is to model your state, as you would in an OO or other type system, you might just try not doing that and see what happens. Nested records are very painful and it's hard for me to envision how this could be paid off in terms of modeling or other conceptual benefits. Maps might be your friend -- I'm starting to use them and dealing with nested maps is 100x better than dealing with nested records. I have happily dropped the "Is A" thinking and I just go with "how the heck do I get this to work" -- and then drive the complexity down until the result is clear to understand (obvious). Probably not a very clear answer :) If you provide the various record definitions of what you're thinking, it might be easier to propose something sane. Garrett From rtrlists@REDACTED Mon Jun 23 16:09:57 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 23 Jun 2014 15:09:57 +0100 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> Message-ID: Hi Max, since you are already using separate nodes running NIFs, there's probably not much worth in converting to a C node or port. So this is just for posterity. The inconvenience you appear to see in the C node setup is the same to that of your setup. You have to have a way to start your transcoder server (open_port & ei_connect & ei_xreceive_msg vs slave:start & load_nif & ERL_NIF_INIT) and you have to translate/access the data from/in Erlang to/from C (ei_x_decode_... vs enif_get_...). It's just that you've already implemented your approach, and changing that would indeed be inconvenient. The biggest architectural difference is that a C node or port must be based around messaging, whereas a NIF is based on an API. The underlying functionality is likely to be mostly identical. And one scenario where a NIF is probably more convenient is if your C code must operate in place on large binaries stored on the Erlang side. But by using a separate node, I'm not entirely sure you get that benefit anyway. Your data must find it's way to the transcoder node in any case. Sorry I can't be of more assistance on the NIF vs async_driver question. Regards, Robby On Jun 22, 2014 5:24 PM, "Max Lapshin" wrote: Dmitry, I'm using slave:start for spawning separate Erlang process for each transcoder and use nif (now with dirty schedulers) for running decode/encode. C port and c node are both very inconvenient, because they require lot of marshalling/demarshalling. Also it is impossible to run erlang between different parts of C job. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon Jun 23 16:12:45 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 23 Jun 2014 09:12:45 -0500 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: <1403470978.22145.131673469.08CF9B0A@webmail.messagingengine.com> References: <1403470978.22145.131673469.08CF9B0A@webmail.messagingengine.com> Message-ID: On Sun, Jun 22, 2014 at 4:02 PM, Tristan Sloughter wrote: > I wrote a post about this recently because I found the idea of Go being an > alternative to be ludicrous, especially after working with Go: > http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/ This is a very good article that capably dives into the differences between Go and Erlang. If you haven't read it and care about any of this, read it :) Garrett From essen@REDACTED Mon Jun 23 16:23:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 23 Jun 2014 16:23:22 +0200 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: <53A8385A.4020902@ninenines.eu> On 06/23/2014 03:49 PM, Roger Lipscombe wrote: > Now I'd like to actually start representing *state* with the State[1]. > That is, I'd like to be able to match on #init, #ready, > #expecting_key, #whatever records. This will hopefully make the code > easier to read, and means that my record doesn't have to contain > fields for stuff that's not relevant in the given state. Don't. Use gen_fsm instead. That's what it's for. -- Lo?c Hoguin http://ninenines.eu From tim@REDACTED Mon Jun 23 16:24:18 2014 From: tim@REDACTED (Timothy Das) Date: Mon, 23 Jun 2014 10:24:18 -0400 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: <53A8385A.4020902@ninenines.eu> References: <53A8385A.4020902@ninenines.eu> Message-ID: Is there a way to unsubscribe from this list? On Mon, Jun 23, 2014 at 10:23 AM, Lo?c Hoguin wrote: > On 06/23/2014 03:49 PM, Roger Lipscombe wrote: > >> Now I'd like to actually start representing *state* with the State[1]. >> That is, I'd like to be able to match on #init, #ready, >> #expecting_key, #whatever records. This will hopefully make the code >> easier to read, and means that my record doesn't have to contain >> fields for stuff that's not relevant in the given state. >> > > Don't. Use gen_fsm instead. That's what it's for. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psidrinal@REDACTED Mon Jun 23 16:37:36 2014 From: psidrinal@REDACTED (Raphael Korsoski) Date: Mon, 23 Jun 2014 16:37:36 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <2435915.1FFjRGMdE2@jalapeno> Message-ID: The only dissertation on the subject that I'm aware of is Lars ?ke Fredlund's thesis from 2001: "A Framework for Reasoning about ERLANG Code" It uses modal logic to model time; specifically an extension of the mu-calculus in the "usual" Gentzen-style deductive framework. If there are other approaches that have been investigated for Erlang specifically, I'd be very interested in links etc! /// Raphael On Mon, Jun 23, 2014 at 2:17 PM, Ignas Vy?niauskas wrote: > On Mon, Jun 23, 2014 at 2:43 PM, Raphael Korsoski > wrote: > > I'd go so far as to say that Erlang and the Actor Model are in the same > > programming paradigm, but with different axioms in their semantics-- > > although that's of course conjecture without (large, tedious) proof.... > > > > In my opinion, strictly separating Erlang-style concurrency and the Actor > > model is only of academic interest; unless you are implementing, say, an > > Erlang runtime of course. The differences are certainly relevant to > category > > theorists, language theorists, mathematicians working in the Curry-Howard > > domain and so forth, but for the general programmer the differences are > more > > or less implementation details ("up-to the usual nonsense"). > > I agree with you in the general spirit of "formally it doesn't matter > much because it's mostly the same thing." > > However, there is one crucial thing in Erlang which, on the positive > side makes it a very practical tool, and on the negative side makes it > very hard to talk about formal semantics and prove things like > progress. This is the availability of the `receiver .. after ..` > primitive. Allowing local-timing-based behaviour in processes usually > means that you need some very strong global fairness assumptions in > order to do any kind of formal proofs. I don't see how one could > obtain a (useful) representation of Erlang semantics in any of the > usual process calculi without ignoring this fact. It would be > interesting to find out if anyone ever did something similar formally. > > -- > Ignas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Mon Jun 23 16:52:55 2014 From: freza@REDACTED (Jachym Holecek) Date: Mon, 23 Jun 2014 10:52:55 -0400 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: <20140623145255.GA2952@circlewave.net> # Roger Lipscombe 2014-06-23: > I'm probably thinking too OO by calling it "deriving", but here's the problem: > > OTP handlers (gen_server, etc.) take a State parameter. You can stick > anything in here, but generally I've been using a #state record, and > keeping a bunch of values in it. Sure, that's how everybody uses them all the time. > Now I'd like to actually start representing *state* with the State[1]. > That is, I'd like to be able to match on #init, #ready, > #expecting_key, #whatever records. Why? What actual real-world problem are you trying to solve, and why does this approach look like a plausible solution to it? Why do you think gen_fsm is not adequate for describing what looks every bit like a state machine? > This will hopefully make the code easier to read, I quite doubt it will, to be honest. > and means that my record doesn't have to contain > fields for stuff that's not relevant in the given state. > > However, some of the fields *are* shared between states, so my > question is (in OO terms) how do I derive record types from > each-other? > > I've thought about using a tuple: {Shared, State} when Shared :: > #shared{}, State :: #init{} | #etc{} > That might be hard to read in matches, though, maybe. > > I've thought about using a container record: > -record(state { shared :: #shared{}, inner :: #init{} | #etc{} }). > > Are there any good solutions[2] to this problem? Can't think of anything that wouldn't read like a horror story. > Or are there better ways to do what I'm trying to do? There may be a way to avoid doing what you're trying to do. :-) My guess is you're uncomfortable with what you've got now because your gen_server/gen_fsm ended up having way too much functionality in it (Ulf's "Death by accidental complexity" comes to mind) and starts looking too messy. Quite often one can break things into a toplevel gen_server/gen_fsm with a bunch of private small processes running underneath it via proc_lib:spawn_link/X or whatever -- just plain simple processes. These workers can do all sorts of utility control loops and regulators, whilst the parent coordinates the whole show, takes highlevel decisions and maybe also serves as public point of contact to this particular subsystem/resource. (This is really just a particular example of "designing more concurrently", which clearly is a pretty vague thing to say and thus unhelpful. ;-) Worked nicely for me every time... but then I haven't seen your project specification or the code in question. BR, -- Jachym From roger@REDACTED Mon Jun 23 16:44:33 2014 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 23 Jun 2014 15:44:33 +0100 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: On 23 June 2014 15:08, Garrett Smith wrote: > How many fields are actually shared? Is it really a problem to just > duplicate the values? About 15. Granted, some of these go around together (ID has three parts, for example), so could be in a smaller number of subrecords. > I've managed some pretty complex state in the past but it never > occurred to me to use separate records. I would tend to use a single > record field to represent this "lifecycle" state (I think that's what > you're describing) and just load the record up with whatever fields > are needed for all of the various lifecycle states. That's what I'm doing now, but it feels unwieldy -- and I'm in the middle of refactoring it -- so I'm exploring options. > If your motivation here is to model your state, as you would in an OO > or other type system, you might just try not doing that and see what > happens. Sure "not doing that" is definitely an option. It's also probably the one I'll choose eventually :-) > Maps might be your friend -- I'm starting to use them and dealing with > nested maps is 100x better than dealing with nested records. We're still on R16, so I've not started playing with maps yet. We plan to move to R17 in a few weeks' time. > Probably not a very clear answer :) Seems like it fits with my usual style -- find the ugliest piece of code and clean it up. Repeat until pub time. Thanks. From roger@REDACTED Mon Jun 23 16:47:39 2014 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 23 Jun 2014 15:47:39 +0100 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: On 23 June 2014 15:44, Roger Lipscombe wrote: > On 23 June 2014 15:08, Garrett Smith wrote: >> How many fields are actually shared? Is it really a problem to just >> duplicate the values? > > About 15. Granted, some of these go around together (ID has three > parts, for example), so could be in a smaller number of subrecords. I called for a recount: that's about 15 out of about 25, where those last 10 are basically only used between 'init' and 'ready'. /me feels a thought coming on. From zxq9@REDACTED Mon Jun 23 16:52:11 2014 From: zxq9@REDACTED (zxq9) Date: Mon, 23 Jun 2014 23:52:11 +0900 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: <2879604.eGPCledNch@jalapeno> On Monday 23 June 2014 16:34:15 Alexei Sholik wrote: > One little nitpick I have is about zxq9's first reply which mentions: > > Google is a huge company that is spending a *lot* of effort in an attempt to > > prevent yet another of their expensive toys winding up in the rubbish bin > > of > > digital history. > > I have been following the Go community (not too closely) since 2012 and I > haven't seen any indications of Google pouring monetary or marketing > resources into promoting Go. Obviously, it has been paying salaries to the > core team (of some ~5-8 members), but apart from that, unless it is also > paying blog authors and companies to adopt Go, it is fair to say that most > of the praise Go is continuously receiving comes from the word-of-mouth and > talks given by its authors. > > TL;DR: there is no massive campaign carried out by Google to promote Go > like Sun did with Java or MS with C#. This is already offtopic, but I feel > I had to point that out. I'd like to point out that Google doesn't have to carry out a massive campaign; they control your search results. I just opened a sterile environment each in Japan, one in the US and one in France to test this out. A search for "Go" on any Google property points me to Go language resources -- videos, tutorials, conference notes, blogs, etc. -- pages of them, before anything else in most cases and most variants of the search (even when I'm trying to be specific that I want the verb, like "go definition"). The same search on ixquick, Bing, Goo, and DuckDuckGo turn up links to Disney's online property (go.com), the traditional game of Go on Wikipedia, a Japanese pop group, verb definitions on two dictionaries, some ESPN sports page, a 1999 movie called "Go" and any number of other things, but Go the language is nowhere to be found. And you're telling me there isn't an absolutely massive publicity campaign going on? Just because Google is in a unique position to make this both cost almost nothing and require almost no effort doesn't mean the effort isn't significant and targetted. -Craig From yann.secq@REDACTED Mon Jun 23 16:50:52 2014 From: yann.secq@REDACTED (Yann SECQ) Date: Mon, 23 Jun 2014 16:50:52 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <2435915.1FFjRGMdE2@jalapeno> Message-ID: <53A83ECC.4010600@univ-lille1.fr> Le 23/06/2014 16:37, Raphael Korsoski a ?crit : > The only dissertation on the subject that I'm aware of is Lars ?ke > Fredlund's thesis from 2001: "A Framework for Reasoning about ERLANG Code" > > It uses modal logic to model time; specifically an extension of the > mu-calculus in the "usual" Gentzen-style deductive framework. > > If there are other approaches that have been investigated for Erlang > specifically, I'd be very interested in links etc! Perhaps this one: *Formally based tool support for model checking Erlang applications* Qiang Guo, John Derrick International Journal on Software Tools for Technology Transfer August 2011, Volume 13, Issue 4, pp 355-376 http://link.springer.com/article/10.1007%2Fs10009-010-0179-1 Best regards, yann. -- Contact: yann.secq{at}univ-lille1.fr | www.lifl.fr/~secq www.ouverture-independance.fr | www.sauvonsluniversite.com -- "Ne d?sesp?rez jamais. Faites infuser davantage.", Henri Michaux From ddosia@REDACTED Mon Jun 23 16:55:03 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Mon, 23 Jun 2014 07:55:03 -0700 (PDT) Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: <53A827EC.40000@llaisdy.com> References: <53A827EC.40000@llaisdy.com> Message-ID: You can always start remshell, even someone attached: 1. erl -name myremnode -setcookie samecookieas1stnode 2. press Ctrl + g (you can put single char 'h' to get help there) 3. User switch command --> r 'mynodename@REDACTED' --> c Eshell V5.10.4 (abort with ^G) (mynodename@REDACTED)1> if you don't have erlang installed on that machine you could always use thos, which packaged with release: `find rel_dir -type f -name erl` On Monday, June 23, 2014 5:13:25 PM UTC+4, Ivan Uemlianin wrote: > > Dear All > > I have an erlang release (packaged using rebar) running on a server. > After a bit of maintenance and stopping and starting, I notice I can't > attach to the running release: > > $ ./bin/appnode attach > No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such > device or address > > The pipe directory exists, containing files erlang.pipe.123.r and > erlang.pipe.123.w. File permissions look ok. I can ping the node. The > release is running normally. > > I have tried > > $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 > > and that has the same result. (the version of erts is quite old). > > I have googled around the interwebs. > > Can anyone suggset some ideas for why this is happening and, mainly, how > I can attach? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > iv...@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Mon Jun 23 16:56:01 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Mon, 23 Jun 2014 07:56:01 -0700 Subject: [erlang-questions] Intel Xeon Phi In-Reply-To: References: <20140619150512.GG15725@csr-pc9.zib.de> Message-ID: Would the folks who know something about (and have developed) Erlang on Xeon Phi like to come on MostlyErlang and talk about it? I have been interested in this for a few months and would love to spread the word. --Zach Moslty Erlang Podcast On Thu, Jun 19, 2014 at 8:15 AM, Josh Adams wrote: > This article looks nice: http://dl.acm.org/citation.cfm?id=2505307 > > Wanting to see some benchmarks on Erlang performance on the xeon phi, but > I haven't yet knuckled down and bought that paper (because every time I'm > tempted to, I want to buy the digital library subscription, and then I > don't). Anyone have any benchmarks that aren't behind a paywall? > > > Hi List, Is the Erlang runtime capable of spawning processes on a Xeon >> Phicoprocessor? Or is this piece of hardware too rare for Erlang to beable >> to take advatage of it? >> > > -- > Josh Adams > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Zach Kessin Mostly Erlang Podcast Twitter: @zkessin Skype: zachkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon Jun 23 16:58:52 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 23 Jun 2014 09:58:52 -0500 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 9:47 AM, Roger Lipscombe wrote: > On 23 June 2014 15:44, Roger Lipscombe wrote: >> On 23 June 2014 15:08, Garrett Smith wrote: >>> How many fields are actually shared? Is it really a problem to just >>> duplicate the values? >> >> About 15. Granted, some of these go around together (ID has three >> parts, for example), so could be in a smaller number of subrecords. > > I called for a recount: that's about 15 out of about 25, where those > last 10 are basically only used between 'init' and 'ready'. Are you pattern matching on all of these? That'd be a lot of logic for a single module. Of course there's nothing magical about "pattern matching" - but as this usually surfaces at the function level, the behavior implemented by your gen_server will reflect a lot of complexity across these 25 fields. Is there logic/behavior that you can farm off to another module (or more) in the interest of separating concerns? If yes, you can use these modules to manage the state for a smaller number of top-level fields. Your top level gen_server would handle the dispatch logic. Someone mentioned using sub-processes to separate concerns. I'd caution against that, unless in fact you have separate concurrent activities (as in real life concurrent) that you want to represent. If there's just one process here, use modules to manage opaque data structures and implement behavior associated with that data (e.g. use dict as a model for this type of module). Again, probably clear as mud. Fire back if you need clarification. Garrett From ulf@REDACTED Mon Jun 23 17:00:24 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 23 Jun 2014 17:00:24 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <2435915.1FFjRGMdE2@jalapeno> Message-ID: <663EC108-B08C-4D6A-B256-1711B3513951@feuerlabs.com> I have argued in a number of presentations that what selective receive does for Erlang is to allow a form of ?local-scoping? of events. Haskell, Occam and for that matter, UNIX select(), accomplish this using separate buffered (or blocking) channels, where the program can choose which channel(s) to receive from at any given time. The underlying observation is that there is no defined ordering between events which arrive to a process from different senders. What any selective receive model does is to allow the receiver to reduce the statespace by ignoring events that are irrelevant for the operation at hand. I?m not sure who deserves most credit for talking about ?accidental complexity? in terms of Erlang programming, but I?m leaning towards crediting Joe for evangelizing it the most, although I?ve seen stencils from the late ?70s where Mike Williams wrote very good stuff about it. The term has of course been used elsewhere, not least by Fred Brooks. One can compare FIFO, run-to-completion message handling with GOTO programming, and I recall Simon Peyton-Jones noting that the key to avoiding the problem is to have proper scoping of messages (c.f. variable scoping). Reducing the state space is of course key to any formal verification effort, so I?d claim that Erlang actually provides some tools for extending the reach of formal verification. But the real benefit of Erlang is that it allows developers to write more complex event handling systems that are at least *debuggable*, if not entirely formally verifiable. The properties ?fairness? and ?reachability? are global, and are made a bit more difficult to verify in systems that make use of selective receive. OTOH, verification of a global state-event matrix has a pretty low complexity ceiling, and at least in telecoms (and, I?d claim, in the Web), a missed deadline is not a system-wide failure, which means that you can get very far with informal testing and statistical goodness properties.? BR, Ulf W On 23 Jun 2014, at 14:17, Ignas Vy?niauskas wrote: > This is the availability of the `receiver .. after ..` > primitive. Allowing local-timing-based behaviour in processes usually > means that you need some very strong global fairness assumptions in > order to do any kind of formal proofs. I don't see how one could > obtain a (useful) representation of Erlang semantics in any of the > usual process calculi without ignoring this fact. Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From lukas@REDACTED Mon Jun 23 17:08:03 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 23 Jun 2014 17:08:03 +0200 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: <53A827EC.40000@llaisdy.com> References: <53A827EC.40000@llaisdy.com> Message-ID: Hello, Have you made sure that the run_erl program is still running? > ps aux | grep run_erl This sort of problem would happen if run_erl for some reason exited without taking the erlang vm with it and not cleaning up the fifos. There should be a file called run_erl.log in the same directlory where the erlang log files are, maybe it contains some information about what has happened? Lukas On Mon, Jun 23, 2014 at 3:13 PM, Ivan Uemlianin wrote: > Dear All > > I have an erlang release (packaged using rebar) running on a server. After > a bit of maintenance and stopping and starting, I notice I can't attach to > the running release: > > $ ./bin/appnode attach > No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such device > or address > > The pipe directory exists, containing files erlang.pipe.123.r and > erlang.pipe.123.w. File permissions look ok. I can ping the node. The > release is running normally. > > I have tried > > $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 > > and that has the same result. (the version of erts is quite old). > > I have googled around the interwebs. > > Can anyone suggset some ideas for why this is happening and, mainly, how I > can attach? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From streamingmind@REDACTED Mon Jun 23 14:02:58 2014 From: streamingmind@REDACTED (=?utf-8?B?c3RyZWFtaW5nbWluZEBnbWFpbC5jb20=?=) Date: Mon, 23 Jun 2014 05:02:58 -0700 (PDT) Subject: [erlang-questions] How to specify receiver for erl_drv_send_term Message-ID: <000f4242.0423915e00cf4309@gmail.com> Hi all, I've been practicing writing a port driver for a legacy SIGTRN product. In attempting to send back data from the port driver to a erlang process, I don't know how to convert existing erlang_pid data to a ErlDrvTerm data which is required by erl_drv_send_term(), as the receiver parameter. It'll be graceful if somebody here could give me a hand. Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Jun 23 17:17:59 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 23 Jun 2014 17:17:59 +0200 Subject: [erlang-questions] Deriving records from one another? In-Reply-To: References: Message-ID: It sounds to me that you are trying to model multiple state machines inside one process. If I?m wrong about this, you may skip the rest of this mail. ;-) I talked about a similar problem in this presentation http://vimeo.com/8672652 (?redev 2009), ca 44 minutes into the presentation (41 - 44 minutes might also be interesting to listen to, depending on how used you are to the Erlang style). I recall encountering this issue in ?industrial programmers?, where they model processes as they are used to from C programming. Splitting processes into multiple state machines can then simplify the code greatly and also make it both faster and more robust. BR, Ulf W On 23 Jun 2014, at 15:49, Roger Lipscombe wrote: > I'm probably thinking too OO by calling it "deriving", but here's the problem: > > OTP handlers (gen_server, etc.) take a State parameter. You can stick > anything in here, but generally I've been using a #state record, and > keeping a bunch of values in it. > > Now I'd like to actually start representing *state* with the State[1]. > That is, I'd like to be able to match on #init, #ready, > #expecting_key, #whatever records. This will hopefully make the code > easier to read, and means that my record doesn't have to contain > fields for stuff that's not relevant in the given state. > > ... > > Cheers, > Roger. > > [1] No, I don't think that gen_fsm is the answer at this point. > Interesting suggestion, though, thanks. > [2] Still on R16, so I can't use maps, but I'm still interested in how > they might help, if at all. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From garazdawi@REDACTED Mon Jun 23 17:21:58 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Mon, 23 Jun 2014 17:21:58 +0200 Subject: [erlang-questions] How to specify receiver for erl_drv_send_term In-Reply-To: <000f4242.0423915e00cf4309@gmail.com> References: <000f4242.0423915e00cf4309@gmail.com> Message-ID: Hello, The only way that I know if from either driver_caller or driver_connected. What I have done to solve this problem is to make the process that should get the message "register" with the port. When it does the register call I get the pid using driver_caller and save the pid in the port state. You should probably also monitor the process from the driver to in case it terminates. Lukas On Mon, Jun 23, 2014 at 2:02 PM, streamingmind@REDACTED < streamingmind@REDACTED> wrote: > Hi all, > > > > I've been practicing writing a port driver for a legacy SIGTRN product. In > attempting to send back data from the port driver to a erlang process, I > don't know how to convert existing erlang_pid data to a ErlDrvTerm data > which is required by erl_drv_send_term(), as the receiver parameter. It'll > be graceful if somebody here could give me a hand. > > > > Regards, > > Ben > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Jun 23 17:25:32 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 23 Jun 2014 16:25:32 +0100 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: References: <53A827EC.40000@llaisdy.com> Message-ID: <53A846EC.5050700@llaisdy.com> Excellent! Works. Thanks v much. Ivan On 23/06/2014 15:55, Daniil Churikov wrote: > You can always start remshell, even someone attached: > > 1. erl -name myremnode -setcookie samecookieas1stnode > 2. press Ctrl + g (you can put single char 'h' to get help there) > 3. User switch command > --> r 'mynodename@REDACTED' > --> c > Eshell V5.10.4 (abort with ^G) > (mynodename@REDACTED)1> > > if you don't have erlang installed on that machine you could always use > thos, which packaged with release: `find rel_dir -type f -name erl` > > > On Monday, June 23, 2014 5:13:25 PM UTC+4, Ivan Uemlianin wrote: > > Dear All > > I have an erlang release (packaged using rebar) running on a server. > After a bit of maintenance and stopping and starting, I notice I can't > attach to the running release: > > $ ./bin/appnode attach > No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such > device or address > > The pipe directory exists, containing files erlang.pipe.123.r and > erlang.pipe.123.w. File permissions look ok. I can ping the node. > The > release is running normally. > > I have tried > > $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 > > and that has the same result. (the version of erts is quite old). > > I have googled around the interwebs. > > Can anyone suggset some ideas for why this is happening and, mainly, > how > I can attach? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > iv...@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From ivan@REDACTED Mon Jun 23 17:27:43 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 23 Jun 2014 16:27:43 +0100 Subject: [erlang-questions] Can't attach to a running release: "No such device or address" In-Reply-To: References: <53A827EC.40000@llaisdy.com> Message-ID: <53A8476F.2020108@llaisdy.com> Bingo. Looks like this is exactly what happened. Thanks both. I can now attach and see why the app is running in this weird state. Ivan On 23/06/2014 16:08, Lukas Larsson wrote: > Hello, > > Have you made sure that the run_erl program is still running? > > > ps aux | grep run_erl > > This sort of problem would happen if run_erl for some reason exited > without taking the erlang vm with it and not cleaning up the fifos. > There should be a file called run_erl.log in the same directlory where > the erlang log files are, maybe it contains some information about what > has happened? > > Lukas > > > On Mon, Jun 23, 2014 at 3:13 PM, Ivan Uemlianin > wrote: > > Dear All > > I have an erlang release (packaged using rebar) running on a server. > After a bit of maintenance and stopping and starting, I notice I > can't attach to the running release: > > $ ./bin/appnode attach > No running Erlang on pipe /tmp/path/to/erlang.pipe.123: No such > device or address > > The pipe directory exists, containing files erlang.pipe.123.r and > erlang.pipe.123.w. File permissions look ok. I can ping the node. > The release is running normally. > > I have tried > > $./erts-5.9.3.1/bin/to_erl /tmp/path/to/erlang.pipe.123 > > and that has the same result. (the version of erts is quite old). > > I have googled around the interwebs. > > Can anyone suggset some ideas for why this is happening and, mainly, > how I can attach? > > With thanks and best wishes > > Ivan > > > -- > ==============================__============================== > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/__ivanuemlianin > > > festina lente > ==============================__============================== > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From max.lapshin@REDACTED Mon Jun 23 17:29:11 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 23 Jun 2014 19:29:11 +0400 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> Message-ID: On Mon, Jun 23, 2014 at 6:09 PM, Robert Raschke wrote: > Hi Max, > > since you are already using separate nodes running NIFs, there's probably > not much worth in converting to a C node or port. So this is just for > posterity. > Wrong. It will be a very big work to convert to C node. Right now my data flow is following: 1) 5-8 mbit of data are transferred to separate node 2) they pass through complicated code on erlang that prepares them for decoding 3) then original frame goes to decoder 4) decoder outputs from 100 to 1000 megabits of data 5) then they again go to tricky logic 6) after this huge amount of raw data gets into encoders 7) and again through erlang it gets back, being around 2-4 mbit/s So erlang has to copy less than 10 mbit here and there. All serious payload is zerocopies inside one node. If I change to driver, then I will have to write much more boilerplate demarshalling code. If I change to C node or port then I will have to rewrite big amount of working erlang code in C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darach@REDACTED Mon Jun 23 17:30:10 2014 From: darach@REDACTED (Darach Ennis) Date: Mon, 23 Jun 2014 16:30:10 +0100 Subject: [erlang-questions] Intel Xeon Phi In-Reply-To: References: <20140619150512.GG15725@csr-pc9.zib.de> Message-ID: Hi guys, There are some benchmarks for MPI here https://www.xsede.org/documents/271087/586927/Panda-dk-mic.pdf for Xeon Phi clusters. The ACM paper refers to the bencherl benchmark - so this would allow easy comparison of Erlang on a traditional intel based system and the Phi. However, what is missing is a comparison of native only vs erlang to get some idea of the overhead of erlang-based usage of the Phi verses pure native usage. With Steve's dirty schedulers around the corner it might be better for certain algorithms to have a NIF based hook into native code running on the Phi with an abstraction similar to CUDA's concurrent kernel execution facility for a reasonably sane and easy to use integrated environment that insulates end users from device/host concurrency and memory abstractions. Kevin Smith has an open source CUDA framework that balances these concerns very well: https://github.com/kevsmith/pteracuda However, as it seems Erlang can run natively on the Phi it is far more interesting potentially for folk running complex simulations with large numbers of processes. If anyone has attempted or succeeded in using the Phi for simulations or analytics with pure Erlang or Erlang as a control plane I and I imagine many others would be interested in an experience report... Effective use of coprocessors tends to be very domain specific in terms of benefits verses concerns. But, the Phi seems to support running Erlang on-core. This is very exciting as frameworks are dropping to C is the usual case. Cheers, Darach. On Mon, Jun 23, 2014 at 3:56 PM, Zachary Kessin wrote: > Would the folks who know something about (and have developed) Erlang on > Xeon Phi like to come on MostlyErlang and talk about it? I have been > interested in this for a few months and would love to spread the word. > > --Zach > Moslty Erlang Podcast > > > > On Thu, Jun 19, 2014 at 8:15 AM, Josh Adams > wrote: > >> This article looks nice: http://dl.acm.org/citation.cfm?id=2505307 >> >> Wanting to see some benchmarks on Erlang performance on the xeon phi, but >> I haven't yet knuckled down and bought that paper (because every time I'm >> tempted to, I want to buy the digital library subscription, and then I >> don't). Anyone have any benchmarks that aren't behind a paywall? >> >> > Hi List, Is the Erlang runtime capable of spawning processes on a Xeon >>> Phicoprocessor? Or is this piece of hardware too rare for Erlang to beable >>> to take advatage of it? >>> >> >> -- >> Josh Adams >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Zach Kessin > Mostly Erlang Podcast > Twitter: @zkessin > Skype: zachkessin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Mon Jun 23 18:00:01 2014 From: sean@REDACTED (Functional Jobs) Date: Mon, 23 Jun 2014 12:00:01 -0400 Subject: [erlang-questions] New Functional Programming Job Opportunities Message-ID: <53a84f0486dfd@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Developer / DevOps Engineer at Klarna http://functionaljobs.com/jobs/8721-developer-devops-engineer-at-klarna Cheers, Sean Murphy FunctionalJobs.com From raould@REDACTED Mon Jun 23 19:19:33 2014 From: raould@REDACTED (Raoul Duke) Date: Mon, 23 Jun 2014 10:19:33 -0700 Subject: [erlang-questions] node.js vs erlang In-Reply-To: <1567668.L9TW3cJVpr@jalapeno> References: <1899380.1Z2M3BliFt@jalapeno> <1567668.L9TW3cJVpr@jalapeno> Message-ID: > Care to elaborate? Unqualified derision does not express anything useful about > what you (would) like. how did you know that was my band name? "Thank you! We are: UNQUALIFIED DERISION! Good night!" anyway. django docs do this thing that i see elsewhere, too: they have a story that is the happy path that you have to follow to a T to get it to stay Happy. if you slightly diverge then often things go to hell, now or later in the story you are following; if you want to learn something that isn't in the docs good luck Charlie with that; etc. it just seems really sorta lame, narrow, patronizing, fluffly, not really sufficiently helpful, automagic (in a bad way), etc. to me. From mjtruog@REDACTED Mon Jun 23 19:45:21 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 23 Jun 2014 10:45:21 -0700 Subject: [erlang-questions] Difference between enif_schedule_dirty_nif and driver_async? In-Reply-To: References: <8F8ADD09-E9D0-4903-84BF-C8AE0E9CA600@gmail.com> Message-ID: <53A867B1.6050506@gmail.com> On 06/23/2014 08:29 AM, Max Lapshin wrote: > > > > On Mon, Jun 23, 2014 at 6:09 PM, Robert Raschke > wrote: > > Hi Max, > > since you are already using separate nodes running NIFs, there's probably not much worth in converting to a C node or port. So this is just for posterity. > > > Wrong. It will be a very big work to convert to C node. > > Right now my data flow is following: > > 1) 5-8 mbit of data are transferred to separate node > 2) they pass through complicated code on erlang that prepares them for decoding > 3) then original frame goes to decoder > 4) decoder outputs from 100 to 1000 megabits of data > 5) then they again go to tricky logic > 6) after this huge amount of raw data gets into encoders > 7) and again through erlang it gets back, being around 2-4 mbit/s > > > So erlang has to copy less than 10 mbit here and there. All serious payload is zerocopies inside one node. > > If I change to driver, then I will have to write much more boilerplate demarshalling code. > > If I change to C node or port then I will have to rewrite big amount of working erlang code in C. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions If you want, you could use https://github.com/okeuday/GEPD/ to be able to switch between an Erlang port and an Erlang port driver (where the port driver can use the async thread pool). The code is done with the preprocessor to avoid overhead. It would be possible to add NIF generation that uses the dirty scheduler for async calls. Since you are dealing with higher throughput though, it seems like you should want more than 1 connection to the Erlang VM and CloudI would help you there (http://cloudi.org), since otherwise the single connection (cnode or port) will always be a bottleneck (making multiple connections for higher throughput isn't really a way of solving the problem, just a way of ignoring it). With a port driver and port level locking you can have multiple ports used concurrently if your C/C++ code is perfect. So, that is an approach if you are able to have perfect source code for integration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Mon Jun 23 22:07:55 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Mon, 23 Jun 2014 16:07:55 -0400 Subject: [erlang-questions] Erlang that matters Message-ID: <26AD46FB-DA11-4442-83FE-096F9958628F@writersglen.com> Hello, This post may not be suitable for this list. So please consider it an invitation. I just finished one of the most provocative and profound books that I've read in some time. It has direct bearing on what we do everyday as Erlang programmers: The Open-Source Everything Manifesto: Transparency, Truth, and Trust http://www.amazon.com/The-Open-Source-Everything-Manifesto-Transparency/dp/1583944435/ref=cm_cr_pr_product_top If nothing else, it could be a fruitful generator of ideas for important and rewarding Erlang applications. In my view it's that and much much more. I'd love to engage in a constructive conversation/brainstorm re: the implications of this book. Please respond to me off list if interested or, if deemed relevant, on-list. All the best, LRP Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Mon Jun 23 22:36:38 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Mon, 23 Jun 2014 22:36:38 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> Message-ID: On 2014-06-23 11:43:11 +0000, Raphael Korsoski said: > On the other hand, it is more or less trivial to _implement_ models of > Actors in Erlang,?whichever of the many proposed semantics for actors > you choose.? I agree, except the automatic garbage collection of actors that are inactive which seems so important for Hewitt. The latter would not be trivial to implement. Not sure why he thinks its such a big deal. > Although I have never completed the exercise, I believe quite strongly > that you could also fully embed Erlang's style of concurrency in both > abstract actor models and operational (process calculi) implementations > of those, with relatively simple, or even trivial, translations; eg > selective receive as a set of actors with a receptionist. Well in theory you can implement everything in almost everything. In practice its eaither infeasible or has quite bad performance if you model Erlangs mailbox, linking and monitoring behavour. > In my opinion, strictly separating Erlang-style concurrency and the > Actor model is only of academic interest; unless you are implementing, > say, an Erlang runtime of course. I disagree. Almost all the good things in Erlang come from differences from the Actor model: * mailboxes with selective receive help to significantly reduce state complexity. If you don't know what I mean please watch http://www.infoq.com/presentations/Death-by-Accidental-Complexity Of cours if you are only using sycronous gen_server calls you won't notice the differences but at the same time giving up lots of expresive power. * links and monitors and the failure handling derived from them * The possibility of sequential long running preempted code Generally Erlang implements something that "solves the problem", wheras actors are just a theoretical construct. Cheers -- Peer > The differences are certainly relevant to category theorists, language > theorists, mathematicians working in the Curry-Howard domain and so > forth, but for the general programmer the differences are more or less > implementation details ("up-to the usual nonsense"). > > By contrast, although it is just as relevant, we generally don't > discern between object-oriented models that allow either contra- or > covariant inheritance (or both). Should we really distinguish > process-oriented models by the semantics of the "becomes" relation? > > /// Raphael > > > On Mon, Jun 23, 2014 at 4:40 AM, zxq9 wrote: > On Monday 23 June 2014 11:22:36 Ngoc Dao wrote: > > > In many ways an Erlang system does have an OS feeling about it. At least > > > > I think so. > > > > I think so, too: > > http://www.slideshare.net/ngocdaothanh/cloud-erlang > > I enjoyed the abbreviated cut-down (once I got over the use of the empty, > warped, buzzsound term "cloud"... its necessary to attract attention from a > certain type of party, but they aren't the sort who are really going to > embrace what you have to say). ?Its a good reference to explain why Erlang > implies a lot more than just a language. Much better, I think, to do like > you've done here and treat Erlang/OTP as a system that supports a very > different model of computation than most folks are accustomed to than to start > them on the language syntax first. > > Actually, quite a few interesting early attempts at explaining Erlang as a > system up-front have come out over the last few threads. Most of this stuff is > unpolished, but represents a lot of effort in a good direction. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Mon Jun 23 23:46:46 2014 From: raould@REDACTED (Raoul Duke) Date: Mon, 23 Jun 2014 14:46:46 -0700 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> Message-ID: > Generally Erlang implements something that "solves the problem", wheras > actors are just a theoretical construct. well yes the Actor model stuff was/is intended to be a foundational thing to build on top of. so when you say "theoretical construct" in a way it would be taken as a compliment, not an insult ;-) so i expect from Hewlitt et. al.'s perspective one would want to implement Erlang on top of actors. :-) From mfidelman@REDACTED Tue Jun 24 00:14:28 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 23 Jun 2014 18:14:28 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> Message-ID: <53A8A6C4.2010005@meetinghouse.net> Raoul Duke wrote: >> Generally Erlang implements something that "solves the problem", wheras >> actors are just a theoretical construct. > well yes the Actor model stuff was/is intended to be a foundational > thing to build on top of. so when you say "theoretical construct" in a > way it would be taken as a compliment, not an insult ;-) > > so i expect from Hewlitt et. al.'s perspective one would want to > implement Erlang on top of actors. :-) > _______________________________________________ > Seems to me that the core of the actor model is shared-nothing, message passing concurrency. Yes there are some fine differences between the full model as defined by Hewitt (and implemented by him in some cases) and Erlang - but that seems to get into the world of implementation details. Now whether any of that influenced Erlang, or was a case of parallel invention, is a different question. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From steven.charles.davis@REDACTED Tue Jun 24 00:34:03 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 23 Jun 2014 15:34:03 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> Message-ID: <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> Hi Richard, I'm confused by your response... is it possible to do tail-recursion in Java (and thus make iteration and recursion similar)? I had imagined that each recursive function call in a JVM would add a frame to the stack and eventually cause an overflow. Maybe I missed making my point. :( /s On Sunday, June 22, 2014 11:40:54 PM UTC-5, Richard A. O'Keefe wrote: > > > On 21/06/2014, at 12:58 PM, Steve Davis wrote: > > > It's not hard... but can be extremely expensive if it builds a call > stack (e.g. Java)... > > Presumably "It" here refers to "recursion". > > Extremely expensive compared to *what*? > > There are problems where you could naturally use either > iteration or tail recursion, and it doesn't matter which > one you use because they are the same thing. > > And there are problems that can be expressed simply using > general recursion. For those problems, doing without it > results in code that harder for people and worse for computers. > > There can be no problems that are easier with iteration than > recursion, although there can be problems that are easier > with particular *syntax*. > > If we are talking about "Erlang for youngsters", > I wonder whether it might not be easier to teach > the *use* of higher-order traversal functions than > direct loops of any kind. I remember it being > *amazing* how much you could get done in APL without > a loop of your own in sight. > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Tue Jun 24 00:38:19 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 23 Jun 2014 15:38:19 -0700 (PDT) Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> Message-ID: <41592710-b2d7-4378-ba73-aeca46f2dd3f@googlegroups.com> I do however see how the idea encapsulated by "X = X+1" is the root of many computation problems - and is probably not a great thing to teach to kids without caveats. On Monday, June 23, 2014 5:34:04 PM UTC-5, Steve Davis wrote: > > Hi Richard, > > I'm confused by your response... is it possible to do tail-recursion in > Java (and thus make iteration and recursion similar)? > > I had imagined that each recursive function call in a JVM would add a > frame to the stack and eventually cause an overflow. > > Maybe I missed making my point. :( > > /s > > On Sunday, June 22, 2014 11:40:54 PM UTC-5, Richard A. O'Keefe wrote: >> >> >> On 21/06/2014, at 12:58 PM, Steve Davis wrote: >> >> > It's not hard... but can be extremely expensive if it builds a call >> stack (e.g. Java)... >> >> Presumably "It" here refers to "recursion". >> >> Extremely expensive compared to *what*? >> >> There are problems where you could naturally use either >> iteration or tail recursion, and it doesn't matter which >> one you use because they are the same thing. >> >> And there are problems that can be expressed simply using >> general recursion. For those problems, doing without it >> results in code that harder for people and worse for computers. >> >> There can be no problems that are easier with iteration than >> recursion, although there can be problems that are easier >> with particular *syntax*. >> >> If we are talking about "Erlang for youngsters", >> I wonder whether it might not be easier to teach >> the *use* of higher-order traversal functions than >> direct loops of any kind. I remember it being >> *amazing* how much you could get done in APL without >> a loop of your own in sight. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Jun 24 02:53:05 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 24 Jun 2014 12:53:05 +1200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> Message-ID: I like the way Friedman and Wise put it in 1974: Although there are those who argue that recursion is an unnatural programming construct, it has been demonstrated to be rather an intuitive and entirely convenient way to program IF LEARNED FIRST. Moreover, this control for repetitive processes better approximates the standards of readability, provability, and changeability required in schemes of structured programming. (Emphasis mine. The body of that classic paper cites a source for the claim of "intuitive ... if learned first.") On 24/06/2014, at 10:34 AM, Steve Davis wrote: > Hi Richard, > > I'm confused by your response... is it possible to do tail-recursion in Java (and thus make iteration and recursion similar)? (a) I was not talking about Java at all. I took "e.g. Java" to be an aside, not the meat of your claim. (b) Whether Java *does* do TRO is one question, whether Java *could* is another. And in fact the question is not one about Java the language but javac the compiler (or other Java compilers). It so happens that the C compilers I use have been doing this for a long time, so I don't see any reason why a native code compiler for Java couldn't. (c) As evidence, apparently the .NET JIT *does* do tail call optimisation (not just direct TRO). See http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-jit-conditions.aspx The CLR has explicit support for tail calls, and the JIT may sometimes turn call...;ret; into a tail call even without that explicit marker. (d) According to the Wikipedia article on tail calls, "functional languages such as Scala that target the JVM can efficiently implement direct tail recursion, but not mutual tail recursion." (e) Eric Bruno wrote in April that "Brian Goetz at Oracle [...] said that [TRO is] on a list of things to be added to the JVM, but it's just not a high-priority item." Direct tail recursion is the one you need to replace iteration. > > I had imagined that each recursive function call in a JVM would add a frame to the stack and eventually cause an overflow. It *may* be done that way, but it doesn't *have* to be. There is nothing stopping a Java compiler turning direct tail recursion into JVM-level gotos. If a Java compiler *doesn't* do that, that's a quality-of-implementation issue in that particular compiler, not a fundamental property of the language or of recursion as such. > Maybe I missed making my point. :( Indeed you did. You missed MY point, which is "expensive COMPARED TO WHAT?" If you have a naturally recursive algorithm, and you code it somehow without (formally) using recursion, chances are you have *emulated* recursion by manipulating stacks of things, and the odds are that this will be *more* expensive than letting the compiler into the secret and having it get on with the job. It is virtually certain that the code will be buggy and hard to maintain. As it happens, I've rewritten a number of algorithms in non-recursive form. There was one machine I used with a 4MB address space but a 128kB stack. There was one system where there are a number of key operations that had to be coded in assembler... It's *painful*. Getting back to the point of this thread, just a month or two ago I was making a bunch of student programs for a fairly simple task. The recursive programs were short, simple, and correct. (They weren't always *efficient* because Java had seduced some of them into first creating a tree of objects and then traversing it in a second pass, instead of doing it directly.) The non-recursive programs were much longer, nightmarish to try to understand, and took much longer to debug. From lloyd@REDACTED Tue Jun 24 03:33:48 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Mon, 23 Jun 2014 21:33:48 -0400 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <2013dce7-0a5f-43d4-a552-d0fe97108c39@googlegroups.com> <1FF62F7B-26A2-4D10-82A0-2A20F1C166C2@cs.otago.ac.nz> <4A0B1C17-A20E-489C-94E1-4C1A6FE5B471@cs.otago.ac.nz> <4f7a87d1-0b95-42e0-b701-9fd781540cbc@googlegroups.com> Message-ID: <87DF7494-E71E-4F1F-ACF9-D958895E8996@writersglen.com> Hello, Logo, based on Lisp, developed at MIT, has been widely taught to kids, er, rather, given to kids to teach themselves. They develop recursive programs to draw beautiful turtle graphics. http://en.m.wikipedia.org/wiki/Logo_(programming_language) http://el.media.mit.edu/logo-foundation/logo/programming.html Children's Mental Models of Recursive Computer Programs http://halshs.archives-ouvertes.fr/docs/00/19/05/37/PDF/A27_Kurland_Pea_85.pdf Best, Lloyd Sent from my iPad > On Jun 23, 2014, at 8:53 PM, "Richard A. O'Keefe" wrote: > > > I like the way Friedman and Wise put it in 1974: > Although there are those who argue that recursion > is an unnatural programming construct, it has been > demonstrated to be rather an intuitive and entirely > convenient way to program IF LEARNED FIRST. Moreover, > this control for repetitive processes better > approximates the standards of readability, provability, > and changeability required in schemes of structured > programming. > (Emphasis mine. The body of that classic paper cites a > source for the claim of "intuitive ... if learned first.") > >> On 24/06/2014, at 10:34 AM, Steve Davis wrote: >> >> Hi Richard, >> >> I'm confused by your response... is it possible to do tail-recursion in Java (and thus make iteration and recursion similar)? > > (a) I was not talking about Java at all. I took "e.g. Java" > to be an aside, not the meat of your claim. > (b) Whether Java *does* do TRO is one question, > whether Java *could* is another. And in fact > the question is not one about Java the language > but javac the compiler (or other Java compilers). > It so happens that the C compilers I use have been > doing this for a long time, so I don't see any reason > why a native code compiler for Java couldn't. > (c) As evidence, apparently the .NET JIT *does* do tail > call optimisation (not just direct TRO). See > http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-jit-conditions.aspx > The CLR has explicit support for tail calls, and the > JIT may sometimes turn call...;ret; into a tail call > even without that explicit marker. > (d) According to the Wikipedia article on tail calls, > "functional languages such as Scala that target the > JVM can efficiently implement direct tail recursion, > but not mutual tail recursion." > (e) Eric Bruno wrote in April that > "Brian Goetz at Oracle [...] said that [TRO is] > on a list of things to be added to the JVM, but it's > just not a high-priority item." > > Direct tail recursion is the one you need to replace > iteration. >> >> I had imagined that each recursive function call in a JVM would add a frame to the stack and eventually cause an overflow. > > It *may* be done that way, but it doesn't *have* to be. > There is nothing stopping a Java compiler turning > direct tail recursion into JVM-level gotos. > > If a Java compiler *doesn't* do that, that's a > quality-of-implementation issue in that particular > compiler, not a fundamental property of the language > or of recursion as such. > >> Maybe I missed making my point. :( > > Indeed you did. You missed MY point, which is > "expensive COMPARED TO WHAT?" > > If you have a naturally recursive algorithm, and > you code it somehow without (formally) using recursion, > chances are you have *emulated* recursion by manipulating > stacks of things, and the odds are that this will be > *more* expensive than letting the compiler into the secret > and having it get on with the job. It is virtually > certain that the code will be buggy and hard to maintain. > > As it happens, I've rewritten a number of algorithms in > non-recursive form. There was one machine I used with a > 4MB address space but a 128kB stack. There was one > system where there are a number of key operations that > had to be coded in assembler... It's *painful*. > > Getting back to the point of this thread, just a month or > two ago I was making a bunch of student programs for a > fairly simple task. The recursive programs were short, > simple, and correct. (They weren't always *efficient* > because Java had seduced some of them into first creating a > tree of objects and then traversing it in a second pass, > instead of doing it directly.) The non-recursive programs > were much longer, nightmarish to try to understand, and > took much longer to debug. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jay@REDACTED Tue Jun 24 04:51:31 2014 From: jay@REDACTED (Jay Nelson) Date: Mon, 23 Jun 2014 19:51:31 -0700 Subject: [erlang-questions] Dictionary strategy of last value wins In-Reply-To: <30895187-3B74-41D3-BCBB-89078911248C@duomark.com> References: <30895187-3B74-41D3-BCBB-89078911248C@duomark.com> Message-ID: <9192412B-A39E-4EAD-A91B-B1CCD6690931@duomark.com> Mailer issues lost my first draft and resulted in the 2nd being only addressed to Bob. Posting for the list and feedback. On Jun 23, 2014, at 7:18 PM, Jay Nelson wrote: > > On Jun 22, 2014, at 11:16 AM, Bob Ippolito wrote: > >> If you do want to keep a full history of inserts, couldn't you use a dict(K, [V])? Sure, you'd have to write a few functions, since dict:append/3 doesn't have the desired semantics, but such functions are straightforward to write. >> >> prepend(K, V, D) -> >> dict:update(K, fun (Vs) -> [V | Vs] end, [V], D). > > It?s kind of funny that the imperative append is provided in our functional dict > module. I guess it mirrors the thinking on the init list. This is a simple approach > to keep versioned data for all keys. > > I rambled too much in my original post. My question was actually only about the > initialization. I am trying to make an abstract dictionary for object-like handling > of data, with translation between DB access and Application access. The seeds > of the idea are at https://github.com/duomark/epode/tree/dict-types (I haven?t > merged the latest code to master yet). > > As a library I wanted to provide a convenient initialization method with proplists > as my guide, because initializing sets of objects with defaults and contextual > overrides fits the model of push down contexts or environments better. I am > curious if people initialize their dictionaries with imperatively constructed lists > (with the most recent change at the end, relying on clobber semantics) or > with push/pop contexts on top of default values. > > The recommended approach for maps is to merge a default map with the > overrides (or I suppose a sequence of overrides and rule for proper merge > ordering). Dictionaries appear to be an imperative approach that has been > adapted to functional in a way that exhibits features of both approaches. > I was conditioned with LISP to use proplists and environment contexts. > > jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From streamingmind@REDACTED Tue Jun 24 03:11:52 2014 From: streamingmind@REDACTED (=?utf-8?B?c3RyZWFtaW5nbWluZEBnbWFpbC5jb20=?=) Date: Mon, 23 Jun 2014 18:11:52 -0700 (PDT) Subject: [erlang-questions] How to specify receiver for erl_drv_send_term Message-ID: <000f4242.2278e7c72456932c@gmail.com> Hi all, I've been practicing writing a port driver for a legacy SIGTRN product. In attempting to send back data from the port driver to a erlang process, I don't know how to convert existing erlang_pid data to a ErlDrvTerm data which is required by erl_drv_send_term(), as the receiver parameter. It'll be graceful if somebody here could give me a hand. Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From khirata28@REDACTED Tue Jun 24 04:31:36 2014 From: khirata28@REDACTED (Ken Hirata) Date: Mon, 23 Jun 2014 19:31:36 -0700 Subject: [erlang-questions] Erlang filtering RARPs? Message-ID: I can't seem to receive RARPs within an Erlang application using procket. I can see RARPs on a tcpdump trace running within Ubuntu Linux when the Erlang shell isn't executing. RARPs are not recorded once I execute erl. The RARPs contain the Ethernet source MAC address in the RARP Sender and Target MAC address fields. Does invoking Erlang initialize the OS network stack so that RARPs are discarded? If so, are there any configuration parameters to change the behavior? - Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Tue Jun 24 13:54:49 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Tue, 24 Jun 2014 13:54:49 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> <53A8A6C4.2010005@meetinghouse.net> Message-ID: On 2014-06-23 22:14:28 +0000, Miles Fidelman said: > Raoul Duke wrote: >>> Generally Erlang implements something that "solves the problem", wheras >>> actors are just a theoretical construct. >> well yes the Actor model stuff was/is intended to be a foundational >> thing to build on top of. so when you say "theoretical construct" in a >> way it would be taken as a compliment, not an insult ;-) >> >> so i expect from Hewlitt et. al.'s perspective one would want to >> implement Erlang on top of actors. :-) >> _______________________________________________ >> > > Seems to me that the core of the actor model is shared-nothing, message > passing concurrency. Yes there are some fine differences between the > full model as defined by Hewitt (and implemented by him in some cases) > and Erlang - but that seems to get into the world of implementation details. How is having a quite different semantics being a "implementation detail". But I should probably give up, the "Erlang is a implementation of the Actor model" meme seems to be stronger than unimportant details than semantics. Peer From yann.secq@REDACTED Tue Jun 24 17:39:57 2014 From: yann.secq@REDACTED (Yann SECQ) Date: Tue, 24 Jun 2014 17:39:57 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> <53A8A6C4.2010005@meetinghouse.net> Message-ID: <53A99BCD.3050108@univ-lille1.fr> Le 24/06/2014 13:54, Peer Stritzinger a ?crit : > How is having a quite different semantics being a "implementation detail". > But I should probably give up, the "Erlang is a implementation of the > Actor model" meme seems to be stronger than unimportant details than > semantics. I've found this piece particularly interesting in the context of this thread: The Hewitt Actor Model and the Labyrinth of Metaphysics http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-metaphysics-v-001/ Cheers, yann. -- Contact: yann.secq{at}univ-lille1.fr | www.lifl.fr/~secq www.ouverture-independance.fr | www.sauvonsluniversite.com -- "Ne d?sesp?rez jamais. Faites infuser davantage.", Henri Michaux From paulo.ferraz.oliveira@REDACTED Tue Jun 24 17:58:11 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 24 Jun 2014 16:58:11 +0100 Subject: [erlang-questions] Dialyzer: Unknown functions Message-ID: Hi. I'm applying dialyzer to my project and still have a bunch of warnings whose origin I can't seem to figure out. Unknown functions: cover:compile_beam/1 cover:compile_beam/2 cover:compile_module/2 cover:export/2 cover:get_term/1 cover:import/1 cover:is_compiled/1 cover:module_info/1 cover:write/2 eprof:analyze/1 eprof:log/1 eprof:start/0 eprof:start_profiling/1 eprof:stop_profiling/0 packages:last/1 packages:strip_last/1 xref:add_application/3 xref:analyze/2 xref:set_default/3 xref:set_library_path/2 xref:start/2 xref:stop/1 Unknown types: ... I'm using the following to generate the PLT: dialyzer --build_plt --verbose --statistics -Wunmatched_returns -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit gs mnesia -I include Does anybody know how to solve this (I don't want to ignore the warnings) or could probably point me in the right direction so that I can figure it out? Thanks. Cheers. - Paulo F. Oliveira -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Tue Jun 24 18:02:53 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Tue, 24 Jun 2014 18:02:53 +0200 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: References: Message-ID: Hi Paulo, cover, xref & eprof are part of the tools application. So just add tools to your --apps list. I don't know where the packages is from though? Cheers, -- Pierre Fenoll On 24 June 2014 17:58, Paulo F. Oliveira wrote: > Hi. > > I'm applying dialyzer to my project and still have a bunch of warnings > whose origin I can't seem to figure out. > > Unknown functions: > cover:compile_beam/1 > cover:compile_beam/2 > cover:compile_module/2 > cover:export/2 > cover:get_term/1 > cover:import/1 > cover:is_compiled/1 > cover:module_info/1 > cover:write/2 > eprof:analyze/1 > eprof:log/1 > eprof:start/0 > eprof:start_profiling/1 > eprof:stop_profiling/0 > packages:last/1 > packages:strip_last/1 > xref:add_application/3 > xref:analyze/2 > xref:set_default/3 > xref:set_library_path/2 > xref:start/2 > xref:stop/1 > Unknown types: > ... > > I'm using the following to generate the PLT: > > dialyzer --build_plt --verbose --statistics -Wunmatched_returns > -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs -r > deps --apps ebin asn1 compiler crypto erts hipe inets kernel public_key > runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit gs mnesia -I > include > > Does anybody know how to solve this (I don't want to ignore the warnings) > or could probably point me in the right direction so that I can figure it > out? > > Thanks. > > Cheers. > > - Paulo F. Oliveira > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jun 24 18:05:59 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 24 Jun 2014 18:05:59 +0200 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: References: Message-ID: <53A9A1E7.2020102@ninenines.eu> Is your code calling the cover, eprof, packages?? or xref functions there? If not, then it's completely pointless to include them in your PLT! You should only include the applications that your code uses, otherwise all you end up doing is dialyzing OTP when you build your PLT, which is probably not what you want. On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote: > Hi. > > I'm applying dialyzer to my project and still have a bunch of warnings > whose origin I can't seem to figure out. > > Unknown functions: > cover:compile_beam/1 > cover:compile_beam/2 > cover:compile_module/2 > cover:export/2 > cover:get_term/1 > cover:import/1 > cover:is_compiled/1 > cover:module_info/1 > cover:write/2 > eprof:analyze/1 > eprof:log/1 > eprof:start/0 > eprof:start_profiling/1 > eprof:stop_profiling/0 > packages:last/1 > packages:strip_last/1 > xref:add_application/3 > xref:analyze/2 > xref:set_default/3 > xref:set_library_path/2 > xref:start/2 > xref:stop/1 > Unknown types: > ... > > I'm using the following to generate the PLT: > > dialyzer --build_plt --verbose --statistics -Wunmatched_returns > -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs > -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel > public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit > gs mnesia -I include > > Does anybody know how to solve this (I don't want to ignore the > warnings) or could probably point me in the right direction so that I > can figure it out? > > Thanks. > > Cheers. > > - Paulo F. Oliveira > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From paulo.ferraz.oliveira@REDACTED Tue Jun 24 18:10:13 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 24 Jun 2014 17:10:13 +0100 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: <53A9A1E7.2020102@ninenines.eu> References: <53A9A1E7.2020102@ninenines.eu> Message-ID: Thank you, Pierre and Lo?c. In any case, is it normal to have warnings when building the PLT, then? - Paulo F. Oliveira On 24 June 2014 17:05, Lo?c Hoguin wrote: > Is your code calling the cover, eprof, packages?? or xref functions there? > > If not, then it's completely pointless to include them in your PLT! > > You should only include the applications that your code uses, otherwise > all you end up doing is dialyzing OTP when you build your PLT, which is > probably not what you want. > > > On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote: > >> Hi. >> >> I'm applying dialyzer to my project and still have a bunch of warnings >> whose origin I can't seem to figure out. >> >> Unknown functions: >> cover:compile_beam/1 >> cover:compile_beam/2 >> cover:compile_module/2 >> cover:export/2 >> cover:get_term/1 >> cover:import/1 >> cover:is_compiled/1 >> cover:module_info/1 >> cover:write/2 >> eprof:analyze/1 >> eprof:log/1 >> eprof:start/0 >> eprof:start_profiling/1 >> eprof:stop_profiling/0 >> packages:last/1 >> packages:strip_last/1 >> xref:add_application/3 >> xref:analyze/2 >> xref:set_default/3 >> xref:set_library_path/2 >> xref:start/2 >> xref:stop/1 >> Unknown types: >> ... >> >> I'm using the following to generate the PLT: >> >> dialyzer --build_plt --verbose --statistics -Wunmatched_returns >> -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs >> -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel >> public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit >> gs mnesia -I include >> >> Does anybody know how to solve this (I don't want to ignore the >> warnings) or could probably point me in the right direction so that I >> can figure it out? >> >> Thanks. >> >> Cheers. >> >> - Paulo F. Oliveira >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jun 24 18:11:12 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 24 Jun 2014 18:11:12 +0200 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: References: <53A9A1E7.2020102@ninenines.eu> Message-ID: <53A9A320.3070303@ninenines.eu> Unless you include all applications in OTP, yes. On 06/24/2014 06:10 PM, Paulo F. Oliveira wrote: > Thank you, Pierre and Lo?c. > > In any case, is it normal to have warnings when building the PLT, then? > > - Paulo F. Oliveira > > > On 24 June 2014 17:05, Lo?c Hoguin > wrote: > > Is your code calling the cover, eprof, packages?? or xref functions > there? > > If not, then it's completely pointless to include them in your PLT! > > You should only include the applications that your code uses, > otherwise all you end up doing is dialyzing OTP when you build your > PLT, which is probably not what you want. > > > On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote: > > Hi. > > I'm applying dialyzer to my project and still have a bunch of > warnings > whose origin I can't seem to figure out. > > Unknown functions: > cover:compile_beam/1 > cover:compile_beam/2 > cover:compile_module/2 > cover:export/2 > cover:get_term/1 > cover:import/1 > cover:is_compiled/1 > cover:module_info/1 > cover:write/2 > eprof:analyze/1 > eprof:log/1 > eprof:start/0 > eprof:start_profiling/1 > eprof:stop_profiling/0 > packages:last/1 > packages:strip_last/1 > xref:add_application/3 > xref:analyze/2 > xref:set_default/3 > xref:set_library_path/2 > xref:start/2 > xref:stop/1 > Unknown types: > ... > > I'm using the following to generate the PLT: > > dialyzer --build_plt --verbose --statistics -Wunmatched_returns > -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs > -Wspecdiffs > -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel > public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc > eunit > gs mnesia -I include > > Does anybody know how to solve this (I don't want to ignore the > warnings) or could probably point me in the right direction so > that I > can figure it out? > > Thanks. > > Cheers. > > - Paulo F. Oliveira > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > -- > Lo?c Hoguin > http://ninenines.eu > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From paulo.ferraz.oliveira@REDACTED Tue Jun 24 18:27:02 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 24 Jun 2014 17:27:02 +0100 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: <53A9A320.3070303@ninenines.eu> References: <53A9A1E7.2020102@ninenines.eu> <53A9A320.3070303@ninenines.eu> Message-ID: Great. Reduced the --apps to ebin erts kernel stdlib and was able to make it work like expected. Thanks again. - Paulo F. Oliveira On 24 June 2014 17:11, Lo?c Hoguin wrote: > Unless you include all applications in OTP, yes. > > On 06/24/2014 06:10 PM, Paulo F. Oliveira wrote: > >> Thank you, Pierre and Lo?c. >> >> In any case, is it normal to have warnings when building the PLT, then? >> >> - Paulo F. Oliveira >> >> >> On 24 June 2014 17:05, Lo?c Hoguin > > wrote: >> >> Is your code calling the cover, eprof, packages?? or xref functions >> there? >> >> If not, then it's completely pointless to include them in your PLT! >> >> You should only include the applications that your code uses, >> otherwise all you end up doing is dialyzing OTP when you build your >> PLT, which is probably not what you want. >> >> >> On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote: >> >> Hi. >> >> I'm applying dialyzer to my project and still have a bunch of >> warnings >> whose origin I can't seem to figure out. >> >> Unknown functions: >> cover:compile_beam/1 >> cover:compile_beam/2 >> cover:compile_module/2 >> cover:export/2 >> cover:get_term/1 >> cover:import/1 >> cover:is_compiled/1 >> cover:module_info/1 >> cover:write/2 >> eprof:analyze/1 >> eprof:log/1 >> eprof:start/0 >> eprof:start_profiling/1 >> eprof:stop_profiling/0 >> packages:last/1 >> packages:strip_last/1 >> xref:add_application/3 >> xref:analyze/2 >> xref:set_default/3 >> xref:set_library_path/2 >> xref:start/2 >> xref:stop/1 >> Unknown types: >> ... >> >> I'm using the following to generate the PLT: >> >> dialyzer --build_plt --verbose --statistics -Wunmatched_returns >> -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs >> -Wspecdiffs >> -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel >> public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc >> eunit >> gs mnesia -I include >> >> Does anybody know how to solve this (I don't want to ignore the >> warnings) or could probably point me in the right direction so >> that I >> can figure it out? >> >> Thanks. >> >> Cheers. >> >> - Paulo F. Oliveira >> >> >> _________________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/__listinfo/erlang-questions >> >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stamarit@REDACTED Tue Jun 24 19:14:43 2014 From: stamarit@REDACTED (Salvador Tamarit) Date: Tue, 24 Jun 2014 19:14:43 +0200 Subject: [erlang-questions] Call for bugs In-Reply-To: <24FF92F8-6270-46CB-99D8-EC27E957A6AA@gmail.com> References: <24FF92F8-6270-46CB-99D8-EC27E957A6AA@gmail.com> Message-ID: Thanks for your answers. They have been very helpful. If you have more bugs, please send them to us. Shayan and Anthony, we will add you in the acknowledgements section of a paper that we are writing about the tool. Thanks again! Salvador Tamarit 2014-06-13 17:00 GMT+02:00 Anthony Ramine : > http://erlang.org/pipermail/erlang-bugs/2014-May/004408.html > https://github.com/nox/otp/commit/a10a7979887403ea61c30155cef18aa7324420a6 > > -- > Anthony Ramine > > Le 13 juin 2014 ? 13:57, Salvador Tamarit a > ?crit : > > > Hi all, > > > > we are working in an alternative debugger for Erlang based on the > concept of declarative debugging. We have found some difficulties finding > interesting buggy programs to test our tool, so we think that maybe you all > can help us in this. We will need examples of buggy functions or modules > or, if it exits, a place where there is a collection of them. Also any bug > that you remember that was difficult to solve in order to try to reproduce > it again in a new program. We are more interested in bugs that Dialyzer > can't find, because the intention of the tool is to help to find bugs after > running Dialyzer. > > > > Thanks in advance for your collaboration. > > Salvador Tamarit > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Jun 24 21:26:02 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 24 Jun 2014 15:26:02 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> <53A8A6C4.2010005@meetinghouse.net> Message-ID: <53A9D0CA.9020204@meetinghouse.net> Peer Stritzinger wrote: > On 2014-06-23 22:14:28 +0000, Miles Fidelman said: > >> Raoul Duke wrote: >>>> Generally Erlang implements something that "solves the problem", >>>> wheras >>>> actors are just a theoretical construct. >>> well yes the Actor model stuff was/is intended to be a foundational >>> thing to build on top of. so when you say "theoretical construct" in a >>> way it would be taken as a compliment, not an insult ;-) >>> >>> so i expect from Hewlitt et. al.'s perspective one would want to >>> implement Erlang on top of actors. :-) >>> _______________________________________________ >>> >> >> Seems to me that the core of the actor model is shared-nothing, message >> passing concurrency. Yes there are some fine differences between the >> full model as defined by Hewitt (and implemented by him in some cases) >> and Erlang - but that seems to get into the world of implementation >> details. > > How is having a quite different semantics being a "implementation > detail". > > But I should probably give up, the "Erlang is a implementation of the > Actor model" meme seems to be stronger than unimportant details than > semantics. > Maybe this is a clearer way of looking at it: (?) 1. From a 50,000 foot level, the Actor Model is a model of computation characterized by actors, messages, and message-passing concurrency. 2. The Actor Model presents a useful way to conceptualize certain classes of problems 3. Erlang is arguably the best, most mature programming/run-time environment for implementing systems that fit Actor-oriented design patterns Beyond that: 4. The Actor Model, as formally defined by Hewitt (including some mathematical modeling thereof), differs from Erlang in some ways (or Erlang differs from it). Though, as Hewitt says, "As was the case with the lambda calculus and functional programming, it has taken decades since they were invented [Hewitt, Bishop, and Steiger 1973] to understand the scientific and engineering of Actor Systems and it is still very much a work in progress." 5. Erlang does not appear to have been directly influenced by work on the Actor Model. Rather, it seems to have been a case of parallel developing of a similar approach to computation. FYI: As a result of this thread, I've found two very educational sources on these matters: http://arxiv.org/ftp/arxiv/papers/1008/1008.1459.pdf (recent paper by Hewitt, cited earlier by someone else on this thread - includes a discussion of Erlang) http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask - 48 minute video of an informal discussion of the Actor Model, between Hewitt and a couple of other academics, at the Lang.Next 2012 conference. Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From essen@REDACTED Tue Jun 24 21:35:37 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 24 Jun 2014 21:35:37 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> <53A8A6C4.2010005@meetinghouse.net> Message-ID: <53A9D309.2070505@ninenines.eu> On 06/24/2014 01:54 PM, Peer Stritzinger wrote: > But I should probably give up, the "Erlang is a implementation of the > Actor model" meme seems to be stronger than unimportant details than > semantics. When people talk about Erlang and actors I look at them funny. Not because of what you said, how Erlang isn't actors, but because that's completely missing the point of Erlang. The beauty of the Erlang processes is that they were made for achieving fault tolerance. It is this particular aspect that make them incredibly good: you can focus on the happy path, "let it crash", keeping the code very tidy; you can detect failure and recover from it automatically, allowing you to sleep at night; and you don't have to deal with broken state. For me Erlang is first fault tolerant, then concurrent, then functional, yet for many people it seems to be the opposite order. I personally care very little about Erlang being functional (though I do care a great deal about immutability and pattern matching being the default behavior, the rest not so much), and the concurrency is nice but only because it enables all the fault tolerance features of the language. -- Lo?c Hoguin http://ninenines.eu From mfidelman@REDACTED Tue Jun 24 21:49:59 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 24 Jun 2014 15:49:59 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53A9D309.2070505@ninenines.eu> References: <1541116.OTeGbQ0VmZ@jalapeno> <53A63A50.5070205@meetinghouse.net> <2435915.1FFjRGMdE2@jalapeno> <53A8A6C4.2010005@meetinghouse.net> <53A9D309.2070505@ninenines.eu> Message-ID: <53A9D667.6000706@meetinghouse.net> Lo?c Hoguin wrote: > On 06/24/2014 01:54 PM, Peer Stritzinger wrote: >> But I should probably give up, the "Erlang is a implementation of the >> Actor model" meme seems to be stronger than unimportant details than >> semantics. > > When people talk about Erlang and actors I look at them funny. Not > because of what you said, how Erlang isn't actors, but because that's > completely missing the point of Erlang. > > The beauty of the Erlang processes is that they were made for > achieving fault tolerance. It is this particular aspect that make them > incredibly good: you can focus on the happy path, "let it crash", > keeping the code very tidy; you can detect failure and recover from it > automatically, allowing you to sleep at night; and you don't have to > deal with broken state. > > For me Erlang is first fault tolerant, then concurrent, then > functional, yet for many people it seems to be the opposite order. I > personally care very little about Erlang being functional (though I do > care a great deal about immutability and pattern matching being the > default behavior, the rest not so much), and the concurrency is nice > but only because it enables all the fault tolerance features of the > language. > Interesting - because what I find most compelling is the concurrency. Perhaps, this is because I came to Erlang with a background in two areas that emphasize concurrent thinking - networking and simulation. In the first, things tend to be easy - new connection, span a process for the duration. For simulation, though, the paradigm is often "an object per simulated entity - with spaghetti coded execution pathways that run every second." Erlang provides a run-time environment that's much better for thinking about inherently concurrent problems. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From zxq9@REDACTED Tue Jun 24 22:44:48 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 25 Jun 2014 05:44:48 +0900 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53A9D667.6000706@meetinghouse.net> References: <53A9D309.2070505@ninenines.eu> <53A9D667.6000706@meetinghouse.net> Message-ID: <8461511.kg6Qc7HA17@jalapeno> On Tuesday 24 June 2014 15:49:59 Miles Fidelman wrote: > Lo?c Hoguin wrote: > > On 06/24/2014 01:54 PM, Peer Stritzinger wrote: > >> But I should probably give up, the "Erlang is a implementation of the > >> Actor model" meme seems to be stronger than unimportant details than > >> semantics. > > > > When people talk about Erlang and actors I look at them funny. Not > > because of what you said, how Erlang isn't actors, but because that's > > completely missing the point of Erlang. > > > > The beauty of the Erlang processes is that they were made for > > achieving fault tolerance. It is this particular aspect that make them > > incredibly good: you can focus on the happy path, "let it crash", > > keeping the code very tidy; you can detect failure and recover from it > > automatically, allowing you to sleep at night; and you don't have to > > deal with broken state. > > > > For me Erlang is first fault tolerant, then concurrent, then > > functional, yet for many people it seems to be the opposite order. I > > personally care very little about Erlang being functional (though I do > > care a great deal about immutability and pattern matching being the > > default behavior, the rest not so much), and the concurrency is nice > > but only because it enables all the fault tolerance features of the > > language. > > Interesting - because what I find most compelling is the concurrency. > Perhaps, this is because I came to Erlang with a background in two areas > that emphasize concurrent thinking - networking and simulation. In the > first, things tend to be easy - new connection, span a process for the > duration. For simulation, though, the paradigm is often "an object per > simulated entity - with spaghetti coded execution pathways that run > every second." Erlang provides a run-time environment that's much > better for thinking about inherently concurrent problems. I think the more important aspect here being that its very hard to be happy with concurrency in a world where you have to handle every combination of message*state, and that means fault tolerance is a neccessary component of any environment where one can happily build large concurrent systems. In particular, any large system is non-trivial, and concurrency itself is non- trivial. Without fault-tolerance you wind up with an explosively complex fault situation to handle. Since we're hoppping down the semantic rabbit-hole in this discussion already, I suppose its worth mentioning that the term "fault-tolerance" in this context is outlined by the idea that an asynchronous message-stew requires a program to be capable of reasonable behavior when unexpected messages are received, and that this should not mandate the programmer write a special case for every combination that might occur along the message*state matrix. Not every definition of "fault-tolerance" carries this meaning. Come to think of it, I don't think it would be very easy to apply Erlang's concept of fault-tolerance without pattern matching as a central feature in many areas of the language. I could be wrong, I'm just trying to imagine an alternative without pattern matching -- and I don't see any alternative than to emulate it with exclusive guards or something (which still equates to pattern-matching, just less easy to read), which in the extreme case is almost as bad as the common practice in some languages of actually enumerating every negative case -- which usually vastly outnumber the positive cases -- and providing an exception handler for each. I recall a talk Ulf Wiger gave a while back about something like this. Along the lines of how its easy to drown in an ocean of incidental complexity in large concurrent systems, and "large" doesn't have to be very big. Actually, he gave examples in Erlang of how you can even drown in Erlang, so its not just language-specific, it was more a structural issue. (Now I want to go back and find that again...) My point is that its hard to have concurrency without fault-tolerance, fault- tolerance only means what we think it means in a concurrent environment, and both are much easier to think about in a functional, immutable world (with assignment meaning labels, not variable storage). So each of these three points is hard to assign a priority, regardless what feature we personally think of as most important. -Craig From mfidelman@REDACTED Tue Jun 24 23:05:21 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 24 Jun 2014 17:05:21 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <8461511.kg6Qc7HA17@jalapeno> References: <53A9D309.2070505@ninenines.eu> <53A9D667.6000706@meetinghouse.net> <8461511.kg6Qc7HA17@jalapeno> Message-ID: <53A9E811.2000302@meetinghouse.net> zxq9 wrote: > I think the more important aspect here being that its very hard to be happy > with concurrency in a world where you have to handle every combination of > message*state, and that means fault tolerance is a neccessary component of any > environment where one can happily build large concurrent systems. In > particular, any large system is non-trivial, and concurrency itself is non- > trivial. Without fault-tolerance you wind up with an explosively complex fault > situation to handle. > > > Come to think of it, I don't think it would be very easy to apply Erlang's > concept of fault-tolerance without pattern matching as a central feature in > many areas of the language. I could be wrong, I'm just trying to imagine an > alternative without pattern matching -- and I don't see any alternative than > to emulate it with exclusive guards or something (which still equates to > pattern-matching, just less easy to read), which in the extreme case is almost > as bad as the common practice in some languages of actually enumerating every > negative case -- which usually vastly outnumber the positive cases -- and > providing an exception handler for each. Well, falling further down the rabbit hole .... I kind of agree with you that massive concurrency and fault-tolerance go hand-in-hand. On the other hand, I kind of see pattern matching as more associated with message-oriented communication: Somehow I don't see doing a lot of message selection and processing without pattern matching at the front end. Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rvirding@REDACTED Wed Jun 25 00:09:35 2014 From: rvirding@REDACTED (Robert Virding) Date: Wed, 25 Jun 2014 00:09:35 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53A9E811.2000302@meetinghouse.net> References: <53A9D309.2070505@ninenines.eu> <53A9D667.6000706@meetinghouse.net> <8461511.kg6Qc7HA17@jalapeno> <53A9E811.2000302@meetinghouse.net> Message-ID: I think it is very lucky that we weren't interested in, or worried about, the theoretical aspects, or that we had heard about the actor model. If we had we would probably still be discussing whether we were doing the actor model and which parts of it, or where we differed and how important that was? Or should we differ and maybe we should drop the differences to we would comply, etc ... :-) We were trying to solve *THE* problem and this was the best solution we could come with. It was purely pragmatic. We definitely took ideas from other inputs but not from the Actor model. Robert On 24 June 2014 23:05, Miles Fidelman wrote: > zxq9 wrote: > > I think the more important aspect here being that its very hard to be >> happy >> with concurrency in a world where you have to handle every combination of >> message*state, and that means fault tolerance is a neccessary component >> of any >> environment where one can happily build large concurrent systems. In >> particular, any large system is non-trivial, and concurrency itself is >> non- >> trivial. Without fault-tolerance you wind up with an explosively complex >> fault >> situation to handle. >> >> >> Come to think of it, I don't think it would be very easy to apply Erlang's >> concept of fault-tolerance without pattern matching as a central feature >> in >> many areas of the language. I could be wrong, I'm just trying to imagine >> an >> alternative without pattern matching -- and I don't see any alternative >> than >> to emulate it with exclusive guards or something (which still equates to >> pattern-matching, just less easy to read), which in the extreme case is >> almost >> as bad as the common practice in some languages of actually enumerating >> every >> negative case -- which usually vastly outnumber the positive cases -- and >> providing an exception handler for each. >> > > > Well, falling further down the rabbit hole .... > > I kind of agree with you that massive concurrency and fault-tolerance go > hand-in-hand. > > On the other hand, I kind of see pattern matching as more associated with > message-oriented communication: Somehow I don't see doing a lot of message > selection and processing without pattern matching at the front end. > > Cheers, > > Miles > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Wed Jun 25 01:50:15 2014 From: g@REDACTED (Garrett Smith) Date: Tue, 24 Jun 2014 18:50:15 -0500 Subject: [erlang-questions] Chicago Erlang User Group this Thurs Message-ID: If anyone's in the Chicago area this Thursday and lamenting the fact there's just no Erlang events to go that night, I have some *great* news! http://www.meetup.com/ErlangChicago/events/190292312/ And if you know someone who might be lamenting, tell them! Garrett From kostis@REDACTED Wed Jun 25 02:13:09 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 25 Jun 2014 02:13:09 +0200 Subject: [erlang-questions] Dialyzer: Unknown functions In-Reply-To: References: Message-ID: <53AA1415.4080201@cs.ntua.gr> [ASIDE: Please do not reply with top postings.] On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote: > Hi. > > I'm applying dialyzer to my project and still have a bunch of warnings > whose origin I can't seem to figure out. > > Unknown functions: > cover:compile_beam/1 > cover:compile_beam/2 > cover:compile_module/2 > cover:export/2 > cover:get_term/1 > cover:import/1 > cover:is_compiled/1 > cover:module_info/1 > cover:write/2 > eprof:analyze/1 > eprof:log/1 > eprof:start/0 > eprof:start_profiling/1 > eprof:stop_profiling/0 > packages:last/1 > packages:strip_last/1 > xref:add_application/3 > xref:analyze/2 > xref:set_default/3 > xref:set_library_path/2 > xref:start/2 > xref:stop/1 > Unknown types: > ... > > I'm using the following to generate the PLT: > > dialyzer --build_plt --verbose --statistics -Wunmatched_returns > -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs > -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel > public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit > gs mnesia -I include > > Does anybody know how to solve this (I don't want to ignore the > warnings) or could probably point me in the right direction so that I > can figure it out? There are various issues in what you do. First of all, you have to understand what a PLT is. It stands for Persistent Lookup Table and is a file that is used to cache information about functions (mainly their types) you do not want to analyze again and again. In most cases, these are Erlang/OTP libraries and other applications that your application depends on but you take "as is" (i.e. you do not control or can modify them). So this PLT you ideally build only once and forget about it until you update your Erlang/OTP. It typically does not make much sense to add -W* (warning) options when you build this PLT. Remember that this is the part of the code that you do not control or intend to modify. So asking dialyzer for the warnings of this code base might indeed give you some information about its quality but will not improve the quality of your PLT. So in your case I would start with a command of the form: dialyzer --build_plt -r deps --apps erts kernel stdlib (Add --statistics to the above for more information about the size of the analyzed code and the time of the main passes of Dialyzer if you are interested in seeing this.) This will build a PLT. What _can_ improve the PLT's quality is to pay attention whether there are any _important_ unknown functions, and this is why dialyzer informs you about them. Note that these are not warnings, but instead just an indication that the information that the analysis has computed may not be as strong as it would have been if you supplied the analysis with the missing functions/modules. So, you probably want to also include these modules in your PLT. Note that you do not have to rebuild one from scratch. Dialyzer will incrementally refine the analysis results if you supply the missing modules/libraries: dialyzer --add_to_plt path/to/missing_module.beam Now, having built a PLT that you are happy with, you can now analyze your own code: dialyzer -r ebin -Wunmatched_returns ... perhaps other -W options here and keep doing only this step from now on. Hope this helps, Kostis From rmcl2303@REDACTED Wed Jun 25 03:11:44 2014 From: rmcl2303@REDACTED (Richard McLean) Date: Wed, 25 Jun 2014 11:11:44 +1000 Subject: [erlang-questions] matching Rest/binary using bit syntax - why does it have to be the last element specified if all other elements are sized ? Message-ID: <3FBAF25A-F91F-4331-A9A8-3E3E54043D4C@bigpond.net.au> This is my first question to the mailing list so apologies if there are any newbie errors. Regarding bit syntax and pattern matching, you can match the remaining part of the binary using the Rest/binary idiom as long as the element of unspecified size (ie Rest/binary) is at the end of the pattern (ie. the very last specified element)... eg. suppose I have a binary of unknown size (here I'm using <<1,2,3,4>> as the example) and I want to separate it into 2 binaries - one containing the first 8 bits, and the other containing the remainder... eg. 1> BinA = <<1,2,3,4>>. <<1,2,3,4>> 2> <> = BinA. <<1,2,3,4>> 3> BinB. <<1>> 4> BinC. <<2,3,4>> So far so good... Now suppose I want to take the same input binary (of unknown size) and this time I want to separate it into 2 binaries - one containing the LAST 24 bits (say some sort of footer), and the other containing the remainder (ie all the PRECEDING data)... This should still be possible from the the compiler/erlang VM point of view as we are still specifying all the element sizes except one, but erlang generates an error if the binary element of unspecified size is anything but the last match element. eg. 1> BinA = <<1,2,3,4>>. <<1,2,3,4>> 2> <> = BinA. * 1: a binary field without size is only allowed at the end of a binary pattern What is the easiest way to achieve this sort of thing ? I'm supposing the binary could be reversed, the front X bits extracted, then reversing the extracted binary and the remainder, but is there an easier way ? And if there are any of the erlang maintainers reading this, would it be possible in a future release to change the rules on the Rest/binary idiom to allow Rest/binary to be any element of the match pattern as long as all other elements are size specified ? I don't think it would be a big change to the implement but perhaps there are hidden gotchas I'm not considering ? Regards Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Jun 25 08:37:17 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 25 Jun 2014 09:37:17 +0300 Subject: [erlang-questions] matching Rest/binary using bit syntax - why does it have to be the last element specified if all other elements are sized ? In-Reply-To: <3FBAF25A-F91F-4331-A9A8-3E3E54043D4C@bigpond.net.au> References: <3FBAF25A-F91F-4331-A9A8-3E3E54043D4C@bigpond.net.au> Message-ID: Hello, Here is one way to make it: Head = byte_size(BinC) * 8 - 24. <> = BinC. The reverse operation for binary is expensive. Best Regards, Dmitry >-|-|-(*> > On 25.6.2014, at 4.11, Richard McLean wrote: > > This is my first question to the mailing list so apologies if there are any newbie errors. > > Regarding bit syntax and pattern matching, you can match the remaining part of the binary using the Rest/binary idiom as long as the element of unspecified size (ie Rest/binary) is at the end of the pattern (ie. the very last specified element)... > > eg. suppose I have a binary of unknown size (here I'm using <<1,2,3,4>> as the example) and I want to separate it into 2 binaries - one containing the first 8 bits, and the other containing the remainder... > > eg. > 1> BinA = <<1,2,3,4>>. > <<1,2,3,4>> > 2> <> = BinA. > <<1,2,3,4>> > 3> BinB. > <<1>> > 4> BinC. > <<2,3,4>> > > So far so good... > > Now suppose I want to take the same input binary (of unknown size) and this time I want to separate it into 2 binaries - one containing the LAST 24 bits (say some sort of footer), and the other containing the remainder (ie all the PRECEDING data)... > > This should still be possible from the the compiler/erlang VM point of view as we are still specifying all the element sizes except one, but erlang generates an error if the binary element of unspecified size is anything but the last match element. > > eg. > 1> BinA = <<1,2,3,4>>. > <<1,2,3,4>> > 2> <> = BinA. > * 1: a binary field without size is only allowed at the end of a binary pattern > > What is the easiest way to achieve this sort of thing ? > I'm supposing the binary could be reversed, the front X bits extracted, then reversing the extracted binary and the remainder, but is there an easier way ? > > And if there are any of the erlang maintainers reading this, would it be possible in a future release to change the rules on the Rest/binary idiom to allow Rest/binary to be any element of the match pattern as long as all other elements are size specified ? > > I don't think it would be a big change to the implement but perhaps there are hidden gotchas I'm not considering ? > > Regards > > Richard > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Wed Jun 25 09:37:08 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 25 Jun 2014 07:37:08 +0000 (UTC) Subject: [erlang-questions] matching Rest/binary using bit syntax - why does it have to be the last element specified if all other elements are sized ? In-Reply-To: References: <3FBAF25A-F91F-4331-A9A8-3E3E54043D4C@bigpond.net.au> Message-ID: <635810529.61477.1403681828225.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > Hello, > > Here is one way to make it: > > Head = byte_size(BinC) * 8 - 24. > <> = BinC. > > The reverse operation for binary is expensive. As you demonstrated, no reverse operation is needed. The compiler could actually be smart enough to generate above code by itself when given a match like: <> = BinC Even having the variable length part (as long as there is only one) somewhere in the middle, would still allow the compiler to construct the expression. Things would become a bit more complicated in case or guard matches. Question to experts of the Erlang internals: Is there a non trivial reason the compiler/runtime system can't handle such matches? Regards Andreas > > Best Regards, > Dmitry >-|-|-(*> > > > On 25.6.2014, at 4.11, Richard McLean < rmcl2303@REDACTED > wrote: > > > > > This is my first question to the mailing list so apologies if there are any > newbie errors. > > Regarding bit syntax and pattern matching, you can match the remaining part > of the binary using the Rest/binary idiom as long as the element of > unspecified size (ie Rest/binary) is at the end of the pattern (ie. the very > last specified element)... > > eg. suppose I have a binary of unknown size (here I'm using <<1,2,3,4>> as > the example) and I want to separate it into 2 binaries - one containing the > first 8 bits, and the other containing the remainder... > > eg. > 1> BinA = <<1,2,3,4>>. > <<1,2,3,4>> > 2> <> = BinA. > <<1,2,3,4>> > 3> BinB. > <<1>> > 4> BinC. > <<2,3,4>> > > So far so good... > > Now suppose I want to take the same input binary (of unknown size) and this > time I want to separate it into 2 binaries - one containing the LAST 24 bits > (say some sort of footer), and the other containing the remainder (ie all > the PRECEDING data)... > > This should still be possible from the the compiler/erlang VM point of view > as we are still specifying all the element sizes except one, but erlang > generates an error if the binary element of unspecified size is anything but > the last match element. > > eg. > 1> BinA = <<1,2,3,4>>. > <<1,2,3,4>> > 2> <> = BinA. > * 1: a binary field without size is only allowed at the end of a binary > pattern > > What is the easiest way to achieve this sort of thing ? > I'm supposing the binary could be reversed, the front X bits extracted, then > reversing the extracted binary and the remainder, but is there an easier way > ? > > And if there are any of the erlang maintainers reading this, would it be > possible in a future release to change the rules on the Rest/binary idiom to > allow Rest/binary to be any element of the match pattern as long as all > other elements are size specified ? > > I don't think it would be a big change to the implement but perhaps there are > hidden gotchas I'm not considering ? > > Regards > > Richard > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From kenji@REDACTED Wed Jun 25 11:18:07 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Wed, 25 Jun 2014 18:18:07 +0900 Subject: [erlang-questions] Erlang filtering RARPs? In-Reply-To: References: Message-ID: <20140625091807.GA26181@k2r.org> I'm not really familiar with Linux, but I guess it's not a procket issue but Linux kernel issue. The packet(7) man entry in http://linux.die.net/man/7/packet says you need to specify a link-level protocol when calling socket() as: packet_socket = socket(PF_PACKET, int socket_type, int protocol); where the protocol number listed in as: #define ETH_P_RARP 0x8035 /* Reverse Addr Res packet */ You need to use ETH_P_ALL to check out all types of the packets. See Erlang source file erts/emulator/drivers/common/inet_drv.c for the further details. I've found no ETH_P_* stuff defined in OTP-17.0 source in GitHub. Kenji Rikitake ++> Ken Hirata [2014-06-23 19:31:36 -0700]: > Date: Mon, 23 Jun 2014 19:31:36 -0700 > From: Ken Hirata > To: erlang-questions@REDACTED > Subject: [erlang-questions] Erlang filtering RARPs? > > I can't seem to receive RARPs within an Erlang application using procket. > > I can see RARPs on a tcpdump trace running within Ubuntu Linux when the > Erlang shell isn't executing. RARPs are not recorded once I execute erl. > > The RARPs contain the Ethernet source MAC address in the RARP Sender and > Target MAC address fields. > > Does invoking Erlang initialize the OS network stack so that RARPs are > discarded? If so, are there any configuration parameters to change the > behavior? > > - Ken > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kenji@REDACTED Wed Jun 25 11:30:43 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Wed, 25 Jun 2014 18:30:43 +0900 Subject: [erlang-questions] Erlang filtering RARPs? In-Reply-To: <20140625091807.GA26181@k2r.org> References: <20140625091807.GA26181@k2r.org> Message-ID: <20140625093042.GA2215@k2r.org> It seems the default type of procket's packet:socket/0 is ETH_P_IP. You can specify another protocol type in packet:socket/1. See https://github.com/msantos/procket/blob/master/src/packet.erl#L59 and https://github.com/msantos/procket/blob/master/include/packet.hrl#L55 Kenji Rikitake ++> Kenji Rikitake [2014-06-25 18:18:07 +0900]: > Date: Wed, 25 Jun 2014 18:18:07 +0900 > From: Kenji Rikitake > To: Ken Hirata > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Erlang filtering RARPs? > > I'm not really familiar with Linux, but I guess it's not a procket issue > but Linux kernel issue. > > The packet(7) man entry in > http://linux.die.net/man/7/packet > says you need to specify a link-level protocol > when calling socket() as: > > packet_socket = socket(PF_PACKET, int socket_type, int protocol); > > where the protocol number listed in as: > > #define ETH_P_RARP 0x8035 /* Reverse Addr Res packet */ > > You need to use ETH_P_ALL to check out all types of the packets. > > See Erlang source file erts/emulator/drivers/common/inet_drv.c for the > further details. I've found no ETH_P_* stuff defined in OTP-17.0 source > in GitHub. > > Kenji Rikitake > > ++> Ken Hirata [2014-06-23 19:31:36 -0700]: > > Date: Mon, 23 Jun 2014 19:31:36 -0700 > > From: Ken Hirata > > To: erlang-questions@REDACTED > > Subject: [erlang-questions] Erlang filtering RARPs? > > > > I can't seem to receive RARPs within an Erlang application using procket. > > > > I can see RARPs on a tcpdump trace running within Ubuntu Linux when the > > Erlang shell isn't executing. RARPs are not recorded once I execute erl. > > > > The RARPs contain the Ethernet source MAC address in the RARP Sender and > > Target MAC address fields. > > > > Does invoking Erlang initialize the OS network stack so that RARPs are > > discarded? If so, are there any configuration parameters to change the > > behavior? > > > > - Ken > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Wed Jun 25 13:05:39 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 25 Jun 2014 13:05:39 +0200 Subject: [erlang-questions] raw_read_file_info Message-ID: <53AAAD03.5000308@ninenines.eu> Hello, The file.erl module contains: 392 %% Obsolete, undocumented, local node only, don't use!. 393 %% XXX to be removed. 394 raw_read_file_info(Name) -> 395 Args = [file_name(Name)], 396 case check_args(Args) of 397 ok -> 398 [FileName] = Args, 399 ?PRIM_FILE:read_file_info(FileName); 400 Error -> 401 Error 402 end. 403 404 %% Obsolete, undocumented, local node only, don't use!. 405 %% XXX to be removed. 406 raw_write_file_info(Name, #file_info{} = Info) -> 407 Args = [file_name(Name)], 408 case check_args(Args) of 409 ok -> 410 [FileName] = Args, 411 ?PRIM_FILE:write_file_info(FileName, Info); 412 Error -> 413 Error 414 end. Why obsolete, undocumented, and don't use? I really could use that in Cowboy, because we always serve local files, and going through the file server is a pretty big bottleneck. In general I think that all operations that go through a central server "for distributed reasons" should have their local equivalent, for when you know that's what you need. (And that beats calling prim_file and others directly...) -- Lo?c Hoguin http://ninenines.eu From m3oucat@REDACTED Wed Jun 25 11:18:20 2014 From: m3oucat@REDACTED (ami) Date: Wed, 25 Jun 2014 12:18:20 +0300 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? Message-ID: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Hi all, I decided to understand how Erlang works from inside. Probably I?ll even become a contributor(I hope). I started with forking https://github.com/erlang/otp, then cloning it to my local copy. And it?s quite big. And not only big, there are both C and Erlang sources: 1s-MacBook-Pro:otp a1$ find . -name '*.erl' | wc -l 3650 1s-MacBook-Pro:otp a1$ find . -name '*.c' | wc -l 547 I would say, Erlang sources mostly. Here?s my question. Which IDEs do you use to treat all the source tree(both Erlang & C) as a single project? I might use one IDE for C and another for Erlang. But it?s quite ugly and inconvenient. Though, I?m not the very first person who decided to contribute to Erlang/OTP :) So, I think, that somebody already faced with these questions. If you use some * special-designed IDEs(preferably), BTW, do they exist in nature? * emacs plugins(less preferably) or * vim plugins, please share links, configs, etc. The most needed features are: * go to declaration * code completion * easy navigation through the code Thanks in advance, Alexander From dmkolesnikov@REDACTED Wed Jun 25 13:25:20 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 25 Jun 2014 14:25:20 +0300 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: <0389F710-6C87-4DD7-BFDC-D9854ADCE1A3@gmail.com> Hello, I am using Sublime Text + command line to build. - Dmitry On 25 Jun 2014, at 12:18, ami wrote: > Hi all, > > I decided to understand how Erlang works from inside. > Probably I?ll even become a contributor(I hope). > > I started with forking https://github.com/erlang/otp, then cloning it to my local copy. > And it?s quite big. And not only big, there are both C and Erlang sources: > > 1s-MacBook-Pro:otp a1$ find . -name '*.erl' | wc -l > 3650 > 1s-MacBook-Pro:otp a1$ find . -name '*.c' | wc -l > 547 > > I would say, Erlang sources mostly. > > Here?s my question. > > Which IDEs do you use to treat all the source tree(both Erlang & C) as a single project? > I might use one IDE for C and another for Erlang. But it?s quite ugly and inconvenient. > > Though, I?m not the very first person who decided to contribute to Erlang/OTP :) > So, I think, that somebody already faced with these questions. > > If you use some > * special-designed IDEs(preferably), BTW, do they exist in nature? > * emacs plugins(less preferably) or > * vim plugins, > > please share links, configs, etc. > > The most needed features are: > * go to declaration > * code completion > * easy navigation through the code > > > Thanks in advance, > > Alexander > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Wed Jun 25 13:26:21 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 25 Jun 2014 15:26:21 +0400 Subject: [erlang-questions] raw_read_file_info In-Reply-To: <53AAAD03.5000308@ninenines.eu> References: <53AAAD03.5000308@ninenines.eu> Message-ID: Yes, really. Flussonic is using prim_file directly almost everywhere, because using central file server doesn't allow to scale. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Wed Jun 25 14:36:38 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 25 Jun 2014 21:36:38 +0900 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53A9E811.2000302@meetinghouse.net> References: <8461511.kg6Qc7HA17@jalapeno> <53A9E811.2000302@meetinghouse.net> Message-ID: <1808157.C8ub9aU8BK@jalapeno> On Tuesday 24 June 2014 17:05:21 Miles Fidelman wrote: > zxq9 wrote: > > I think the more important aspect here being that its very hard to be > > happy > > with concurrency in a world where you have to handle every combination of > > message*state, and that means fault tolerance is a neccessary component of > > any environment where one can happily build large concurrent systems. In > > particular, any large system is non-trivial, and concurrency itself is > > non- trivial. Without fault-tolerance you wind up with an explosively > > complex fault situation to handle. > > > > > > Come to think of it, I don't think it would be very easy to apply Erlang's > > concept of fault-tolerance without pattern matching as a central feature > > in > > many areas of the language. I could be wrong, I'm just trying to imagine > > an > > alternative without pattern matching -- and I don't see any alternative > > than to emulate it with exclusive guards or something (which still > > equates to pattern-matching, just less easy to read), which in the > > extreme case is almost as bad as the common practice in some languages of > > actually enumerating every negative case -- which usually vastly > > outnumber the positive cases -- and providing an exception handler for > > each. > > > > Well, falling further down the rabbit hole .... > > I kind of agree with you that massive concurrency and fault-tolerance go > hand-in-hand. > > On the other hand, I kind of see pattern matching as more associated > with message-oriented communication: Somehow I don't see doing a lot of > message selection and processing without pattern matching at the front end. I believe message passing is going to be a necessary part of any massively concurrent system (otherwise it couldn't get very massive...). In other words, I not only agree with you, I think this is not even "on the other hand" -- you're identifying another part that is central to Erlang having done things right. Without message passing a system would, at the very least, require an API to emulate the act of message passing (and so what's the difference?). Its also interesting that this is what Schemers mean when they say "message passing" but not what Java-like OOP means by it (and its not shades of gray -- message passing is not RPC, though it may support it). Consider what happens with "web APIs": in a race to avoid inventing a protocol by using HTTP folks are constantly re-inventing protocols in a drastically limited semantic space (within URL-safe strings) -- an advanced form of missing the point while message passing. From zxq9@REDACTED Wed Jun 25 14:38:47 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 25 Jun 2014 21:38:47 +0900 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> Message-ID: <2452064.4BLlgzMsyl@jalapeno> On Wednesday 25 June 2014 00:09:35 Robert Virding wrote: > I think it is very lucky that we weren't interested in, or worried about, > the theoretical aspects, or that we had heard about the actor model. If we > had we would probably still be discussing whether we were doing the actor > model and which parts of it, or where we differed and how important that > was? Or should we differ and maybe we should drop the differences to we > would comply, etc ... :-) > > We were trying to solve *THE* problem and this was the best solution we > could come with. It was purely pragmatic. We definitely took ideas from > other inputs but not from the Actor model. Its an illustrative lesson in how to avoid slaving away at the Ivory Tower only to have a Turing tarpit to show for it. From paulo.ferraz.oliveira@REDACTED Wed Jun 25 15:34:28 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Wed, 25 Jun 2014 14:34:28 +0100 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: On 25 June 2014 10:18, ami wrote: > > (...) > Which IDEs do you use to treat all the source tree(both Erlang & C) as a > single project? > (...) > The most needed features are: > * go to declaration > Check 3. below. > * code completion > Check 1. below. > * easy navigation through the code > I'm using Sublime Text for development and bash for the other stuff (compiler, dialyzer, eunit, etc.). There's also a nice (albeit I think not maintained at the moment - updated 1 year ago) Sublime Text plugin called SublimErl ( https://github.com/ostinelli/SublimErl) that introduces: 1. auto-completion (mostly satisfying, but with a few minor issues - sometimes doesn't find a function) 2. auto-indentation: which I don't use 3. quick goto functions: it's buggy at the moment, but it least it opens the file it's supposed to (only doesn't target the line correctly) 4. auto-compilation, upon saving: which is a very nice feature as it shows you a console with errors, if any (I'm using it along erlc's warn_missing_spec, so that way I keep everything -spec'ed all the time) Hope it helps. - Paulo F. Oliveira -------------- next part -------------- An HTML attachment was scrubbed... URL: From nx@REDACTED Wed Jun 25 15:38:25 2014 From: nx@REDACTED (nx) Date: Wed, 25 Jun 2014 09:38:25 -0400 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: I use vim without plugins. I use sync and relx with the devmode option (relx -d) profusely during development. sync: https://github.com/rustyio/sync relx: https://github.com/erlware/relx On Wed, Jun 25, 2014 at 9:34 AM, Paulo F. Oliveira wrote: > On 25 June 2014 10:18, ami wrote: >> >> (...) >> >> Which IDEs do you use to treat all the source tree(both Erlang & C) as a >> single project? >> (...) >> >> The most needed features are: >> * go to declaration > > > Check 3. below. > >> >> * code completion > > > Check 1. below. > >> >> * easy navigation through the code > > > I'm using Sublime Text for development and bash for the other stuff > (compiler, dialyzer, eunit, etc.). > > There's also a nice (albeit I think not maintained at the moment - updated 1 > year ago) Sublime Text plugin called SublimErl > (https://github.com/ostinelli/SublimErl) that introduces: > > 1. auto-completion (mostly satisfying, but with a few minor issues - > sometimes doesn't find a function) > > 2. auto-indentation: which I don't use > > 3. quick goto functions: it's buggy at the moment, but it least it opens the > file it's supposed to (only doesn't target the line correctly) > > 4. auto-compilation, upon saving: which is a very nice feature as it shows > you a console with errors, if any (I'm using it along erlc's > warn_missing_spec, so that way I keep everything -spec'ed all the time) > > Hope it helps. > > - Paulo F. Oliveira > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From paulo.ferraz.oliveira@REDACTED Wed Jun 25 16:04:27 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Wed, 25 Jun 2014 15:04:27 +0100 Subject: [erlang-questions] Documentation for list_to_binary Message-ID: Hi. Using Google to search for "erlang list_to_binary" the first result I get is http://www.erlang.org/doc/man/erlang.html, which states, in the Description "The module erlang is moved to the runtime system application. Please see erlang(3) in the erts reference manual instead." The link presented by erlang(3) points to the same page. Is this normal? Thanks. Cheers. - Paulo F. Oliveira From mfidelman@REDACTED Wed Jun 25 17:20:09 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 25 Jun 2014 11:20:09 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <2452064.4BLlgzMsyl@jalapeno> References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> Message-ID: <53AAE8A9.3020109@meetinghouse.net> > On Wednesday 25 June 2014 00:09:35 Robert Virding wrote: >> I think it is very lucky that we weren't interested in, or worried about, >> the theoretical aspects, or that we had heard about the actor model. If we >> had we would probably still be discussing whether we were doing the actor >> model and which parts of it, or where we differed and how important that >> was? Or should we differ and maybe we should drop the differences to we >> would comply, etc ... :-) >> >> We were trying to solve *THE* problem and this was the best solution we >> could come with. It was purely pragmatic. We definitely took ideas from >> other inputs but not from the Actor model. > Robert, I know it's probably documented somewhere, but... 1. what do (did) you see as "*THE* problem" you were trying to solve at the time 2. what sources DID you draw from (other than the predecessor languages at Ericsson), are there any that you'd consider primary influences? Thanks! Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From kenneth.lundin@REDACTED Wed Jun 25 17:29:50 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 25 Jun 2014 17:29:50 +0200 Subject: [erlang-questions] [ANN] Erlang/OTP 17.1 has been released Message-ID: Erlang/OTP 17.1 has been released. Erlang/OTP 17.1 is a service release on the 17 track with mostly bug fixes, but is does contain a number of new features and characteristics improvements as well. Some highlights of the release are: - crypto: Add aes_cfb8 cypher to crypto:block_encrypt and block_decrypt. - diameter: Add result code counters for CEA, DWA, and DPA. - erts: The following built in functions in the erlang and binary modules now bump an appropriate amount of reductions and yield when out of reductions: binary_to_list/1, binary_to_list/3, bitstring_to_list/1, list_to_binary/1, iolist_to_binary/1, list_to_bitstring/1, binary:list_to_bin/1 - hipe: Handle Maps instructions get_map_elements, put_map_assoc, put_map_exact in the HiPE native code compiler. - mnesia: The time for inserting locks for a transaction with large number of locks is reduced significantly. - ssh: Option max_sessions added to ssh:daemon/{2,3}. - stdlib: Add maps:get/3 to maps module. The function will return the supplied default value if the key does not exist in the map. Many thanks to 24 different contributors in this release You can find the README file with more detailed info at http://www.erlang.org/download/otp_src_17.1.readme You can download the full source distribution from http://www.erlang.org/download/otp_src_17.1.tar.gz Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions please read the README that is part of the distribution. You can also find this release at the official Erlang/OTP Git-repository at Github here: https://github.com/erlang/otp tagged "OTP-17.1" The Windows binary distribution can be downloaded from http://www.erlang.org/download/otp_win32_17.1.exe http://www.erlang.org/download/otp_win64_17.1.exe You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_doc_html_17.1.tar.gz http://www.erlang.org/download/otp_doc_man_17.1.tar.gz We also want to thank those that sent us patches, suggestions and bug reports. The Erlang/OTP Team at Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From stonecypher@REDACTED Wed Jun 25 18:20:33 2014 From: stonecypher@REDACTED (John Haugeland) Date: Wed, 25 Jun 2014 09:20:33 -0700 (PDT) Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: References: Message-ID: <3c2d68b4-6d84-479d-90cb-112f6d8da5d2@googlegroups.com> > 2. In his recent talk at EUC Garrett Smith showed us an interesting > slide[1] where Go appears to be one of the primary alternatives to Erlang, > as chosen by _Erlang programmers themselves_. To me this implies that > Erlang programmers have found in Go some of the principles Erlang builds > upon, the fact I'm going to dispute below. > The people switching from Erlang to Go weren't Erlang programmers. They were multi-language programmers who heard about Erlang from news sites and social media, and were dabbling. This is like thinking that Ruby is over because, for around a year, HN told them to switch to Twisted Python, or Go, or now Rust. Nope. People come and people Go. We had a brief wave of dilettantes from the WhatsApp sale. G'bye. Dart isn't going to kill anything either. It's a bunch of people "ooh" ing and "aah" ing at the Google name and some benchmarks that first show Go being faster than everything, and then later show Go catching up to and passing the things they previously claimed to be faster than. (And still aren't as fast as.) If it's a fun language, try it. We're in no danger though. > [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large > > So now comes the question: what do Erlang programmers think about Go > stealing some of the mindshare (and job-share) in the area of building > distributed systems? Why would if be a good option? Or not an option at > all? Just professional opinions based on your experience with Erlang please. > > Let me explain what suggests Go might be a viable alternative: > > * the slide mentioned above > * Go has been used for teaching distributed systems at the Carnegie > Mellon University since 2011. (Go 1 was release in early 2012) See this > blog from the teacher: > http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html > * increased activity on projects such as libswarm[2], libchan[3], there > are more. > > [2]: https://github.com/docker/libswarm > [3]: https://github.com/docker/libchan > > If you haven't been keeping up with Go, here's a brief overview of its > principles: > > * imperative, statically typed, garbage collected, lower level than > scripting languages, but higher level than C > * builtin concurrency with lightweight processes (called goroutines) > which are scheduled cooperatively > * single address space for all goroutines (modifying shared data is > discouraged, but possible); hence no isolation > * goroutines have no identity, communication between them is only > possible through channels; hence no ability to monitor or link to > goroutines, so no supervision > * writing to a channel is always synchronous; it is possible to make a > buffered channel, but once the buffer is full, the next goroutine trying to > write to it will block > * all errors must be handled explicitly; can be done at goroutine level > by setting up a catch-all handler. But crashing in the catch-call handler > will crash the goroutine. And crashing a goroutine crashes the whole > program. No Erlang-style "let it crash" or "let someone else handle errors" > > From this short survey Go looks more like the ultimate antagonist to > Erlang, or at least its philosophy. What could justify its being chosen as > an _alternative_ to Erlang? > > Sorry if it turned out a bit too long. Ultimately, I'm curious about the > reasons Go appears in a huge font on Garrett's slide. Also, finding out why > Go has seen a tremendous growth in just 2 years since initial stable > release and is already seen as a good fit for tasks Erlang is considered > the best tool in these circles might shed some light on which steps Erlang > community could take to increase the awareness about its merits (especially > in the light of a few recent threads on this list). > > This ended up rather convoluted, I know. If it was the wrong place to > bring up this topic, I apologize. Feel free to ignore this thread in that > case. > > Thanks for reading this far. > > -- > Best regards > Alexei Sholik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Jun 25 18:29:10 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 Jun 2014 18:29:10 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53AAE8A9.3020109@meetinghouse.net> References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> Message-ID: On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman wrote: > > On Wednesday 25 June 2014 00:09:35 Robert Virding wrote: >> >>> I think it is very lucky that we weren't interested in, or worried about, >>> the theoretical aspects, or that we had heard about the actor model. If >>> we >>> had we would probably still be discussing whether we were doing the actor >>> model and which parts of it, or where we differed and how important that >>> was? Or should we differ and maybe we should drop the differences to we >>> would comply, etc ... :-) >>> >>> We were trying to solve *THE* problem and this was the best solution we >>> could come with. It was purely pragmatic. We definitely took ideas from >>> other inputs but not from the Actor model. >>> >> >> Robert, I know it's probably documented somewhere, but... > 1. what do (did) you see as "*THE* problem" you were trying to solve at > the time > Joe here - I'll dive in with a reply: Bjarne D?ckers thesis has a good outline of the problem the thesis is here http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1957 This blog has a good summary of Bjarnes thesis http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html > 2. what sources DID you draw from (other than the predecessor languages at > Ericsson), are there any that you'd consider primary influences? > > Prolog and Smalltalk in equal measure. Pattern matching and syntax was inspired by Prolog. Messaging from Smalltalk. We took a few ideas on guarded commands from Dijkstra. The message queues were largely inspired by SDL and occam (SDL has a graphic notation very similar to selective receive) Links were invented by Mike Williams and based on the idea of a C-wire (a form of electrical circuit breaker). Cheers /Joe > Thanks! > > > Miles > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Wed Jun 25 18:42:59 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 25 Jun 2014 18:42:59 +0200 Subject: [erlang-questions] [ANN] Erlang/OTP 17.1 has been released In-Reply-To: References: Message-ID: Den 25 jun 2014 17:40 skrev "Josh Adams" : > > I think at Erlang factory it was stated that maps would have good performance for a large number of keys in 17.1. I don't see it here. Did that happen? Nothing has happened with maps in that respect. At Erlang User Conference in Stockholm on June 10th I said that our plan is to support "large" maps in OTP 18 which will be released around Q2 2015. /Kenneth , Erlang/OTP Ericsson > > On Jun 25, 2014 10:30 AM, "Kenneth Lundin" wrote: >> >> Erlang/OTP 17.1 has been released. >> >> Erlang/OTP 17.1 is a service release on the 17 track with mostly bug fixes, but is does contain a number of new features and characteristics improvements as well. >> >> Some highlights of the release are: >> crypto: Add aes_cfb8 cypher to crypto:block_encrypt and block_decrypt. >> diameter: Add result code counters for CEA, DWA, and DPA. >> erts: The following built in functions in the erlang and binary modules now bump an appropriate amount >> of reductions and yield when out of reductions: >> binary_to_list/1, binary_to_list/3, bitstring_to_list/1, list_to_binary/1, >> iolist_to_binary/1, list_to_bitstring/1, binary:list_to_bin/1 >> hipe: Handle Maps instructions get_map_elements, put_map_assoc, >> put_map_exact in the HiPE native code compiler. >> mnesia: The time for inserting locks for a transaction with large >> number of locks is reduced significantly. >> ssh: Option max_sessions added to ssh:daemon/{2,3}. >> stdlib: Add maps:get/3 to maps module. The function will return the >> supplied default value if the key does not exist in the map. >> >> Many thanks to 24 different contributors in this release >> >> You can find the README file with more detailed info at http://www.erlang.org/download/otp_src_17.1.readme >> >> You can download the full source distribution from http://www.erlang.org/download/otp_src_17.1.tar.gz >> >> Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions please read the README that is part of the distribution. >> >> You can also find this release at the official Erlang/OTP Git-repository at Github here: https://github.com/erlang/otp tagged "OTP-17.1" >> >> The Windows binary distribution can be downloaded from >> >> http://www.erlang.org/download/otp_win32_17.1.exe >> >> http://www.erlang.org/download/otp_win64_17.1.exe >> >> You can also download the complete HTML documentation or the Unix manual files >> >> http://www.erlang.org/download/otp_doc_html_17.1.tar.gz >> http://www.erlang.org/download/otp_doc_man_17.1.tar.gz >> >> We also want to thank those that sent us patches, suggestions and bug reports. >> >> The Erlang/OTP Team at Ericsson >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Wed Jun 25 18:56:07 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 25 Jun 2014 12:56:07 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> Message-ID: <53AAFF27.9020300@meetinghouse.net> Joe, Thanks for the info. A bit of follow-up if I might (embedded inline): Joe Armstrong wrote: > > On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman > > wrote: > > > On Wednesday 25 June 2014 00:09:35 Robert Virding wrote: > > I think it is very lucky that we weren't interested in, or > worried about, > the theoretical aspects, or that we had heard about the > actor model. If we > had we would probably still be discussing whether we were > doing the actor > model and which parts of it, or where we differed and how > important that > was? Or should we differ and maybe we should drop the > differences to we > would comply, etc ... :-) > > We were trying to solve *THE* problem and this was the > best solution we > could come with. It was purely pragmatic. We definitely > took ideas from > other inputs but not from the Actor model. > > > Robert, I know it's probably documented somewhere, but... > 1. what do (did) you see as "*THE* problem" you were trying to > solve at the time > > > Joe here - I'll dive in with a reply: > > Bjarne D?ckers thesis has a good outline of the problem the thesis is > here http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1957 > > This blog has a good summary of Bjarnes thesis > > http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html Thanks for the pointers - and yes, the blog post is a very nice summary! Re. > 2. what sources DID you draw from (other than the predecessor > languages at Ericsson), are there any that you'd consider primary > influences? > > > Prolog and Smalltalk in equal measure. Pattern matching and syntax was > inspired by Prolog. Messaging from Smalltalk. We took a few ideas on > guarded commands from > Dijkstra. > This is mostly in the form of historical curiosity of course, but... can you say a bit more about the Smalltalk influence, and in particular, which version of Smalltalk? I ask, because: - The earlier versions of smalltalk included (at least in theory) a lot of concurrency (objects seemed a bit more like actors), whereas later versions, starting with Smalltalk-72, pretty much dropped concurrency as a focus (there was really interesting exchange with Alan Kay on this, a while back, on the fonc email list). - During that time period (very early 70s), there was a lot of cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, actor model), and Steele and Sussman (Scheme) (I'm kind of exploring Robert's statement that "I think it is very lucky that we weren't interested in, or worried about, the theoretical aspects, or that we had heard about the actor model." Particularly, in that Alan Kay cites PLANNER as a key influence on Smalltalk. I'm kind of interested in the origins and history of languages that treat processes as fundamental units of computation, vs. the object model). Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From gleber.p@REDACTED Wed Jun 25 19:13:44 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 25 Jun 2014 19:13:44 +0200 Subject: [erlang-questions] Go vs Erlang for distribution In-Reply-To: <3c2d68b4-6d84-479d-90cb-112f6d8da5d2@googlegroups.com> References: <3c2d68b4-6d84-479d-90cb-112f6d8da5d2@googlegroups.com> Message-ID: In my opinion Go is not a right tool for almost any job. It falls short in many areas: - it ignores two decades of programming languages design research - it does very poorly compared to other strongly typed statically compiled language - it has inconsistent type system - it is absurdly verbose - it's error handling is horrendous - it is not a simple nor a small language - it has too many special cases and exceptions in it's semantics - no polymorphic data types (not to mention higher kinded polymorphism) - etc. In my opinion, in almost all uses of Go I heard, I am pretty sure choosing either Erlang or Haskell would work much better. With all engineering hours which were invested in Go, world could have gotten a superb language instead of something so very mediocre. On Wed, Jun 25, 2014 at 6:20 PM, John Haugeland wrote: > >> 2. In his recent talk at EUC Garrett Smith showed us an interesting >> slide[1] where Go appears to be one of the primary alternatives to Erlang, >> as chosen by _Erlang programmers themselves_. To me this implies that Erlang >> programmers have found in Go some of the principles Erlang builds upon, the >> fact I'm going to dispute below. > > > The people switching from Erlang to Go weren't Erlang programmers. They > were multi-language programmers who heard about Erlang from news sites and > social media, and were dabbling. This is like thinking that Ruby is over > because, for around a year, HN told them to switch to Twisted Python, or Go, > or now Rust. > > Nope. People come and people Go. We had a brief wave of dilettantes from > the WhatsApp sale. G'bye. > > Dart isn't going to kill anything either. It's a bunch of people "ooh" ing > and "aah" ing at the Google name and some benchmarks that first show Go > being faster than everything, and then later show Go catching up to and > passing the things they previously claimed to be faster than. (And still > aren't as fast as.) > > If it's a fun language, try it. We're in no danger though. > > > > >> >> [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large >> >> So now comes the question: what do Erlang programmers think about Go >> stealing some of the mindshare (and job-share) in the area of building >> distributed systems? Why would if be a good option? Or not an option at all? >> Just professional opinions based on your experience with Erlang please. >> >> Let me explain what suggests Go might be a viable alternative: >> >> * the slide mentioned above >> * Go has been used for teaching distributed systems at the Carnegie >> Mellon University since 2011. (Go 1 was release in early 2012) See this blog >> from the teacher: >> http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html >> * increased activity on projects such as libswarm[2], libchan[3], there >> are more. >> >> [2]: https://github.com/docker/libswarm >> [3]: https://github.com/docker/libchan >> >> If you haven't been keeping up with Go, here's a brief overview of its >> principles: >> >> * imperative, statically typed, garbage collected, lower level than >> scripting languages, but higher level than C >> * builtin concurrency with lightweight processes (called goroutines) >> which are scheduled cooperatively >> * single address space for all goroutines (modifying shared data is >> discouraged, but possible); hence no isolation >> * goroutines have no identity, communication between them is only >> possible through channels; hence no ability to monitor or link to >> goroutines, so no supervision >> * writing to a channel is always synchronous; it is possible to make a >> buffered channel, but once the buffer is full, the next goroutine trying to >> write to it will block >> * all errors must be handled explicitly; can be done at goroutine level >> by setting up a catch-all handler. But crashing in the catch-call handler >> will crash the goroutine. And crashing a goroutine crashes the whole >> program. No Erlang-style "let it crash" or "let someone else handle errors" >> >> From this short survey Go looks more like the ultimate antagonist to >> Erlang, or at least its philosophy. What could justify its being chosen as >> an _alternative_ to Erlang? >> >> Sorry if it turned out a bit too long. Ultimately, I'm curious about the >> reasons Go appears in a huge font on Garrett's slide. Also, finding out why >> Go has seen a tremendous growth in just 2 years since initial stable release >> and is already seen as a good fit for tasks Erlang is considered the best >> tool in these circles might shed some light on which steps Erlang community >> could take to increase the awareness about its merits (especially in the >> light of a few recent threads on this list). >> >> This ended up rather convoluted, I know. If it was the wrong place to >> bring up this topic, I apologize. Feel free to ignore this thread in that >> case. >> >> Thanks for reading this far. >> >> -- >> Best regards >> Alexei Sholik > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From federico.carrone@REDACTED Wed Jun 25 19:48:17 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Wed, 25 Jun 2014 14:48:17 -0300 Subject: [erlang-questions] Dependencies, included applications and supervision Message-ID: We have been having a long discussion the previous months about included applications and supervision at our workspace. Some of us just lists the needed applications in the .app file and make sure that all necessary application are started when our application starts. For some teammates this has a big issue that: if a depencendy dies, our application's supervision tree will not know about it. They say that the system would be in an inconsistent state. So what they do is that they add the applications inside the included applications and they start the top level supervisor of each dependency inside our application supervisor tree. I do not really like this since I think that each application should be separate. I would REALLY like to know the community views and experiencies on this. Thanks in advance, Federico Carrone. -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Jun 25 20:39:06 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 25 Jun 2014 21:39:06 +0300 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: References: Message-ID: Hello Federico, I would agree with you here. Personally, I think the trick with included applications complicates design and dependencies management. Here is my view on the problem of ?dependency supervision?: A dependent application provides variour resource to parent application. Those resources are either provided using start_link semantic or open/close paradigm (e.g. sockets). The start_link dependencies are manageable using supervisor tree of parent application. For example, you application uses cache, it instantiates cache bucket using start_link within root superior. The death & recovery of cache instance is handled by root supervisor of ?parent? application. The second case is manageable in similar fashion with an exception that you have a client process that open/close and uses resource service. The failure of resource is propagated to client and it?s top supervisor. I do not see any reason why you need to implement extra supervision layer for these applications. On another hand, you solution might be composed of sibling application, each is responsible for own subsystem. The concept of permanent applications and heart solves the problem of system recovery to consistent state. The failure or permanent application triggers VM failure and concequent recovery by heart application. My usual design of supevisor trees leads the application termination as ultimate, last resort recovery solution. My solutions are composed of multiple interchangeable nodes, the temporary loss of node is transparent to clients. The usage of this model does not require any explicit supervision of application by it self. Best Regards, Dmitry On 25 Jun 2014, at 20:48, Federico Carrone wrote: > We have been having a long discussion the previous months about included applications and supervision at our workspace. > > Some of us just lists the needed applications in the .app file and make sure that all necessary application are started when our application starts. > > For some teammates this has a big issue that: if a depencendy dies, our application's supervision tree will not know about it. They say that the system would be in an inconsistent state. So what they do is that they add the applications inside the included applications and they start the top level supervisor of each dependency inside our application supervisor tree. > > I do not really like this since I think that each application should be separate. > > I would REALLY like to know the community views and experiencies on this. > > Thanks in advance, > Federico Carrone. > > -- > http://federicocarrone.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Jun 25 20:39:31 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 Jun 2014 20:39:31 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <53AAFF27.9020300@meetinghouse.net> References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> Message-ID: On Wed, Jun 25, 2014 at 6:56 PM, Miles Fidelman wrote: > Joe, Thanks for the info. A bit of follow-up if I might (embedded inline): > > Joe Armstrong wrote: > > >> On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman < >> mfidelman@REDACTED > wrote: >> >> >> On Wednesday 25 June 2014 00:09:35 Robert Virding wrote: >> >> I think it is very lucky that we weren't interested in, or >> worried about, >> the theoretical aspects, or that we had heard about the >> actor model. If we >> had we would probably still be discussing whether we were >> doing the actor >> model and which parts of it, or where we differed and how >> important that >> was? Or should we differ and maybe we should drop the >> differences to we >> would comply, etc ... :-) >> >> We were trying to solve *THE* problem and this was the >> best solution we >> could come with. It was purely pragmatic. We definitely >> took ideas from >> other inputs but not from the Actor model. >> >> >> Robert, I know it's probably documented somewhere, but... >> 1. what do (did) you see as "*THE* problem" you were trying to >> solve at the time >> >> >> Joe here - I'll dive in with a reply: >> >> Bjarne D?ckers thesis has a good outline of the problem the thesis is >> here http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1957 >> >> This blog has a good summary of Bjarnes thesis >> >> http://jlouisramblings.blogspot.se/2012/10/ramblings- >> on-thesis-of-bjarne-dacker.html >> > Thanks for the pointers - and yes, the blog post is a very nice summary! > > Re. > > > 2. what sources DID you draw from (other than the predecessor >> languages at Ericsson), are there any that you'd consider primary >> influences? >> >> >> Prolog and Smalltalk in equal measure. Pattern matching and syntax was >> inspired by Prolog. Messaging from Smalltalk. We took a few ideas on >> guarded commands from >> Dijkstra. >> >> This is mostly in the form of historical curiosity of course, but... > can you say a bit more about the Smalltalk influence, and in particular, > which version of Smalltalk? I ask, because: > - The earlier versions of smalltalk included (at least in theory) a lot of > concurrency (objects seemed a bit more like actors), whereas later > versions, starting with Smalltalk-72, pretty much dropped concurrency as a > focus (there was really interesting exchange with Alan Kay on this, a while > back, on the fonc email list). > I can't be sure but at a guess smalltalk-80. The version I used was on a sun workstation and I used to take a coffee break when it garbage collected. To be honest I was more influenced by the books than the implementation which was very slow - the red green and blue books were great reading. > - During that time period (very early 70s), there was a lot of > cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, actor > model), and Steele and Sussman (Scheme) (I'm kind of exploring Robert's statement that "I think it is very lucky > that we weren't interested in, or worried about, the theoretical aspects, > or that we had heard about the actor model." Particularly, in that Alan Kay > cites PLANNER as a key influence on Smalltalk. I'm kind of interested in > the origins and history of languages that treat processes as fundamental > units of computation, vs. the object model). > All the smalltalk stuff did talk about "sending messages to objects" - so was in a sense a message passing model - there were a few problems with this - message passing was really just a disguised function call, and time and errors didn't fit into the model. I always thought it was funny to say "everything is an object" - time and errors don't seem to naturally fit into this ontology - a time value (like 10.45 pm on 12 march 1984) might be represented by an object - but not time as being something which passes as processes execute - this is some kind of invisible stuff that is outside the computation. It's funny that the "sending message to an object" way of describing Java and Smalltalk, Objective-C, C++ etc. objects has persisted despite the fact that this is manifestly *not* what happens (which is a function call). In Erlang we really do send a message to an object (well a process actually) - so Erlang is probably the only OO language there is :-) /Joe > > Thanks, > > Miles Fidelman > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Wed Jun 25 20:43:30 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 25 Jun 2014 11:43:30 -0700 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> Message-ID: Objective-C comes a hair closer than Java/C#/etc. in that the messages are interceptable and reroutable in various ways. Yes it is still a synchronous call stack, so no it isn't like full-on message passing, but it isn't exactly as impoverished as the others. :-} From rtrlists@REDACTED Wed Jun 25 22:01:25 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 25 Jun 2014 21:01:25 +0100 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> Message-ID: On Jun 25, 2014 7:39 PM, "Joe Armstrong" wrote: > > I can't be sure but at a guess smalltalk-80. The version I used was > on a sun workstation and I used to take a coffee break when it garbage collected. To be honest I was more influenced by the books than the > implementation which was very slow - the red green and blue books > were great reading. > BTW, these three amazing books are available here: http://stephane.ducasse.free.fr/FreeBooks.html Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Wed Jun 25 22:16:54 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 25 Jun 2014 16:16:54 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> Message-ID: <53AB2E36.20203@meetinghouse.net> Joe Armstrong wrote: > I can't be sure but at a guess smalltalk-80. The version I used was > on a sun workstation and I used to take a coffee break when it garbage > collected. Ok, well after concurrency was out of the picture. > To be honest I was more influenced by the books than the > implementation which was very slow - the red green and blue books > were great reading. Ain't that the truth. Talk about books with long-term influence. Along with the Smalltalk issue of Byte, and Ted Nelson's Dream Machines. :-) > - During that time period (very early 70s), there was a lot of > cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, > actor model), and Steele and Sussman (Scheme) > > (I'm kind of exploring Robert's statement that "I think it is very > lucky that we weren't interested in, or worried about, the > theoretical aspects, or that we had heard about the actor model." > Particularly, in that Alan Kay cites PLANNER as a key influence on > Smalltalk. I'm kind of interested in the origins and history of > languages that treat processes as fundamental units of > computation, vs. the object model). > > > All the smalltalk stuff did talk about "sending messages to objects" - > so was > in a sense a message passing model - there were a few problems with > this - message passing was really just a disguised function call, and > time and errors didn't fit into the model. Exactly. What a disappointment that turned out to me when one actually started to play with it. > In Erlang we really do send a message to an object (well a process > actually) - so Erlang is probably the only OO language there is :-) > I periodically think about what it would look like, and work like, to combine Erlang's core constructs and plumbing (which I continue to think of as actors) with a Smalltalk like environment (inspectors, browsers, classes). Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jay@REDACTED Wed Jun 25 22:32:38 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 13:32:38 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision Message-ID: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> I am a strong advocate of using included_applications, but even a stronger advocate of using ?least constraint? architectural choices. If you choose to implement your application in a manner compatible with the included application rules (no initialization before root supervisor starts, only one root supervisor called directly from application:start function), then it is possible for someone else to include your application under their own supervisor hierarchy. If you choose not to follow these rules, then you have chosen to not allow anyone else to supervise your application from within theirs without access to your source and copy and paste maintenance whenever you release a new version. The latter is restricting the choice of future integration. When you run ?sibling applications? three things happen: 1) You must choose whether application death is ignored, or whether it will crash the entire node ? there is no in between. 2) You have to sprinkle ?ensure_started? calls throughout your code if there is a dependency. And trust me, you can never be completely assured that it is started at any given moment, ensure_started is yet another race condition. 3) You cannot guarantee start ordering and you may have unexpected race conditions if you try to roll your own restart mechanism (every combination of single or multiple application failure must be accounted for with every interleaving of application restart). As Max said, you can take a hammer to it and force all application deaths to crash your node, and just ensure you always have multiple nodes, and a healthy load balancer and guarantee that there are no hiccups with long restart times. An application is really just a registry in an ets table with environment associated, and some thin semantics about starting. It is a semantic container for a supervisor hierarchy that provides a set of related functionality delivering a single service. I like to integrate single services into a larger hierarchy with ordering and restart semantics that I control. It is a more structured way to integrate erlang applications, by removing one container and placing more than one root supervisor into a new container. I think a better future is to have sibling services and the ability to have services degrade or go down, rather than a strict hierarchical supervision tree. But given only a supervision hierarchy, there is no reason to write a library or an application that precludes using the included_applications option. It should be the choice of the integrator how to organize (and deal with the consequences) of their own application server. jay From essen@REDACTED Wed Jun 25 22:39:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 25 Jun 2014 22:39:19 +0200 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> Message-ID: <53AB3377.40406@ninenines.eu> On 06/25/2014 10:32 PM, Jay Nelson wrote: > 2) You have to sprinkle ?ensure_started? calls throughout your code if there is a > dependency. And trust me, you can never be completely assured that it is started > at any given moment, ensure_started is yet another race condition. I'm sorry what? Why would you ever call ensure_started outside of the shell while developing or a test suite? Releases figure out dependencies and start applications in the appropriate order. -- Lo?c Hoguin http://ninenines.eu From jay@REDACTED Wed Jun 25 22:42:51 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 13:42:51 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <53AB3377.40406@ninenines.eu> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> Message-ID: <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> On Jun 25, 2014, at 1:39 PM, Lo?c Hoguin wrote: > On 06/25/2014 10:32 PM, Jay Nelson wrote: >> 2) You have to sprinkle ?ensure_started? calls throughout your code if there is a >> dependency. And trust me, you can never be completely assured that it is started >> at any given moment, ensure_started is yet another race condition. > > I'm sorry what? > > Why would you ever call ensure_started outside of the shell while developing or a test suite? Releases figure out dependencies and start applications in the appropriate order. > > -- > Lo?c Hoguin > http://ninenines.eu Why does crypto code always do this? What if your application goes down but doesn?t take the VM with it? If there is a dependency, you must ensure that the required application is started, not just when you start your application, but at any time later after which it may have subsequently failed. From jay@REDACTED Wed Jun 25 22:49:02 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 13:49:02 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision Message-ID: Not every application can be separate. We have an application called ?presence_server? which is embedded in every node. When the server comes up, and is finished with its full initialization, it announces ?service available? so that other nodes can contact it. If the presence_server is run as a sibling application, it can go down and cause services to be unavailable until it is restarted. The desire to have all applications independent is laudable, but code reuse allows us to have ?presence? capabilities embedded in more than one application and be reliable because it is restarted by the supervisor hierarchy. Your teammates fears of inconsistent dependencies are real and well-founded even if you haven?t encountered a failure situation yet. jay From essen@REDACTED Wed Jun 25 22:50:49 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 25 Jun 2014 22:50:49 +0200 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> Message-ID: <53AB3629.3060209@ninenines.eu> On 06/25/2014 10:42 PM, Jay Nelson wrote: > Why does crypto code always do this? Not sure what you mean? crypto is a library it doesn't need to be started. > What if your application goes down but doesn?t take the VM with it? If you configure the VM to do that you probably have good reasons and *don't* want it to restart. For example to debug things out. Configuring the VM to crash, and it failing to do so, has about the same chances of happening as your supervisor not restarting the included_application. > If there is a dependency, you must ensure that the required application > is started, not just when you start your application, but at any time later > after which it may have subsequently failed. Only if you want to restart it, which you don't. -- Lo?c Hoguin http://ninenines.eu From jay@REDACTED Wed Jun 25 23:03:17 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 14:03:17 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <53AB3629.3060209@ninenines.eu> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> <53AB3629.3060209@ninenines.eu> Message-ID: <373545A9-A4E3-4FC3-8A20-7D084966990F@duomark.com> On Jun 25, 2014, at 1:50 PM, Lo?c Hoguin wrote: > On 06/25/2014 10:42 PM, Jay Nelson wrote: >> Why does crypto code always do this? > > Not sure what you mean? crypto is a library it doesn't need to be started. I misspoke. Take a look at pg2:ensure_started. I don?t want to write code like that to make sure that an application is running. I thought I recalled similar things in ssh and others that depend on crypto but I guess I was wrong. > >> What if your application goes down but doesn?t take the VM with it? > > If you configure the VM to do that you probably have good reasons and *don't* want it to restart. For example to debug things out. > > Configuring the VM to crash, and it failing to do so, has about the same chances of happening as your supervisor not restarting the included_application. I thought it was apparent from the context, but I meant, what if your required essential dependency of an application goes down and you didn?t configure it as a permanent application (because it?s a hammer and you want something less than the entire node to go down and still recover). The fact that you have two choices: kill the node or ignore, is limiting when dealing with complex dependency constraints. Especially in continuous realtime services where the loss of a database connection is an essential dependency but not sufficient to immediately turn off all access to the node. > >> If there is a dependency, you must ensure that the required application >> is started, not just when you start your application, but at any time later >> after which it may have subsequently failed. > > Only if you want to restart it, which you don?t. I wasn?t aware that you were familiar with my code. In my case I do want to restart. But you as library or reusable application developer can?t possibly know what I will use it for in the future. And arbitrary restrictions on reuse shouldn?t be built in unless there are good reasons for doing so. jay From essen@REDACTED Wed Jun 25 23:28:57 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 25 Jun 2014 23:28:57 +0200 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <373545A9-A4E3-4FC3-8A20-7D084966990F@duomark.com> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> <53AB3629.3060209@ninenines.eu> <373545A9-A4E3-4FC3-8A20-7D084966990F@duomark.com> Message-ID: <53AB3F19.6080501@ninenines.eu> On 06/25/2014 11:03 PM, Jay Nelson wrote: > > On Jun 25, 2014, at 1:50 PM, Lo?c Hoguin wrote: > >> On 06/25/2014 10:42 PM, Jay Nelson wrote: >>> Why does crypto code always do this? >> >> Not sure what you mean? crypto is a library it doesn't need to be started. > > I misspoke. Take a look at pg2:ensure_started. I don?t want to write code like that to make > sure that an application is running. I'm not sure how that's related. pg2 isn't an application. It's not written this way for handling restarts, because as you can see it's marked as permanent, and if kernel_safe_sup dies the Erlang node is killed anyway. The VM doesn't start pg2 by default, which is probably why this function is there. It's ugly, but it's completely unrelated to the topic at hand. >>> What if your application goes down but doesn?t take the VM with it? >> >> If you configure the VM to do that you probably have good reasons and *don't* want it to restart. For example to debug things out. >> >> Configuring the VM to crash, and it failing to do so, has about the same chances of happening as your supervisor not restarting the included_application. > > I thought it was apparent from the context, but I meant, what if your required > essential dependency of an application goes down and you didn?t configure > it as a permanent application (because it?s a hammer and you want something > less than the entire node to go down and still recover). The fact that you have > two choices: kill the node or ignore, is limiting when dealing with complex > dependency constraints. Especially in continuous realtime services where the > loss of a database connection is an essential dependency but not sufficient to > immediately turn off all access to the node. But why would you make the application crash if you need it to stay alive? If your DB driver application crashes because the DB is gone, something is *very* wrong with your DB driver application. I personally would stay the hell away from it. Regardless, if the DB driver application crashes because the DB is gone, I'm not sure how including it in your other application is any better, as it'll quickly kill it too if it starts doing a restart-crash-loop. >>> If there is a dependency, you must ensure that the required application >>> is started, not just when you start your application, but at any time later >>> after which it may have subsequently failed. >> >> Only if you want to restart it, which you don?t. > > I wasn?t aware that you were familiar with my code. In my case I do want > to restart. But you as library or reusable application developer can?t possibly > know what I will use it for in the future. And arbitrary restrictions on reuse > shouldn?t be built in unless there are good reasons for doing so. Don't think anyone here spoke about restricting reuse. -- Lo?c Hoguin http://ninenines.eu From jay@REDACTED Wed Jun 25 23:45:51 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 14:45:51 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <53AB3F19.6080501@ninenines.eu> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> <53AB3629.3060209@ninenines.eu> <373545A9-A4E3-4FC3-8A20-7D084966990F@duomark.com> <53AB3F19.6080501@ninenines.eu> Message-ID: <7D646A4E-E4EC-4795-B93C-93A0010192F2@duomark.com> On Jun 25, 2014, at 2:28 PM, Lo?c Hoguin wrote: > I'm not sure how that's related. pg2 isn't an application. It's not written this way for handling restarts, because as you can see it's marked as permanent, and if kernel_safe_sup dies the Erlang node is killed anyway. The VM doesn't start pg2 by default, which is probably why this function is there. > > It's ugly, but it's completely unrelated to the topic at hand. There?s no difference between an application that is not started by default on start up (but is used at some later time), and one that crashes after being started and is needed later and must be restarted. My point on restricting use was made because library and application developers should be aware that even though they themselves may not use or like included_applications, it is incumbent on them to provide a complete solution and that they be aware of the existence of included_applications and the guidelines that must be followed to enable their use. Most cases when included_applications were not allowed by default (and there have been several including an OTP application which I patched) were because of initialization prior to the start of the root supervisor, or the lack of an exported function to call the root supervisor (which most often happens when people try to save files by putting application and supervisor in the same module). The drawback to using included_applications comes with start_phases. When there is a sequence of dependencies that must be started in a particular order the built in method is to code start_phases in your application module and invoke them in order from the .app.src. There is a minor problem in that the including application must be aware of all start_phases of all included applications and must have a superset of all start_phases specified. The bigger obstacle that makes start_phases problematic comes in that they are not invoked from the supervisors, but from the startup sequence, so they are never invoked during a restart. With complex startup dependencies among multiple applications, you may need to quickly start a static supervisor hierarchy (possibly without children) and then programmatically trigger the instantiation of children. This approach can be run at any time, not just at startup, so you can programmatically enable start_phase-like functionality during restarts with your own code. This is probably when a VM node restart is more likely to be the easy path, but is also the case when restarting a node is likely to take a significant amount of time. I am not aware of anyone else in the community who as advocated included_applications. I have never come across an OSS library that uses included_applications other than my own, although I do know Ericsson built and uses these features for a reason. I think this aspect of OTP is probably the weakest aspect, and I would welcome alternatives that more closely resemble a soup of peer services with less rigidity than a supervisor hierarchy and which allow and enforce restart logic and start_phases in a sane way, yet still allow awareness of whether dependencies are currently running or not. jay From mjtruog@REDACTED Thu Jun 26 00:33:37 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 25 Jun 2014 15:33:37 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> Message-ID: <53AB4E41.7020109@gmail.com> Comments below: On 06/25/2014 01:32 PM, Jay Nelson wrote: > I am a strong advocate of using included_applications, but even a stronger advocate > of using ?least constraint? architectural choices. > > If you choose to implement your application in a manner compatible with the included > application rules (no initialization before root supervisor starts, only one root supervisor > called directly from application:start function), then it is possible for someone else to > include your application under their own supervisor hierarchy. > > If you choose not to follow these rules, then you have chosen to not allow anyone else > to supervise your application from within theirs without access to your source and copy > and paste maintenance whenever you release a new version. > > The latter is restricting the choice of future integration. Normally, included_applications is used for supervisors that were not started as part of their application, or perhaps with an application that didn't provide a root supervisor. When you are starting processes for a separate application, you are breaking encapsulation that Erlang/OTP applications can provide (problem 1). The other concern with using included_applications is that it can make supervision hierarchies larger (more levels in the tree) which can make it more difficult to have MaxR and MaxT settings that allow the whole application to fail when errors occur (problem 2). So, using included_applications normally would be contrary to allowing applications to fail-fast. included_applications is only a way to integrate with Erlang applications that are not using OTP (i.e., not using an application behaviour as it was intended), and it shows a design problem in the application that must be used in this way. > > When you run ?sibling applications? three things happen: > > 1) You must choose whether application death is ignored, or whether it will crash > the entire node ? there is no in between. > > 2) You have to sprinkle ?ensure_started? calls throughout your code if there is a > dependency. And trust me, you can never be completely assured that it is started > at any given moment, ensure_started is yet another race condition. I have some code at https://github.com/okeuday/reltool_util that does more than 'ensure_started' is able to do, since 'ensure_started' doesn't choose to handle some of the loading issues when trying to start or stop applications dynamically. This code also is able to start a release dynamically based on the release's script file. I think more dynamic usage of Erlang is important and that it is good to avoid having a single release that can only be provided on the command line. So, making stuff more dynamic is advantageous, not making it less dynamic by having a single static hierarchy of processes. I understand you are concerned about race conditions, which is a valid concern, but with proper timeout usage you can anticipate startup delays due to initialization. If race conditions are still created, then Erlang processes from separate applications should be merged to make the startup deterministic while encapsulating hard dependencies that might otherwise cause failures due to race conditions. I don't think included_applications will be required to merge the applications because the race condition problems would be in code you control. > > 3) You cannot guarantee start ordering and you may have unexpected race > conditions if you try to roll your own restart mechanism (every combination of > single or multiple application failure must be accounted for with every interleaving > of application restart). I agree that not having a dependable strict ordering of application startup can make some problems ambiguous, which is a concern, when startup is determined automatically based on dependencies and the result of release generation. If you use a CloudI configuration file (http://cloudi.org), all services are listed in the order they are started, which is much easier to reason about when problems occur with CloudI services. Internal CloudI services are services written in Erlang which can be (but are not required to be) Erlang applications, so they can start Erlang applications dynamically outside of a release, which provides more dynamic behavior than is normally available within Erlang. > > As Max said, you can take a hammer to it and force all application deaths to crash > your node, and just ensure you always have multiple nodes, and a healthy load > balancer and guarantee that there are no hiccups with long restart times. > > An application is really just a registry in an ets table with environment associated, > and some thin semantics about starting. It is a semantic container for a supervisor > hierarchy that provides a set of related functionality delivering a single service. > I like to integrate single services into a larger hierarchy with ordering and restart > semantics that I control. It is a more structured way to integrate erlang applications, > by removing one container and placing more than one root supervisor into a new > container. > > I think a better future is to have sibling services and the ability to have services > degrade or go down, rather than a strict hierarchical supervision tree. But given > only a supervision hierarchy, there is no reason to write a library or an application > that precludes using the included_applications option. It should be the choice of > the integrator how to organize (and deal with the consequences) of their own > application server. CloudI provides a better way of doing this. Examples if you are interested for Erlang development and enforcing ordering are https://github.com/CloudI/CloudI/tree/master/examples/hello_world1#purpose and https://github.com/CloudI/CloudI/tree/master/examples/hello_world5#purpose . > > jay > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mononcqc@REDACTED Thu Jun 26 00:52:43 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 25 Jun 2014 18:52:43 -0400 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: References: Message-ID: <20140625225242.GC96473@ferdmbp.local> On 06/25, Jay Nelson wrote: > Not every application can be separate. We have an application called ?presence_server? > which is embedded in every node. When the server comes up, and is finished with its > full initialization, it announces ?service available? so that other nodes can contact it. If > the presence_server is run as a sibling application, it can go down and cause services > to be unavailable until it is restarted. > What happens if the server fails repeatedly then? Does it crash the node, but only after another cycle of crashing everything? If your app is designed as: [AppSup] [PresenceSup] / \ | [SubSup] [SomeWorker] [Server] / | \ [[[Workers]]] Let's say I allow AppSup to crash 10 times a minute, and I allow PresenceSup to crash 3 times per hour. If I make the latter permanent, after 3 failures in an hour my node crashes. In the included_application scenario I can go: [AppSup]-------------->[PresenceSup] / \ | [SubSup] [SomeWorker] [Server] / | \ [[[Workers]]] In which case my presence sup now needs to crash 3 times and hour, and then 10 times a minute to bring down the entire node. So what's the benefit to doing this instead of leaving PresenceSup as it is, but just raising its limit to 10 times a minute (or more)? In terms of your supervision strategy, not a lot. I can understand the need for synchronization, but if you make that standalone application have similar limits as the supervisor you'd put it under, it sounds like you wouldn't lose a lot. Is it otherwise a question of being able to control these limits remotely (from another app), or specifying other arguments to be used? I'm not sure I even understand the point for controlling supervision in many cases. You just added one more layer that needs failing many times, but little more. In a previous e-mail, Ulf Wiger mentioned some of the original cases: http://erlang.org/pipermail/erlang-questions/2010-September/053594.html > > Included applications were mainly introduced since the same > call-handling applications needed to move as one during failover and > takeover, and starting a dozen or so top applications made that much > more difficult. It was just too much code and too many modules to > integrate into one single application without one more structuring > layer. > That's also why start phases were used. For single nodes, I'm not sure a good use case even exists in terms of what the purposes of included applications were. Then again, you know I love debating included applications with you. Regards, Fred. From jay@REDACTED Thu Jun 26 01:14:57 2014 From: jay@REDACTED (Jay Nelson) Date: Wed, 25 Jun 2014 16:14:57 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <20140625225242.GC96473@ferdmbp.local> References: <20140625225242.GC96473@ferdmbp.local> Message-ID: <574CB3CE-8BB2-4151-BAB2-30981779BB8A@duomark.com> On Jun 25, 2014, at 3:52 PM, Fred Hebert wrote: > > What happens if the server fails repeatedly then? Does it crash the > node, but only after another cycle of crashing everything? > > If your app is designed as: There may be better alternatives to what we have done (we have tried lesser alternatives in the past and would welcome a better approach), but the current approach involves essentially three elements: 1) ets table of services 2) some application supervisor hierarchy for the service 3) advertising that the service is available This sequence is enforced in a rest_for_one pattern, so that if the service advertising or the implementation of the service becomes unavailable, then the service will read as offline. Once rest_for_one has restored everything, the last step advertises that the service is available. The ets table is created and owned by the first supervisor so that it is not lost during transient failure of other components. This is essential because the ets holds other services advertised by other nodes and is consulted locally. In reality, the included_application ?presence_server? is essentially a library with some convenient supervisors that we plug into the node?s hierarchy because the service behaviour has to be plugged in between the ets and the advertising capabilities, so a variant from the typical inclusion of one root supervisor. The ?lesser alternatives? I referred to resulted in situations where the presence subsystem went away but the service was available and running just fine, but not receiving traffic because it appeared to be offline. jay From ok@REDACTED Thu Jun 26 02:08:14 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 26 Jun 2014 12:08:14 +1200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> Message-ID: <83AF5B41-F60C-47EB-A525-DE514A6F866F@cs.otago.ac.nz> I've been reading the ActoScript paper, and am quite confused. The title of the paper is ActorScript(TM) extension of C#, Java, Objective C, JavaScript, and System Verilog using iAdaptive(TM) concurrency for antiCloud(TM) privacy and security So the title says it's an extension of several other languages (one of which is notorious for not having any concurrency). But then what the paper describes is variant of the actor language from long long ago making use of quirky Unicode characters, talking about an ActorScript-specific IDE, and making strong claims of efficiency. The Tutorial http://arxiv.org/pdf/1008.2748v20.pdf uses slightly different syntax. So what _is_ it? Is there such a thing as an ActorScript implementation I could download or buy? ActorScript, iAdaptive, and so on seem to be products or services of a company called UltraConcurrent, Inc, which has apparently applied to trademark the name WHACK-A-MOLE. It's remarkably hard to find anything useful about them; there are a couple of GoogleDocs that are technically in the trash. The link for ActorScript there is to actorscript.co, which does not exist, nor does actorscript.com. There's a link for iadaptive.co, which doesn't exist, while iadaptive.com is blocked here on the grounds that it contains pornography. http://carlhewitt.info has lots of links to papers &c but I am still searching in vain for the *expected* evidence that ActorScript is something other than vapourware. I say *expected* because the Actor model has been around for a long time, Hewitt is a highly respected researcher, and I trust him not to talk about ActorScript as an existing thing if it isn't. But I'd certainly like to see some non-trivial examples of code and some performance measurements to back up claims like "ActorScript programs are as efficient as the same implementation in machine code. For example, message passing has essentially the same overhead as procedure calls and looping." Surely there must be *some* measurements somewhere to back this up, but I have spent several hours looking. I guess I'm just going to have to keep on using Erlang... I sometimes think that the most innovative idea in Erlang is links. Oh, the way a downstream crash in a Unix pipeline can take out earlier members of the pipe is sort of similar. I wonder if that could have been one of the inspirations for the idea? ActorScript has "Swiss cheese" (which seems to be not entirely unlike monitors, to the very limited extent that I understand it), but not (again, ttvletiui) links. From mononcqc@REDACTED Thu Jun 26 02:10:03 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 25 Jun 2014 20:10:03 -0400 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <574CB3CE-8BB2-4151-BAB2-30981779BB8A@duomark.com> References: <20140625225242.GC96473@ferdmbp.local> <574CB3CE-8BB2-4151-BAB2-30981779BB8A@duomark.com> Message-ID: <20140626001003.GD96473@ferdmbp.local> On 06/25, Jay Nelson wrote: > [snip] > > This sequence is enforced in a rest_for_one pattern, so that if the service > advertising or the implementation of the service becomes unavailable, then > the service will read as offline. Once rest_for_one has restored everything, > the last step advertises that the service is available. > > The ets table is created and owned by the first supervisor so that it is not > lost during transient failure of other components. This is essential because > the ets holds other services advertised by other nodes and is consulted > locally. > What I can think of in this case is a bit like this. What you provide is twofold: 1. Registration of your service to say you're online 2. Caching of external services' presence in ETS. They're complimentary, but intersect in some way. What I see for these is therefore: 1. A presence management and registration app, let's call it presencerl; 2. A lightweight self-registration process that contacts presencerl to register. (MyApp) (Presencerl) [MyApp_sup] [presencerl_sup]---ETS / | \ / \ [w1] [w1] [agent] [presencerl_local] [presencerl_remote] Where MyApp_sup can be using a rest_for_one strategy. The 'agent' process is in charge of calling something like 'presencerl:register(App, self())', and then it can just hibernate forever. presencerl_local just monitors any agent that contacted it and matches it in the ETS table owned by the supervisor (which can be super resilient and do 100000 MaxR for 1 MaxT for no reason) and broadcasts to peers. Presencerl_remote listens to peers and populates the table in ETS. Using it that way, you decouple your service discovery from your principal app, and can build multiple apps that all depend on presencerl independently. You can even have 'sub-services' if you want, and you just did away with your included applications. You can also disable specific services during partial upgrades without needing to shut down other services running on the same node! > > The ?lesser alternatives? I referred to resulted in situations where the > presence subsystem went away but the service was available and running > just fine, but not receiving traffic because it appeared to be offline. > This doesn't really go away in this case, unless you make the presencerl app permanent, which can then have it share similar failure thresholds to your main app, something that is somewhat equivalent to shoving both under the same supervisor. Anyway, that's a quick idea of how it could be done, I think. Regards, Fred. From ok@REDACTED Thu Jun 26 02:17:13 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 26 Jun 2014 12:17:13 +1200 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: <23D40501-A2D8-4F58-A83E-7DEB1C174C51@cs.otago.ac.nz> On 25/06/2014, at 9:18 PM, ami wrote: > Which IDEs do you use to treat all the source tree(both Erlang & C) as a single project? > I might use one IDE for C and another for Erlang. But it?s quite ugly and inconvenient. I've had the Erlang sources for years. It's very rare for me to look at the C sources at all, so I really don't see the inconvenience. Someone developing a NIF would have a different experience, but that's something that should be done with extreme vigilant trepidation (thanks for the phrase, Rex Stout) after a long experience of doing things purely in Erlang. > please share links, configs, etc. > > The most needed features are: > * go to declaration You do realise that in any sufficiently dynamic language, it may be impossible to do this correctly? > * code completion > * easy navigation through the code You did do a web search for "Erlang IDE"? You would find http://www.erlang.org/faq/tools.html and of course erlide. From mfidelman@REDACTED Thu Jun 26 03:29:54 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 25 Jun 2014 21:29:54 -0400 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <83AF5B41-F60C-47EB-A525-DE514A6F866F@cs.otago.ac.nz> References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> <83AF5B41-F60C-47EB-A525-DE514A6F866F@cs.otago.ac.nz> Message-ID: <53AB7792.8080306@meetinghouse.net> Richard A. O'Keefe wrote: > I've been reading the ActoScript paper, and am quite confused. > The title of the paper is > ActorScript(TM) > extension of C#, Java, Objective C, JavaScript, > and System Verilog > using > iAdaptive(TM) concurrency > for > antiCloud(TM) privacy and security > > So the title says it's an extension of several other languages > (one of which is notorious for not having any concurrency). > But then what the paper describes is variant of the actor > language from long long ago making use of quirky Unicode > characters, talking about an ActorScript-specific IDE, and > making strong claims of efficiency. The Tutorial > http://arxiv.org/pdf/1008.2748v20.pdf uses slightly different > syntax. > > So what _is_ it? Is there such a thing as an ActorScript > implementation I could download or buy? ActorScript, > Probably better addressed to Carl Hewitt :-) For what it's worth - after PLANNER, I've been more a fan of his conceptual models than his implementations. The Actor stuff was brilliant, and I remember some interesting conversations from my student days at MIT (40 years ago, mind you) - but every time he releases some kind of implementation, it confuses the heck out of me. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lists@REDACTED Thu Jun 26 11:28:31 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 11:28:31 +0200 Subject: [erlang-questions] io module encoding Message-ID: Hello, On Mac OS X, when I start an Erlang shell from the command-line the io module encoding is set to unicode: > Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.4 (abort with ^G) > 1> os:getenv("LC_CTYPE"). > "UTF-8" > 2> lists:keyfind(encoding, 1, io:getopts()). > {encoding,unicode} So that?s great. Now, I have a GUI application that launches the Erlang shell. At first I thought the LC_CTYPE environment variable was not set (which was the case), but even when set to UTF-8, this does not work as expected: Here's the output of the shell launched by the GUI application: > 1> os:getenv("LC_CTYPE"). > "UTF-8" > 2> lists:keyfind(encoding, 1, io:getopts()). > {encoding,latin1} I want {encoding, unicode}, and don?t understand why it defaults to latin1. How can it be? The documentation of io says: (http://erlang.org/doc/man/io.html) > The standard shell will be set for either Unicode or latin1 encoding when the system is started. The actual encoding is set with the help of the LANG or LC_CTYPE environment variables on Unix-like system or by other means on other systems. Does Mac OS X applies to ?other systems?? If so, what are the ?other means?? Thanks! Best, Cam From jesper.louis.andersen@REDACTED Thu Jun 26 11:51:20 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 26 Jun 2014 11:51:20 +0200 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> Message-ID: On Wed, Jun 25, 2014 at 10:42 PM, Jay Nelson wrote: > What if your application goes down but doesn?t take the VM with it? Applications which are declared permanent in the release does always reap the VM. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Jun 26 11:51:26 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Thu, 26 Jun 2014 11:51:26 +0200 Subject: [erlang-questions] io module encoding In-Reply-To: References: Message-ID: Camille, I have reported two bugs related to this area as I was expecting this behaviour to change on 17.0: http://erlang.org/pipermail/erlang-bugs/2014-April/004309.html http://erlang.org/pipermail/erlang-bugs/2014-April/004310.html Only the erlang shell, the one started via the erl command, respects LC_CTYPE and the +fnu flags. If you pass -noshell, use the "dumb terminal" (triggered when you set TERM to something else), use stderr, or an escript, the encoding will remain as latin1. You can change the encoding in those situations by calling: io:setopts(standard_io, [{encoding,utf8}]); I hope this helps, PS: In case you want to call the line above in your application callback, you may notice a slow down when starting the application along side the shell with something like: erl -s my_app start. That's because the group_leader sends a message to the shell to change the encoding but the shell is not yet ready. I was able to work around this particular scenario by using: case init:get_argument(noshell) of {ok, _} -> io:setopts(standard_io, [{encoding,utf8}]); error -> ok end A patch was sent to OTP to fix this particular issue: https://github.com/erlang/otp/pull/351 *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Thu, Jun 26, 2014 at 11:28 AM, Camille Troillard wrote: > Hello, > > > On Mac OS X, when I start an Erlang shell from the command-line the io > module encoding is set to unicode: > > > > Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:8:8] > [async-threads:10] [hipe] [kernel-poll:false] > > > > Eshell V5.10.4 (abort with ^G) > > 1> os:getenv("LC_CTYPE"). > > "UTF-8" > > 2> lists:keyfind(encoding, 1, io:getopts()). > > {encoding,unicode} > > > > So that?s great. > > Now, I have a GUI application that launches the Erlang shell. At first I > thought the LC_CTYPE environment variable was not set (which was the case), > but even when set to UTF-8, this does not work as expected: > > Here's the output of the shell launched by the GUI application: > > > 1> os:getenv("LC_CTYPE"). > > "UTF-8" > > 2> lists:keyfind(encoding, 1, io:getopts()). > > {encoding,latin1} > > > I want {encoding, unicode}, and don?t understand why it defaults to latin1. > How can it be? > > > The documentation of io says: > > (http://erlang.org/doc/man/io.html) > > The standard shell will be set for either Unicode or latin1 encoding > when the system is started. The actual encoding is set with the help of the > LANG or LC_CTYPE environment variables on Unix-like system or by other > means on other systems. > > Does Mac OS X applies to ?other systems?? If so, what are the ?other > means?? > > Thanks! > > > Best, > Cam > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@REDACTED Thu Jun 26 12:29:31 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 12:29:31 +0200 Subject: [erlang-questions] io module encoding In-Reply-To: References: Message-ID: <3ABBC445-9888-498E-A2F3-0F3136DB1BD0@tuli.pe> Fantastic, thank you Jos?! On 26 Jun 2014, at 11:51, Jos? Valim wrote: > Camille, > > I have reported two bugs related to this area as I was expecting this behaviour to change on 17.0: > > http://erlang.org/pipermail/erlang-bugs/2014-April/004309.html > http://erlang.org/pipermail/erlang-bugs/2014-April/004310.html > > Only the erlang shell, the one started via the erl command, respects LC_CTYPE and the +fnu flags. If you pass -noshell, use the "dumb terminal" (triggered when you set TERM to something else), use stderr, or an escript, the encoding will remain as latin1. > > You can change the encoding in those situations by calling: > > io:setopts(standard_io, [{encoding,utf8}]); > > I hope this helps, > > PS: In case you want to call the line above in your application callback, you may notice a slow down when starting the application along side the shell with something like: erl -s my_app start. That's because the group_leader sends a message to the shell to change the encoding but the shell is not yet ready. I was able to work around this particular scenario by using: > > case init:get_argument(noshell) of > {ok, _} -> io:setopts(standard_io, [{encoding,utf8}]); > error -> ok > end > > A patch was sent to OTP to fix this particular issue: https://github.com/erlang/otp/pull/351 > > > > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jun 26, 2014 at 11:28 AM, Camille Troillard wrote: > Hello, > > > On Mac OS X, when I start an Erlang shell from the command-line the io module encoding is set to unicode: > > > > Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] > > > > Eshell V5.10.4 (abort with ^G) > > 1> os:getenv("LC_CTYPE"). > > "UTF-8" > > 2> lists:keyfind(encoding, 1, io:getopts()). > > {encoding,unicode} > > > > So that?s great. > > Now, I have a GUI application that launches the Erlang shell. At first I thought the LC_CTYPE environment variable was not set (which was the case), but even when set to UTF-8, this does not work as expected: > > Here's the output of the shell launched by the GUI application: > > > 1> os:getenv("LC_CTYPE"). > > "UTF-8" > > 2> lists:keyfind(encoding, 1, io:getopts()). > > {encoding,latin1} > > > I want {encoding, unicode}, and don?t understand why it defaults to latin1. > How can it be? > > > The documentation of io says: > > (http://erlang.org/doc/man/io.html) > > The standard shell will be set for either Unicode or latin1 encoding when the system is started. The actual encoding is set with the help of the LANG or LC_CTYPE environment variables on Unix-like system or by other means on other systems. > > Does Mac OS X applies to ?other systems?? If so, what are the ?other means?? > > Thanks! > > > Best, > Cam > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@REDACTED Thu Jun 26 12:42:28 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 12:42:28 +0200 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: Hello Alexander, I use IntelliJ IDEA. While it is not the primary purpose of this editor, it has a good plugin for Erlang/OTP. http://ignatov.github.io/intellij-erlang/ The real time-saver of this IDE is the ability to mix and match different languages. It has strong support for Javascript and HTML, so if you are developing a web-app on top of Erlang, this can be a pretty confortable working environment. I am not sure about C though. I haven?t had luck with Emacs, I found there was too much configuration, not enough documentation, and that ultimately it did not work well on my Mac, YMMV. Cam On 25 Jun 2014, at 11:18, ami wrote: > Hi all, > > I decided to understand how Erlang works from inside. > Probably I?ll even become a contributor(I hope). > > I started with forking https://github.com/erlang/otp, then cloning it to my local copy. > And it?s quite big. And not only big, there are both C and Erlang sources: > > 1s-MacBook-Pro:otp a1$ find . -name '*.erl' | wc -l > 3650 > 1s-MacBook-Pro:otp a1$ find . -name '*.c' | wc -l > 547 > > I would say, Erlang sources mostly. > > Here?s my question. > > Which IDEs do you use to treat all the source tree(both Erlang & C) as a single project? > I might use one IDE for C and another for Erlang. But it?s quite ugly and inconvenient. > > Though, I?m not the very first person who decided to contribute to Erlang/OTP :) > So, I think, that somebody already faced with these questions. > > If you use some > * special-designed IDEs(preferably), BTW, do they exist in nature? > * emacs plugins(less preferably) or > * vim plugins, > > please share links, configs, etc. > > The most needed features are: > * go to declaration > * code completion > * easy navigation through the code > > > Thanks in advance, > > Alexander > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Thu Jun 26 12:54:34 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 26 Jun 2014 12:54:34 +0200 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: The best IDE for this is asking where is what to real persons on the Erlang IRC channels. -- Anthony Ramine Le 25 juin 2014 ? 11:18, ami a ?crit : > * easy navigation through the code From attila.r.nohl@REDACTED Thu Jun 26 13:30:48 2014 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Thu, 26 Jun 2014 13:30:48 +0200 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: 2014-06-25 11:18 GMT+02:00 ami : [...] > If you use some > * special-designed IDEs(preferably), BTW, do they exist in nature? > * emacs plugins(less preferably) or > * vim plugins, > > please share links, configs, etc. > > The most needed features are: > * go to declaration vim + ctags covers this partly. Of course not that useful when you want to look for a handle_info function call. I have a small vim macro to use the module name too, but that's not production quality. > * code completion vim mostly covers this (use Ctrl-P) > * easy navigation through the code Again, vim + ctags. From i.vysniauskas@REDACTED Thu Jun 26 15:10:12 2014 From: i.vysniauskas@REDACTED (=?UTF-8?Q?Ignas_Vy=C5=A1niauskas?=) Date: Thu, 26 Jun 2014 15:10:12 +0200 Subject: [erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution In-Reply-To: <83AF5B41-F60C-47EB-A525-DE514A6F866F@cs.otago.ac.nz> References: <53A9E811.2000302@meetinghouse.net> <2452064.4BLlgzMsyl@jalapeno> <53AAE8A9.3020109@meetinghouse.net> <53AAFF27.9020300@meetinghouse.net> <83AF5B41-F60C-47EB-A525-DE514A6F866F@cs.otago.ac.nz> Message-ID: On Thu, Jun 26, 2014 at 2:08 AM, Richard A. O'Keefe wrote: > http://carlhewitt.info has lots of links to papers &c but > I am still searching in vain for the *expected* evidence > that ActorScript is something other than vapourware. > > I say *expected* because the Actor model has been around for > a long time, Hewitt is a highly respected researcher, and I > trust him not to talk about ActorScript as an existing thing > if it isn't. If you go through the other papers listed on Hewitt's page you will notice some interesting "publications", like: * "Mathematics self-proves its own Consistency (contra G?del et. al.)", where Hewitt claims having disproved long established mathematical results via some ad-hoc philosophical arguments; * "What is computation? Actor Model versus Turing's Model", where he argues that the Actor Model expresses hypercomputation and thus transcends Turing machines; and other gems of varying degree. To put it lightly, I think Hewitt's papers published after circa 2000 should be taken with a grain of salt. If you look at his publication history[1], you will notice he has not released a single paper in a respectable (sic) journal since then. He has also been notoriously banned from Wikipedia[2][3] for destructively editing articles according to his own beliefs. I could go on with many other "interesting" facts, but they can be easily discovered by oneself. Respectability is not a permanent trait. [1]: http://www.informatik.uni-trier.de/~ley/pers/hd/h/Hewitt:Carl [2]: http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Carl_Hewitt [3]: http://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/CarlHewitt/Archive -- Ignas From daniel.goertzen@REDACTED Thu Jun 26 16:22:31 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 26 Jun 2014 09:22:31 -0500 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: +1 for IntelliJ. Declaration following works very well. They are working on C/C++ support. The Erlang plugin site says they are also working on a standalone Erlang IDE which could lower barriers for Erlang newcomers. I didn't mind using emacs under Linux, but I couldn't get it working right on Windows so I was driven to ErlIDE. That worked well for a few years, but the shoddy plugins I used to overcome annoying Eclipse-isms eventually bricked my installation and drove me to IntelliJ. So far so good with IntelliJ. On Thu, Jun 26, 2014 at 5:42 AM, Camille Troillard wrote: > Hello Alexander, > > I use IntelliJ IDEA. While it is not the primary purpose of this editor, > it has a good plugin for Erlang/OTP. > > http://ignatov.github.io/intellij-erlang/ > > The real time-saver of this IDE is the ability to mix and match different > languages. It has strong support for Javascript and HTML, so if you are > developing a web-app on top of Erlang, this can be a pretty confortable > working environment. I am not sure about C though. > > I haven?t had luck with Emacs, I found there was too much configuration, > not enough documentation, and that ultimately it did not work well on my > Mac, YMMV. > > Cam > > > > > On 25 Jun 2014, at 11:18, ami wrote: > > > Hi all, > > > > I decided to understand how Erlang works from inside. > > Probably I?ll even become a contributor(I hope). > > > > I started with forking https://github.com/erlang/otp, then cloning it > to my local copy. > > And it?s quite big. And not only big, there are both C and Erlang > sources: > > > > 1s-MacBook-Pro:otp a1$ find . -name '*.erl' | wc -l > > 3650 > > 1s-MacBook-Pro:otp a1$ find . -name '*.c' | wc -l > > 547 > > > > I would say, Erlang sources mostly. > > > > Here?s my question. > > > > Which IDEs do you use to treat all the source tree(both Erlang & C) as a > single project? > > I might use one IDE for C and another for Erlang. But it?s quite ugly > and inconvenient. > > > > Though, I?m not the very first person who decided to contribute to > Erlang/OTP :) > > So, I think, that somebody already faced with these questions. > > > > If you use some > > * special-designed IDEs(preferably), BTW, do they exist in nature? > > * emacs plugins(less preferably) or > > * vim plugins, > > > > please share links, configs, etc. > > > > The most needed features are: > > * go to declaration > > * code completion > > * easy navigation through the code > > > > > > Thanks in advance, > > > > Alexander > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Jun 26 16:59:21 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 26 Jun 2014 16:59:21 +0200 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: Hello, On Wed, Jun 25, 2014 at 11:18 AM, ami wrote: > > Which IDEs do you use to treat all the source tree(both Erlang & C) as a > single project? > I might use one IDE for C and another for Erlang. But it?s quite ugly and > inconvenient. > > Almost all of the developers at the Erlang/OTP group use Emacs+ctags for development. A few rebels use vim/slickedit and some other stuff. Personally I use Emacs+ctags and it works well enough. I've tried to use Eclipse in the past, but I can't stand it when my text editor sometimes decides to hang/crash so I've stopped using it. At times I do miss the reverse lookup/c-refactoring/auto-completion stuff of Eclipse, but not enough to move back :) and if I really needed it I'm sure there is an Emacs plugin for it somewhere. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@REDACTED Thu Jun 26 17:58:44 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 17:58:44 +0200 Subject: [erlang-questions] file:read_file an UTF-8 encoded file Message-ID: Hi list, This is a simple question, yet I haven?t found the right answer. Using Erlang/OTP 16B03-2: I read a file using file:read_file(?my_utf8_file.txt?). The result binary contains the 3 BOM bytes. I was not expecting that. Since this is such a high-level call, isn?t file:read_file/1 supposed to get rid of the byte order mark? So, how do you professional Erlang users read the contents of a UTF-8 encoded file on Erlang 16B03? All the bast, Cam From jay@REDACTED Thu Jun 26 18:03:34 2014 From: jay@REDACTED (Jay Nelson) Date: Thu, 26 Jun 2014 09:03:34 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <20140626001003.GD96473@ferdmbp.local> References: <20140625225242.GC96473@ferdmbp.local> <574CB3CE-8BB2-4151-BAB2-30981779BB8A@duomark.com> <20140626001003.GD96473@ferdmbp.local> Message-ID: <7A8DF371-8AD7-4732-B174-1CEF6222CFA6@duomark.com> On Jun 25, 2014, at 5:10 PM, Fred Hebert wrote: > What I see for these is therefore: > > 1. A presence management and registration app, let's call it presencerl; > 2. A lightweight self-registration process that contacts presencerl to > register. > > (MyApp) (Presencerl) > [MyApp_sup] [presencerl_sup]---ETS > / | \ / \ > [w1] [w1] [agent] [presencerl_local] [presencerl_remote] > > Where MyApp_sup can be using a rest_for_one strategy. The 'agent' > process is in charge of calling something like 'presencerl:register(App, > self())', and then it can just hibernate forever. We may try this just for grins. It is closer to the service style of things that I think should be in OTP?s future. The key is using monitors properly. I?ve been leaning toward rewriting our supervisor hierarchies to be shallower without children on init, then triggering the population of the hierarchy later with an FSM-style controller that is the marionette- master. > Using it that way, you decouple your service discovery from your > principal app, and can build multiple apps that all depend on presencerl > independently.You can even have 'sub-services' if you want, and you > just did away with your included applications. > > You can also disable specific services during partial upgrades without > needing to shut down other services running on the same node! It?s really just a tradeoff. Your goal was to eliminate included applications, mine was to have them so I have more control of the app. Just a preference (with consequences). I can understand fear of the complexity that arises with deep hierarchies and startup sequences, but I also see that in code where 8 or 10 applications are started there is no thought to how they interact. There is just a big function that starts them all, or the new ensure_all_started hack and no thought into how things shutdown because everyone who touches the code adds ?just one more? app. I would rather force new additions to have put some thought into why and when they are running and how failure occurs and what are its implications. > >> >> The ?lesser alternatives? I referred to resulted in situations where the >> presence subsystem went away but the service was available and running >> just fine, but not receiving traffic because it appeared to be offline. >> > > This doesn't really go away in this case, unless you make the presencerl > app permanent, which can then have it share similar failure thresholds > to your main app, something that is somewhat equivalent to shoving both > under the same supervisor. For presence I would definitely make it a permanent app. We have experienced real situations where the node is functioning normally and not advertising its availability. That is a problem for our service. And that was the fear of OP?s teammates originally. One we?ve experienced. jay From ivan@REDACTED Thu Jun 26 18:20:26 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 26 Jun 2014 17:20:26 +0100 Subject: [erlang-questions] file:read_file an UTF-8 encoded file In-Reply-To: References: Message-ID: <53AC484A.3040401@llaisdy.com> Could you use {ok, Pid} = file:open(F,[read, {encoding, utf8}]). Pid is an IoDevice, like a cursor. Then L = io:get_line(Pid, x). L is an ordinary erlang "string", i.e., a list of integers. You could have a maybe_strip_bom/1 function, eg for data in utf-8: maybe_strip_bom([65279|T]) -> T; maybe_strip_bom(T) -> T. Ivan On 26/06/2014 16:58, Camille Troillard wrote: > Hi list, > > This is a simple question, yet I haven?t found the right answer. > Using Erlang/OTP 16B03-2: > > I read a file using file:read_file(?my_utf8_file.txt?). > > The result binary contains the 3 BOM bytes. I was not expecting that. Since this is such a high-level call, isn?t file:read_file/1 supposed to get rid of the byte order mark? > > So, how do you professional Erlang users read the contents of a UTF-8 encoded file on Erlang 16B03? > > > All the bast, > Cam > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From essen@REDACTED Thu Jun 26 18:23:25 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 26 Jun 2014 18:23:25 +0200 Subject: [erlang-questions] file:read_file an UTF-8 encoded file In-Reply-To: References: Message-ID: <53AC48FD.5060006@ninenines.eu> file:read_file/1 reads a file as a sequence of bytes. It doesn't know what kind of file it is, or how to interpret it. It's not file:read_text_file/1 or similar, it's just read_file. It's not high level at all, it's just a convenient shortcut. On 06/26/2014 05:58 PM, Camille Troillard wrote: > Hi list, > > This is a simple question, yet I haven?t found the right answer. > Using Erlang/OTP 16B03-2: > > I read a file using file:read_file(?my_utf8_file.txt?). > > The result binary contains the 3 BOM bytes. I was not expecting that. Since this is such a high-level call, isn?t file:read_file/1 supposed to get rid of the byte order mark? > > So, how do you professional Erlang users read the contents of a UTF-8 encoded file on Erlang 16B03? > > > All the bast, > Cam > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From lists@REDACTED Thu Jun 26 18:37:15 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 18:37:15 +0200 Subject: [erlang-questions] file:read_file an UTF-8 encoded file In-Reply-To: <53AC48FD.5060006@ninenines.eu> References: <53AC48FD.5060006@ninenines.eu> Message-ID: <80E91245-006C-48C0-A02F-80E4FE6B63F0@tuli.pe> On 26 Jun 2014, at 18:23, Lo?c Hoguin wrote: > file:read_file/1 reads a file as a sequence of bytes. It doesn't know what kind of file it is, or how to interpret it. It's not file:read_text_file/1 or similar, it's just read_file. It's not high level at all, it's just a convenient shortcut. Thank you Lo?c, for this educative answer. But as you know file:open takes an encoding option, so it wouldn?t be totally insane to have the same on file:read_file/1. So I understand there is no ?high level? way of reading an entire text file in Erlang? From jay@REDACTED Thu Jun 26 19:16:17 2014 From: jay@REDACTED (Jay Nelson) Date: Thu, 26 Jun 2014 10:16:17 -0700 Subject: [erlang-questions] Alternative supervision approaches Message-ID: <05BEEA20-FF9B-4AD5-9CB6-744D76D634D6@duomark.com> I believe the supervisor and link constructs pre-date monitoring. Would supervision have been implemented differently in OTP if monitors were available (nudge, Lenart, Francesco)? Does anyone start supervisors without children and then use an external FSM to control starting of children as their approach to managing when services are available? One technique for allowing a service to fail and restart later when conditions have changed is to make a restart strategy for the supervisor of workers, but make its supervisor use a transient strategy. The workers will restart a few times, then the parent fails but does not restart. Monitoring plus some strategies for altering the setup environment can be used before reinstantiating the children on the transient supervisor. Anyone else use non-standard supervision approaches they would like to share? jay From raould@REDACTED Thu Jun 26 19:20:51 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 26 Jun 2014 10:20:51 -0700 Subject: [erlang-questions] Alternative supervision approaches In-Reply-To: <05BEEA20-FF9B-4AD5-9CB6-744D76D634D6@duomark.com> References: <05BEEA20-FF9B-4AD5-9CB6-744D76D634D6@duomark.com> Message-ID: > Anyone else use non-standard supervision approaches they > would like to share? this is a cool thread. please do share, y'all. gathering up some info on various "design patterns" (barf) people have come up with and vetted/critiqued/thrown away would be great. From raould@REDACTED Thu Jun 26 19:24:20 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 26 Jun 2014 10:24:20 -0700 Subject: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) Message-ID: > One technique for allowing a service to fail and restart later when > conditions have changed is to make a restart strategy for the > supervisor of workers, but make its supervisor use a transient > strategy. The workers will restart a few times, then the parent > fails but does not restart. Monitoring plus some strategies for > altering the setup environment can be used before reinstantiating > the children on the transient supervisor. while i love erlang and all this stuff, on the other hand it all feels like people are not having any love for things like actually modeling their system and doing static checking of it before hand. instead we just throw in some hacky timeouts and hope it will get unstuck eventually. that makes me really kinda sad, even if it does let people just get on with life and shipping products :-}. i wish things like TLA were more de rigeur. of course i'm the pot or kettle who lives in a glass house since i've never used TLA myself :-( From ulf@REDACTED Thu Jun 26 20:09:07 2014 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 26 Jun 2014 20:09:07 +0200 Subject: [erlang-questions] Alternative supervision approaches In-Reply-To: <05BEEA20-FF9B-4AD5-9CB6-744D76D634D6@duomark.com> References: <05BEEA20-FF9B-4AD5-9CB6-744D76D634D6@duomark.com> Message-ID: <1F17BC3F-9CEE-4117-A225-0822D00F376B@feuerlabs.com> On 26 Jun 2014, at 19:16, Jay Nelson wrote: > I believe the supervisor and link constructs pre-date monitoring. > Would supervision have been implemented differently in OTP if > monitors were available (nudge, Lenart, Francesco)? As it turns out, supervisors need both links and monitors. Links are needed for cascading exits, and monitors for orderly shutdown. Well, actually, supervisors would need a form of link that the child cannot *unlink*. If it did, it wouldn?t need monitors, and this also makes the cascading exit functionality slightly unsafe. > > Does anyone start supervisors without children and then use an > external FSM to control starting of children as their approach to > managing when services are available? Sure. I do that in kvdb, for example. > One technique for allowing a service to fail and restart later when > conditions have changed is to make a restart strategy for the > supervisor of workers, but make its supervisor use a transient > strategy. The workers will restart a few times, then the parent > fails but does not restart. Monitoring plus some strategies for > altering the setup environment can be used before reinstantiating > the children on the transient supervisor. > > Anyone else use non-standard supervision approaches they > would like to share? I once made an extension to supervisor.erl that allows the child to enquire about the restart history. I?ve found that complex restart scenarios are often frustrated by the fact that the child cannot tell the difference between the first restart and the nth restart following an escalated recovery. There?s something to be said for a brain-dead recovery mechanism, but sometimes, you really, really do need more. I actually have it lying around somewhere. I posted it to the list, and at some later point, managed to excavate it and save it from oblivion. BR; Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From jay@REDACTED Thu Jun 26 20:23:30 2014 From: jay@REDACTED (Jay Nelson) Date: Thu, 26 Jun 2014 11:23:30 -0700 Subject: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) Message-ID: Raoul Duke wrote: > while i love erlang and all this stuff, on the other hand it all feels > like people are not having any love for things like actually modeling > their system and doing static checking of it before hand. instead we > just throw in some hacky timeouts and hope it will get unstuck > eventually. In response to my post: > The workers will restart a few times, then the parent > fails but does not restart. Monitoring plus some strategies for > altering the setup environment can be used before reinstantiating > the children on the transient supervisor. I was referring to something formally based on an FSM and detecting the current environment and state of the node before restarting the children and not just using timeouts. Not sure if that was clear based on your response. jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity@REDACTED Thu Jun 26 20:52:56 2014 From: icfp.publicity@REDACTED (David Van Horn) Date: Thu, 26 Jun 2014 14:52:56 -0400 Subject: [erlang-questions] ICFP 2014 Call for Participation Message-ID: [ Please note that much of the block reservation of hotel rooms currently being held for ICFP participants will be released next week. The beginning of September is a very busy conference week in G?teborg, so there is high pressure on hotel rooms in that period. If you plan to attend ICFP 2014, it would be best to make your hotel reservations now before the block reservation expires. ] ===================================================================== Call for Participation ICFP 2014 19th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 31 - September 6, 2013 Gothenburg, Sweden http://icfpconference.org/icfp2014/ ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. A full week dedicated to functional programming: 1 conference, 1 symposium, 10 workshops, tutorials, programming contest results, student research competition * Accepted Papers: http://www.icfpconference.org/icfp2014/accepted.html * Local arrangements (including travel and accommodation): http://icfpconference.org/icfp2014/local.html * Registration is available via: https://regmaster4.com/2014conf/ICFP14/register.php Early registration is due 3 August, 2014. * Programming contest, 25-28 July, 2014: http://icfpcontest.org/ * Follow @icfp_conference on twitter for the latest news: http://twitter.com/#!/icfp_conference There are several events affiliated with ICFP: Sunday, August 31 ACM SIGPLAN Workshop on Generic Programming ACM SIGPLAN Workshop on Higher-order Programming with Effects Monday, September 1 ? Wednesday, September 3 ICFP Thursday, September 4 ACM SIGPLAN Commercial Users of Functional Programming: Day 1, Tutorials ACM SIGPLAN Haskell Symposium: Day 1 ACM SIGPLAN Workshop on Functional High-Performance Computing ACM SIGPLAN ML Family Workshop Friday, September 5 ACM SIGPLAN Commercial Users of Functional Programming: Day 2, Tutorials ACM SIGPLAN Haskell Symposium: Day 2 ACM SIGPLAN OCaml Workshop ACM SIGPLAN Erlang Workshop ACM SIGPLAN Workshop on Haskell and Rewriting Techniques Saturday, September 6 ACM SIGPLAN Commercial Users of Functional Programming: Day 3, Talks ACM SIGPLAN Haskell Implementors Workshop ACM SIGPLAN Workshop on Functional Art, Music, Modeling and Design Conference Organizers General Chair: Johan Jeuring, Utrecht University Program Chair: Manuel Chakravarty, University of New South Wales Local Arrangements Chair: Bj?rn von Sydow, Chalmers University Industrial Relations Chair: Anil Madhavapeddy, University of Cambridge Workshop Co-Chairs: Tom Schrijvers, Ghent University Sam Tobin-Hochstadt, Indiana University Programming Contest Co-Chairs: Duncan Coutts, Well Typed LLP Nicolas Wu, University of Oxford Student Research Competition Chair: Meng Wang, Chalmers University Publicity Chair: David Van Horn, University of Maryland Video Chair: Iavor Diatchki, Galois Malcolm Wallace, Standard Chartered Bank Industrial partners: Platinum partners Jane Street Capital Gold partners Google Microsoft Research Mozilla Oracle Labs Standard Chartered Bank Silver partners Bloomberg Credit Suisse CyberPoint Erlang Solutions Facebook Galois Klarna Lexifi Twitter Bronze partners IntelliFactory Opera Software QuviQ ===================================================================== From raould@REDACTED Thu Jun 26 21:10:16 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 26 Jun 2014 12:10:16 -0700 Subject: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) In-Reply-To: References: Message-ID: > I was referring to something formally based on an FSM and detecting the > current > environment and state of the node before restarting the children and not > just using > timeouts. Not sure if that was clear based on your response. whatever the mechanism, the point to me is that i get the impression that: a) it failed at all in the first place and b) it seems like it is not always an expected failure and c) the "fix" is to restart & pray and then if the prayers don't work then wait a little longer or do some as-yet-unspecified random jiggery-pokery of the 'environment' and start praying again. i'm not trying to say that formal methods are the be-all-end-all. but i do wish that the state of the art-and-practice was more into formal methods and model checking and all that jazz. by which i think i mean that i wish the barriers to using those things were lower. i ass/ume the effort required to go that route is large and always seen as bad roi unless one is working on nasa or healthcare type stuff. i just wonder how many other people have similar pie-in-the-sky day-dream wishes or if the standard groupthink is, "eh, whatever, restarts will be enough to get us shipping and maybe making a profit!" i mean i personally wouldn't be able to use model checking because i'm for the most part utterly ignorant wrt the tools. so i would practically pragmatically firmly be in the "eh, whatever, restarts will be enough" camp! on the other flipper, if one were programming with CSP or some such then in theory you'd "simply" run FDR over your code and get answers about deadlock for "free". vs. doing something in TLA and then maintaing it vs. the "real" code. etc. yes i am a blithering rambler. From essen@REDACTED Thu Jun 26 21:40:31 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 26 Jun 2014 21:40:31 +0200 Subject: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) In-Reply-To: References: Message-ID: <53AC772F.9000403@ninenines.eu> On 06/26/2014 09:10 PM, Raoul Duke wrote: >> I was referring to something formally based on an FSM and detecting the >> current >> environment and state of the node before restarting the children and not >> just using >> timeouts. Not sure if that was clear based on your response. > > whatever the mechanism, the point to me is that i get the impression that: > > a) it failed at all in the first place and b) it seems like it is not > always an expected failure and c) the "fix" is to restart & pray and > then if the prayers don't work then wait a little longer or do some > as-yet-unspecified random jiggery-pokery of the 'environment' and > start praying again. a) Even statically checked things fail. The program may run out of memory. The network might go down. Network might be slow or bumpy. Hardware may fail. Knowing that your program works on paper is nice, but has its limits. b) An infinite number of things may fail. The only thing you can expect is that something *will* fail. You can't prevent that. You can only make sure that when something does fail, you recover as gracefully as possible. c) I'm not sure where you got the "wait a little longer" part, because neither Erlang nor OTP waits. The point is to restart processes in a consistent state, and then if we can't do that (for example we depend on an ets table managed above in the tree), restart a larger group of processes. The VM crashing is when something *really bad* happened and you typically want a dirty human to look at it, but many odd failures aren't worth spending much time over. > i just wonder how many other people have similar pie-in-the-sky > day-dream wishes or if the standard groupthink is, "eh, whatever, > restarts will be enough to get us shipping and maybe making a profit!" It's about solving a real world problem, which is that programs fail. > on the other flipper, if one were programming with CSP or some such > then in theory you'd "simply" run FDR over your code and get answers > about deadlock for "free". vs. doing something in TLA and then > maintaing it vs. the "real" code. Dialyzer has some race condition checks nowadays. Concuerror can help you find many race conditions and deadlocks too. But neither of those can anticipate all possible cases that make program fail. They are very nice to have because they allow you to increase the quality of your codebase, but they do not solve the problem of programs failing. You can think of and test for many failure cases but you can never cover them all. You still need supervision and restarts regardless of how well your codebase is tested. Stop dreaming and start building real things, I say. -- Lo?c Hoguin http://ninenines.eu From lists@REDACTED Thu Jun 26 21:46:19 2014 From: lists@REDACTED (Camille Troillard) Date: Thu, 26 Jun 2014 21:46:19 +0200 Subject: [erlang-questions] file:read_file an UTF-8 encoded file In-Reply-To: <53AC48FD.5060006@ninenines.eu> References: <53AC48FD.5060006@ninenines.eu> Message-ID: <1885A646-AFB7-4D00-A350-3DB28E045FB1@tuli.pe> Here is what came to: % Read a file as a binary, knowing the contents is UTF-8 encoded text. read_utf8_file(Name) -> {ok, Binary} = file:read_file(Name), {_, Skip} = unicode:bom_to_encoding(Binary), <<_:Skip/unit:8, Contents/binary>> = Binary, Contents. Thanks to all for your advices. On 26 Jun 2014, at 18:23, Lo?c Hoguin wrote: > file:read_file/1 reads a file as a sequence of bytes. It doesn't know what kind of file it is, or how to interpret it. It's not file:read_text_file/1 or similar, it's just read_file. It's not high level at all, it's just a convenient shortcut. > > On 06/26/2014 05:58 PM, Camille Troillard wrote: >> Hi list, >> >> This is a simple question, yet I haven?t found the right answer. >> Using Erlang/OTP 16B03-2: >> >> I read a file using file:read_file(?my_utf8_file.txt?). >> >> The result binary contains the 3 BOM bytes. I was not expecting that. Since this is such a high-level call, isn?t file:read_file/1 supposed to get rid of the byte order mark? >> >> So, how do you professional Erlang users read the contents of a UTF-8 encoded file on Erlang 16B03? >> >> >> All the bast, >> Cam >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu From raould@REDACTED Thu Jun 26 21:48:20 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 26 Jun 2014 12:48:20 -0700 Subject: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) In-Reply-To: <53AC772F.9000403@ninenines.eu> References: <53AC772F.9000403@ninenines.eu> Message-ID: > Stop dreaming and start building real things, I say. i don't disagree. :-) i don't think i said, i wasn't trying to say that monitoring and restarting is something we can do away with. i hold out weird hope for more formal methods someday automagically helping out with the failures that we actually *could* study 'on paper' and thus avoid. yes there will always the tripping over the power cord type stuff even though. still even there i'd love it if my model checking could tell me, "dood, if the power goes out at this spot of the code, then your db will be totally horked and your recovery will be a nightmare" etc.) e.g. this: http://www.hpl.hp.com/techreports/2011/HPL-2011-44.html is not at the formal methods level but it seems like a nice attempt to incrementally do more study and nailing down of such issues above and beyond the run-of-the-mill restart-and-pray stuff. From lloyd@REDACTED Thu Jun 26 21:50:24 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Thu, 26 Jun 2014 15:50:24 -0400 (EDT) Subject: [erlang-questions] =?utf-8?q?obviously_no_bugs=3F_=28Re=3A_Altern?= =?utf-8?q?ative_supervision_approaches=29?= In-Reply-To: <53AC772F.9000403@ninenines.eu> References: <53AC772F.9000403@ninenines.eu> Message-ID: <1403812224.93599436@apps.rackspace.com> Hello, This is so clear and succinct. It belongs high up in the Erlang docs. Best, L. -----Original Message----- From: "Lo?c Hoguin" Sent: Thursday, June 26, 2014 3:40pm To: "Raoul Duke" , "erlang-questions" Subject: Re: [erlang-questions] obviously no bugs? (Re: Alternative supervision approaches) On 06/26/2014 09:10 PM, Raoul Duke wrote: >> I was referring to something formally based on an FSM and detecting the >> current >> environment and state of the node before restarting the children and not >> just using >> timeouts. Not sure if that was clear based on your response. > > whatever the mechanism, the point to me is that i get the impression that: > > a) it failed at all in the first place and b) it seems like it is not > always an expected failure and c) the "fix" is to restart & pray and > then if the prayers don't work then wait a little longer or do some > as-yet-unspecified random jiggery-pokery of the 'environment' and > start praying again. a) Even statically checked things fail. The program may run out of memory. The network might go down. Network might be slow or bumpy. Hardware may fail. Knowing that your program works on paper is nice, but has its limits. b) An infinite number of things may fail. The only thing you can expect is that something *will* fail. You can't prevent that. You can only make sure that when something does fail, you recover as gracefully as possible. c) I'm not sure where you got the "wait a little longer" part, because neither Erlang nor OTP waits. The point is to restart processes in a consistent state, and then if we can't do that (for example we depend on an ets table managed above in the tree), restart a larger group of processes. The VM crashing is when something *really bad* happened and you typically want a dirty human to look at it, but many odd failures aren't worth spending much time over. > i just wonder how many other people have similar pie-in-the-sky > day-dream wishes or if the standard groupthink is, "eh, whatever, > restarts will be enough to get us shipping and maybe making a profit!" It's about solving a real world problem, which is that programs fail. > on the other flipper, if one were programming with CSP or some such > then in theory you'd "simply" run FDR over your code and get answers > about deadlock for "free". vs. doing something in TLA and then > maintaing it vs. the "real" code. Dialyzer has some race condition checks nowadays. Concuerror can help you find many race conditions and deadlocks too. But neither of those can anticipate all possible cases that make program fail. They are very nice to have because they allow you to increase the quality of your codebase, but they do not solve the problem of programs failing. You can think of and test for many failure cases but you can never cover them all. You still need supervision and restarts regardless of how well your codebase is tested. Stop dreaming and start building real things, I say. -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From felixgallo@REDACTED Thu Jun 26 22:35:11 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Thu, 26 Jun 2014 13:35:11 -0700 Subject: [erlang-questions] Dependencies, included applications and supervision In-Reply-To: <53AB3F19.6080501@ninenines.eu> References: <941A712E-2A54-41F0-8980-D869881582DC@duomark.com> <53AB3377.40406@ninenines.eu> <79A8EF94-3FCA-478F-9A5D-8173B98F4089@duomark.com> <53AB3629.3060209@ninenines.eu> <373545A9-A4E3-4FC3-8A20-7D084966990F@duomark.com> <53AB3F19.6080501@ninenines.eu> Message-ID: On Wed, Jun 25, 2014 at 2:28 PM, Lo?c Hoguin wrote: > > > But why would you make the application crash if you need it to stay alive? > If your DB driver application crashes because the DB is gone, something is > *very* wrong with your DB driver application. I personally would stay the > hell away from it. > This is one of those things that as an erlang newbie I don't have a great intuition for yet. On one hand I can imagine a properly implemented database application that, when the database goes away, crashes, is restarted appropriately, restores the connection or picks a new slave or whatever, etc., etc. -- and that design could be quite clean, free of ugly error handling code, and so on. On the other hand, I can also envision a scenario under which that is a giant pain in the ass for clients of the database application, especially if there's any asynchronous messaging involved. I know there's one subschool of the 'let it crash' mentality that appends '...until the error shows up in the log, and then update your code to handle it'. And there's a subschool also which seems to draw a distinction between infrastructure applications (e.g., db drivers) and application-applications and applies 'let it crash' to each slightly differently. In the end I know it's a pragmatic architectural decision which is heavily dependent on circumstances, but it would be interesting to hear from the old erlang dogs about, e.g., db drivers and other core underpinnings and what the battle-tested best practice is. F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Jun 27 00:49:08 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 27 Jun 2014 10:49:08 +1200 Subject: [erlang-questions] io module encoding In-Reply-To: References: Message-ID: <8DA62AAB-FE75-460B-9A38-A6E1E35059E7@cs.otago.ac.nz> I notice that you are just querying os:getenv("LC_CYTPE"). But it's a little more complicated. To determine the value of an LC_xxxx property: (1) First check LC_ALL. If that's set, use it. Otherwise, (2) next check LC_xxxx. If that's set, use it. Otherwise, (3) next check LANG. If that's set, use it. Otherwise, (4) use the default C locale. While LC_CTYPE is set the same in both your examples, it's possible that LC_ALL might be set differently. Transcript: sh% export LC_CTYPE=en_NZ.UTF-8 LC_ALL=en_NZ.ISO8859-1 sh% erl 1> io:getopts(). [... {encoding,latin1}] From kukhyun@REDACTED Fri Jun 27 03:39:42 2014 From: kukhyun@REDACTED (KukHyun Lee) Date: Fri, 27 Jun 2014 10:39:42 +0900 Subject: [erlang-questions] os:cmd string parsing bug on Windows's erl Message-ID: Hello, erl on Windows7, os:cmd doesn't parse 'white-space'. C:\>erl Eshell V6.0 (abort with ^G) 1> os:cmd("c:/Program Files/test.exe"). 'c:/Program' is not recognized as an internal or external command, operable program or batch file. [] Same bug exist in escript. but no problem in werl. C:\>werl Erlang/OTP 17 [erts-6.0] [64-bit] [smp:4:4] [async-threads:10] Eshell V6.0 (abort with ^G) 1> os:cmd("c:/Program Files/test.exe"). [] Thanks, KukHyun. From juan.facorro@REDACTED Fri Jun 27 04:41:40 2014 From: juan.facorro@REDACTED (Juan Facorro) Date: Thu, 26 Jun 2014 19:41:40 -0700 (PDT) Subject: [erlang-questions] Documentation for list_to_binary In-Reply-To: References: Message-ID: <69c53567-8a28-4098-96fe-29b2eee37840@googlegroups.com> Hi Paulo, I might be doing something wrong here but the *Description* section I see in http://www.erlang.org/doc/man/erlang.html is the following: DESCRIPTION By convention, most built-in functions (BIFs) are seen as being in the module erlang. A number of the BIFs are viewed more or less as part of the Erlang programming language and are *auto-imported*. Thus, it is not necessary to specify the module name and both the callsatom_to_list(Erlang) and erlang:atom_to_list(Erlang) are identical. In the text, auto-imported BIFs are listed without module prefix. BIFs listed with module prefix are not auto-imported. BIFs may fail for a variety of reasons. All BIFs fail with reason badarg if they are called with arguments of an incorrect type. The other reasons that may make BIFs fail are described in connection with the description of each individual BIF. Some BIFs may be used in guard tests, these are marked with "Allowed in guard tests". I couldn't find the reference to *erlang(3)* you mention. Cheers, Juan On Wednesday, June 25, 2014 11:04:39 AM UTC-3, Paulo F. Oliveira wrote: > > Hi. > > Using Google to search for "erlang list_to_binary" the first result I > get is http://www.erlang.org/doc/man/erlang.html, which states, in the > Description "The module erlang is moved to the runtime system > application. Please see erlang(3) in the erts reference manual > instead." > > The link presented by erlang(3) points to the same page. Is this normal? > > Thanks. Cheers. > > - Paulo F. Oliveira > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Fri Jun 27 10:29:49 2014 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 27 Jun 2014 10:29:49 +0200 Subject: [erlang-questions] os:cmd string parsing bug on Windows's erl In-Reply-To: References: Message-ID: Hello, On Fri, Jun 27, 2014 at 3:39 AM, KukHyun Lee wrote: > Hello, > > erl on Windows7, os:cmd doesn't parse 'white-space'. > > C:\>erl > Eshell V6.0 (abort with ^G) > 1> os:cmd("c:/Program Files/test.exe"). > 'c:/Program' is not recognized as an internal or external command, > operable program or batch file. > [] > > Thanks for reporting this bug! I believe that I have fixed it already. Unfortunately the fix introduces a backwards incompatibility so it will not be released until OTP 18. The fix is already merged into the master branch at github. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Jun 27 11:54:01 2014 From: eriksoe@REDACTED (=?UTF-8?Q?Erik_S=C3=B8e_S=C3=B8rensen?=) Date: Fri, 27 Jun 2014 11:54:01 +0200 Subject: [erlang-questions] os:cmd string parsing bug on Windows's erl In-Reply-To: References: Message-ID: While on the topic, could we please have an "cmd()" which takes a program name and a list of parameters, instead of just a string? That would be less prone to both whitespace errors and injection issues. Using os:cmd() with anything but a fixed string always gives me an uneasy feeling: 15> Echo = fun(Text) -> os:cmd("echo "++Text) end. #Fun 16> Echo("Hello!"). "Hello!\n" 17> Echo("; date"). "\nfre jun 27 11:51:07 CEST 2014\n" (On the other hand, I'm glad that open_port() *does* support the program name + argument list mode.) 2014-06-27 10:29 GMT+02:00 Lukas Larsson : > Hello, > > On Fri, Jun 27, 2014 at 3:39 AM, KukHyun Lee wrote: > >> Hello, >> >> erl on Windows7, os:cmd doesn't parse 'white-space'. >> >> C:\>erl >> Eshell V6.0 (abort with ^G) >> 1> os:cmd("c:/Program Files/test.exe"). >> 'c:/Program' is not recognized as an internal or external command, >> operable program or batch file. >> [] >> >> > Thanks for reporting this bug! I believe that I have fixed it already. > Unfortunately the fix introduces a backwards incompatibility so it will not > be released until OTP 18. The fix is already merged into the master branch > at github. > > Lukas > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m3oucat@REDACTED Fri Jun 27 12:03:06 2014 From: m3oucat@REDACTED (ami) Date: Fri, 27 Jun 2014 13:03:06 +0300 Subject: [erlang-questions] matching Rest/binary using bit syntax - why does it have to be the last element specified if all other elements are sized ? In-Reply-To: <635810529.61477.1403681828225.JavaMail.zimbra@tpip.net> References: <3FBAF25A-F91F-4331-A9A8-3E3E54043D4C@bigpond.net.au> <635810529.61477.1403681828225.JavaMail.zimbra@tpip.net> Message-ID: <5954F82B-6B9D-4831-8E6A-51134DC1DDD8@gmail.com> Hi Andreas, You wrote: > As you demonstrated, no reverse operation is needed. The compiler > could actually be smart enough to generate above code by itself > when given a match like: > > <> = BinC But what do you mean under ?the compiler could actually be smart enough" But when I?m trying 6> A = <<1,2,3,4,5>>. <<1,2,3,4,5>> 7> <> = A. Im getting an error: * 1: a binary field without size is only allowed at the end of a binary pattern (Erlang/OTP 17 [erts-6.0] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]) The same thing if I try not just try out the code in erlang shell, but if I try to write a file & compile it: -module(test). -export([mytest/0]). mytest() -> A = <<1,2,3,4,5>>, <> = A, [H,T]. a1$ erlc test.erl test.erl:7: a binary field without size is only allowed at the end of a binary pattern Kind regards, Alex On Jun 25, 2014, at 10:37, Andreas Schultz wrote: > Hi, > > ----- Original Message ----- >> Hello, >> >> Here is one way to make it: >> >> Head = byte_size(BinC) * 8 - 24. >> <> = BinC. >> >> The reverse operation for binary is expensive. > > As you demonstrated, no reverse operation is needed. The compiler > could actually be smart enough to generate above code by itself > when given a match like: > > <> = BinC > > Even having the variable length part (as long as there is only > one) somewhere in the middle, would still allow the compiler > to construct the expression. > > Things would become a bit more complicated in case or guard > matches. > > Question to experts of the Erlang internals: Is there a non trivial > reason the compiler/runtime system can't handle such matches? > > Regards > Andreas > >> >> Best Regards, >> Dmitry >-|-|-(*> >> >> >> On 25.6.2014, at 4.11, Richard McLean < rmcl2303@REDACTED > wrote: >> >> >> >> >> This is my first question to the mailing list so apologies if there are any >> newbie errors. >> >> Regarding bit syntax and pattern matching, you can match the remaining part >> of the binary using the Rest/binary idiom as long as the element of >> unspecified size (ie Rest/binary) is at the end of the pattern (ie. the very >> last specified element)... >> >> eg. suppose I have a binary of unknown size (here I'm using <<1,2,3,4>> as >> the example) and I want to separate it into 2 binaries - one containing the >> first 8 bits, and the other containing the remainder... >> >> eg. >> 1> BinA = <<1,2,3,4>>. >> <<1,2,3,4>> >> 2> <> = BinA. >> <<1,2,3,4>> >> 3> BinB. >> <<1>> >> 4> BinC. >> <<2,3,4>> >> >> So far so good... >> >> Now suppose I want to take the same input binary (of unknown size) and this >> time I want to separate it into 2 binaries - one containing the LAST 24 bits >> (say some sort of footer), and the other containing the remainder (ie all >> the PRECEDING data)... >> >> This should still be possible from the the compiler/erlang VM point of view >> as we are still specifying all the element sizes except one, but erlang >> generates an error if the binary element of unspecified size is anything but >> the last match element. >> >> eg. >> 1> BinA = <<1,2,3,4>>. >> <<1,2,3,4>> >> 2> <> = BinA. >> * 1: a binary field without size is only allowed at the end of a binary >> pattern >> >> What is the easiest way to achieve this sort of thing ? >> I'm supposing the binary could be reversed, the front X bits extracted, then >> reversing the extracted binary and the remainder, but is there an easier way >> ? >> >> And if there are any of the erlang maintainers reading this, would it be >> possible in a future release to change the rules on the Rest/binary idiom to >> allow Rest/binary to be any element of the match pattern as long as all >> other elements are size specified ? >> >> I don't think it would be a big change to the implement but perhaps there are >> hidden gotchas I'm not considering ? >> >> Regards >> >> Richard >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From m3oucat@REDACTED Fri Jun 27 12:44:52 2014 From: m3oucat@REDACTED (ami) Date: Fri, 27 Jun 2014 13:44:52 +0300 Subject: [erlang-questions] Which IDE do you use for Erlang/OTP core development? In-Reply-To: References: <86A7A4A8-9C0F-4FD5-9BF3-89127C081036@gmail.com> Message-ID: Thanks a lot to all for your advices! I decided to settle down with IntellijIDEA + erlang plugin(for erlang files) and a separate IDE for C files. I tried emacs+ distel, but it?s quite buggy & it seems that it?s not supported anymore. Kind regards, Alex On Jun 26, 2014, at 17:59, Lukas Larsson wrote: > Hello, > > On Wed, Jun 25, 2014 at 11:18 AM, ami wrote: > > Which IDEs do you use to treat all the source tree(both Erlang & C) as a single project? > I might use one IDE for C and another for Erlang. But it?s quite ugly and inconvenient. > > > Almost all of the developers at the Erlang/OTP group use Emacs+ctags for development. A few rebels use vim/slickedit and some other stuff. > > Personally I use Emacs+ctags and it works well enough. I've tried to use Eclipse in the past, but I can't stand it when my text editor sometimes decides to hang/crash so I've stopped using it. At times I do miss the reverse lookup/c-refactoring/auto-completion stuff of Eclipse, but not enough to move back :) and if I really needed it I'm sure there is an Emacs plugin for it somewhere. > > Lukas From alcosholik@REDACTED Fri Jun 27 14:39:11 2014 From: alcosholik@REDACTED (Alexei Sholik) Date: Fri, 27 Jun 2014 15:39:11 +0300 Subject: [erlang-questions] Efficiently backing up a DETS files Message-ID: Hi all, I've been thinking about and googling for ways to back up a running dets database (i.e. with no interruption to the main service using it) and here's what I have come up with so far. 1. On the same node that currently has the dets file open, create an empty ETS table and another empty dets file. Call dets:to_ets and then ets:to_dets to write to the new dets file. After closing the latter file it will be safe to move it to the backup location. 2. Open a new dets file and use dets:bchunk on the production file in combination with dets:init_table. I wasn't sure if init_table would iterate over the original dets file automatically (iow, handling all the continuations before receiving '$end_of_table'). 3. Use one of the traversal functions to copy elements from one dets file to another one. I first thought the 1st approach to be the most efficient one (provided there is enough free RAM for the temporary ETS table). However, if bchunk() works like this with init_table(): TableSize = dets:info(my_table, size), dets:open_file(new_table, [{min_no_slots, TableSize}]), InitFun = dets:bchunk(my_table, start), dets:init_table(new_table, InitFun, [{min_no_slots, TableSize}, {format, bchunk}]), dets:close(new_table). then this 2nd approach looks like the best candidate. Here I could also use 'ram_file' option for new_table to speed up the subsequent init_table() call provided there is enough free RAM. Is this correct? I will appreciate anyone pointing out mistakes in my reasoning above. Thanks -- Best regards Alexei Sholik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tty.erlang@REDACTED Fri Jun 27 14:58:03 2014 From: tty.erlang@REDACTED (T Ty) Date: Fri, 27 Jun 2014 13:58:03 +0100 Subject: [erlang-questions] Efficiently backing up a DETS files In-Reply-To: References: Message-ID: Any reason why you don't want to run Mnesia instead and use it's backup and restore functions ? On Fri, Jun 27, 2014 at 1:39 PM, Alexei Sholik wrote: > Hi all, > > I've been thinking about and googling for ways to back up a running dets > database (i.e. with no interruption to the main service using it) and > here's what I have come up with so far. > > 1. On the same node that currently has the dets file open, create an empty > ETS table and another empty dets file. Call dets:to_ets and then > ets:to_dets to write to the new dets file. After closing the latter file it > will be safe to move it to the backup location. > > 2. Open a new dets file and use dets:bchunk on the production file in > combination with dets:init_table. I wasn't sure if init_table would iterate > over the original dets file automatically (iow, handling all the > continuations before receiving '$end_of_table'). > > 3. Use one of the traversal functions to copy elements from one dets file > to another one. > > I first thought the 1st approach to be the most efficient one (provided > there is enough free RAM for the temporary ETS table). However, if bchunk() > works like this with init_table(): > > TableSize = dets:info(my_table, size), > dets:open_file(new_table, [{min_no_slots, TableSize}]), > InitFun = dets:bchunk(my_table, start), > dets:init_table(new_table, InitFun, [{min_no_slots, TableSize}, > {format, bchunk}]), > dets:close(new_table). > > then this 2nd approach looks like the best candidate. Here I could also > use 'ram_file' option for new_table to speed up the subsequent init_table() > call provided there is enough free RAM. Is this correct? > > I will appreciate anyone pointing out mistakes in my reasoning above. > > Thanks > > -- > Best regards > Alexei Sholik > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Fri Jun 27 15:14:03 2014 From: shayan@REDACTED (Shayan Pooya) Date: Fri, 27 Jun 2014 09:14:03 -0400 Subject: [erlang-questions] raw_read_file_info In-Reply-To: References: <53AAAD03.5000308@ninenines.eu> Message-ID: Disco is also using prim_file which is inconvenient because we had to copy and change some other modules to work with prim_file (e.g. https://github.com/discoproject/disco/blob/develop/master/src/discozip.erl). I am still looking for a better solution. On Wed, Jun 25, 2014 at 7:26 AM, Max Lapshin wrote: > Yes, really. > > Flussonic is using prim_file directly almost everywhere, because using > central file server doesn't allow to scale. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.liden@REDACTED Fri Jun 27 15:22:57 2014 From: magnus.liden@REDACTED (Magnus Liden) Date: Fri, 27 Jun 2014 15:22:57 +0200 Subject: [erlang-questions] Documentation for list_to_binary In-Reply-To: <69c53567-8a28-4098-96fe-29b2eee37840@googlegroups.com> References: <69c53567-8a28-4098-96fe-29b2eee37840@googlegroups.com> Message-ID: <53AD7031.4040100@ericsson.com> Hi, We corrected this faulty document yesterday. There was a problem in the script generating the online documentation, thanks for reporting! Regards, Magnus Lid?n Erlang/OTP On 06/27/2014 04:41 AM, Juan Facorro wrote: > Hi Paulo, > > I might be doing something wrong here but the *Description* section I > see in http://www.erlang.org/doc/man/erlang.html is the following: > > > DESCRIPTION > > By convention, most built-in functions (BIFs) are seen as being in the > module erlang. A number of the BIFs are viewed more or less as part of > the Erlang programming language and are *auto-imported*. Thus, it is > not necessary to specify the module name and both the > callsatom_to_list(Erlang) and erlang:atom_to_list(Erlang) are identical. > > In the text, auto-imported BIFs are listed without module prefix. BIFs > listed with module prefix are not auto-imported. > > BIFs may fail for a variety of reasons. All BIFs fail with reason > badarg if they are called with arguments of an incorrect type. The > other reasons that may make BIFs fail are described in connection with > the description of each individual BIF. > > Some BIFs may be used in guard tests, these are marked with "Allowed > in guard tests". > > I couldn't find the reference to *erlang(3)* you mention. > > Cheers, > > Juan > > On Wednesday, June 25, 2014 11:04:39 AM UTC-3, Paulo F. Oliveira wrote: > > Hi. > > Using Google to search for "erlang list_to_binary" the first result I > get is http://www.erlang.org/doc/man/erlang.html > , which states, in the > Description "The module erlang is moved to the runtime system > application. Please see erlang(3) in the erts reference manual > instead." > > The link presented by erlang(3) points to the same page. Is this > normal? > > Thanks. Cheers. > > - Paulo F. Oliveira > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Jun 27 15:54:00 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 27 Jun 2014 15:54:00 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: References: <53AAAD03.5000308@ninenines.eu> Message-ID: <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> Once #408 [1] is merged, you will be able to use ?file? with almost no overhead in ?raw? mode for most operations. [1] https://github.com/erlang/otp/pull/408 -- Anthony Ramine Le 25 juin 2014 ? 13:26, Max Lapshin a ?crit : > Flussonic is using prim_file directly almost everywhere, because using central file server doesn't allow to scale. > From essen@REDACTED Fri Jun 27 15:56:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 27 Jun 2014 15:56:19 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> Message-ID: <53AD7803.9050103@ninenines.eu> There is no raw option for most file functions, including the very useful read_file_info. On 06/27/2014 03:54 PM, Anthony Ramine wrote: > Once #408 [1] is merged, you will be able to use ?file? with almost no overhead in ?raw? mode for most operations. > > [1] https://github.com/erlang/otp/pull/408 > -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Fri Jun 27 16:03:20 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 27 Jun 2014 16:03:20 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: <53AD7803.9050103@ninenines.eu> References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> Message-ID: AFAIK, most functions in file can take a #file_descriptor{} and these end up as direct calls to #file_descriptor.module which is prim_file when ?raw? is given to file:open/2. -- Anthony Ramine Le 27 juin 2014 ? 15:56, Lo?c Hoguin a ?crit : > There is no raw option for most file functions, including the very useful read_file_info. From richard.youngkin@REDACTED Fri Jun 27 16:08:05 2014 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Fri, 27 Jun 2014 08:08:05 -0600 Subject: [erlang-questions] erlang-questions Digest, Vol 171, Issue 9 In-Reply-To: References: Message-ID: Fred Hebert's blog - It's about the guarantees - has a good discussion regarding why it's not always about "restart & pray" http://ferd.ca/it-s-about-the-guarantees.html Cheers, Rich > Message: 20 > Date: Thu, 26 Jun 2014 21:40:31 +0200 > From: Lo?c Hoguin > To: Raoul Duke , erlang-questions > > Subject: Re: [erlang-questions] obviously no bugs? (Re: Alternative > supervision approaches) > Message-ID: <53AC772F.9000403@REDACTED> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 06/26/2014 09:10 PM, Raoul Duke wrote: > >> I was referring to something formally based on an FSM and detecting the > >> current > >> environment and state of the node before restarting the children and not > >> just using > >> timeouts. Not sure if that was clear based on your response. > > > > whatever the mechanism, the point to me is that i get the impression > that: > > > > a) it failed at all in the first place and b) it seems like it is not > > always an expected failure and c) the "fix" is to restart & pray and > > then if the prayers don't work then wait a little longer or do some > > as-yet-unspecified random jiggery-pokery of the 'environment' and > > start praying again. > > a) Even statically checked things fail. The program may run out of > memory. The network might go down. Network might be slow or bumpy. > Hardware may fail. Knowing that your program works on paper is nice, but > has its limits. > > b) An infinite number of things may fail. The only thing you can expect > is that something *will* fail. You can't prevent that. You can only make > sure that when something does fail, you recover as gracefully as possible. > > c) I'm not sure where you got the "wait a little longer" part, because > neither Erlang nor OTP waits. The point is to restart processes in a > consistent state, and then if we can't do that (for example we depend on > an ets table managed above in the tree), restart a larger group of > processes. The VM crashing is when something *really bad* happened and > you typically want a dirty human to look at it, but many odd failures > aren't worth spending much time over. > > > i just wonder how many other people have similar pie-in-the-sky > > day-dream wishes or if the standard groupthink is, "eh, whatever, > > restarts will be enough to get us shipping and maybe making a profit!" > > It's about solving a real world problem, which is that programs fail. > > > on the other flipper, if one were programming with CSP or some such > > then in theory you'd "simply" run FDR over your code and get answers > > about deadlock for "free". vs. doing something in TLA and then > > maintaing it vs. the "real" code. > > Dialyzer has some race condition checks nowadays. Concuerror can help > you find many race conditions and deadlocks too. > > But neither of those can anticipate all possible cases that make program > fail. They are very nice to have because they allow you to increase the > quality of your codebase, but they do not solve the problem of programs > failing. > > You can think of and test for many failure cases but you can never cover > them all. You still need supervision and restarts regardless of how well > your codebase is tested. > > Stop dreaming and start building real things, I say. > > -- > Lo?c Hoguin > http://ninenines.eu > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alcosholik@REDACTED Fri Jun 27 16:20:28 2014 From: alcosholik@REDACTED (Alexei Sholik) Date: Fri, 27 Jun 2014 17:20:28 +0300 Subject: [erlang-questions] Efficiently backing up a DETS files In-Reply-To: References: Message-ID: I shied away from the added complexity and learning curve of Mnesia. My simple use case involves permanently storing key-value data that is not going to be modified or searched for. I'm not using RAM storage either because I have modest amounts of memory. Data is read not that often, so dets works just fine for me. I wasn't aware of Mnesia's builtin backup facilities though. Thanks for mentioning that. On Fri, Jun 27, 2014 at 3:58 PM, T Ty wrote: > Any reason why you don't want to run Mnesia instead and use it's backup > and restore functions ? > > > On Fri, Jun 27, 2014 at 1:39 PM, Alexei Sholik > wrote: > >> Hi all, >> >> I've been thinking about and googling for ways to back up a running dets >> database (i.e. with no interruption to the main service using it) and >> here's what I have come up with so far. >> >> 1. On the same node that currently has the dets file open, create an >> empty ETS table and another empty dets file. Call dets:to_ets and then >> ets:to_dets to write to the new dets file. After closing the latter file it >> will be safe to move it to the backup location. >> >> 2. Open a new dets file and use dets:bchunk on the production file in >> combination with dets:init_table. I wasn't sure if init_table would iterate >> over the original dets file automatically (iow, handling all the >> continuations before receiving '$end_of_table'). >> >> 3. Use one of the traversal functions to copy elements from one dets file >> to another one. >> >> I first thought the 1st approach to be the most efficient one (provided >> there is enough free RAM for the temporary ETS table). However, if bchunk() >> works like this with init_table(): >> >> TableSize = dets:info(my_table, size), >> dets:open_file(new_table, [{min_no_slots, TableSize}]), >> InitFun = dets:bchunk(my_table, start), >> dets:init_table(new_table, InitFun, [{min_no_slots, TableSize}, >> {format, bchunk}]), >> dets:close(new_table). >> >> then this 2nd approach looks like the best candidate. Here I could also >> use 'ram_file' option for new_table to speed up the subsequent init_table() >> call provided there is enough free RAM. Is this correct? >> >> I will appreciate anyone pointing out mistakes in my reasoning above. >> >> Thanks >> >> -- >> Best regards >> Alexei Sholik >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Best regards Alexei Sholik -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jun 27 16:21:30 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 27 Jun 2014 16:21:30 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> Message-ID: <53AD7DEA.9000105@ninenines.eu> The functions that operate on *open* files, yes. Not read_file_info. On 06/27/2014 04:03 PM, Anthony Ramine wrote: > AFAIK, most functions in file can take a #file_descriptor{} and these end up as direct calls to #file_descriptor.module which is prim_file when ?raw? is given to file:open/2. > -- Lo?c Hoguin http://ninenines.eu From alcosholik@REDACTED Fri Jun 27 16:26:50 2014 From: alcosholik@REDACTED (Alexei Sholik) Date: Fri, 27 Jun 2014 17:26:50 +0300 Subject: [erlang-questions] Failure semantics of dets:insert_new vs dets:insert Message-ID: The signature for dets:insert_new is insert(Name, Objects) -> ok | {error, Reason} However, in my use case, I'm using a hash of the value as the key. So I thought I'd switch to using insert_new because that might be slightly more efficient (no need to update stored value). But the signature for insert_new is insert_new(Name, Objects) -> boolean() In this case, false only indicates that a value for the key is already in the table. What about failure cases of insert()? With insert() I have this code case dets:insert(table, {Key,Value}) of ok -> ok; {error, _}=Other -> Other end With insert_new it turns to just dets:insert_new(table, {Key,Value}), ok. IOW, it loses error handling. Does insert_new() somehow handle any errors that could arise when calling insert()? -- Best regards Alexei Sholik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Fri Jun 27 23:09:26 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 27 Jun 2014 23:09:26 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! Message-ID: Hi, Earlier today I released the erldocs version of the documentation of Erlang/OTP 17.1. Erldocs-the-tool has seen a lot of improvement since the previous erldocs.com release. In particular, exported types and function specs are now rendered and exported functions now have their arguments. Here is an example: http://erldocs.com/current/kernel/file.html Note: if you haven't already, update your bookmark to http://erldocs.com/current/ If you see something uncommon please file an issue here https://github.com/fenollp/erldocs/issues I hope you will enjoy this release! Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From gumm@REDACTED Sat Jun 28 03:15:27 2014 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 27 Jun 2014 20:15:27 -0500 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: Thanks Pierre, The new changes look fantastic! -Jesse On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll wrote: > Hi, > > Earlier today I released the erldocs version of the documentation of > Erlang/OTP 17.1. > > Erldocs-the-tool has seen a lot of improvement since the previous > erldocs.com release. > In particular, exported types and function specs are now rendered and > exported functions now have their arguments. > Here is an example: > http://erldocs.com/current/kernel/file.html > > Note: if you haven't already, update your bookmark to > http://erldocs.com/current/ > > If you see something uncommon please file an issue here > https://github.com/fenollp/erldocs/issues > > I hope you will enjoy this release! > > Cheers, > -- > Pierre Fenoll > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From roe.adrian@REDACTED Sat Jun 28 07:51:35 2014 From: roe.adrian@REDACTED (Adrian Roe) Date: Sat, 28 Jun 2014 06:51:35 +0100 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: <9BA524E320864BFE8ABA807433D0EA03@gmail.com> That they do. I?ve noticed one minor typo in the site - on the home page under versions, both 17.1 and 17.0 point to the same place (17.0). Thanks for a great site! Adrian -- Adrian Roe Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Saturday, 28 June 2014 at 02:15, Jesse Gumm wrote: > Thanks Pierre, > > The new changes look fantastic! > > -Jesse > > On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll wrote: > > Hi, > > > > Earlier today I released the erldocs version of the documentation of > > Erlang/OTP 17.1. > > > > Erldocs-the-tool has seen a lot of improvement since the previous > > erldocs.com (http://erldocs.com) release. > > In particular, exported types and function specs are now rendered and > > exported functions now have their arguments. > > Here is an example: > > http://erldocs.com/current/kernel/file.html > > > > Note: if you haven't already, update your bookmark to > > http://erldocs.com/current/ > > > > If you see something uncommon please file an issue here > > https://github.com/fenollp/erldocs/issues > > > > I hope you will enjoy this release! > > > > Cheers, > > -- > > Pierre Fenoll > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com (http://sigma-star.com) || @jessegumm > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED) > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sat Jun 28 08:47:02 2014 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 27 Jun 2014 23:47:02 -0700 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: <9BA524E320864BFE8ABA807433D0EA03@gmail.com> References: <9BA524E320864BFE8ABA807433D0EA03@gmail.com> Message-ID: <53AE64E6.8030406@gmail.com> Is this because we no longer have access to the minor version number? On 06/27/2014 10:51 PM, Adrian Roe wrote: > That they do. I've noticed one minor typo in the site - on the home page under versions, both 17.1 and 17.0 point to the same place (17.0). > > Thanks for a great site! > > Adrian > -- > Adrian Roe > Sent with Sparrow > > On Saturday, 28 June 2014 at 02:15, Jesse Gumm wrote: > >> Thanks Pierre, >> >> The new changes look fantastic! >> >> -Jesse >> >> On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll > wrote: >>> Hi, >>> >>> Earlier today I released the erldocs version of the documentation of >>> Erlang/OTP 17.1. >>> >>> Erldocs-the-tool has seen a lot of improvement since the previous >>> erldocs.com release. >>> In particular, exported types and function specs are now rendered and >>> exported functions now have their arguments. >>> Here is an example: >>> http://erldocs.com/current/kernel/file.html >>> >>> Note: if you haven't already, update your bookmark to >>> http://erldocs.com/current/ >>> >>> If you see something uncommon please file an issue here >>> https://github.com/fenollp/erldocs/issues >>> >>> I hope you will enjoy this release! >>> >>> Cheers, >>> -- >>> Pierre Fenoll >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> Jesse Gumm >> Owner, Sigma Star Systems >> 414.940.4866 || sigma-star.com || @jessegumm >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Sat Jun 28 09:19:33 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Sat, 28 Jun 2014 09:19:33 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: This is great! Thank you very much On Sat, Jun 28, 2014 at 3:15 AM, Jesse Gumm wrote: > Thanks Pierre, > > The new changes look fantastic! > > -Jesse > > On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll > wrote: > > Hi, > > > > Earlier today I released the erldocs version of the documentation of > > Erlang/OTP 17.1. > > > > Erldocs-the-tool has seen a lot of improvement since the previous > > erldocs.com release. > > In particular, exported types and function specs are now rendered and > > exported functions now have their arguments. > > Here is an example: > > http://erldocs.com/current/kernel/file.html > > > > Note: if you haven't already, update your bookmark to > > http://erldocs.com/current/ > > > > If you see something uncommon please file an issue here > > https://github.com/fenollp/erldocs/issues > > > > I hope you will enjoy this release! > > > > Cheers, > > -- > > Pierre Fenoll > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com || @jessegumm > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Jun 28 10:33:31 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 28 Jun 2014 10:33:31 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: <53AD7DEA.9000105@ninenines.eu> References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> <53AD7DEA.9000105@ninenines.eu> Message-ID: <8EC2BCAF-765C-43D7-9BAB-716F926EE351@gmail.com> My original post was in reply to Max, who is probably not using prim_file just for file_info functions. The operative word was "most". That being said: https://github.com/erlang/otp/pull/413 Regards, -- Anthony Ramine Le 27 juin 2014 ? 16:21, Lo?c Hoguin a ?crit : > The functions that operate on *open* files, yes. Not read_file_info. From n.oxyde@REDACTED Sat Jun 28 10:43:05 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 28 Jun 2014 10:43:05 +0200 Subject: [erlang-questions] Failure semantics of dets:insert_new vs dets:insert In-Reply-To: References: Message-ID: <38A3A29D-2A8B-476A-9F49-96BD567645E5@gmail.com> Looking at the code, I don't see how dets:insert/2 can ever return an error instead of crashing with badarg. -- Anthony Ramine Le 27 juin 2014 ? 16:26, Alexei Sholik a ?crit : > The signature for dets:insert_new is > > insert(Name, Objects) -> ok | {error, Reason} > > However, in my use case, I'm using a hash of the value as the key. So I thought I'd switch to using insert_new because that might be slightly more efficient (no need to update stored value). > > But the signature for insert_new is > > insert_new(Name, Objects) -> boolean() > > In this case, false only indicates that a value for the key is already in the table. What about failure cases of insert()? > > With insert() I have this code > > case dets:insert(table, {Key,Value}) of > ok -> ok; > {error, _}=Other -> Other > end > > With insert_new it turns to just > > dets:insert_new(table, {Key,Value}), > ok. > > IOW, it loses error handling. > > Does insert_new() somehow handle any errors that could arise when calling insert()? > > -- > Best regards > Alexei Sholik > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From pierrefenoll@REDACTED Sat Jun 28 12:43:43 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sat, 28 Jun 2014 12:43:43 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: Thanks everyone! This is very sweet. Adrian, Michael: This was indeed a typo, thanks for spotting it. Cheers, -- Pierre Fenoll On 28 June 2014 09:19, Ali Sabil wrote: > This is great! Thank you very much > > > On Sat, Jun 28, 2014 at 3:15 AM, Jesse Gumm wrote: > >> Thanks Pierre, >> >> The new changes look fantastic! >> >> -Jesse >> >> On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll >> wrote: >> > Hi, >> > >> > Earlier today I released the erldocs version of the documentation of >> > Erlang/OTP 17.1. >> > >> > Erldocs-the-tool has seen a lot of improvement since the previous >> > erldocs.com release. >> > In particular, exported types and function specs are now rendered and >> > exported functions now have their arguments. >> > Here is an example: >> > http://erldocs.com/current/kernel/file.html >> > >> > Note: if you haven't already, update your bookmark to >> > http://erldocs.com/current/ >> > >> > If you see something uncommon please file an issue here >> > https://github.com/fenollp/erldocs/issues >> > >> > I hope you will enjoy this release! >> > >> > Cheers, >> > -- >> > Pierre Fenoll >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> >> >> -- >> Jesse Gumm >> Owner, Sigma Star Systems >> 414.940.4866 || sigma-star.com || @jessegumm >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Sun Jun 29 21:53:41 2014 From: shayan@REDACTED (Shayan Pooya) Date: Sun, 29 Jun 2014 15:53:41 -0400 Subject: [erlang-questions] raw_read_file_info In-Reply-To: <8EC2BCAF-765C-43D7-9BAB-716F926EE351@gmail.com> References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> <53AD7DEA.9000105@ninenines.eu> <8EC2BCAF-765C-43D7-9BAB-716F926EE351@gmail.com> Message-ID: Thanks Anthony. What about the other operations like file:mkdir, file:rename, file:list_dir and others that do not open the file (hence there is no raw option)? For them we still have to use prim_file to avoid paying the price of a round-trip. Is that right? Regards. On Sat, Jun 28, 2014 at 4:33 AM, Anthony Ramine wrote: > My original post was in reply to Max, who is probably not using prim_file > just for file_info functions. The operative word was "most". > > That being said: > > https://github.com/erlang/otp/pull/413 > > Regards, > > -- > Anthony Ramine > > Le 27 juin 2014 ? 16:21, Lo?c Hoguin a ?crit : > > > The functions that operate on *open* files, yes. Not read_file_info. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sun Jun 29 22:45:35 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 30 Jun 2014 00:45:35 +0400 Subject: [erlang-questions] raw_read_file_info In-Reply-To: References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> <53AD7DEA.9000105@ninenines.eu> <8EC2BCAF-765C-43D7-9BAB-716F926EE351@gmail.com> Message-ID: On Sun, Jun 29, 2014 at 11:53 PM, Shayan Pooya wrote: > For them we still have to use prim_file to avoid paying the price of a > round-trip. Is that right? > Problem is not in "paying the price of round-trip". It costs nothing to send message to file_server1 and receive it back. Problem is that while singleton file_server is working hard on reading file info from NFS or HDD, your request to open file on SSD is waiting in queue. This is the problem. file module is implemented right now so that it scales badly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Jun 29 23:39:10 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 29 Jun 2014 23:39:10 +0200 Subject: [erlang-questions] raw_read_file_info In-Reply-To: References: <53AAAD03.5000308@ninenines.eu> <7E164B40-7565-4227-A013-2A1566ECDF07@gmail.com> <53AD7803.9050103@ninenines.eu> <53AD7DEA.9000105@ninenines.eu> <8EC2BCAF-765C-43D7-9BAB-716F926EE351@gmail.com> Message-ID: These don?t have an Options argument, and I wasn?t bored enough to add one. I can do it if the OTP team likes the idea. -- Anthony Ramine Le 29 juin 2014 ? 21:53, Shayan Pooya a ?crit : > What about the other operations like file:mkdir, file:rename, file:list_dir and others that do not open the file (hence there is no raw option)? From sedrik@REDACTED Mon Jun 30 08:36:05 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Mon, 30 Jun 2014 08:36:05 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: Lovely. Would it be possible to re-generate old versions documentation for us who are still stuck on older versions and can't move forward just yet. example: http://erldocs.com/R15B03/kernel/file.html On Sat, Jun 28, 2014 at 12:43 PM, Pierre Fenoll wrote: > Thanks everyone! This is very sweet. > > Adrian, Michael: > This was indeed a typo, thanks for spotting it. > > > Cheers, > -- > Pierre Fenoll > > > > On 28 June 2014 09:19, Ali Sabil wrote: > >> This is great! Thank you very much >> >> >> On Sat, Jun 28, 2014 at 3:15 AM, Jesse Gumm wrote: >> >>> Thanks Pierre, >>> >>> The new changes look fantastic! >>> >>> -Jesse >>> >>> On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll >>> wrote: >>> > Hi, >>> > >>> > Earlier today I released the erldocs version of the documentation of >>> > Erlang/OTP 17.1. >>> > >>> > Erldocs-the-tool has seen a lot of improvement since the previous >>> > erldocs.com release. >>> > In particular, exported types and function specs are now rendered and >>> > exported functions now have their arguments. >>> > Here is an example: >>> > http://erldocs.com/current/kernel/file.html >>> > >>> > Note: if you haven't already, update your bookmark to >>> > http://erldocs.com/current/ >>> > >>> > If you see something uncommon please file an issue here >>> > https://github.com/fenollp/erldocs/issues >>> > >>> > I hope you will enjoy this release! >>> > >>> > Cheers, >>> > -- >>> > Pierre Fenoll >>> > >>> > >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> > >>> >>> >>> >>> -- >>> Jesse Gumm >>> Owner, Sigma Star Systems >>> 414.940.4866 || sigma-star.com || @jessegumm >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Mon Jun 30 09:47:25 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 09:47:25 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> Message-ID: Richard A. O'Keefe writes: > On 17/06/2014, at 8:17 PM, Torben Hoffmann wrote: >> >> Staying on the visual track for a second; I had a look at the DRAKON editor >> (http://drakon-editor.sourceforge.net/drakon-erlang/intro.html) which has >> support for Erlang to generate code. Unfortunately it does not generate idiomatic >> Erlang code and the Tcl UI feels a bit dated. > > One thing on that page hit me in the eye: > > * Recursion is not immediately visible. > > This fits into my general "why can't I *see* the structure?" feeling > about many programming languages, notably Java and Python, but Erlang > too. I often get the feeling that if you need diagrams to help you > find your way around, there is something important missing from the > textual notation. Maybe one day I will be wise enough to see it. > I think one of the issues is that structure is inherently a visual thing - at least to me - and that means that some sort of visualisation is necessary to get the full picture. The good thing about Erlang is that you can survive a lot longer without anything on the visual side, but I think that in order to spread Erlang even further we need to have some sort of visual notation to help communicate things better. > One of the things I always liked about Scheme was > named-let: > > (let (( ) ... ( )) > ) > > Within the body, is visible as a function of n arguments. > It's equivalent to > > (letrec (( (lambda ( ... ) ))) > ( ... ) > > So it's really just defining and calling a local recursive > function. The way it's normally used is as a loop, with calls > to being tail calls. (Which in Scheme means it *is* a > loop, with the tail calls just rebinding the arguments and jumping.) > > Perhaps some 'intention annotations' might help. > Is a function > - not supposed to be recursive (directly or indirectly) at all? > - supposed to be tail recursive (directly or indirectly)? > - supposed to be generally recursive (directly or indirectly)? > - meant to terminate because some measure (which?) of some > argument or combination of argument (which?) strictly > decreases on each recursive call? > If the compiler enforced such annotations, that could both help > with debugging (if you meant something to be tail recursive but > it wasn't, for example) and make it easier to read. > > Imagine something vaguely like > -recursion(sort(List, Comparator), {general, length(List)}). > This is a quite interesting idea. I can see it working for really good programmers, but how it would fare with beginners is unclear to me. I have a feeling (not hard data) that it is not the easiest thing to teach > >> Visual Erlang (https://github.com/esl/visual_erlang) is still in its infancy, but >> adding extensions to fit the teaching purpose is not impossible. One can steal ideas >> from DRAKON and other notations like SDL. > > Having looked at DRAKON, my opinion is that it has no ideas > worth stealing. > I appreciate that evaluation - on a second visit I can see the points you are making and it would not help Visual Erlang by going down a route of adding more details in the style of DRAKON. > By the way, who says that an embedded system cannot do > graphics? These days, when I pay at a parking building, I'm > using an *embedded* system that has a colour screen. > See http://store.earthlcd.com/Home/ezLCD for an example of > a company boasting that their touch LCD products > 'work.. with any micro-controller, including Arduino'. > The prices on that page are within the reach of even a school. > > Right now I'm looking at www.trademe.co.nz and I'm seeing > "2014 New Android Jelly Bean4.2.2 10.1 inch > 1024*600 capacitive touch screen Dual Core Tablet > 1G DDR3 RAM 16GB Flash BT WIFI Dual Cameras ... Mic Speaker" > at "buy now, $180 + $15 shipping". So that's USD 170, or > 125 Euros. I see that Erlang R14 is available for Android: > http://www.burbas.se/artiklar/erlang-for-the-android-plattform/ > There's also > http://code.google.com/p/erlang4android/downloads/detail?name=Erlang4AndroidR16B.apk > which offers "a small version of Erlang" adequate for > running OTP applications. > > So what would it be like to have pupils working on something > that was plainly and visibly distributed across a bunch of > cheap tablets? I'm not saying that embedded systems cannot do graphics. I think embedded systems are really cool and can do a lot of things. What I fear - after playing with the Raspberry Pi myself - is that introducing an embedded platform might take too much attention away from the programming. Hardware has a way of stealing your time, so it is balance between coolness and not having to deal with weird things. At work we run an Erlang Embedded workshop and it is always quite "funny" to wrestle with the Raspberry Pi's as preparation for the workshop. It just takes time. But the ezLCD you mention has the benefit that it can be hooked directly up to a computer via USB and then you are in business. So it might be a good route into getting the cool factor of hardware involved. Thanks for the good insights you have provided. Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 30 09:53:25 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 09:53:25 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: <59EBE8A4-E690-4583-A0F6-DB79DD94F4B3@writersglen.com> References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <59EBE8A4-E690-4583-A0F6-DB79DD94F4B3@writersglen.com> Message-ID: Lloyd R. Prentice writes: > Hi Torben, > > Good thoughts. > > But note re: > >> Going embedded means that doing things with graphics is impossible. >> On a computer we could tap into graphical libraries, say Processing, and create a >> very visual feedback. > > Odroid U3 runs Ubuntu, has HD HDMI graphics with a fairly powerful graphic coprocessor. > > It also has an active community and a very attractive magazine packed with interesting projects: > > magazine.odroid.com > > I don't want to overly pitch the case since I haven't fired it up and can't speak to warts. But based on printed specs and price/performance, this is a very interesting device. > > Summary of specs > > Hardkernel lists these specifications for the Odroid-U3: > > Processor ? Samsung Exynos 4412 Prime SoC: > CPU ? Quad-core ARM Cortex-A9, clocked at 1.7GHz > GPU ? 3D accelerator Mali-400 Quad Core 440MHz > RAM ? 2GB LP-DDR2 SDRAM > Storage: > MicroSD card socket > eMMC module socket > HDMI video interface: > Supports 1080p (H.264+AAC based MP4 container format) > micro HDMI connector > Audio ? 3.5mm headphone jack > LAN ? 10/100Mb Ethernet (RJ-45 Jack) > USB: > 3x USB2.0 Host ports (standard A type connectors) > 1x USB2.0 OTG Device port (Micro USB) > 8-pin I/O expansion header ? UART, IRQ, I2C, GPIO, power > Power ? 5VDC @ 2A > Operating system ? Xubuntu 13.10; U-Boot 2010.12; Linux kernel 3.0.x; Android 4.x > Dimensions ? 83 x 48 x 22mm (with heatsink) > Weight ? 48g (with heatsink) > > More here: > > http://blog.hsc.com/android/technology-trends/raspberry-pi-vs-odroid-u3/ > > http://hardkernel.com/main/products/prdt_info.php > Hi Lloyd, I can see that my prejudice about the power of these platforms is wrong. The Odroid-U3 combined with ezLCD (which Richard O'Keefe mentioned) could actually be an interesting platform. Still worried about the time that hardware always consumes... Cheers, Torben -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 30 09:54:36 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 09:54:36 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> Message-ID: Kudos for putting your money into a good cause! Mark Nijhof writes: > Done, use: http://leanpub.com/functionalerlang/c/FreeForKids which is also > listed on the website itself. > > -Mark > > > On Mon, Jun 16, 2014 at 9:14 PM, Mark Nijhof > wrote: > >> Not sure how much it helps but I am more then happy to have an unending >> (and publicly visible) coupon to get my book for free for kids. It is not >> specifically targeted to kids but does have a very high example driven >> approach. I.e. together we build stuff. Will make one tonight. >> >> http://gettingfunctionalwitherlang.com (btw not yet done). >> >> -Mark >> On Jun 16, 2014 8:58 PM, wrote: >> >>> Hello, >>> >>> So many great ideas. So many talented contributors. A fantasy--- >>> >>> One or more of... >>> >>> - a website >>> - hosting platform >>> - an e-book - free for download >>> - a hard-cover book - royalties kick back to help kids >>> - a hardware platform - profits kick back to help kids >>> >>> Projects >>> >>> - build your own website >>> - chat with friends >>> - organize your collections >>> - build a multi-player game >>> - control a robot >>> - control your house >>> - build your own supercomputer >>> ???? >>> >>> Contest for project submissions >>> >>> Team >>> >>> - dedicated Erlang volunteers >>> - perhaps formalize with a foundation ala Raspberry Pi >>> >>> Process >>> >>> - Dream >>> - Brainstorm >>> - Set goals >>> - Organize >>> - Delegate >>> - Produce >>> >>> Platform >>> >>> - Software projects can be done on Windows assuming easy peasy Erlang >>> install >>> >>> - How can we get youngsters into Linux? >>> >>> - A hardware platform would open up robotics and control applications: >>> >>> Cheap (under $100) ARM boards >>> >>> -- Arduino etc. >>> >>> -- Raspberry Pi >>> >>> -- I have an Odroid U3 on my desk. No time to fire it up yet; but very >>> compact, quiet, low power, plenty of computing power, runs Linux. Total of >>> $90 for board, pwr supply, HDMI cable, wi-fi module, and case. Would need >>> an MicroSD card with Linux and Erlang installed. >>> >>> Over the past year there have been a slew of such devices hitting the >>> market and more coming. >>> >>> Can we get /software/hardware cos to help sponsor the effort? >>> >>> Best, >>> >>> Lloyd >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: "Ferenc Holzhauser" >>> Sent: Monday, June 16, 2014 1:30pm >>> To: "Tony Rogvall" >>> Cc: "erlang-questions@REDACTED" >>> Subject: Re: [erlang-questions] Erlang for youngsters >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> Robotics is really nice but in this case accessibility is even nicer. It >>> is >>> great if kids can play after class too with interesting things without >>> having to put items of fairly significant value (for some) on their >>> wishlist. These days a >>> computer with internet access can be a fascinatingly accessible way of >>> creativity. An idea could be to make a simple game backend to compete with >>> their friends and fellow students (e.g. a 2d tank shooting game or >>> something). Eventually with chat and similar functions to add. Then the >>> teacher could make things go wrong on the server(s) that they'd need to >>> fix >>> (distribute/scale/fail over) depending on their progress. You could lure >>> them into AI like things too if you fancy. I'm sure someone with the >>> skills >>> (e.g. SVG/ezwebframe) and time could make some simple client "building >>> blocks" work for something like this. >>> >>> >>> On 16 June 2014 18:12, Tony Rogvall wrote: >>> >>> > >>> > On 16 jun 2014, at 13:55, Mark Nijhof >>> > wrote: >>> > >>> > +1 on this, this rings very true to home. But I also believe that it >>> needs >>> > to return results quickly. I.e. building a game is great, but if they >>> have >>> > to "code" for days before they see something happen then they loose >>> > interest (assumption). So preparing "building blocks" might be a good >>> > approach and have them first implement higher level stuff and then step >>> by >>> > step dig deeper and implement the building blocks you prepared. >>> > >>> > An other exercise I planned is to program a drone (not sure about the >>> > language there yet) to fly an obstacle course. So they see it is not >>> just >>> > something that happens on their iPads ;) >>> > >>> > You program drone in Erlang of course :-) >>> > >>> > https://github.com/tonyrog/edrone >>> > >>> > /Tony >>> > >>> > -Mark >>> > >>> > >>> > On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >>> > mahesh@REDACTED> wrote: >>> > >>> >> The most important thing here I believe is to have a nice collection of >>> >>> simple tasks/problems that are appealing to the target audience and >>> best >>> >>> (easiest/nicest) solved in Erlang. >>> >> >>> >> Amen! >>> >> The least relevant part of teaching kids programming is the syntax, or >>> >> the choice of language - they don't, and won't, give a s**t about it. >>> >> As a simple thought experiment, just look at how you raised your kids >>> in >>> >> a multi-lingual environment (yes my American brethren, this is hard. >>> >> Pretend :-) ) Notice how they - fluidly - bounce across languages, >>> >> massacring every grammar rule ever, but quite happily making sure that >>> you >>> >> understand that "I amn't going to eat pea, ???? ????????, ???? >>> ????????, >>> >> odio odio odio la piselli, i don't wanna, where is my red truck?" >>> >> Mind you, they will pick up the rules over time, but the key here is >>> the >>> >> importance of the problem at hand ("How To Avoid Eating Peas") - the >>> more >>> >> immediately relevant it is to the young 'uns, the more rapidly they >>> will >>> >> pick up the tools, the specifics of the language be damned. >>> >> >>> >> Cheers >>> >> >>> >> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >>> >> ferenc.holzhauser@REDACTED> wrote: >>> >> >>> >>> The most important thing here I believe is to have a nice collection >>> of >>> >>> simple tasks/problems that are appealing to the target audience and >>> best >>> >>> (easiest/nicest) solved in Erlang. That's a bit of a challenge >>> considering >>> >>> that Erlang is created to solve problems that are rather "industrial" >>> and >>> >>> most people "from outside" can't really relate to. If the audience is >>> not >>> >>> comfortable with understanding the problem itself then it is tricky >>> to make >>> >>> them understand/like the solution too. >>> >>> >>> >>> This we can see with many new people getting into Erlang: The problems >>> >>> they are given are new and difficult to understand. So they often >>> just go >>> >>> off and eagerly try to solve all sort of issues they are familiar with >>> >>> (even when they are not relevant in the particular case) before even >>> trying >>> >>> to understand what the real challenge is. Then they start complaining >>> that >>> >>> Erlang is not very good for some/many of those issues they are busy >>> with. >>> >>> >>> >>> And other way around: people coming to Erlang with the right >>> >>> understanding of the problem area it is made for find it amazingly >>> simple >>> >>> to learn. >>> >>> >>> >>> Coming from the wrong (or right ?) background my imagination fails to >>> >>> come up with these appealing challenges for the youngster target >>> group, but >>> >>> I'm sure many of you can do much better. >>> >>> >>> >>> Ferenc >>> >>> >>> >>> >>> >>> On 16 June 2014 11:31, Miles Fidelman >>> >>> wrote: >>> >>> >>> >>>> Garrett Smith wrote: >>> >>>> >>> >>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>> >>>>> wrote: >>> >>>>> >>> >>>>> -snip- >>> >>>>> >>> >>>>> I think that a learning resource focused on teaching people the >>> >>>>>> Erlang model from the >>> >>>>>> ground up would be a great improvement. A clear narrative around >>> how >>> >>>>>> do we solve a >>> >>>>>> problem the Erlang way. Teaching the basic constructs is not the >>> >>>>>> problem. >>> >>>>>> >>> >>>>>> My initial target for such a learning resources would be young >>> people >>> >>>>>> in the higher >>> >>>>>> grades of elementary school, say 12-15 years. Why? Because I want >>> to >>> >>>>>> influence them >>> >>>>>> before their minds are totally corrupted by other programming >>> models. >>> >>>>>> >>> >>>>>> I don't think we would have to dumb anything down in particular for >>> >>>>>> this group - we >>> >>>>>> just have to find a cool example and organise the learning around >>> how >>> >>>>>> to become so >>> >>>>>> good that one can solve such a problem. >>> >>>>>> Some sort of game will probably be the best candidate, say, some >>> sort >>> >>>>>> of Transport >>> >>>>>> Tycoon clone?!?! >>> >>>>>> >>> >>>>> I don't have enough experience teaching programming to this age >>> group >>> >>>>> to provide anything more than a hunch. But I suspect that the Erlang >>> >>>>> way, which is hard enough for very seasoned programmers to grok, >>> might >>> >>>>> be a bit ambitious for these young learners. >>> >>>>> >>> >>>>> I'm speaking in particular about the model that emerges when you >>> >>>>> isolate processes. It changes everything: your approach to building >>> >>>>> software (move from state oriented to activity oriented), error >>> >>>>> handling (move from defensive measures to assertive/let-it-crash), >>> >>>>> program structure (from monolith to system), and so on. The benefits >>> >>>>> of this shift are hard to get across, in my experience anyway. I >>> wish >>> >>>>> it wasn't, or I wish I was better at communicating. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>> I'm with the folks who suggest that this group has fewer >>> >>>> pre-conceptions to unlearn. >>> >>>> >>> >>>> It strikes me that the actor model is far more natural for certain >>> >>>> classes of problems - network code, simulation, and gaming come to >>> mind. >>> >>>> It's simply conceptually easier to think in terms of LOTS of >>> independent >>> >>>> processes. >>> >>>> >>> >>>> Miles Fidelman >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> In theory, there is no difference between theory and practice. >>> >>>> In practice, there is. .... Yogi Berra >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> erlang-questions mailing list >>> >>>> erlang-questions@REDACTED >>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> erlang-questions mailing list >>> >>> erlang-questions@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> >>> >> * Mahesh Paolini-Subramanya >>> >> >>> That >>> >> tall bald Indian guy..* >>> >> * Google+ >>> >> | Blog | Twitter >>> >> | LinkedIn >>> >> * >>> >> >>> >> _______________________________________________ >>> >> erlang-questions mailing list >>> >> erlang-questions@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >>> >> >>> > >>> > >>> > -- >>> > Mark Nijhof >>> > t: @MarkNijhof >>> > s: marknijhof >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> > >>> > >>> > "Installing applications can lead to corruption over time. Applications >>> > gradually write over each other's libraries, partial upgrades occur, >>> user >>> > and system errors happen, and minute changes may be unnoticeable and >>> > difficult to fix" >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> > >>> > >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 30 10:32:43 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 10:32:43 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> Message-ID: Robots are always cool. There is this KERL (Kent Erlang Robotics Library): http://kerl.sourceforge.net It does not seem to have been updated for years :-( But a connection to Player/Stage could be good for teaching. Cheers, Torben Leonard Boyce writes: > I remember using Rur-ple http://rur-ple.sourceforge.net/ to get my > daughter interested in programming. She seemed to find it fairly > entertaining and I was quite impressed at how quickly she progressed. > > Something similar for Erlang may work quite well. > > Leonard > -- > > On Mon, Jun 16, 2014 at 1:30 PM, Ferenc Holzhauser > wrote: >> Robotics is really nice but in this case accessibility is even nicer. It is >> great if kids can play after class too with interesting things without >> having to put items of fairly significant value (for some) on their >> wishlist. These days a >> computer with internet access can be a fascinatingly accessible way of >> creativity. An idea could be to make a simple game backend to compete with >> their friends and fellow students (e.g. a 2d tank shooting game or >> something). Eventually with chat and similar functions to add. Then the >> teacher could make things go wrong on the server(s) that they'd need to fix >> (distribute/scale/fail over) depending on their progress. You could lure >> them into AI like things too if you fancy. I'm sure someone with the skills >> (e.g. SVG/ezwebframe) and time could make some simple client "building >> blocks" work for something like this. >> >> >> On 16 June 2014 18:12, Tony Rogvall wrote: >>> >>> >>> On 16 jun 2014, at 13:55, Mark Nijhof >>> wrote: >>> >>> +1 on this, this rings very true to home. But I also believe that it needs >>> to return results quickly. I.e. building a game is great, but if they have >>> to "code" for days before they see something happen then they loose interest >>> (assumption). So preparing "building blocks" might be a good approach and >>> have them first implement higher level stuff and then step by step dig >>> deeper and implement the building blocks you prepared. >>> >>> An other exercise I planned is to program a drone (not sure about the >>> language there yet) to fly an obstacle course. So they see it is not just >>> something that happens on their iPads ;) >>> >>> You program drone in Erlang of course :-) >>> >>> https://github.com/tonyrog/edrone >>> >>> /Tony >>> >>> -Mark >>> >>> >>> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya >>> wrote: >>>>> >>>>> The most important thing here I believe is to have a nice collection of >>>>> simple tasks/problems that are appealing to the target audience and best >>>>> (easiest/nicest) solved in Erlang. >>>> >>>> Amen! >>>> The least relevant part of teaching kids programming is the syntax, or >>>> the choice of language - they don't, and won't, give a s**t about it. >>>> As a simple thought experiment, just look at how you raised your kids in >>>> a multi-lingual environment (yes my American brethren, this is hard. Pretend >>>> :-) ) Notice how they - fluidly - bounce across languages, massacring >>>> every grammar rule ever, but quite happily making sure that you understand >>>> that "I amn't going to eat pea, ???? ????????, ???? ????????, odio odio odio >>>> la piselli, i don't wanna, where is my red truck?" >>>> Mind you, they will pick up the rules over time, but the key here is the >>>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>>> immediately relevant it is to the young 'uns, the more rapidly they will >>>> pick up the tools, the specifics of the language be damned. >>>> >>>> Cheers >>>> >>>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser >>>> wrote: >>>>> >>>>> The most important thing here I believe is to have a nice collection of >>>>> simple tasks/problems that are appealing to the target audience and best >>>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>>> that Erlang is created to solve problems that are rather "industrial" and >>>>> most people "from outside" can't really relate to. If the audience is not >>>>> comfortable with understanding the problem itself then it is tricky to make >>>>> them understand/like the solution too. >>>>> >>>>> This we can see with many new people getting into Erlang: The problems >>>>> they are given are new and difficult to understand. So they often just go >>>>> off and eagerly try to solve all sort of issues they are familiar with (even >>>>> when they are not relevant in the particular case) before even trying to >>>>> understand what the real challenge is. Then they start complaining that >>>>> Erlang is not very good for some/many of those issues they are busy with. >>>>> >>>>> And other way around: people coming to Erlang with the right >>>>> understanding of the problem area it is made for find it amazingly simple to >>>>> learn. >>>>> >>>>> Coming from the wrong (or right ?) background my imagination fails to >>>>> come up with these appealing challenges for the youngster target group, but >>>>> I'm sure many of you can do much better. >>>>> >>>>> Ferenc >>>>> >>>>> >>>>> On 16 June 2014 11:31, Miles Fidelman >>>>> wrote: >>>>>> >>>>>> Garrett Smith wrote: >>>>>>> >>>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>>> wrote: >>>>>>> >>>>>>> -snip- >>>>>>> >>>>>>>> I think that a learning resource focused on teaching people the >>>>>>>> Erlang model from the >>>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>>> do we solve a >>>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>>> problem. >>>>>>>> >>>>>>>> My initial target for such a learning resources would be young people >>>>>>>> in the higher >>>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>>> influence them >>>>>>>> before their minds are totally corrupted by other programming models. >>>>>>>> >>>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>>> this group - we >>>>>>>> just have to find a cool example and organise the learning around how >>>>>>>> to become so >>>>>>>> good that one can solve such a problem. >>>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>>> of Transport >>>>>>>> Tycoon clone?!?! >>>>>>> >>>>>>> I don't have enough experience teaching programming to this age group >>>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>>> be a bit ambitious for these young learners. >>>>>>> >>>>>>> I'm speaking in particular about the model that emerges when you >>>>>>> isolate processes. It changes everything: your approach to building >>>>>>> software (move from state oriented to activity oriented), error >>>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>>> program structure (from monolith to system), and so on. The benefits >>>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>>> it wasn't, or I wish I was better at communicating. >>>>>>> >>>>>>> >>>>>> >>>>>> I'm with the folks who suggest that this group has fewer >>>>>> pre-conceptions to unlearn. >>>>>> >>>>>> It strikes me that the actor model is far more natural for certain >>>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>>> processes. >>>>>> >>>>>> Miles Fidelman >>>>>> >>>>>> >>>>>> -- >>>>>> In theory, there is no difference between theory and practice. >>>>>> In practice, there is. .... Yogi Berra >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> >>>> -- >>>> Mahesh Paolini-Subramanya >>>> That tall bald Indian guy.. >>>> Google+ | Blog | Twitter | LinkedIn >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> >>> -- >>> Mark Nijhof >>> t: @MarkNijhof >>> s: marknijhof >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> "Installing applications can lead to corruption over time. Applications >>> gradually write over each other's libraries, partial upgrades occur, user >>> and system errors happen, and minute changes may be unnoticeable and >>> difficult to fix" >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From torben.hoffmann@REDACTED Mon Jun 30 10:40:50 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 10:40:50 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> Message-ID: Darach Ennis writes: > Hi guys, > > I have 4 kids under 10 years of age. They all program at some level except > for the 2 year old. Although > the 2 year old is already familiar with squishy circuits > http://courseweb.stthomas.edu/apthomas/SquishyCircuits/ > and conductive paint http://www.bareconductive.com/. So, the fact that > diodes (namely LEDs) are directional (only > work one way around) are familiar concepts to them from a young age. > Cool. > A good introductory language is scratch (http://scratch.mit.edu/) > followed by Python (from about 7 years of age depending on the child, > python works very well, the > strict syntax is a benefit too). Python has excellent resources for kids > and parents the "Python for Kids" book in > http://www.amazon.co.uk/Python-Kids-Playful-Introduction-Programming/dp/1593274076/ref=sr_1_1?ie=UTF8&qid=1402920402&sr=8-1&keywords=python+for+kids > which is playful. > I agree. Scratch is a good play to start. > These are good starts but alone may not keep all children's interest. For > this, tactile and interactive > experiences are far better teaching aids. I use robotics, electronics, > crafts together with scratch and > python. > Makes total sense. > With a basic feel for logic, structure and feedback from programming tools > (with assistance) then > Erlang would be a good next step. Torben is probably right with respect to > age group by setting it > to mid high school level. Elixir, also, would probably be an easier > language to teach and to learn > with fringe benefits (namely learning Elixir) for some of us... > Yes, they must be polyglots and then we move them into the E-world! > Kids program in their own time too. Games like minecraft reward pattern > matching, for example. > > Far more important, in my experience, is allowing the kids drive the agenda > and stepping back to > assist, guide and encourage. As Mark points out, quick results are > important so that the experience > is playful and rewarding enough to keep interest levels high. For this, we > would need a course that > is fun, playful and assists both the teacher and student. Libraries like > erlang-ale that allow interaction > with cheap hardware such as arduino or raspberry pi also help to bring the > subject to life. > I'm still torn here - how do we balance the motivational aspect of hardware with the potential drain of time? Is the motivation simply enough to endure fighting with hardware? How does one mitigate that risk? I'm not a hardware guy, so I would be swimming upstream in such a set-up... > Another line of questioning exists around what to teach? Teach > Erlang/Elixir the languages or > teach the philosophy? A bit of both? I think the philosophy and modes of > thinking are far more important... > I agree. I think the chain is something like this: problem - thinking - programming. So we have to provide interesting problems, then help them think about how to approach them and finally turn it into programs. Cheers, Torben > Cheers, > > Darach. > > > > > > On Mon, Jun 16, 2014 at 12:55 PM, Mark Nijhof < > mark.nijhof@REDACTED> wrote: > >> +1 on this, this rings very true to home. But I also believe that it needs >> to return results quickly. I.e. building a game is great, but if they have >> to "code" for days before they see something happen then they loose >> interest (assumption). So preparing "building blocks" might be a good >> approach and have them first implement higher level stuff and then step by >> step dig deeper and implement the building blocks you prepared. >> >> An other exercise I planned is to program a drone (not sure about the >> language there yet) to fly an obstacle course. So they see it is not just >> something that happens on their iPads ;) >> >> -Mark >> >> >> On Mon, Jun 16, 2014 at 1:36 PM, Mahesh Paolini-Subramanya < >> mahesh@REDACTED> wrote: >> >>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. >>> >>> Amen! >>> The least relevant part of teaching kids programming is the syntax, or >>> the choice of language - they don't, and won't, give a s**t about it. >>> As a simple thought experiment, just look at how you raised your kids in >>> a multi-lingual environment (yes my American brethren, this is hard. >>> Pretend :-) ) Notice how they - fluidly - bounce across languages, >>> massacring every grammar rule ever, but quite happily making sure that you >>> understand that "I amn't going to eat pea, ???? ????????, ???? ????????, >>> odio odio odio la piselli, i don't wanna, where is my red truck?" >>> Mind you, they will pick up the rules over time, but the key here is the >>> importance of the problem at hand ("How To Avoid Eating Peas") - the more >>> immediately relevant it is to the young 'uns, the more rapidly they will >>> pick up the tools, the specifics of the language be damned. >>> >>> Cheers >>> >>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser < >>> ferenc.holzhauser@REDACTED> wrote: >>> >>>> The most important thing here I believe is to have a nice collection of >>>> simple tasks/problems that are appealing to the target audience and best >>>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering >>>> that Erlang is created to solve problems that are rather "industrial" and >>>> most people "from outside" can't really relate to. If the audience is not >>>> comfortable with understanding the problem itself then it is tricky to make >>>> them understand/like the solution too. >>>> >>>> This we can see with many new people getting into Erlang: The problems >>>> they are given are new and difficult to understand. So they often just go >>>> off and eagerly try to solve all sort of issues they are familiar with >>>> (even when they are not relevant in the particular case) before even trying >>>> to understand what the real challenge is. Then they start complaining that >>>> Erlang is not very good for some/many of those issues they are busy with. >>>> >>>> And other way around: people coming to Erlang with the right >>>> understanding of the problem area it is made for find it amazingly simple >>>> to learn. >>>> >>>> Coming from the wrong (or right ?) background my imagination fails to >>>> come up with these appealing challenges for the youngster target group, but >>>> I'm sure many of you can do much better. >>>> >>>> Ferenc >>>> >>>> >>>> On 16 June 2014 11:31, Miles Fidelman >>>> wrote: >>>> >>>>> Garrett Smith wrote: >>>>> >>>>>> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann >>>>>> wrote: >>>>>> >>>>>> -snip- >>>>>> >>>>>> I think that a learning resource focused on teaching people the >>>>>>> Erlang model from the >>>>>>> ground up would be a great improvement. A clear narrative around how >>>>>>> do we solve a >>>>>>> problem the Erlang way. Teaching the basic constructs is not the >>>>>>> problem. >>>>>>> >>>>>>> My initial target for such a learning resources would be young people >>>>>>> in the higher >>>>>>> grades of elementary school, say 12-15 years. Why? Because I want to >>>>>>> influence them >>>>>>> before their minds are totally corrupted by other programming models. >>>>>>> >>>>>>> I don't think we would have to dumb anything down in particular for >>>>>>> this group - we >>>>>>> just have to find a cool example and organise the learning around how >>>>>>> to become so >>>>>>> good that one can solve such a problem. >>>>>>> Some sort of game will probably be the best candidate, say, some sort >>>>>>> of Transport >>>>>>> Tycoon clone?!?! >>>>>>> >>>>>> I don't have enough experience teaching programming to this age group >>>>>> to provide anything more than a hunch. But I suspect that the Erlang >>>>>> way, which is hard enough for very seasoned programmers to grok, might >>>>>> be a bit ambitious for these young learners. >>>>>> >>>>>> I'm speaking in particular about the model that emerges when you >>>>>> isolate processes. It changes everything: your approach to building >>>>>> software (move from state oriented to activity oriented), error >>>>>> handling (move from defensive measures to assertive/let-it-crash), >>>>>> program structure (from monolith to system), and so on. The benefits >>>>>> of this shift are hard to get across, in my experience anyway. I wish >>>>>> it wasn't, or I wish I was better at communicating. >>>>>> >>>>>> >>>>>> >>>>> I'm with the folks who suggest that this group has fewer >>>>> pre-conceptions to unlearn. >>>>> >>>>> It strikes me that the actor model is far more natural for certain >>>>> classes of problems - network code, simulation, and gaming come to mind. >>>>> It's simply conceptually easier to think in terms of LOTS of independent >>>>> processes. >>>>> >>>>> Miles Fidelman >>>>> >>>>> >>>>> -- >>>>> In theory, there is no difference between theory and practice. >>>>> In practice, there is. .... Yogi Berra >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> >>> -- >>> >>> * Mahesh Paolini-Subramanya >>> That >>> tall bald Indian guy..* >>> * Google+ >>> | Blog | Twitter >>> | LinkedIn >>> * >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From rtrlists@REDACTED Mon Jun 30 11:54:29 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 30 Jun 2014 10:54:29 +0100 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> Message-ID: On 30 June 2014 08:47, Torben Hoffmann wrote: > > I think one of the issues is that structure is inherently a visual thing - > at least > to me - and that means that some sort of visualisation is necessary to get > the full > picture. > > The thing to remember is that different people "see it" differently. I find the visual clutter of diagrams tedious and very hard to read :-) I think there must be both, textual and visual, in order to convey something to a wider audience, as some will prefer text, some diagrams, and some like both. In a previous life, during the requirements gathering phase, I would capture business logic as a kind of textual "given-when-then" list of bullets, as well as draw a state chart diagram, in order to try my best at getting useful feedback from the client on the veracity of the designed logic. The ideal system allows you to move back and forth between textual and visual notation, with neither missing anything from the other. This is hard to achieve, though :-( And my fear is that such a system would only capture the intersection of what the two methods provide. Leading to a useless system, as each (text or visualisation) would provide benefits not nicely expressible in the other. Is there research in this area that can be tapped into? Regards, Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From torben.hoffmann@REDACTED Mon Jun 30 13:02:04 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 30 Jun 2014 13:02:04 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> Message-ID: Robert Raschke writes: > On 30 June 2014 08:47, Torben Hoffmann > wrote: > >> >> I think one of the issues is that structure is inherently a visual thing - >> at least >> to me - and that means that some sort of visualisation is necessary to get >> the full >> picture. >> >> > The thing to remember is that different people "see it" differently. I find > the visual clutter of diagrams tedious and very hard to read :-) > Horses for courses ;-) If the diagrams does not read easily they are done wrong. An interaction with processes from >=2 modules in Erlang should be possible to communicate clearly in a diagram. It is a matter of having a visual notation that fits the domain. > I think there must be both, textual and visual, in order to convey > something to a wider audience, as some will prefer text, some diagrams, and > some like both. > That's part of the reason why I am creating Visual Erlang with a dual textual and visual notation. Each has it time and place. > In a previous life, during the requirements gathering phase, I would > capture business logic as a kind of textual "given-when-then" list of > bullets, as well as draw a state chart diagram, in order to try my best at > getting useful feedback from the client on the veracity of the designed > logic. > > The ideal system allows you to move back and forth between textual and > visual notation, with neither missing anything from the other. This is hard > to achieve, though :-( And my fear is that such a system would only capture > the intersection of what the two methods provide. Leading to a useless > system, as each (text or visualisation) would provide benefits not nicely > expressible in the other. Is there research in this area that can be tapped > into? > It is truly a difficult balance and I am not aware of any research into this area. What I have noticed is that in the UML world the main focus with diagrams seems to be to be able to generate code from the diagrams. Not a route I fancy. Basically, I think that having a textual-visual correspondence between code and diagrams, so that one can freely manipulate either, is not going to work. Better to separate the purpose of the visual notation from the executable nature of the code. Cheers, Torben > Regards, > Robby -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From jesper.louis.andersen@REDACTED Mon Jun 30 13:12:30 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 30 Jun 2014 13:12:30 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> Message-ID: On Mon, Jun 30, 2014 at 11:54 AM, Robert Raschke wrote: > I think there must be both, textual and visual, in order to convey > something to a wider audience, as some will prefer text, some diagrams, and > some like both. This is very true. People learn and ingest in different ways. So to have success you need to make it possible to understand your text in several ways. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Mon Jun 30 13:18:09 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 30 Jun 2014 11:18:09 +0000 Subject: [erlang-questions] Failure semantics of dets:insert_new vs dets:insert In-Reply-To: References: Message-ID: <56466BD70414EA48969B4064696CF28C037FC977@ESESSMB207.ericsson.se> [Alexei Sholik:] > But the signature for insert_new is > > insert_new(Name, Objects) -> boolean() > > In this case, false only indicates that a value for the key is already > in the table. What about failure cases of insert()? The type of the return value should include {error, Reason}. We'll correct the docs in 17.3. Thanks for reporting. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Mon Jun 30 13:17:28 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Mon, 30 Jun 2014 13:17:28 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: Hi Fredrik, It should be possible! though I can't promise to do this before the end of the week. I have exams and all? Cheers, -- Pierre Fenoll On 30 June 2014 08:36, Fredrik Andersson wrote: > Lovely. > > Would it be possible to re-generate old versions documentation for us who > are still stuck on older versions and can't move forward just yet. > > example: http://erldocs.com/R15B03/kernel/file.html > > > On Sat, Jun 28, 2014 at 12:43 PM, Pierre Fenoll > wrote: > >> Thanks everyone! This is very sweet. >> >> Adrian, Michael: >> This was indeed a typo, thanks for spotting it. >> >> >> Cheers, >> -- >> Pierre Fenoll >> >> >> >> On 28 June 2014 09:19, Ali Sabil wrote: >> >>> This is great! Thank you very much >>> >>> >>> On Sat, Jun 28, 2014 at 3:15 AM, Jesse Gumm wrote: >>> >>>> Thanks Pierre, >>>> >>>> The new changes look fantastic! >>>> >>>> -Jesse >>>> >>>> On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll >>>> wrote: >>>> > Hi, >>>> > >>>> > Earlier today I released the erldocs version of the documentation of >>>> > Erlang/OTP 17.1. >>>> > >>>> > Erldocs-the-tool has seen a lot of improvement since the previous >>>> > erldocs.com release. >>>> > In particular, exported types and function specs are now rendered and >>>> > exported functions now have their arguments. >>>> > Here is an example: >>>> > http://erldocs.com/current/kernel/file.html >>>> > >>>> > Note: if you haven't already, update your bookmark to >>>> > http://erldocs.com/current/ >>>> > >>>> > If you see something uncommon please file an issue here >>>> > https://github.com/fenollp/erldocs/issues >>>> > >>>> > I hope you will enjoy this release! >>>> > >>>> > Cheers, >>>> > -- >>>> > Pierre Fenoll >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > erlang-questions mailing list >>>> > erlang-questions@REDACTED >>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>> > >>>> >>>> >>>> >>>> -- >>>> Jesse Gumm >>>> Owner, Sigma Star Systems >>>> 414.940.4866 || sigma-star.com || @jessegumm >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From puneet@REDACTED Mon Jun 30 12:08:35 2014 From: puneet@REDACTED (Puneet Ahuja) Date: Mon, 30 Jun 2014 15:38:35 +0530 Subject: [erlang-questions] erlang node core dumps in erl_bestfit_alloc Message-ID: <41F70AB8-D68C-4DF5-BE15-B3A5F8355A2F@octro.com> Hi, We are frequently (every two days or so) encountering an issue where an erlang node crashes with the following backtrace, the same crash is replicated on more than one machine (with the same backtrace): Core was generated by `/usr/local/lib/erlang/erts-5.10.4/bin/beam.smp -zdbbl 20000 -swt very_low -sbt'. Program terminated with signal 11, Segmentation fault. #0 replace (allctr=0x130d400, size=296, cand_blk=, cand_size=) at beam/erl_bestfit_alloc.c:287 287 else if (x == x->parent->left) #0 replace (allctr=0x130d400, size=296, cand_blk=, cand_size=) at beam/erl_bestfit_alloc.c:287 #1 bf_unlink_free_block (allctr=0x130d400, size=296, cand_blk=, cand_size=) at beam/erl_bestfit_alloc.c:797 #2 bf_get_free_block (allctr=0x130d400, size=296, cand_blk=, cand_size=) at beam/erl_bestfit_alloc.c:857 #3 0x0000000000443106 in mbc_alloc_block (allctr=0x130d400, size=287) at beam/erl_alloc_util.c:1956 #4 mbc_alloc (allctr=0x130d400, size=287) at beam/erl_alloc_util.c:2085 #5 0x0000000000448963 in erts_alcu_alloc_thr_pref (type=170, extra=, size=287) at beam/erl_alloc_util.c:4932 #6 0x00000000005099a8 in erts_alloc (type=, size=287) at beam/erl_alloc.h:223 #7 0x0000000000509b7e in erts_bin_nrml_alloc (c_p=0x7ff5e3d85e48, reg=, live=, build_size_term=, extra_words=, unit=) at beam/erl_binary.h:260 #8 erts_bs_append (c_p=0x7ff5e3d85e48, reg=, live=, build_size_term=, extra_words=, unit=) at beam/erl_bits.c:1373 #9 0x000000000053d510 in process_main () at beam/beam_emu.c:3843 #10 0x000000000049dc8b in sched_thread_func (vesdp=0x7ff5e30168c0) at beam/erl_process.c:5801 #11 0x00000000005bda96 in thr_wrapper (vtwd=0x7fffc11bd510) at pthread/ethread.c:106 #12 0x0000003883c079d1 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038838e8b6d in clone () from /lib64/libc.so.6 The erlang otp version is R16B03-1 built from the source code without any customisation with respect to the configure script parameters. The exmpp library we depend on uses port drivers. We don?t encounter this problem in the nodes running on R15. The source code at the crash point seems to point to some kind of memory corruption in the erlang acquired memory in erl_bestfit_alloc. Any pointers on how to resolve this problem would help. Linux Kernel Version: 2.6.32-431.3.1.el6.x86_64 Linux Flavor: Centos 6.5 The crash occurs during minimal load conditions. Additionally gdb shows following libraries from the core dump: * * Libraries * From To Syms Read Shared Object Library 0x0000003885400e10 0x0000003885401688 Yes (*) /lib64/libutil.so.1 0x0000003dd0c00de0 0x0000003dd0c01998 Yes (*) /lib64/libdl.so.2 0x0000003884403e70 0x0000003884443fb8 Yes (*) /lib64/libm.so.6 0x00000039cac06a30 0x00000039cac1cf88 Yes (*) /lib64/libncurses.so.5 0x0000003883c05760 0x0000003883c110c8 Yes (*) /lib64/libpthread.so.0 0x0000003884002140 0x00000038840054f8 Yes (*) /lib64/librt.so.1 0x000000388381ea60 0x000000388394024c Yes (*) /lib64/libc.so.6 0x00000039cc00c840 0x00000039cc015c08 Yes (*) /lib64/libtinfo.so.5 0x0000003883000b00 0x00000038830198eb Yes (*) /lib64/ld-linux-x86-64.so.2 0x00007ff5d9a873c0 0x00007ff5d9a8e2c8 Yes /usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so 0x00007ff5d970abc0 0x00007ff5d97fd9a8 Yes (*) /usr/lib64/libcrypto.so.10 0x0000003884802120 0x000000388480d3a8 Yes (*) /lib64/libz.so.1 0x00007ff5d94a1900 0x00007ff5d94a1bf8 Yes /usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto_callback.so 0x00007ff5d9272f00 0x00007ff5d9276708 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_stringprep.so 0x00007ff5d8c38fa0 0x00007ff5d8c3dbf8 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_expat.so 0x0000003886403cd0 0x000000388641cc88 Yes (*) /lib64/libexpat.so.1 0x00007ff5d8a2ef00 0x00007ff5d8a33948 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_expat_legacy.so 0x00007ff5d8824f50 0x00007ff5d8829a28 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_libxml2.so 0x0000003cc562c7c0 0x0000003cc5709498 Yes (*) /usr/lib64/libxml2.so.2 0x00007ff5d3979950 0x00007ff5d397db18 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_tls_openssl.so 0x00007ff5d34d0180 0x00007ff5d350a938 Yes (*) /usr/lib64/libssl.so.10 0x0000003cc3a0ac30 0x0000003cc3a38728 Yes (*) /lib64/libgssapi_krb5.so.2 0x0000003cc4e1b430 0x0000003cc4e94a78 Yes (*) /lib64/libkrb5.so.3 0x00007ff5d32b53f0 0x00007ff5d32b5fc8 Yes (*) /lib64/libcom_err.so.2 0x0000003cc36043d0 0x0000003cc361d5a8 Yes (*) /lib64/libk5crypto.so.3 0x0000003cc4a02a40 0x0000003cc4a080c8 Yes (*) /lib64/libkrb5support.so.0 0x0000003cc3e00bf0 0x0000003cc3e011d8 Yes (*) /lib64/libkeyutils.so.1 0x0000003886003930 0x0000003886012938 Yes (*) /lib64/libresolv.so.2 0x0000003cc1a05850 0x0000003cc1a15cc8 Yes (*) /lib64/libselinux.so.1 0x00007ff5d30af5d0 0x00007ff5d30b2a28 Yes /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_compress_zlib.so Regards, Puneet From sedrik@REDACTED Mon Jun 30 13:21:48 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Mon, 30 Jun 2014 13:21:48 +0200 Subject: [erlang-questions] [ANN] erldocs.com's docs for 17.1! In-Reply-To: References: Message-ID: On Mon, Jun 30, 2014 at 1:17 PM, Pierre Fenoll wrote: > Hi Fredrik, > > It should be possible! though I can't promise to do this before the end of > the week. > I have exams and all? > No worries, thanks for keeping erldocs.org alive =) > > > Cheers, > -- > Pierre Fenoll > > > > On 30 June 2014 08:36, Fredrik Andersson wrote: > >> Lovely. >> >> Would it be possible to re-generate old versions documentation for us who >> are still stuck on older versions and can't move forward just yet. >> >> example: http://erldocs.com/R15B03/kernel/file.html >> >> >> On Sat, Jun 28, 2014 at 12:43 PM, Pierre Fenoll >> wrote: >> >>> Thanks everyone! This is very sweet. >>> >>> Adrian, Michael: >>> This was indeed a typo, thanks for spotting it. >>> >>> >>> Cheers, >>> -- >>> Pierre Fenoll >>> >>> >>> >>> On 28 June 2014 09:19, Ali Sabil wrote: >>> >>>> This is great! Thank you very much >>>> >>>> >>>> On Sat, Jun 28, 2014 at 3:15 AM, Jesse Gumm >>>> wrote: >>>> >>>>> Thanks Pierre, >>>>> >>>>> The new changes look fantastic! >>>>> >>>>> -Jesse >>>>> >>>>> On Fri, Jun 27, 2014 at 4:09 PM, Pierre Fenoll >>>>> wrote: >>>>> > Hi, >>>>> > >>>>> > Earlier today I released the erldocs version of the documentation of >>>>> > Erlang/OTP 17.1. >>>>> > >>>>> > Erldocs-the-tool has seen a lot of improvement since the previous >>>>> > erldocs.com release. >>>>> > In particular, exported types and function specs are now rendered and >>>>> > exported functions now have their arguments. >>>>> > Here is an example: >>>>> > http://erldocs.com/current/kernel/file.html >>>>> > >>>>> > Note: if you haven't already, update your bookmark to >>>>> > http://erldocs.com/current/ >>>>> > >>>>> > If you see something uncommon please file an issue here >>>>> > https://github.com/fenollp/erldocs/issues >>>>> > >>>>> > I hope you will enjoy this release! >>>>> > >>>>> > Cheers, >>>>> > -- >>>>> > Pierre Fenoll >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > erlang-questions mailing list >>>>> > erlang-questions@REDACTED >>>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Jesse Gumm >>>>> Owner, Sigma Star Systems >>>>> 414.940.4866 || sigma-star.com || @jessegumm >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Mon Jun 30 18:02:50 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Mon, 30 Jun 2014 18:02:50 +0200 Subject: [erlang-questions] erlang node core dumps in erl_bestfit_alloc In-Reply-To: <41F70AB8-D68C-4DF5-BE15-B3A5F8355A2F@octro.com> References: <41F70AB8-D68C-4DF5-BE15-B3A5F8355A2F@octro.com> Message-ID: Hello, 99% of the time when you see a memory corruption error in the erlang allocators it is because a nif/linked-in driver is miss managing memory it got from driver/nif_alloc. To track down the error I would either build a debug or valgrind enabled emulator and see if that shows anything. For a description on how to build a debug emulator see the INSTALL[1] howto. If you want to build a valgrind emulator just substitute debug with valgrind in the guide and it should work. Lukas [1]: https://github.com/erlang/otp/blob/master/HOWTO/INSTALL.md#how-to-build-a-debug-enabled-erlang-runtime-system On Mon, Jun 30, 2014 at 12:08 PM, Puneet Ahuja wrote: > Hi, > > > We are frequently (every two days or so) encountering an issue where an > erlang node crashes with the following backtrace, the same crash is > replicated on more than one machine (with the same backtrace): > > Core was generated by `/usr/local/lib/erlang/erts-5.10.4/bin/beam.smp > -zdbbl 20000 -swt very_low -sbt'. > Program terminated with signal 11, Segmentation fault. > #0 replace (allctr=0x130d400, size=296, cand_blk=, > cand_size=) at beam/erl_bestfit_alloc.c:287 > 287 else if (x == x->parent->left) > #0 replace (allctr=0x130d400, size=296, cand_blk=, > cand_size=) at beam/erl_bestfit_alloc.c:287 > #1 bf_unlink_free_block (allctr=0x130d400, size=296, cand_blk= optimized out>, cand_size=) at > beam/erl_bestfit_alloc.c:797 > #2 bf_get_free_block (allctr=0x130d400, size=296, cand_blk= optimized out>, cand_size=) at > beam/erl_bestfit_alloc.c:857 > #3 0x0000000000443106 in mbc_alloc_block (allctr=0x130d400, size=287) at > beam/erl_alloc_util.c:1956 > #4 mbc_alloc (allctr=0x130d400, size=287) at beam/erl_alloc_util.c:2085 > #5 0x0000000000448963 in erts_alcu_alloc_thr_pref (type=170, extra= optimized out>, size=287) at beam/erl_alloc_util.c:4932 > #6 0x00000000005099a8 in erts_alloc (type=, > size=287) at beam/erl_alloc.h:223 > #7 0x0000000000509b7e in erts_bin_nrml_alloc (c_p=0x7ff5e3d85e48, > reg=, live=, > build_size_term=, extra_words=, > unit=) at beam/erl_binary.h:260 > #8 erts_bs_append (c_p=0x7ff5e3d85e48, reg=, > live=, build_size_term=, > extra_words=, unit=) at > beam/erl_bits.c:1373 > #9 0x000000000053d510 in process_main () at beam/beam_emu.c:3843 > #10 0x000000000049dc8b in sched_thread_func (vesdp=0x7ff5e30168c0) at > beam/erl_process.c:5801 > #11 0x00000000005bda96 in thr_wrapper (vtwd=0x7fffc11bd510) at > pthread/ethread.c:106 > #12 0x0000003883c079d1 in start_thread () from /lib64/libpthread.so.0 > #13 0x00000038838e8b6d in clone () from /lib64/libc.so.6 > > > The erlang otp version is R16B03-1 built from the source code without any > customisation with respect to the configure script parameters. The exmpp > library we depend on uses port drivers. We don?t encounter this problem in > the nodes running on R15. > The source code at the crash point seems to point to some kind of memory > corruption in the erlang acquired memory in erl_bestfit_alloc. Any pointers > on how to resolve this problem would help. > > Linux Kernel Version: 2.6.32-431.3.1.el6.x86_64 > Linux Flavor: Centos 6.5 > > The crash occurs during minimal load conditions. > > Additionally gdb shows following libraries from the core dump: > > * > * Libraries > * > From To Syms Read Shared Object Library > 0x0000003885400e10 0x0000003885401688 Yes (*) /lib64/libutil.so.1 > 0x0000003dd0c00de0 0x0000003dd0c01998 Yes (*) /lib64/libdl.so.2 > 0x0000003884403e70 0x0000003884443fb8 Yes (*) /lib64/libm.so.6 > 0x00000039cac06a30 0x00000039cac1cf88 Yes (*) /lib64/libncurses.so.5 > 0x0000003883c05760 0x0000003883c110c8 Yes (*) /lib64/libpthread.so.0 > 0x0000003884002140 0x00000038840054f8 Yes (*) /lib64/librt.so.1 > 0x000000388381ea60 0x000000388394024c Yes (*) /lib64/libc.so.6 > 0x00000039cc00c840 0x00000039cc015c08 Yes (*) /lib64/libtinfo.so.5 > 0x0000003883000b00 0x00000038830198eb Yes (*) > /lib64/ld-linux-x86-64.so.2 > 0x00007ff5d9a873c0 0x00007ff5d9a8e2c8 Yes > /usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so > 0x00007ff5d970abc0 0x00007ff5d97fd9a8 Yes (*) > /usr/lib64/libcrypto.so.10 > 0x0000003884802120 0x000000388480d3a8 Yes (*) /lib64/libz.so.1 > 0x00007ff5d94a1900 0x00007ff5d94a1bf8 Yes > /usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto_callback.so > 0x00007ff5d9272f00 0x00007ff5d9276708 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_stringprep.so > 0x00007ff5d8c38fa0 0x00007ff5d8c3dbf8 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_expat.so > 0x0000003886403cd0 0x000000388641cc88 Yes (*) /lib64/libexpat.so.1 > 0x00007ff5d8a2ef00 0x00007ff5d8a33948 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_expat_legacy.so > 0x00007ff5d8824f50 0x00007ff5d8829a28 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_xml_libxml2.so > 0x0000003cc562c7c0 0x0000003cc5709498 Yes (*) /usr/lib64/libxml2.so.2 > 0x00007ff5d3979950 0x00007ff5d397db18 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_tls_openssl.so > 0x00007ff5d34d0180 0x00007ff5d350a938 Yes (*) /usr/lib64/libssl.so.10 > 0x0000003cc3a0ac30 0x0000003cc3a38728 Yes (*) > /lib64/libgssapi_krb5.so.2 > 0x0000003cc4e1b430 0x0000003cc4e94a78 Yes (*) /lib64/libkrb5.so.3 > 0x00007ff5d32b53f0 0x00007ff5d32b5fc8 Yes (*) /lib64/libcom_err.so.2 > 0x0000003cc36043d0 0x0000003cc361d5a8 Yes (*) /lib64/libk5crypto.so.3 > 0x0000003cc4a02a40 0x0000003cc4a080c8 Yes (*) > /lib64/libkrb5support.so.0 > 0x0000003cc3e00bf0 0x0000003cc3e011d8 Yes (*) /lib64/libkeyutils.so.1 > 0x0000003886003930 0x0000003886012938 Yes (*) /lib64/libresolv.so.2 > 0x0000003cc1a05850 0x0000003cc1a15cc8 Yes (*) /lib64/libselinux.so.1 > 0x00007ff5d30af5d0 0x00007ff5d30b2a28 Yes > /usr/local/lib/erlang/lib/exmpp-0.9.9-10-g3d17ff4/priv/lib/exmpp_compress_zlib.so > > Regards, > Puneet > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeljalvarezmiguel@REDACTED Mon Jun 30 22:19:45 2014 From: angeljalvarezmiguel@REDACTED (Angel Alvarez (GMAIL)) Date: Mon, 30 Jun 2014 22:19:45 +0200 Subject: [erlang-questions] Erlang for youngsters In-Reply-To: References: <539EB979.40605@meetinghouse.net> <2B7E3E06-8001-4E1A-97F2-C61B5C4B81DD@rogvall.se> <1402945075.869528733@apps.rackspace.com> <9A551891-D3DC-4140-9F8B-8A68F3A14247@cs.otago.ac.nz> Message-ID: Hi guys, Have any you seen this? http://twdkz.wordpress.com/2014/06/26/teenage-haskell/ I hope it is, of interest to this thread despite being haskell related.. Angel Alvarez angeljalvarezmiguel at gmail.com