From ok@REDACTED Fri Aug 1 00:33:14 2014 From: ok@REDACTED (ok@REDACTED) Date: Fri, 1 Aug 2014 10:33:14 +1200 Subject: [erlang-questions] How to run erlang code on GPU In-Reply-To: <15F2F098-EBA2-4203-AFEA-A4C51F803716@gmail.com> References: <15F2F098-EBA2-4203-AFEA-A4C51F803716@gmail.com> Message-ID: > Has anyone done this or given the GPU architecture it's impossible? Given the general characteristics of GPUs, trying to run existing Erlang on them seems unlikely to be fruitful. What seems more likely to pay off would be - designing a sublanguage of Erlang with a special-purpose library (this would rely heavily on the Dialyzer, I imagine) - and building a compiler from that language to OpenCL - so that chunks of compute-intensive code could be written in an Erlang-friendly way. From fritchie@REDACTED Fri Aug 1 07:52:59 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 01 Aug 2014 00:52:59 -0500 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: Message of "Wed, 30 Jul 2014 02:53:16 PDT." <7d709a3b-ffe5-40c3-9420-c0f9f0aff0ed@googlegroups.com> Message-ID: <32860.1406872379@snookles.snookles.com> marcos quesada wrote: mq> module 'cluster_test' mq> cluster_test: cluster_formation_suite_test_...*timed out* mq> undefined mq> [done in 5.001 s] Hi, Marcos. Is your test really requiring 5 seconds or more to run? If so, then you're hitting the EUnit default timeout of 5 seconds. You need to change the EUnit test specification with a {timeout,...} wrapper to set a longer timeout. See http://erlang.org/doc/apps/eunit/chapter.html for details. -Scott From fritchie@REDACTED Fri Aug 1 08:05:44 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 01 Aug 2014 01:05:44 -0500 Subject: [erlang-questions] R16 + Centos + Crypto + ESL Package In-Reply-To: Message of "Wed\, 30 Jul 2014 20\:49\:14 +0400." Message-ID: <33743.1406873144@snookles.snookles.com> ?????? ??????? wrote: dg> Hello, During our work on migration from R14B04 to R16B03-1 we hit dg> the problem with `crypto` on `CentOS [...] Hi! I just discovered the same thing yesterday, for a completely different reason. And some of Basho's Riak 2.0.0 release candidate packages are affected(*), hooray that they aren't final yet. The autoconf toolchain seems to go to great lengths to disable all -O compiler optimizations whenever the CFLAGS environment variable is specified, regardless of what it's set to? There really *are* times where we want to have symbols in the executables & libraries without also disabling optimizations. In my case, I simply want to add "-g" to the CFLAGS & LDFLAGS so that the Linux "perf" tool suite would have some extra symbols available. The same applies when using DTrace: without symbols, user stack traces via D's ustack() function lose most of their value. This feels like a toolchain bug ... or, at the very least a very surprising(**) change of behavior. -Scott (*) The Riak 2.0.0 release candidate for CentOS 6 has an Erlang/OTP VM compiled to work around the very crypto problem that Danila is also working around. The same Configure script + CFLAGS="-DOPENSSL_NO_EC=1" method is used by our release team. (**) Yes, I know that compiler optimizations can confuse someone using a symbolic debugger like GDB ... and that's probably why the toolchain is removing all -O in invocations? From marcos.quesadas@REDACTED Fri Aug 1 09:54:12 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Fri, 1 Aug 2014 09:54:12 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: <32860.1406872379@snookles.snookles.com> References: <7d709a3b-ffe5-40c3-9420-c0f9f0aff0ed@googlegroups.com> <32860.1406872379@snookles.snookles.com> Message-ID: Yep! I Know that I'm hitting Eunit timeout, and that's the thing that i don't understant. As I said, executing: make start and then "cluster_test:cluster_formation()", the test works fine, no timeout appears an all the suite runs like a charm. In the other hand: make quicktests, runs the same but using test environment, here it is where timeout failure appears. 2014-08-01 7:52 GMT+02:00 Scott Lystig Fritchie : > marcos quesada wrote: > > mq> module 'cluster_test' > mq> cluster_test: cluster_formation_suite_test_...*timed out* > mq> undefined > mq> [done in 5.001 s] > > Hi, Marcos. Is your test really requiring 5 seconds or more to run? If > so, then you're hitting the EUnit default timeout of 5 seconds. You > need to change the EUnit test specification with a {timeout,...} wrapper > to set a longer timeout. See > http://erlang.org/doc/apps/eunit/chapter.html for details. > > -Scott > -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Fri Aug 1 10:18:07 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 01 Aug 2014 03:18:07 -0500 Subject: [erlang-questions] R16 + Centos + Crypto + ESL Package In-Reply-To: Message of "Fri, 01 Aug 2014 01:05:44 CDT." <33743.1406873144@snookles.snookles.com> Message-ID: <43048.1406881087@snookles.snookles.com> Scott Lystig Fritchie wrote: slf> The autoconf toolchain seems to go to great lengths to disable all slf> -O compiler optimizations whenever the CFLAGS environment variable slf> is specified, regardless of what it's set to? Hahaha, oh, how I delude myself. It's amazing what a person can learn from reading documentation ... in this case, the GNU Make docs. $(subst from,to,text) Performs a textual replacement on the text text: each occurrence of from is replaced by to. The result is substituted for the function call. So, I was mis-reading all of the Makefile.in templates. For example, from erts/emulator/Makefile.in: $(OBJDIR)/%.o: beam/%.c $(CC) $(subst -O2, $(GEN_OPT_FLGS), $(CFLAGS)) $(INCLUDES) -c $< -o $@ My misunderstanding was that -O2 was the result of the $(subst ...). Silly me. My interpretation of all of the Makefile.in template files is that they embed the following assumption: if a default CFLAGS-related variable or compiler-optimization-related variable is going to contain an -O flag of some kind, it's going to be "-O2". There are many places where the Makefile.in templates then decide: * I'm going to change the default optimization to $(GEN_OPT_FLGS) * I'm going to remove the default optimization entirely, e.g., done in a handful of places when building a valgrind or debug version. Furthermore, the location for the default optimization is the top-level "configure" script itself. "Configure" checks whether you're using GCC, and based on the result will set CFLAGS to be: 1. The value of CFLAGS environment variable is, if it was set prior to running "configure" 2. If using GCC, then "-g -O2" or "-O2", depending on if GCC understands "-g" or not. 3. If using GCC, then "-g" or "", depending on if the compiler understands "-g" or not. So, it seems to me that Danila and I/Basho can solve our optimizer problem and our CentOS-6-broken-SSL-problem at the same time by adding "-O2" to CFLAGS before running "configure" ... then the rest of the autoconf stuff will magically change -O2 -> -O3 in the appropriate places, use -O2 elsewhere, etc., and the world will sing and dance and be fast(er). -Scott From fritchie@REDACTED Fri Aug 1 11:04:27 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 01 Aug 2014 04:04:27 -0500 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: Message of "Fri\, 01 Aug 2014 04\:00\:23 CDT." <45939.1406883623@snookles.snookles.com> Message-ID: <46244.1406883867@snookles.snookles.com> marcos quesada wrote: mq> As I said, executing: ? make start and mq> then "cluster_test:cluster_formation()", the test works fine, no mq> timeout appears an all the suite runs like a charm. Yes, but you aren't using EUnit to execute it: you're executing it directly. What happens when you run this? eunit:test(cluster_test). Or when you run the test without EUnit and measure the wall clock time: timer:tc(fun() -> cluster_test:cluster_formation() end). That will return a 2-tuple, where the 1st element is the number of microseconds elapsed during your test. -Scott From marcos.quesadas@REDACTED Fri Aug 1 11:36:57 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Fri, 1 Aug 2014 11:36:57 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: <45939.1406883623@snookles.snookles.com> References: <45939.1406883623@snookles.snookles.com> Message-ID: Exactly, that is where expected result fails! Here's the test: *http://pastebin.com/vsRuLKVj * Running timer:tc(fun() -> cluster_test:cluster_formation() end). , It works like a charm, cluster is well created, slave nodes are added to the main one , running fine. Here's the result: Eshell V5.10.4 (abort with ^G) *(node1@REDACTED )1> timer:tc(fun() -> cluster_test:cluster_formation() end).* 11:31:27.940 [info] Application lager started on node 'slave1@REDACTED' 11:31:28.016 [info] Application inets started on node 'slave1@REDACTED' 11:31:28.049 [info] Application crypto started on node 'slave1@REDACTED' 11:31:28.070 [info] Application asn1 started on node 'slave1@REDACTED' 11:31:28.071 [info] Application public_key started on node 'slave1@REDACTED ' 11:31:28.080 [info] Application ssl started on node 'slave1@REDACTED' 11:31:28.095 [info] Application gproc started on node 'slave1@REDACTED' 11:31:28.107 [info] Application cluster started on node 'slave1@REDACTED' 11:31:28.483 [info] Application lager started on node 'slave2@REDACTED' 11:31:28.538 [info] Application inets started on node 'slave2@REDACTED' 11:31:28.563 [info] Application crypto started on node 'slave2@REDACTED' 11:31:28.574 [info] Application asn1 started on node 'slave2@REDACTED' 11:31:28.574 [info] Application public_key started on node 'slave2@REDACTED ' 11:31:28.584 [info] Application ssl started on node 'slave2@REDACTED' 11:31:28.601 [info] Application gproc started on node 'slave2@REDACTED' 11:31:28.617 [info] Application cluster started on node 'slave2@REDACTED' *Cluster formation, nodes: ['node1@REDACTED ','slave1@REDACTED ',* * 'slave2@REDACTED '] * *{3555096,ok}* Executing eunit:test(cluster_test), that's the result: *(node1@REDACTED )1> eunit:test(cluster_test).* cluster_test: cluster_formation_suite_test_...*failed* in function cluster_test:'-cluster_formation/0-fun-4-'/2 (src/cluster_test.erl, line 43) in call from cluster_test:cluster_formation/0 (src/cluster_test.erl, line 43) **error:{assertEqual_failed, [{module,cluster_test}, {line,43}, {expression,"Result1"}, {expected,ok}, {value, {badrpc, {'EXIT', {undef, [{cluster,join,[...],...}, {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} ======================================================= Failed: 1. Skipped: 0. Passed: 0. error It fails in the joinning step, but i'm pretty sure that is in slave:start when the failure starts. 2014-08-01 11:00 GMT+02:00 Scott Lystig Fritchie : > timer:tc(fun() -> cluster_test:cluster_formation() end). > -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Aug 1 15:07:44 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 01 Aug 2014 15:07:44 +0200 Subject: [erlang-questions] [ANN] erlang.mk 1.0 Message-ID: <53DB9120.3070904@ninenines.eu> Hello! erlang.mk 1.0 has been released. erlang.mk is a GNU Make based build system with bootstrap and package index features that make life so much better. https://github.com/ninenines/erlang.mk Going from 0 to release is a 5 steps process with erlang.mk. * # Create a directory for your application * # Download erlang.mk into that directory * make -f erlang.mk bootstrap bootstrap-rel * make * ./_rel/your_release/bin/your_release console And if you want to use a third party project, like Cowboy, you simply need to add this one line to your Makefile and then run make again: * DEPS = cowboy That's really it! A note for previous users: a few small things changed since the previous version. You can take a look at the Cowboy or Ranch repositories for details. It's mostly a number of things you don't have to do anymore so it's a quick upgrade, just delete a few lines! This new version is compatible with projects using an older erlang.mk so you can update at your own pace. Don't forget to add your Make-powered projects to the package index file and send a PR to make everyone's life better! Enjoy! -- Lo?c Hoguin http://ninenines.eu From map@REDACTED Fri Aug 1 16:32:28 2014 From: map@REDACTED (Magnus Ahltorp) Date: Fri, 1 Aug 2014 16:32:28 +0200 Subject: [erlang-questions] Erlang and fsync Message-ID: Hello! When a UNIX program wants to ensure that a file and its contents have been written to disk, the normal way is to call fsync(). In Erlang, there is a file:sync that as far as I can see just calls fsync(). There are, however, two problems with this: 1) Since directories are not openable with file:open, it is not possible to fsync directories. This is a problem, since fsync() doesn't necessarily ensure that the directory entry of a newly created file has reached the disk. 2) fsync() blocks the thread that executes it until the data is submitted to the disk. A number of Erlang processes doing fsync() could totally wreck the realtime performance of the system, since fsync() can take a long time. I tried to search through the mail archives, but I couldn't find any solutions to this. How do people solve this, or don't other people using Erlang want (soft) guarantees that their data is on disk? Do I have to write the code in C and send the files to be fsync:ed over a port? /Magnus From marcos.quesadas@REDACTED Fri Aug 1 16:35:54 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Fri, 1 Aug 2014 07:35:54 -0700 (PDT) Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: Added to my to-do list , thank you Lo?c ;) From marcos.quesadas@REDACTED Fri Aug 1 16:35:54 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Fri, 1 Aug 2014 07:35:54 -0700 (PDT) Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: Added to my to-do list , thank you Lo?c ;) -- 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. From fritchie@REDACTED Fri Aug 1 17:02:17 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 01 Aug 2014 10:02:17 -0500 Subject: [erlang-questions] R16 + Centos + Crypto + ESL Package In-Reply-To: Message of "Fri, 01 Aug 2014 03:18:07 CDT." <43048.1406881087@snookles.snookles.com> Message-ID: <71977.1406905337@snookles.snookles.com> Oops, sorry, a correction: > 3. If using GCC, then "-g" or "", depending on if the compiler > understands "-g" or not. That should read: 3. If *not* using GCC, then "-g" or "", depending on if the compiler understands "-g" or not. -Scott From jj@REDACTED Fri Aug 1 17:37:36 2014 From: jj@REDACTED (Giovanni Giorgi) Date: Fri, 01 Aug 2014 17:37:36 +0200 Subject: [erlang-questions] [ANN] er-zauker v0.0.5 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: <8ee2467ae40d4c9dba6eba74c146fc20@webmail.webfaction.com> Hi, Er Zauker v0.0.5 has been released: Er Zauker is a search engine tailored for programming languages. It is based from ideas taken by old Google Code Search (see ) and uses Redis as storage engine. This Erlang version spots the following features: * czgrep's very nice color output * stunning performance * performance meter via eprof using "make benchmark" * various bugfixes (covered by 30 unit tests) Tip: Please follow instruction on how to configure your redis instance in the readme, to avoid losing collected data. Suggestions, pull requests and bug reports are wellcome!! --- Giovanni Giorgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Fri Aug 1 22:28:04 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Fri, 1 Aug 2014 22:28:04 +0200 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: Lovely to see an update to my favourite Erlang build tool. Great work :-) On Aug 1, 2014 3:07 PM, "Lo?c Hoguin" wrote: > Hello! > > erlang.mk 1.0 has been released. > > erlang.mk is a GNU Make based build system with bootstrap and package > index features that make life so much better. > > https://github.com/ninenines/erlang.mk > > Going from 0 to release is a 5 steps process with erlang.mk. > > * # Create a directory for your application > * # Download erlang.mk into that directory > * make -f erlang.mk bootstrap bootstrap-rel > * make > * ./_rel/your_release/bin/your_release console > > And if you want to use a third party project, like Cowboy, you simply need > to add this one line to your Makefile and then run make again: > > * DEPS = cowboy > > That's really it! > > A note for previous users: a few small things changed since the previous > version. You can take a look at the Cowboy or Ranch repositories for > details. It's mostly a number of things you don't have to do anymore so > it's a quick upgrade, just delete a few lines! This new version is > compatible with projects using an older erlang.mk so you can update at > your own pace. > > Don't forget to add your Make-powered projects to the package index file > and send a PR to make everyone's life better! > > Enjoy! > > -- > 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 icfp.publicity@REDACTED Fri Aug 1 23:49:15 2014 From: icfp.publicity@REDACTED (David Van Horn) Date: Fri, 1 Aug 2014 17:49:15 -0400 Subject: [erlang-questions] ICFP 2014 Final Call for Participation Message-ID: [ Early registration ends 3 Aug; Invited speakers and conference program have been announced. ] ===================================================================== Final Call for Participation ICFP 2014 19th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 31 - September 6, 2014 Gothenburg, Swedenhttp://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 * Program: http://icfpconference.org/icfp2014/program.html * Accepted Papers: http://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 Keynote speakers: * Kathleen Fisher (Tufts University): Using Formal Methods to Enable More Secure Vehicles: DARPA's HACMS Program * Robert Bruce Findler (Northwestern University): Behavioral Software Contracts * Stephanie Weirich (University of Pennsylvania): Depending on Types 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 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 Alephcloud IntelliFactory Opera Software QuviQ Systeor Vest AS ===================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek@REDACTED Sat Aug 2 00:54:40 2014 From: wojtek@REDACTED (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=) Date: Sat, 02 Aug 2014 00:54:40 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: References: Message-ID: <53DC1AB0.1070803@power.com.pl> On 01.08.2014 16:32, Magnus Ahltorp wrote: > How do people solve this, or don't other people using Erlang want (soft) guarantees that their data is on disk? Do I have to write the code in C and send the files to be fsync:ed over a port? > > I would say that for 'soft' guarantees you don't have to do anything, it's already there in the operating system. > Do I have to write the code in C and send the files to be fsync:ed over a port? I'd look at fixing file:open to allow opening directories first. Or better, look at prim_file, as file is useless for any serious IO, it serializes everything. -- Kind regards, Wojetk From map@REDACTED Sun Aug 3 02:07:59 2014 From: map@REDACTED (Magnus Ahltorp) Date: Sun, 3 Aug 2014 02:07:59 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: <53DC1AB0.1070803@power.com.pl> References: <53DC1AB0.1070803@power.com.pl> Message-ID: <21DC42D6-FC34-4255-A5D1-25388B0D0D7F@kth.se> 2 aug 2014 00:54 Wojtek Narczy?ski wrote: > On 01.08.2014 16:32, Magnus Ahltorp wrote: >> How do people solve this, or don't other people using Erlang want (soft) guarantees that their data is on disk? Do I have to write the code in C and send the files to be fsync:ed over a port? >> >> > I would say that for 'soft' guarantees you don't have to do anything, it's already there in the operating system. On some operating systems, it might take a very long time for data to reach the disk, and that is not acceptable in my case. By "soft", I meant that the operating system has done all it can to ensure that the data is permanently stored, but of course the disk can choose not to obey that (which many disks choose to). There is a difference between "reached the disk" and "permanently stored". >> Do I have to write the code in C and send the files to be fsync:ed over a port? > I'd look at fixing file:open to allow opening directories first. Or better, look at prim_file, as file is useless for any serious IO, it serializes everything. But prim_file is not documented, and also refuses to open directories: Eshell V6.1 (abort with ^G) 1> prim_file:open("/tmp", [read]). {error,eisdir} And regarding changing the Erlang libraries, that is interesting looking forward, but this has to work now, without patching Erlang locally, so my question stands: "How do people solve this?". /Magnus From wojtek@REDACTED Sun Aug 3 11:42:33 2014 From: wojtek@REDACTED (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=) Date: Sun, 03 Aug 2014 11:42:33 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: <21DC42D6-FC34-4255-A5D1-25388B0D0D7F@kth.se> References: <53DC1AB0.1070803@power.com.pl> <21DC42D6-FC34-4255-A5D1-25388B0D0D7F@kth.se> Message-ID: <53DE0409.2000906@power.com.pl> On 03.08.2014 02:07, Magnus Ahltorp wrote: > > On some operating systems, it might take a very long time for data to reach the disk, and that is not acceptable in my case. By "soft", I meant that the operating system has done all it can to ensure that the data is permanently stored, but of course the disk can choose not to obey that (which many disks choose to). There is a difference between "reached the disk" and "permanently stored". > If a system is under heavy IO load, this is definitely so. If you are on Linux, you can use ionice to control this to some extent. > But prim_file is not documented, and also refuses to open directories: prim_file is undocumented, but file is radioactive. You have been warned. > Eshell V6.1 (abort with ^G) > 1> prim_file:open("/tmp", [read]). > {error,eisdir} Indeed. I have looked at the source, and the problem is not there, it's probably in the C driver, so no luck here. If memory serves me well, you can't open a directory into a descriptor in Win32, so this is probably the reason why things are so. > And regarding changing the Erlang libraries, that is interesting looking forward, but this has to work now, without patching Erlang locally, You don't have to patch, you can just fork a local copy of a function or module. > so my question stands: "How do people solve this?". > > Well, looks like people don't. But it is rather simple an excercise with a port program. -- Wojtek From cjsvance@REDACTED Sun Aug 3 12:02:57 2014 From: cjsvance@REDACTED (Christopher Vance) Date: Sun, 3 Aug 2014 20:02:57 +1000 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: What is the idiomatic erlang.mk way to replace rebar's platform_define feature? I have code running on different Erlang versions which cross the deprecation boundary for crypto functions, and I'd like my code to adapt appropriately. On Fri, Aug 1, 2014 at 11:07 PM, Lo?c Hoguin wrote: > Hello! > > erlang.mk 1.0 has been released. > > erlang.mk is a GNU Make based build system with bootstrap and package > index features that make life so much better. > > https://github.com/ninenines/erlang.mk > > Going from 0 to release is a 5 steps process with erlang.mk. > > * # Create a directory for your application > * # Download erlang.mk into that directory > * make -f erlang.mk bootstrap bootstrap-rel > * make > * ./_rel/your_release/bin/your_release console > > And if you want to use a third party project, like Cowboy, you simply need > to add this one line to your Makefile and then run make again: > > * DEPS = cowboy > > That's really it! > > A note for previous users: a few small things changed since the previous > version. You can take a look at the Cowboy or Ranch repositories for > details. It's mostly a number of things you don't have to do anymore so > it's a quick upgrade, just delete a few lines! This new version is > compatible with projects using an older erlang.mk so you can update at > your own pace. > > Don't forget to add your Make-powered projects to the package index file > and send a PR to make everyone's life better! > > Enjoy! > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sun Aug 3 12:20:45 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 03 Aug 2014 12:20:45 +0200 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: References: <53DB9120.3070904@ninenines.eu> Message-ID: <53DE0CFD.4060008@ninenines.eu> I'm not sure what platform_define does exactly, having never used it, but I suppose you could easily define ERLC_OPTS conditionally based on the OTP version. The best way to do that would probably be to look inside the OTP_VERSION file. The hard part would be to figure out how to do it without a slow VM start I suppose. That's something that could be added as a plugin once an appropriate way is figured out. On 08/03/2014 12:02 PM, Christopher Vance wrote: > What is the idiomatic erlang.mk way to replace > rebar's platform_define feature? > > I have code running on different Erlang versions which cross the > deprecation boundary for crypto functions, and I'd like my code to adapt > appropriately. > > > On Fri, Aug 1, 2014 at 11:07 PM, Lo?c Hoguin > wrote: > > Hello! > > erlang.mk 1.0 has been released. > > erlang.mk is a GNU Make based build system with > bootstrap and package index features that make life so much better. > > https://github.com/ninenines/__erlang.mk > > > Going from 0 to release is a 5 steps process with erlang.mk > . > > * # Create a directory for your application > * # Download erlang.mk into that directory > * make -f erlang.mk bootstrap bootstrap-rel > * make > * ./_rel/your_release/bin/your___release console > > And if you want to use a third party project, like Cowboy, you > simply need to add this one line to your Makefile and then run make > again: > > * DEPS = cowboy > > That's really it! > > A note for previous users: a few small things changed since the > previous version. You can take a look at the Cowboy or Ranch > repositories for details. It's mostly a number of things you don't > have to do anymore so it's a quick upgrade, just delete a few lines! > This new version is compatible with projects using an older > erlang.mk so you can update at your own pace. > > Don't forget to add your Make-powered projects to the package index > file and send a PR to make everyone's life better! > > Enjoy! > > -- > Lo?c Hoguin > http://ninenines.eu > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > -- > Christopher Vance -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Sun Aug 3 12:33:00 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 3 Aug 2014 12:33:00 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: <53DE0409.2000906@power.com.pl> References: <53DC1AB0.1070803@power.com.pl> <21DC42D6-FC34-4255-A5D1-25388B0D0D7F@kth.se> <53DE0409.2000906@power.com.pl> Message-ID: What? If you want more local-only functions, implement them, just as I did for read_file_info. A ?raw? file opened through the public file module is just as local as a file descriptor coming from prim_file. https://github.com/erlang/otp/pull/413 -- Anthony Ramine Le 3 ao?t 2014 ? 11:42, Wojtek Narczy?ski a ?crit : > prim_file is undocumented, but file is radioactive. You have been warned. From desired.mta@REDACTED Sun Aug 3 13:56:05 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Sun, 3 Aug 2014 13:56:05 +0200 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DE0CFD.4060008@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> <53DE0CFD.4060008@ninenines.eu> Message-ID: On Sun, Aug 3, 2014 at 12:20 PM, Lo?c Hoguin wrote: > That's something that could be added as a plugin once an appropriate way is > figured out. At the moment I see that a 'plugin' is just a piece of code which in the end gets concatenated to `erlang.mk` (see build.config and Makefile). Not really possible to make a 'non-official' plugin. Therefore, maybe we should call them `modules` instead? Are there any plans to support real plugins, which erlang.mk would be the core, and stuff could be added to it per-project? Something like plugins in rebar -- you can extend rebar with a plugin in your repository if you like. I haven't used erlang.mk to be honest (maybe the whole 'real plugin' thing is not applicable?), but it's something I've been willing to do for a while now. But since you mentioned, I would be interested in how you are going to approach this. Motiejus From essen@REDACTED Sun Aug 3 16:08:11 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 03 Aug 2014 16:08:11 +0200 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: References: <53DB9120.3070904@ninenines.eu> <53DE0CFD.4060008@ninenines.eu> Message-ID: <53DE424B.2070105@ninenines.eu> On 08/03/2014 01:56 PM, Motiejus Jak?tys wrote: > On Sun, Aug 3, 2014 at 12:20 PM, Lo?c Hoguin wrote: >> That's something that could be added as a plugin once an appropriate way is >> figured out. > > At the moment I see that a 'plugin' is just a piece of code which in > the end gets concatenated to `erlang.mk` (see build.config and > Makefile). Not really possible to make a 'non-official' plugin. > Therefore, maybe we should call them `modules` instead? It's called plugins because you can just "include theplugin.mk" if you want. The build tool that comes with erlang.mk allows you to build everything into a single file which is easier to work with, but you don't have to use it that way. > Are there any plans to support real plugins, which erlang.mk would be > the core, and stuff could be added to it per-project? Something like > plugins in rebar -- you can extend rebar with a plugin in your > repository if you like. You can extend erlang.mk directly in your Makefile or in your own include files, but it's better if you add to the main repository as a plugin and let other people benefit from it. -- Lo?c Hoguin http://ninenines.eu From fritchie@REDACTED Mon Aug 4 03:00:44 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Sun, 03 Aug 2014 20:00:44 -0500 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: Message of "Fri, 01 Aug 2014 11:36:57 +0200." Message-ID: <96561.1407114044@snookles.snookles.com> marcos quesada wrote: mq> **error:{assertEqual_failed, mq> [{module,cluster_test}, mq> {line,43}, mq> {expression,"Result1"}, mq> {expected,ok}, mq> {value, mq> {badrpc, mq> {'EXIT', mq> {undef, mq> [{cluster,join,[...],...}, mq> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} Have you found the cause of this error? If I had to guess, the slave node's code_server doesn't know the path to your cluster.beam module. If that's true, then appending ["-pz", PathToYourModule] to the Args list of slave:start/3 can correct it. -Scott From ok@REDACTED Mon Aug 4 03:37:26 2014 From: ok@REDACTED (ok@REDACTED) Date: Mon, 4 Aug 2014 13:37:26 +1200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: References: Message-ID: <1e7cf25e600998ccfaf72ff3e70d6bc5.squirrel@chasm.otago.ac.nz> > Hello! > > When a UNIX program wants to ensure that a file and its contents have been > written to disk, the normal way is to call fsync(). >From the Mac OS X manual page for fsync(2): Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physically write the data to the platters for quite some time and it may be written in an out-of-order sequence. Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. The disk drive may also re-order the data so that later writes may be present, while earlier writes are not. This is not a theoretical edge case. This scenario is easily reproduced with real world workloads and drive power failures. It is possible to ask a drive to commit stuff to permanent storage, and Mac OS X provide the F_FULLSYNC fcntl() call to do that. None of the other UNIX systems I have, or have access to manuals for, has the same fcntl() option. If anyone _does_ know of a tolerably portable way to ensure that your data are physically on a permanent medium, I would be glad to hear of it. From lukas@REDACTED Mon Aug 4 09:46:30 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 4 Aug 2014 09:46:30 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: References: Message-ID: Hello! On Fri, Aug 1, 2014 at 4:32 PM, Magnus Ahltorp wrote: > > 1) Since directories are not openable with file:open, it is not possible > to fsync directories. This is a problem, since fsync() doesn't necessarily > ensure that the directory entry of a newly created file has reached the > disk. > As stated in this thread there is no way to do this cross-platform, so if you need this functionality and it is available on your OS I would suggest writing a small nif. 2) fsync() blocks the thread that executes it until the data is submitted > to the disk. A number of Erlang processes doing fsync() could totally wreck > the realtime performance of the system, since fsync() can take a long time. > If you make sure that you open all the sensitive files with the [raw] option and have "enough" async threads to deal with the fsyncs that are in progress then only the Erlang process issuing the command will be blocked. All other processes will continue running, keeping their realtime guarantees. If you do not use [raw], or have too few async threads that you might see queues growing and the overall latency of file operations will increase. It will however not effect non-file related things. Also you might want to consider using the [{sync,true}] option to file:open. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Aug 4 10:05:57 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 4 Aug 2014 10:05:57 +0200 Subject: [erlang-questions] map module functions, map "cons" idea In-Reply-To: References: Message-ID: Hello Daniel! Thanks for taking the time to write down your ideas and suggestions. On Thu, Jul 31, 2014 at 9:28 PM, Daniel Goertzen wrote: > > 1. I ported a few functions from the lists module. The ones I found > useful were filter() and mapfold(). I also found with() useful, which does > the opposite of maps:without(). I would be very happy to see these 3 > functions in the maps module. > I too see the usefulness of these functions. I'll bring it up with the resident expert. > > > 2. In the talk there was a question about matching an empty map, and also > a question about precise matching like how one would match a list. I have > always wondered similar things, so it got me thinking? > > What if we use a "cons" in a map pattern to allow matching all remaining > keys that were not selected in the main part of the pattern? This would be > roughly symmetric to what you can do with lists and binaries. For example: > > #{ a:=A, c:=C | Rest } = #{a=>1, b=>2, c=>3, d=>4}. % Rest = #{b=>2, > d=>4} > > > That in itself I think has limited use, but it could be used to exactly > match a map (ie, no extra pairs other than those specified in the match): > > f(#{ a:=A, c:=C | Rest }) > > when maps:size(Rest)==0 -> > > ? > > > If the pattern to the right of the bar is elided, we could take it to mean > ?match the empty map?. The previous example could be rewritten as: > > f(#{ a:=A, c:=C |}) -> > > ? > > > This also lets you match just the empty map as was asked in the talk: > > f(#{|}) -> > > ? > > > Richard O'Keefe had something very similar to this in his proposal for how frames should work in Erlang. You can find the details here: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf. We have been talking about doing something like this, but want to stabilize and polish off the current feature set before doing any more work on the syntax. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Aug 4 10:14:04 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 4 Aug 2014 10:14:04 +0200 Subject: [erlang-questions] State of Erlang on PPC In-Reply-To: References: Message-ID: Hello Tim, On Wed, Jul 23, 2014 at 11:43 PM, Tim McGilchrist wrote: > What's the current state of the Erlang VM on PPC? Specifically I'm > interested in running it on one of the Freescale embedded boards with one > of these CPUs. (http://en.m.wikipedia.org/wiki/PowerQUICC) > PowerPC is a well supported architecture, we run nightly tests and make sure that all features work well on it. I have not come across the specific CPU that you mention above, but I've worked with other Freescale PPC CPUs. > So who's running Erlang on PPC > > I know of at least 6-7 released products that run Erlang/OTP on Powerpc, I'm sure there are plenty more. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Mon Aug 4 10:18:42 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Mon, 4 Aug 2014 10:18:42 +0200 Subject: [erlang-questions] 17.1 vs R16 In-Reply-To: References: Message-ID: Hello Matthew, On Wed, Jul 23, 2014 at 5:09 PM, Matthew Evans wrote: > > Are there any issues with running code compiled on a 17.1 Erlang release > on an R16 release? > > If the emulator is able to load the code, then it should work. Compiling with an newer release than you run on is not supported and not generally recommended, but if you can load the beam file it should work. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.hubsch@REDACTED Mon Aug 4 13:01:59 2014 From: sylvain.hubsch@REDACTED (Sylvain Hash) Date: Mon, 4 Aug 2014 04:01:59 -0700 (PDT) Subject: [erlang-questions] code:(un)stick_mod not documented ? Message-ID: <24a1728f-d0e6-4519-9a7c-fc065893585d@googlegroups.com> First post, hi list! The code module exports (un)stick_dir and (un)stick_mod functions, but only the first is documented. So I did some tests with the second (v17.1) : * when a module is sticked via stick_mod and I try to reload it, the error is the same as if it were sticked via stick_dir (error sticky_directory) * (un)stick_mod do the job on the module itself (as it should), not entire directory So my questions : is (un)stick_mod really supported ? I understand I should not use it because it is not documented, but why is it not documented as it (deprecated, do not use in your apps etc..) ? Is it an historical bug (the error message) which should be corrected before documented ? Thank you for reading :) Sylvain. -- 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. From marcos.quesadas@REDACTED Mon Aug 4 17:14:03 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Mon, 4 Aug 2014 08:14:03 -0700 (PDT) Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: <96561.1407114044@snookles.snookles.com> References: <96561.1407114044@snookles.snookles.com> Message-ID: Nop, didn't find it. Maybe i'm missing something, but I think that slaves nodes are getting right the path to find all required beams. All slaves are initialized using: Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", In fact when I execute cluster_test:cluster_formation() works fine. What's the difference to use -pz from -pa? Thank you! El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie escribi?: > marcos quesada wrote: > > > > mq> **error:{assertEqual_failed, > > mq> [{module,cluster_test}, > > mq> {line,43}, > > mq> {expression,"Result1"}, > > mq> {expected,ok}, > > mq> {value, > > mq> {badrpc, > > mq> {'EXIT', > > mq> {undef, > > mq> [{cluster,join,[...],...}, > > mq> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} > > > > Have you found the cause of this error? If I had to guess, the slave > > node's code_server doesn't know the path to your cluster.beam module. > > If that's true, then appending ["-pz", PathToYourModule] to the Args > > list of slave:start/3 can correct it. > > > > -Scott > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions From marcos.quesadas@REDACTED Mon Aug 4 17:14:03 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Mon, 4 Aug 2014 08:14:03 -0700 (PDT) Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: <96561.1407114044@snookles.snookles.com> References: <96561.1407114044@snookles.snookles.com> Message-ID: Nop, didn't find it. Maybe i'm missing something, but I think that slaves nodes are getting right the path to find all required beams. All slaves are initialized using: Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", In fact when I execute cluster_test:cluster_formation() works fine. What's the difference to use -pz from -pa? Thank you! El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie escribi?: > marcos quesada wrote: > > > > mq> **error:{assertEqual_failed, > > mq> [{module,cluster_test}, > > mq> {line,43}, > > mq> {expression,"Result1"}, > > mq> {expected,ok}, > > mq> {value, > > mq> {badrpc, > > mq> {'EXIT', > > mq> {undef, > > mq> [{cluster,join,[...],...}, > > mq> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} > > > > Have you found the cause of this error? If I had to guess, the slave > > node's code_server doesn't know the path to your cluster.beam module. > > If that's true, then appending ["-pz", PathToYourModule] to the Args > > list of slave:start/3 can correct it. > > > > -Scott > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions -- 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. From timmcgil@REDACTED Tue Aug 5 05:24:42 2014 From: timmcgil@REDACTED (Tim McGilchrist) Date: Tue, 5 Aug 2014 13:24:42 +1000 Subject: [erlang-questions] State of Erlang on PPC In-Reply-To: References: Message-ID: <18C8E636-43EF-43C1-9F4E-56E6CA0E9CDD@gmail.com> Thanks Lukas, it sounds like it's well supported. ----------------------------------------------------- Tim McGilchrist @lambda_foo http://github.com/tmcgilchrist On 4 Aug 2014, at 6:14 pm, Lukas Larsson wrote: > Hello Tim, > > > On Wed, Jul 23, 2014 at 11:43 PM, Tim McGilchrist wrote: > What's the current state of the Erlang VM on PPC? Specifically I'm interested in running it on one of the Freescale embedded boards with one of these CPUs. (http://en.m.wikipedia.org/wiki/PowerQUICC) > > PowerPC is a well supported architecture, we run nightly tests and make sure that all features work well on it. I have not come across the specific CPU that you mention above, but I've worked with other Freescale PPC CPUs. > > > So who's running Erlang on PPC > > > I know of at least 6-7 released products that run Erlang/OTP on Powerpc, I'm sure there are plenty more. > > Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From gopi@REDACTED Tue Aug 5 14:24:47 2014 From: gopi@REDACTED (Gopi Krishna) Date: Tue, 5 Aug 2014 17:54:47 +0530 Subject: [erlang-questions] Reduce phase in erlang Message-ID: Hi, I am working on riak database , I am having data in a riak bucket for a key like: <<"{\"META\": {\"campaign\": \"5IVUPHE42HP1NEYvKb7qSvpX2Cm\", \"createdat\": 1406978070.0, \"user_email\": \"gopikrishnajonnada@REDACTED\"}, \"mode\": 2, \"status\": \"success\"}">> I have written a map phase which is giving data like [<<"{<<"5IVUPHE42HP1NEYvKb7qSvpX2Cm">>,1}">>, <<"{<<"WL6iHLCgs492rFEFvqewzvCfFfj">>, 2}">>, <<"{"5IVUPHE42HP1NEYvKb7qSvpX2Cm">>, 1}">>, <<"{<<"5IVUPHE42HP1NEYvKb7qSvpX2Cm">>, 2}">>] so for the above data from mapphase i have to write a reduce phase that should give depending on a condition like if it {key,Vlaue} if value is 0 or 1 then i have to to add new variable like ab_leads and it should increment I have tried like this this but the reducefunction should have more number of functions according to [oldlist++newlist] lists:foldl(fun({Key,Mode},Acc) -> if Mode == 0;Mode == 1 -> orddict:update_counter({Key,<<"ab_leads">>},1,Acc); true -> orddict:update_counter({Key,<<"cp_leads">>},1,Acc) end end,orddict:new(),G). [{{Key,{<<"ab_leads">>,10},{<<"cp_leads">>,20}},{Key1,{{<<"ab_leads">>,15},{<<"cp_leads">>,15}}]. please suggest me -- Thanks & Regards, J.Gopi Krishna +91-8341452934, www.lintelindia.com Lintel Technologies Pvt. LTD,Hyderabad. This message contains confidential information and is intended for recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Aug 5 14:43:47 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 05 Aug 2014 14:43:47 +0200 Subject: [erlang-questions] [ANN] Cowboy 1.0 Message-ID: <53E0D183.1060206@ninenines.eu> Hello! Cowboy 1.0 has been released. Cowboy is a small and fast HTTP server for Erlang with support for Webmachine-like REST, Websocket and more. https://github.com/ninenines/cowboy Cowboy is the work of more than 80 people. I would like to congratulate everyone for the great work done so far. Thank you! Please see the CHANGELOG for details on what's changed. https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md This release marks the beginning of the 1.0.x branch which will contain backward compatible fixes. This branch will be maintained at least until Cowboy 2.0 gets released (longer if sponsors request it). It is highly recommended that you follow this branch if you were following master before, as master will receive backward incompatible changes starting tomorrow. Cowboy is now fully documented. It has a user guide, a function reference manual, and a wealth of examples. You can also install man pages as explained in the README of the project. http://ninenines.eu/docs/en/cowboy/1.0/guide/ http://ninenines.eu/docs/en/cowboy/1.0/manual/ https://github.com/ninenines/cowboy/tree/master/examples Following a discussion on the Erlang mailing lists the Getting Started chapter was reworked and greatly simplified, in parts due to the improvements made to erlang.mk. Feedback is of course always welcome. http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ Starting tomorrow the master branch will receive backward incompatible changes. Most of the planned changes are detailed in the ROADMAP. You are welcome to suggest additional changes. https://github.com/ninenines/cowboy/blob/master/ROADMAP.md Cowboy 2.0 is planned to be released at around the same time Erlang/OTP 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although that may change in the coming months if there is interest in new features. Ranch also got upgraded to 1.0, although there was no changes from the previous release. https://github.com/ninenines/ranch Thanks to everyone who made this project what it is today! -- Lo?c Hoguin http://ninenines.eu From semmitmondo@REDACTED Tue Aug 5 14:52:19 2014 From: semmitmondo@REDACTED (semmit mondo) Date: Tue, 5 Aug 2014 14:52:19 +0200 (CEST) Subject: [erlang-questions] How to split a single huge server? Message-ID: Hi, I have a single-process solution for a server that, I feel, could be implementetin a more concurrent fashion. Its internal state is a vector that consists of n numbers.It receives casts without parameters. Every cast is basically a matrix multiplication.The matrices are known in advance. So, if the internal state is v, and the serverprocess receives a cast, and it has the matrix M associated with that cast, then thenew state will be M*v (M is a matrix, * is matrix multiplication, and v is a column vectorrepresenting the previous internal state of the server process). My problem is that the size of v (and the matrices) can be very large, and myserver runs in a single process. It would be great to split it apart and use severalsmaller processes to calculate the new state. I would like to use separateprocesses for each number in v. But because of the nature of matrix multiplication,that's not so easy to achieve, because in order to be able to calculate a singlenumber in th e new state, I need to know all the numbers in the previous state.The prev state could be shared between processes in advance, but that wouldrequire large messages containing all the old values to all the processes around.I believe that is a wrong idea and there must be a better one. My question is how would you crach this problem if efficiency matters? I have one possible solution in mind, and would like to know your opinion: therecould be a main server process and size(v) calculator processes, one for everynumber in v. The server process handles the casts, and it has the whole v vectorin it. The calculator processes have only one number from v, and they have theproper lines from M. When a cast arrives, the server process builds a fun that hasthe whole v encoded in it as a clojure, and this anon function gets sent to thecalculator processes. Then the calculator processes apply the fun to theappropriate line of M, and they have the new number that they have to sendback to the server. I'm not sure if sending a huge ! function with a large body ischeaper than sending a large list of numbers, but I hope there's some optimisationgoing on in BEAM with funs... Am I right with all this? THX -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon@REDACTED Tue Aug 5 15:29:48 2014 From: jon@REDACTED (Jon Schneider) Date: Tue, 5 Aug 2014 14:29:48 +0100 Subject: [erlang-questions] How to split a single huge server? In-Reply-To: References: Message-ID: How large are these matrices ? It all sounds like you'd end up wasting resources on inter-process communication and just about everything else. Remember we've had desktop PCs with instructions (MMX, SSE) that do maybe 8 FLOPS per cycle for about twenty years now but you're not going to be able to take advantage of this by re-inventing matrix multiplication. Jon From max.lapshin@REDACTED Tue Aug 5 15:33:27 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 5 Aug 2014 17:33:27 +0400 Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: <53E0D183.1060206@ninenines.eu> References: <53E0D183.1060206@ninenines.eu> Message-ID: Loic, it is very cool! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Tue Aug 5 16:15:59 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Tue, 5 Aug 2014 16:15:59 +0200 Subject: [erlang-questions] State of Erlang on PPC References: Message-ID: Hi Tim, I run Erlang on top of RTEMS on a MPC8309 (embedded PowerPC controler from Freescale), works fine. Cheers, -- Peer On 2014-07-23 21:43:44 +0000, Tim McGilchrist said: > What's the current state of the Erlang VM on PPC? Specifically I'm > interested in running it on one of the Freescale embedded boards with > one of these CPUs. (http://en.m.wikipedia.org/wiki/PowerQUICC) > > Searching through the mailing list archives suggests that erlang has > previously run on these CPUs. But there isn't much recent activity > suggesting people are using it.? > > So who's running Erlang on PPC > > Thanks > > > > ----------------------------------------------------- > Tim McGilchrist > > @lambda_foo > http://github.com/tmcgilchrist -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico.carrone@REDACTED Tue Aug 5 16:18:36 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Tue, 5 Aug 2014 11:18:36 -0300 Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: References: <53E0D183.1060206@ninenines.eu> Message-ID: Congratulations Loic. I really love cowboy. I got only one question: Why did you change the reply with 400 instead of 422 in cowboy_rest for unprocessable entities? Regards, Federico. On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin wrote: > Loic, it is very cool! > > Thanks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From semmitmondo@REDACTED Tue Aug 5 16:12:11 2014 From: semmitmondo@REDACTED (semmit mondo) Date: Tue, 5 Aug 2014 16:12:11 +0200 (CEST) Subject: [erlang-questions] How to split a single huge server? Message-ID: >How large are these matrices ? They can be huge. 2^16 x 2^16 is an average one but can be much larger.Does the anonymous function trick help me out? So basically what you suggest is that I need an external piece of software written in a low level language that uses low level SIMD instructions on the bare CPU or maybe uses GPU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Tue Aug 5 17:01:51 2014 From: bob@REDACTED (Bob Ippolito) Date: Tue, 5 Aug 2014 08:01:51 -0700 Subject: [erlang-questions] How to split a single huge server? In-Reply-To: References: Message-ID: There are languages such as Python (numpy, numba) or Haskell (repa, accelerate) that have high level and fast implementations of these operations in libraries, supporting CPU and/or GPU. I'm not aware of such popular bindings for Erlang, most of the ones I've come across don't seem to be maintained but cl looks like it might be promising for working with the GPU from Erlang: https://github.com/tonyrog/cl On Tue, Aug 5, 2014 at 7:12 AM, semmit mondo wrote: > > > How large are these matrices ? > > > They can be huge. 2^16 x 2^16 is an average one but can be much larger. > Does the anonymous function trick help me out? > > So basically what you suggest is that I need an external piece of software > written in a low level language that uses low level SIMD instructions on > the bare CPU or maybe uses GPU. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Tue Aug 5 17:34:05 2014 From: roberto@REDACTED (Roberto Ostinelli) Date: Tue, 5 Aug 2014 08:34:05 -0700 Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: <53E0D183.1060206@ninenines.eu> References: <53E0D183.1060206@ninenines.eu> Message-ID: w00t! :) r. On Tue, Aug 5, 2014 at 5:43 AM, Lo?c Hoguin wrote: > Hello! > > Cowboy 1.0 has been released. > > Cowboy is a small and fast HTTP server for Erlang with support for > Webmachine-like REST, Websocket and more. > > https://github.com/ninenines/cowboy > > Cowboy is the work of more than 80 people. I would like to congratulate > everyone for the great work done so far. Thank you! > > Please see the CHANGELOG for details on what's changed. > > https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md > > This release marks the beginning of the 1.0.x branch which will contain > backward compatible fixes. This branch will be maintained at least until > Cowboy 2.0 gets released (longer if sponsors request it). It is highly > recommended that you follow this branch if you were following master > before, as master will receive backward incompatible changes starting > tomorrow. > > Cowboy is now fully documented. It has a user guide, a function reference > manual, and a wealth of examples. You can also install man pages as > explained in the README of the project. > > http://ninenines.eu/docs/en/cowboy/1.0/guide/ > http://ninenines.eu/docs/en/cowboy/1.0/manual/ > https://github.com/ninenines/cowboy/tree/master/examples > > Following a discussion on the Erlang mailing lists the Getting Started > chapter was reworked and greatly simplified, in parts due to the > improvements made to erlang.mk. Feedback is of course always welcome. > > http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ > > Starting tomorrow the master branch will receive backward incompatible > changes. Most of the planned changes are detailed in the ROADMAP. You are > welcome to suggest additional changes. > > https://github.com/ninenines/cowboy/blob/master/ROADMAP.md > > Cowboy 2.0 is planned to be released at around the same time Erlang/OTP > 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although > that may change in the coming months if there is interest in new features. > > Ranch also got upgraded to 1.0, although there was no changes from the > previous release. > > https://github.com/ninenines/ranch > > Thanks to everyone who made this project what it is today! > > -- > 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 gumm@REDACTED Tue Aug 5 17:56:25 2014 From: gumm@REDACTED (Jesse Gumm) Date: Tue, 5 Aug 2014 10:56:25 -0500 Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: <53E0D183.1060206@ninenines.eu> References: <53E0D183.1060206@ninenines.eu> Message-ID: Congrats Loic! -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Aug 5, 2014 7:43 AM, "Lo?c Hoguin" wrote: > Hello! > > Cowboy 1.0 has been released. > > Cowboy is a small and fast HTTP server for Erlang with support for > Webmachine-like REST, Websocket and more. > > https://github.com/ninenines/cowboy > > Cowboy is the work of more than 80 people. I would like to congratulate > everyone for the great work done so far. Thank you! > > Please see the CHANGELOG for details on what's changed. > > https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md > > This release marks the beginning of the 1.0.x branch which will contain > backward compatible fixes. This branch will be maintained at least until > Cowboy 2.0 gets released (longer if sponsors request it). It is highly > recommended that you follow this branch if you were following master > before, as master will receive backward incompatible changes starting > tomorrow. > > Cowboy is now fully documented. It has a user guide, a function reference > manual, and a wealth of examples. You can also install man pages as > explained in the README of the project. > > http://ninenines.eu/docs/en/cowboy/1.0/guide/ > http://ninenines.eu/docs/en/cowboy/1.0/manual/ > https://github.com/ninenines/cowboy/tree/master/examples > > Following a discussion on the Erlang mailing lists the Getting Started > chapter was reworked and greatly simplified, in parts due to the > improvements made to erlang.mk. Feedback is of course always welcome. > > http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ > > Starting tomorrow the master branch will receive backward incompatible > changes. Most of the planned changes are detailed in the ROADMAP. You are > welcome to suggest additional changes. > > https://github.com/ninenines/cowboy/blob/master/ROADMAP.md > > Cowboy 2.0 is planned to be released at around the same time Erlang/OTP > 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although > that may change in the coming months if there is interest in new features. > > Ranch also got upgraded to 1.0, although there was no changes from the > previous release. > > https://github.com/ninenines/ranch > > Thanks to everyone who made this project what it is today! > > -- > 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 peerst@REDACTED Tue Aug 5 18:26:45 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Tue, 5 Aug 2014 18:26:45 +0200 Subject: [erlang-questions] How to split a single huge server? References: Message-ID: You could use https://github.com/tonyrog/cl On 2014-08-05 14:12:11 +0000, semmit mondo said: > --===============4801298331139695666== > > Content-Type: MULTIPART/alternative; > BOUNDARY="2096565089-1804289383-1407247931=:5440" > > > > --2096565089-1804289383-1407247931=:5440 > > Content-Type: TEXT/plain; CHARSET=UTF-8 > > > > > > >How large are these matrices ? > > They can be huge. 2^16 x 2^16 is an average one but can be much > larger.Does the anonymous function trick help me out? So basically what > you suggest is that I need an external piece of software written in a > low level language that uses low level SIMD instructions on the bare > CPU or maybe uses GPU. > > --2096565089-1804289383-1407247931=:5440 > > Content-Type: TEXT/html; CHARSET=UTF-8 > > > >
  > >
> >
> >
> >
How large are these matrices ?
> >
> > > >
 
> > > >
They can be huge.  2^16 x 2^16 is an average one but can be > much larger.
> > > >
Does the anonymous function trick help me out?
> > > >
 
> > > >
So basically what you suggest is that I need an external piece of > software written in a low level language that uses low level SIMD > instructions on the bare CPU or maybe uses GPU.
> > > >
 
> >
> >
> >
> > > > --2096565089-1804289383-1407247931=:5440-- > > > > --===============4801298331139695666== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > From dmkolesnikov@REDACTED Tue Aug 5 18:36:56 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 5 Aug 2014 19:36:56 +0300 Subject: [erlang-questions] How to split a single huge server? In-Reply-To: References: Message-ID: <39FE1437-84BE-4D86-A61A-0E2A0ACEC0B3@gmail.com> Hello, I think the original question was how to run a matrix to vector multiplication efficiently in parallel. The usage of C libraries is one way to handle it. However, we do not see the description of actual use-case. At least, it was not clear to me? was the question about pure ?math? multiplication or something else. All-in-all Here is very good description how to run matrix to vert multiplication in parallel. I guess you can dap at the technique for your need. http://www.hpcc.unn.ru/mskurs/ENG/DOC/pp07.pdf - Dmitry On 05 Aug 2014, at 19:26, Peer Stritzinger wrote: > You could use > > https://github.com/tonyrog/cl > > > On 2014-08-05 14:12:11 +0000, semmit mondo said: > >> --===============4801298331139695666== >> Content-Type: MULTIPART/alternative; BOUNDARY="2096565089-1804289383-1407247931=:5440" >> --2096565089-1804289383-1407247931=:5440 >> Content-Type: TEXT/plain; CHARSET=UTF-8 >> >How large are these matrices ? >> They can be huge. 2^16 x 2^16 is an average one but can be much larger.Does the anonymous function trick help me out? So basically what you suggest is that I need an external piece of software written in a low level language that uses low level SIMD instructions on the bare CPU or maybe uses GPU. --2096565089-1804289383-1407247931=:5440 >> Content-Type: TEXT/html; CHARSET=UTF-8 >>
  >>
>>
>>
>>
How large are these matrices ?
>>
>>
 
>>
They can be huge.  2^16 x 2^16 is an average one but can be much larger.
>>
Does the anonymous function trick help me out?
>>
 
>>
So basically what you suggest is that I need an external piece of software written in a low level language that uses low level SIMD instructions on the bare CPU or maybe uses GPU.
>>
 
>>
>>
>>
>> --2096565089-1804289383-1407247931=:5440-- >> --===============4801298331139695666== >> Content-Type: text/plain; charset="us-ascii" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lloyd@REDACTED Tue Aug 5 19:34:33 2014 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 5 Aug 2014 13:34:33 -0400 (EDT) Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: <53E0D183.1060206@ninenines.eu> References: <53E0D183.1060206@ninenines.eu> Message-ID: <1407260073.80138967@apps.rackspace.com> Tip of the hat, Lo?c et. al. Outstanding and much appreciated work. Best to all, Lloyd -----Original Message----- From: "Lo?c Hoguin" Sent: Tuesday, August 5, 2014 8:43am To: "Erlang" , Extend@REDACTED Subject: [erlang-questions] [ANN] Cowboy 1.0 Hello! Cowboy 1.0 has been released. Cowboy is a small and fast HTTP server for Erlang with support for Webmachine-like REST, Websocket and more. https://github.com/ninenines/cowboy Cowboy is the work of more than 80 people. I would like to congratulate everyone for the great work done so far. Thank you! Please see the CHANGELOG for details on what's changed. https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md This release marks the beginning of the 1.0.x branch which will contain backward compatible fixes. This branch will be maintained at least until Cowboy 2.0 gets released (longer if sponsors request it). It is highly recommended that you follow this branch if you were following master before, as master will receive backward incompatible changes starting tomorrow. Cowboy is now fully documented. It has a user guide, a function reference manual, and a wealth of examples. You can also install man pages as explained in the README of the project. http://ninenines.eu/docs/en/cowboy/1.0/guide/ http://ninenines.eu/docs/en/cowboy/1.0/manual/ https://github.com/ninenines/cowboy/tree/master/examples Following a discussion on the Erlang mailing lists the Getting Started chapter was reworked and greatly simplified, in parts due to the improvements made to erlang.mk. Feedback is of course always welcome. http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ Starting tomorrow the master branch will receive backward incompatible changes. Most of the planned changes are detailed in the ROADMAP. You are welcome to suggest additional changes. https://github.com/ninenines/cowboy/blob/master/ROADMAP.md Cowboy 2.0 is planned to be released at around the same time Erlang/OTP 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although that may change in the coming months if there is interest in new features. Ranch also got upgraded to 1.0, although there was no changes from the previous release. https://github.com/ninenines/ranch Thanks to everyone who made this project what it is today! -- Lo?c Hoguin http://ninenines.eu _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Tue Aug 5 19:55:36 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 5 Aug 2014 20:55:36 +0300 Subject: [erlang-questions] [ANN]: application deployment script Message-ID: <90E11F1D-A5C0-4465-9C0C-3696C6590528@gmail.com> Hello, Please treat this message as blog post, I am sharing my practice on application management and releasing. I am dealing with hybrid environment. I do not have company wide Erlang knowledge. I do have needs to build standalone Erlang software service deployable to hosts on network. My goal was to produce a stand-alone package that contains all dependencies including Erlang VM, enable development on Mac and deployment to Linux? I?ve investigated various build solution such as GNU autotools with custom M4 macros, application packaging as depicted by Erlang OTP In Action, rebar, reltool, erlang.mk and other. However, there is set of requirements which needs to be addressed to simplify production operation, see link. I think that rebar and reltool with naive Makefile glue allows to achieve them. Honestly, I am confused why some people complain about rebar. I have made an effort to depict my release cycles and share my Makefile with community. https://github.com/fogfish/makefile It is streamlined for Mac OS and Linux CentOS... Best Regards, Dmitry From paulo.ferraz.oliveira@REDACTED Tue Aug 5 22:33:17 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 5 Aug 2014 21:33:17 +0100 Subject: [erlang-questions] [ANN] Cowboy 1.0 In-Reply-To: References: <53E0D183.1060206@ninenines.eu> Message-ID: Hi, Federico. Check this out for the "why" regarding your question: https://github.com/ninenines/cowboy/issues/715 It's one of the reasons (I haven't detected others yet) stopping me from moving to 1.0, unfortunately (I have some projects depending on these status codes already), but as soon as I have some time and look at all the _major_ differences between 0.9.0 and 1.0 I think I'll make the move. For the time being, I have found no issues with the REST part of cowboy (the one I use). Thank you, Lo?c et all for the effort and for keeping it open source. Regards. - Paulo F. Oliveira On 5 August 2014 15:18, Federico Carrone wrote: > Congratulations Loic. I really love cowboy. > > I got only one question: Why did you change the reply with 400 instead of > 422 in cowboy_rest for unprocessable entities? > > Regards, > Federico. > > > > On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > wrote: > >> Loic, it is very cool! >> >> Thanks. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > 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 essen@REDACTED Tue Aug 5 22:55:34 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 05 Aug 2014 22:55:34 +0200 Subject: [erlang-questions] [99s-extend] [ANN] Cowboy 1.0 In-Reply-To: References: <53E0D183.1060206@ninenines.eu> Message-ID: <53E144C6.7040701@ninenines.eu> You can easily send 422 and return halt instead of returning false if you need to keep that, it'll just be 2 lines instead of 1. :) On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: > Hi, Federico. > > Check this out for the "why" regarding your question: > https://github.com/ninenines/cowboy/issues/715 > > It's one of the reasons (I haven't detected others yet) stopping me from > moving to 1.0, unfortunately (I have some projects depending on these > status codes already), but as soon as I have some time and look at all > the _major_ differences between 0.9.0 and 1.0 I think I'll make the > move. For the time being, I have found no issues with the REST part of > cowboy (the one I use). > > Thank you, Lo?c et all for the effort and for keeping it open source. > > Regards. > > - Paulo F. Oliveira > > > On 5 August 2014 15:18, Federico Carrone > wrote: > > Congratulations Loic. I really love cowboy. > > I got only one question: Why did you change the reply with 400 > instead of 422 in cowboy_rest for unprocessable entities? > > Regards, > Federico. > > > > On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > wrote: > > Loic, it is very cool! > > Thanks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > http://federicocarrone.com/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > Extend mailing list > Extend@REDACTED > https://lists.ninenines.eu/listinfo/extend > -- Lo?c Hoguin http://ninenines.eu From paulo.ferraz.oliveira@REDACTED Tue Aug 5 23:01:38 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Tue, 5 Aug 2014 22:01:38 +0100 Subject: [erlang-questions] [99s-extend] [ANN] Cowboy 1.0 In-Reply-To: <53E144C6.7040701@ninenines.eu> References: <53E0D183.1060206@ninenines.eu> <53E144C6.7040701@ninenines.eu> Message-ID: Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only important difference I should be aware of, then? I haven't written any real tests, for the time being, to guarantee backward compatibility for dependants... In any case, I'm thinking about updating the dependencies in the future (I own one of them and the other one is an internal project, for the time being). Thanks for the tip. Cheers. - Paulo F. Oliveira On 5 August 2014 21:55, Lo?c Hoguin wrote: > You can easily send 422 and return halt instead of returning false if you > need to keep that, it'll just be 2 lines instead of 1. :) > > On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: > >> Hi, Federico. >> >> Check this out for the "why" regarding your question: >> https://github.com/ninenines/cowboy/issues/715 >> >> It's one of the reasons (I haven't detected others yet) stopping me from >> moving to 1.0, unfortunately (I have some projects depending on these >> status codes already), but as soon as I have some time and look at all >> the _major_ differences between 0.9.0 and 1.0 I think I'll make the >> move. For the time being, I have found no issues with the REST part of >> cowboy (the one I use). >> >> Thank you, Lo?c et all for the effort and for keeping it open source. >> >> Regards. >> >> - Paulo F. Oliveira >> >> >> On 5 August 2014 15:18, Federico Carrone > > wrote: >> >> Congratulations Loic. I really love cowboy. >> >> I got only one question: Why did you change the reply with 400 >> instead of 422 in cowboy_rest for unprocessable entities? >> >> Regards, >> Federico. >> >> >> >> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > > wrote: >> >> Loic, it is very cool! >> >> Thanks. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> http://federicocarrone.com/ >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> _______________________________________________ >> Extend mailing list >> Extend@REDACTED >> https://lists.ninenines.eu/listinfo/extend >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Aug 5 23:06:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 05 Aug 2014 23:06:19 +0200 Subject: [erlang-questions] [99s-extend] [ANN] Cowboy 1.0 In-Reply-To: References: <53E0D183.1060206@ninenines.eu> <53E144C6.7040701@ninenines.eu> Message-ID: <53E1474B.1080407@ninenines.eu> If you were already at the previous version (0.10) then that plus a 400 instead of 500 when header parsing fails are pretty much the only changes. There's some more if you were at 0.9, mostly the body reading interface changed to prevent annoying timeout issues. On 08/05/2014 11:01 PM, Paulo F. Oliveira wrote: > Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only > important difference I should be aware of, then? I haven't written any > real tests, for the time being, to guarantee backward compatibility for > dependants... > > In any case, I'm thinking about updating the dependencies in the future > (I own one of them and the other one is an internal project, for the > time being). > > Thanks for the tip. > > Cheers. > > - Paulo F. Oliveira > > > On 5 August 2014 21:55, Lo?c Hoguin > wrote: > > You can easily send 422 and return halt instead of returning false > if you need to keep that, it'll just be 2 lines instead of 1. :) > > On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: > > Hi, Federico. > > Check this out for the "why" regarding your question: > https://github.com/ninenines/__cowboy/issues/715 > > > It's one of the reasons (I haven't detected others yet) stopping > me from > moving to 1.0, unfortunately (I have some projects depending on > these > status codes already), but as soon as I have some time and look > at all > the _major_ differences between 0.9.0 and 1.0 I think I'll make the > move. For the time being, I have found no issues with the REST > part of > cowboy (the one I use). > > Thank you, Lo?c et all for the effort and for keeping it open > source. > > Regards. > > - Paulo F. Oliveira > > > On 5 August 2014 15:18, Federico Carrone > > >> wrote: > > Congratulations Loic. I really love cowboy. > > I got only one question: Why did you change the reply with 400 > instead of 422 in cowboy_rest for unprocessable entities? > > Regards, > Federico. > > > > On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > > >__> wrote: > > Loic, it is very cool! > > Thanks. > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > -- > http://federicocarrone.com/ > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > _________________________________________________ > Extend mailing list > Extend@REDACTED > https://lists.ninenines.eu/__listinfo/extend > > > > -- > Lo?c Hoguin > http://ninenines.eu > > -- Lo?c Hoguin http://ninenines.eu From yousuke.hara@REDACTED Wed Aug 6 05:53:34 2014 From: yousuke.hara@REDACTED (Yosuke Hara) Date: Wed, 6 Aug 2014 12:53:34 +0900 Subject: [erlang-questions] [ANN] LeoFS 1.1 Message-ID: Hello everyone, I'm happy to announce LeoFS 1.1 has been released. LeoFS is an unstructured object/data storage for the Web and a highly available, distributed, eventually consistent storage system. - Github: https://github.com/leo-project/leofs - Website: http://leo-project.net/leofs You're able to see the CHANGELOG for details on what's changed with LeoFS v1.1.0. - CHANGELOG: https://github.com/leo-project/leofs/blob/master/CHANGELOG.md We've implemented "NFS Support" as one of the LeoFS protocols and pulished "LeoFS with NFS" on our Web site. It is the alpha version. We're going to improve it gradually. - LeoFS with NFS: http://leo-project.net/leofs/docs/configuration_5.html As one more new feature, we provided "leofs-adm" script, which makes administrative operations of LeoFS very easy. - leofs-adm: https://github.com/leo-project/leofs/blob/master/leofs-adm Lastly, I'd like to share the contents as follows: - Getting Started: http://leo-project.net/leofs/docs/getting_started.html - FAQ: http://leo-project.net/leofs/docs/faq.html - Architecture: http://leo-project.net/leofs/docs/architecture.html - Slide: http://www.slideshare.net/rakutentech/scaling-and-high-performance-storage-system-leofs If you have interested in LeoFS, please contact us. Thank you! Yosuke Hara (Tech lead LeoFS and LeoProject) From schoch@REDACTED Tue Aug 5 22:05:46 2014 From: schoch@REDACTED (Jesse Schoch) Date: Tue, 5 Aug 2014 13:05:46 -0700 (PDT) Subject: [erlang-questions] openssl cipher disabled Message-ID: <38867d6b-d868-4edd-8630-487b72ce287d@googlegroups.com> I'm trying to compile 17.1 on a system that has obsolete ciphers disabled, such as RC2. I get the following error In file included from crypto.c:51: /usr/include/openssl/rc2.h:64:2: error: #error RC2 is disabled. It appears the function rc2_cbc_encrypt/3 can't compile. Can these functions be disabled based on the available ciphers in a hardened system? -- 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. From tuncer.ayaz@REDACTED Wed Aug 6 10:03:21 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 6 Aug 2014 10:03:21 +0200 Subject: [erlang-questions] openssl cipher disabled In-Reply-To: <38867d6b-d868-4edd-8630-487b72ce287d@googlegroups.com> References: <38867d6b-d868-4edd-8630-487b72ce287d@googlegroups.com> Message-ID: On Tue, Aug 5, 2014 at 10:05 PM, Jesse Schoch wrote: > I'm trying to compile 17.1 on a system that has obsolete ciphers > disabled, such as RC2. I get the following error > > In file included from crypto.c:51: > /usr/include/openssl/rc2.h:64:2: error: #error RC2 is disabled. > > It appears the function rc2_cbc_encrypt/3 can't compile. Can these > functions be disabled based on the available ciphers in a hardened > system? Given the various actively maintained OpenSSL forks, it seems like lib/crypto should autoconf-check availability of a lot of stuff and use a generated config.h. This might also require partially or completely disabling lib/{ssl, public_key, ...} functionality. The changes in the forks and custom-compiled OpenSSL installs mean: 1. we either require OpenSSL with a certain set of features 2. and/or conditionalize features where feasible The biggest issue I see is with the required build/test matrix. From jon@REDACTED Wed Aug 6 10:37:52 2014 From: jon@REDACTED (Jon Schneider) Date: Wed, 6 Aug 2014 09:37:52 +0100 Subject: [erlang-questions] How to split a single huge server? In-Reply-To: References: Message-ID: <9bde24c4b97f0fdc2b60a1c0dac596dc.squirrel@mail.jschneider.net> > So basically what > you suggest is that I need an external piece of software written in a low > level language that uses low level SIMD instructions on the bare CPU or > maybe uses GPU. I can't say I'm talking from experience but strongly suspect yes. Jon From fritchie@REDACTED Wed Aug 6 15:40:51 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 06 Aug 2014 08:40:51 -0500 Subject: [erlang-questions] Erlang and fsync In-Reply-To: Message of "Mon\, 04 Aug 2014 09\:46\:30 +0200." Message-ID: <38016.1407332451@snookles.snookles.com> Lukas Larsson wrote: ll> ? As stated in this thread there is no way to do this ll> cross-platform, so if you need this functionality and it is ll> available on your OS I would suggest writing a small nif. To avoid angering the reduction-based-scheduling-gods-that-**will**- smite-you-if-you-really-do-this, your NIF is no longer so small because you'll need to do your own thread pool management + use the NIF to initiate the sync + message passing when the pool has finished work. Or you pass the work to a new-fangled dirty scheduler? -Scott From lukas@REDACTED Wed Aug 6 15:47:32 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 6 Aug 2014 15:47:32 +0200 Subject: [erlang-questions] Erlang and fsync In-Reply-To: <38016.1407332451@snookles.snookles.com> References: <38016.1407332451@snookles.snookles.com> Message-ID: On Wed, Aug 6, 2014 at 3:40 PM, Scott Lystig Fritchie wrote: > Lukas Larsson wrote: > > ll> ? As stated in this thread there is no way to do this > ll> cross-platform, so if you need this functionality and it is > ll> available on your OS I would suggest writing a small nif. > > To avoid angering the reduction-based-scheduling-gods-that-**will**- > smite-you-if-you-really-do-this, your NIF is no longer so small because > you'll need to do your own thread pool management + use the NIF to > initiate the sync + message passing when the pool has finished work. > > Or you pass the work to a new-fangled dirty scheduler? > > I knew there was a reason why I tend to write linked-in drivers rather than nifs :) yes you would have to/want to put the call in a dirty scheduler or run your own threading orchestra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prehistorya@REDACTED Wed Aug 6 16:01:35 2014 From: prehistorya@REDACTED (=?UTF-8?Q?=C4=B0brahim_Y=C4=B1lmaz?=) Date: Wed, 6 Aug 2014 07:01:35 -0700 (PDT) Subject: [erlang-questions] =?utf-8?q?Ch=C3=A9ri_Cart_-_Creating_a_Web_App?= =?utf-8?q?_in_Erlang_with_Chicago_Boss_and_Riak_from_Scratch_-_I?= In-Reply-To: References: Message-ID: <5dbea841-5b1b-4953-ae09-24d05e4a34b6@googlegroups.com> Many thanks for sharing bro. On Saturday, July 26, 2014 1:54:15 AM UTC+3, Kunthar wrote: > http://blog.drlinux.org/creating-a-web-app-in-erlang-with-chicago-boss-and-riak-from-scratch-i/ > > just wanted to let you know. -- 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. From lenartlad@REDACTED Wed Aug 6 16:15:13 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Wed, 06 Aug 2014 16:15:13 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? Message-ID: <53E23871.7090609@volny.cz> Hello. A friend of mine asked me: Why is Erlang VM better at handling large volume of running processes than traditional OS like Linux? I have realized that I really don't know. Is it because Erlang process occupies an order of magnitude less space than an OS process? Is it because a userspace scheduler such as Erlang VM is faster at process switching? If so, why is that? Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? Something else? Thank you in advance for enlighten me (us), Ladislav Lenart From lee.sylvester@REDACTED Wed Aug 6 16:20:34 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Wed, 6 Aug 2014 15:20:34 +0100 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E23871.7090609@volny.cz> References: <53E23871.7090609@volny.cz> Message-ID: Hi Ladislav, Erlang processes aren?t the same as OS processes (or even threads). Erlang processes are simply a stack. Because Erlang uses the Actor model, sending data between them using messages, there is no corruption of memory, need for mutexes or locks, and as such, processes can be extremely small, extremely fast and easy to use. I?m no expert myself, but that?s the general gist. Regards, Lee On 6 Aug 2014, at 15:15, Ladislav Lenart wrote: > Hello. > > A friend of mine asked me: > > Why is Erlang VM better at handling large volume of running processes than > traditional OS like Linux? > > I have realized that I really don't know. > > Is it because Erlang process occupies an order of magnitude less space than an > OS process? > Is it because a userspace scheduler such as Erlang VM is faster at process > switching? If so, why is that? > Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? > Something else? > > > Thank you in advance for enlighten me (us), > > Ladislav Lenart > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lenartlad@REDACTED Wed Aug 6 16:27:45 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Wed, 06 Aug 2014 16:27:45 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> Message-ID: <53E23B61.1080803@volny.cz> Hello. On 6.8.2014 16:20, Lee Sylvester wrote: > Hi Ladislav, > > Erlang processes aren?t the same as OS processes (or even threads). > Erlang processes are simply a stack. Because Erlang uses the Actor > model, sending data between them using messages, there is no > corruption of memory, need for mutexes or locks, and as such, > processes can be extremely small, extremely fast and easy to use. Thank you for the explanation, but I already know this. I guess I am looking for a more detailed explanation, if one is available... Thank you, Ladislav Lenart > I?m no expert myself, but that?s the general gist. > > Regards, > Lee > > > On 6 Aug 2014, at 15:15, Ladislav Lenart wrote: > >> Hello. >> >> A friend of mine asked me: >> >> Why is Erlang VM better at handling large volume of running processes than >> traditional OS like Linux? >> >> I have realized that I really don't know. >> >> Is it because Erlang process occupies an order of magnitude less space than an >> OS process? >> Is it because a userspace scheduler such as Erlang VM is faster at process >> switching? If so, why is that? >> Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? >> Something else? >> >> >> Thank you in advance for enlighten me (us), >> >> Ladislav Lenart >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From g@REDACTED Wed Aug 6 16:30:04 2014 From: g@REDACTED (Guilherme Andrade) Date: Wed, 06 Aug 2014 15:30:04 +0100 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E23871.7090609@volny.cz> References: <53E23871.7090609@volny.cz> Message-ID: <53E23BEC.3000107@gandrade.net> Hello Ladislav, On 06/08/14 15:15, Ladislav Lenart wrote: > Is it because Erlang process occupies an order of magnitude less space than an > OS process? > Is it because a userspace scheduler such as Erlang VM is faster at process > switching? If so, why is that? > Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? > Something else? Partially, yes. Some reasons I can think of: - Much smaller process footprint; Erlang processes aren't visible to the OS, their footprint is much lighter (the context they need to keep track of, etc.) OS processes are traditionally heavy, even more-so than OS threads, which are pretty big themselves. - By not being visible to the OS, context & execution switching between different processes by the scheduler doesn't have to deal with userland/kernelspace shenanigans (for the most part, anyway.) - By being shared-nothing, traditional concurrency control mechanisms (which have considerable overhead -- specially on SMP machines) are not needed; - Shooting in the dark here, but the per-process GC might also help on this -- concerning stability and expectable availability variations, anyway. With some oversimplifications, of course; but this is the general idea. -- Guilherme https://www.gandrade.net/ PGP: 0x35CB8191 / 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 Wed Aug 6 16:33:57 2014 From: g@REDACTED (Guilherme Andrade) Date: Wed, 06 Aug 2014 15:33:57 +0100 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E23BEC.3000107@gandrade.net> References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> Message-ID: <53E23CD5.1030408@gandrade.net> If you'd like more detail, I propose you read upon the low-level bells and whistles the process scheduler consists of, and it should become more intuitive by then. No need to look at source-code; a quick web search returns some straightforward stuff[1][2] that seems to be what you're looking for. Cheers, [1]: http://www.erlang.org/euc/08/euc_smp.pdf [2]: http://erlang.org/pipermail/erlang-questions/2001-April/003132.html On 06/08/14 15:30, Guilherme Andrade wrote: > Hello Ladislav, > > On 06/08/14 15:15, Ladislav Lenart wrote: >> Is it because Erlang process occupies an order of magnitude less space than an >> OS process? >> Is it because a userspace scheduler such as Erlang VM is faster at process >> switching? If so, why is that? >> Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? >> Something else? > Partially, yes. Some reasons I can think of: > > - Much smaller process footprint; Erlang processes aren't visible to > the OS, their footprint is much lighter (the context they need to keep > track of, etc.) OS processes are traditionally heavy, even more-so than > OS threads, which are pretty big themselves. > > - By not being visible to the OS, context & execution switching > between different processes by the scheduler doesn't have to deal with > userland/kernelspace shenanigans (for the most part, anyway.) > > - By being shared-nothing, traditional concurrency control > mechanisms (which have considerable overhead -- specially on SMP > machines) are not needed; > > - Shooting in the dark here, but the per-process GC might also help > on this -- concerning stability and expectable availability variations, > anyway. > > > With some oversimplifications, of course; but this is the general idea. > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme https://www.gandrade.net/ PGP: 0x35CB8191 / 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peerst@REDACTED Wed Aug 6 16:55:26 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Wed, 6 Aug 2014 16:55:26 +0200 Subject: [erlang-questions] Poll: How do you handle spurious messages? Message-ID: I'm interested in how you deal with spurious messages to your servers i.e. receive ... your important messages here ... Any -> ??? % we don't want crud to acrete in the mailbox end Or in gen_server speak: what goes into your catchall handle_info(_Info, State) -> ??? Do you: 1. log the messages 1a.) as info 1b.) as warning 1c.) as error 2. count them e.g. with folsom or similar -> then what do you do with the counts? 3. Ignore them without trace? 4. Crash the server (gasp)? Did I forget something? Cheers, -- Peer From g@REDACTED Wed Aug 6 17:07:15 2014 From: g@REDACTED (Guilherme Andrade) Date: Wed, 06 Aug 2014 16:07:15 +0100 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: Message-ID: <53E244A3.3040500@gandrade.net> Hello Peer, It's pretty much a strictness question, as well as depending on the nature of the process; with ephemeral, short-lived processes in an environment that has many of such, unexpected messages are more likely to arrive simply because there's more PID recycling going around. For the most part is harmless; depending on how much do you expect a process to receive those messages, you might choose different logging levels according to the rareness of the event. They might be good for diagnostic purposes -- not as much as diagnosing issues on the *receiver* but mainly issues on the *sender* - "why is it sending messages to the wrong process, and why? And what could be the consequences?" Cheers, On 06/08/14 15:55, Peer Stritzinger wrote: > I'm interested in how you deal with spurious messages to your servers > i.e. > > > receive > ... your important messages here ... > Any -> ??? % we don't want crud to acrete in the > mailbox > end > > Or in gen_server speak: what goes into your catchall > > handle_info(_Info, State) -> ??? > > > Do you: > > 1. log the messages > > 1a.) as info > 1b.) as warning > 1c.) as error > > 2. count them e.g. with folsom or similar -> then what do you do with > the counts? > > 3. Ignore them without trace? > > 4. Crash the server (gasp)? > > Did I forget something? > > Cheers, > -- Peer > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme https://www.gandrade.net/ PGP: 0x35CB8191 / 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 peerst@REDACTED Wed Aug 6 17:08:51 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Wed, 6 Aug 2014 17:08:51 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <53E23CD5.1030408@gandrade.net> Message-ID: Also recommend reading: http://jlouisramblings.blogspot.de/2013/01/how-erlang-does-scheduling.html -- Peer On 2014-08-06 14:33:57 +0000, Guilherme Andrade said: > If you'd like more detail, I propose you read upon the low-level bells > and whistles the process scheduler consists of, and it should become > more intuitive by then. No need to look at source-code; a quick web > search returns some straightforward stuff[1][2] that seems to be what > you're looking for. > > Cheers, > > > > [1]: http://www.erlang.org/euc/08/euc_smp.pdf > [2]: http://erlang.org/pipermail/erlang-questions/2001-April/003132.html > > > On 06/08/14 15:30, Guilherme Andrade wrote: > Hello Ladislav, > > On 06/08/14 15:15, Ladislav Lenart wrote: > Is it because Erlang process occupies an order of magnitude less space than an > OS process? > Is it because a userspace scheduler such as Erlang VM is faster at process > switching? If so, why is that? > Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? > Something else? > Partially, yes. Some reasons I can think of: > > - Much smaller process footprint; Erlang processes aren't visible to > the OS, their footprint is much lighter (the context they need to keep > track of, etc.) OS processes are traditionally heavy, even more-so than > OS threads, which are pretty big themselves. > > - By not being visible to the OS, context & execution switching > between different processes by the scheduler doesn't have to deal with > userland/kernelspace shenanigans (for the most part, anyway.) > > - By being shared-nothing, traditional concurrency control > mechanisms (which have considerable overhead -- specially on SMP > machines) are not needed; > > - Shooting in the dark here, but the per-process GC might also help > on this -- concerning stability and expectable availability variations, > anyway. > > > With some oversimplifications, of course; but this is the general idea. > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- > Guilherme > > https://www.gandrade.net/ > PGP: 0x35CB8191 / 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Wed Aug 6 17:38:44 2014 From: freza@REDACTED (Jachym Holecek) Date: Wed, 6 Aug 2014 11:38:44 -0400 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: Message-ID: <20140806153844.GA6333@circlewave.net> # Peer Stritzinger 2014-08-06: > I'm interested in how you deal with spurious messages to your servers i.e. FWIW this (processes sending messages to the wrong place) was never a problem in real life as far as my memory serves. One would handle unexpected messages as a general safety precaution, and one would imagine such code could come in handy during code upgrades (where after all various internal protocols could be inconsistent over limited period of time), but that's that. > receive > ... your important messages here ... > Any -> ??? % we don't want crud to acrete in the mailbox > end > > Or in gen_server speak: what goes into your catchall > > handle_info(_Info, State) -> ??? Stylistic detail: in both cases I'd go with "_", not "Any" or "_Info". Because why bother putting a name on irrelevant piece of information, and why waste reader's time with it? > Do you: > > 1. log the messages > > 1a.) as info > 1b.) as warning > 1c.) as error > > 2. count them e.g. with folsom or similar -> then what do you do > with the counts? > > 3. Ignore them without trace? > > 4. Crash the server (gasp)? > > Did I forget something? Ignore them without a trace. You can always use native tracing facilities, or temporarily put in a patch that does 1/2, to aid in particular bughunting situations. In more specific cases 1/2/4 is adequate, but usually that wouldn't be a wildcard "_" match -- ie. if a MAP state machine received unexpected TCAP event I sure want a detailed audit log about it (probably followed by dialogue teardown and process exit cause I just don't know what else to do), but I still don't care if somebody decides to send me absolute generic rubbish (it's most likely them being broken, not me, so why should I deal with it?) YMMV. BR, -- Jachym From g@REDACTED Wed Aug 6 17:30:39 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 6 Aug 2014 10:30:39 -0500 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: Message-ID: On Wed, Aug 6, 2014 at 9:55 AM, Peer Stritzinger wrote: > I'm interested in how you deal with spurious messages to your servers i.e. > > > receive > ... your important messages here ... > Any -> ??? % we don't want crud to acrete in the > mailbox > end > > Or in gen_server speak: what goes into your catchall > > handle_info(_Info, State) -> ??? I don't usually have catchalls, which I can get away with because I'm using e2 (just requires a single handle_msg/3 function). > Do you: > > 1. log the messages > > 1a.) as info > 1b.) as warning > 1c.) as error > > 2. count them e.g. with folsom or similar -> then what do you do with the > counts? > > 3. Ignore them without trace? > > 4. Crash the server (gasp)? I think, if you don't have a specific rationale for picking one, pick the least defensive by default - so crash. From essen@REDACTED Wed Aug 6 18:07:03 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 06 Aug 2014 18:07:03 +0200 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: Message-ID: <53E252A7.3040402@ninenines.eu> On 08/06/2014 04:55 PM, Peer Stritzinger wrote: > 1. log the messages For the few processes that can receive more than calls/casts/monitors/exits I want to know what's being dropped in case it's something important. > 3. Ignore them without trace? For everything else, which is the majority of the processes. *Never* crash. Because if you do, then you can easily mess up your system through the shell (like using sys:get_state on a normal process, kaboom). -- Lo?c Hoguin http://ninenines.eu From flw@REDACTED Wed Aug 6 18:48:32 2014 From: flw@REDACTED (Florian Waas) Date: Wed, 6 Aug 2014 09:48:32 -0700 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: <53E252A7.3040402@ninenines.eu> References: <53E252A7.3040402@ninenines.eu> Message-ID: Matter of taste. If you like designs where unidentified messages circulate in your system and endless debugging sessions for race conditions, missed messaged, deadlocks etc. is your thing, ignoring messages is cool. If you're not good at this type of debugging or simple don't have the time for it consider tightening your design and eliminate any kind of slack from the system, then crash for anything that breaks the contract. -fl. On Wed, Aug 6, 2014 at 9:07 AM, Lo?c Hoguin wrote: > On 08/06/2014 04:55 PM, Peer Stritzinger wrote: > >> 1. log the messages >> > > For the few processes that can receive more than > calls/casts/monitors/exits I want to know what's being dropped in case it's > something important. > > > 3. Ignore them without trace? >> > > For everything else, which is the majority of the processes. > > *Never* crash. Because if you do, then you can easily mess up your system > through the shell (like using sys:get_state on a normal process, kaboom). > > -- > 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 Wed Aug 6 19:43:31 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 06 Aug 2014 19:43:31 +0200 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: <53E252A7.3040402@ninenines.eu> Message-ID: <53E26943.3000400@ninenines.eu> I do not think "making it easy for anyone with access to mess up your system when inspecting" is a matter of taste? If I have to fear breaking everything every time I'm trying to look for data to fix a bug, I'll just pack my things and leave, I don't want that kind of stress. You're also making your system less stable if you run misbehaving third party code. And by third party, I include OTP's code. For example a while back the ssl application sent a harmless message to the accepting process under certain conditions, do you really want to crash in cases like this? "Let it crash" is great, but it's not the solution to everything. On 08/06/2014 06:48 PM, Florian Waas wrote: > Matter of taste. If you like designs where unidentified messages > circulate in your system and endless debugging sessions for race > conditions, missed messaged, deadlocks etc. is your thing, ignoring > messages is cool. > > If you're not good at this type of debugging or simple don't have the > time for it consider tightening your design and eliminate any kind of > slack from the system, then crash for anything that breaks the contract. > > -fl. > > > > On Wed, Aug 6, 2014 at 9:07 AM, Lo?c Hoguin > wrote: > > On 08/06/2014 04:55 PM, Peer Stritzinger wrote: > > 1. log the messages > > > For the few processes that can receive more than > calls/casts/monitors/exits I want to know what's being dropped in > case it's something important. > > > 3. Ignore them without trace? > > > For everything else, which is the majority of the processes. > > *Never* crash. Because if you do, then you can easily mess up your > system through the shell (like using sys:get_state on a normal > process, kaboom). > > -- > 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 mononcqc@REDACTED Wed Aug 6 21:39:30 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 6 Aug 2014 15:39:30 -0400 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: References: Message-ID: <20140806193930.GD72385@ferdmbp.local> I tend to go the log route. There isn't a super good reason, but the way I think about it is a bit of probability. When do I send messages to the wrong process? A few ideas are: - Manual debugging - Typoes - A Refactoring gone bad - Initial design got messed up - Erroneous third-party code that doesn't come from my precise development right away. Then the question is what are the consequences I want. - Manual debugging: do nothing, I'm poking around - Typoes: I have to know about these ASAP - Refactoring gone bad: I have to know about these ASAP - Initial design got messed up: Something has to be loud and bad - Third party code: I want the third party to suffer. For these reasons, I tend to take the following approach: - In handle_call/3, I log the event with a string a bit like "mod=MYMOD at=handle_call warning=unexpected_call msg=~p" and then return `{noreply, State}` to force the caller to crash after a timeout. It's their fault, not mine. - In other callbacks, just log similar messages, replacing at=handle_call with at=handle_cast|info and warning=unexpected_cast|info. I can, from time to time, look at logs for 'warning=unexpected_*' in logs and see if something is going weird. If it's something happening rarely, I'm gonna have traces, but without the weird failures (unless it's a call). If it's something frequent, bugs will either show themselves differently, the log volume will be very high, and so on. It tends to give me what I need given the circumstances. It's not always as loud as I'd expect (except for calls, which is ideal), but it tends to give me enough visibility for the occasional stray message, without compromising service levels. Regards, Fred. On 08/06, Peer Stritzinger wrote: > Or in gen_server speak: what goes into your catchall > > handle_info(_Info, State) -> ??? > > > Do you: > > 1. log the messages > 2. count them e.g. with folsom or similar -> then what do you do with the > counts? > 3. Ignore them without trace? > 4. Crash the server (gasp)? From jesper.louis.andersen@REDACTED Wed Aug 6 23:35:03 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 6 Aug 2014 23:35:03 +0200 Subject: [erlang-questions] How to split a single huge server? In-Reply-To: References: Message-ID: On Tue, Aug 5, 2014 at 4:12 PM, semmit mondo wrote: > So basically what you suggest is that I need an external piece of software > written in a low level language that uses low level SIMD instructions on > the bare CPU or maybe uses GPU. It depends. How much RAM are you going to accept using and how fast are you going to want your computation? If you have a small kernel which has to run fast at any cost, it is often better to move to a lower level language. Note that this affects development time and development cost. So you have to decide if it is worth it. Usually, it's not if you are just toying around. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Aug 7 01:59:40 2014 From: ok@REDACTED (ok@REDACTED) Date: Thu, 7 Aug 2014 11:59:40 +1200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E23BEC.3000107@gandrade.net> References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> Message-ID: <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> Let me make an obvious point: the Erlang VM is *NOT* better than operating systems like Linux. The Erlang VM is better at managing hundreds of thousands of lightweight processes. Linux (and Solaris and HP-UX and ...) are constrained by having to present a C/POSIX ABI. And C is an amazingly low-level language (operational definition: you cannot shift the stack because you have no way of telling what is in it). The two systems are simply solving different problems under different constraints. There's no reason why Linux (or Solaris or HP-UX or ...) could not offer an additional interface, call it an Elinuxir interface, that was basically Erlang-like and support that about as well as the Erlang VM does. Come to think of it, Linux and Solaris *do* offer an Elinuxir interface: it's called running the Erlang VM. So the question is ill-posed. What exactly is it that both Linux and the Erlang VM do and the Erlang VM is better at? From flw@REDACTED Thu Aug 7 05:09:44 2014 From: flw@REDACTED (Florian Waas) Date: Wed, 6 Aug 2014 20:09:44 -0700 Subject: [erlang-questions] Poll: How do you handle spurious messages? In-Reply-To: <53E26943.3000400@ninenines.eu> References: <53E252A7.3040402@ninenines.eu> <53E26943.3000400@ninenines.eu> Message-ID: Actually, I think we're very much on the same page here: I really meant it when I said "crash for anything that breaks the contract" -- if your environment requires to take into account stray messages, then by all means take care of them. In closed enterprise software systems, your contract often is much(!) tighter and cracking down on stray messages is usually highly desirable. If SSL spams my inbox I certainly want to know where it comes from, whether it has potential to clog up a process, needs attention, etc. and if I figure it's safe to discard this kind of message, then make a deliberate decision to do so. However, discarding all unexpected message because of this might be less than ideal. -fl. On Wed, Aug 6, 2014 at 10:43 AM, Lo?c Hoguin wrote: > I do not think "making it easy for anyone with access to mess up your > system when inspecting" is a matter of taste? If I have to fear breaking > everything every time I'm trying to look for data to fix a bug, I'll just > pack my things and leave, I don't want that kind of stress. > > You're also making your system less stable if you run misbehaving third > party code. And by third party, I include OTP's code. For example a while > back the ssl application sent a harmless message to the accepting process > under certain conditions, do you really want to crash in cases like this? > > "Let it crash" is great, but it's not the solution to everything. > > > On 08/06/2014 06:48 PM, Florian Waas wrote: > >> Matter of taste. If you like designs where unidentified messages >> circulate in your system and endless debugging sessions for race >> conditions, missed messaged, deadlocks etc. is your thing, ignoring >> messages is cool. >> >> If you're not good at this type of debugging or simple don't have the >> time for it consider tightening your design and eliminate any kind of >> slack from the system, then crash for anything that breaks the contract. >> >> -fl. >> >> >> >> On Wed, Aug 6, 2014 at 9:07 AM, Lo?c Hoguin > > wrote: >> >> On 08/06/2014 04:55 PM, Peer Stritzinger wrote: >> >> 1. log the messages >> >> >> For the few processes that can receive more than >> calls/casts/monitors/exits I want to know what's being dropped in >> case it's something important. >> >> >> 3. Ignore them without trace? >> >> >> For everything else, which is the majority of the processes. >> >> *Never* crash. Because if you do, then you can easily mess up your >> system through the shell (like using sys:get_state on a normal >> process, kaboom). >> >> -- >> 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 raimo+erlang-questions@REDACTED Thu Aug 7 09:38:36 2014 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 7 Aug 2014 09:38:36 +0200 Subject: [erlang-questions] List vs Group Message-ID: <20140807073836.GA3282@erix.ericsson.se> Hi all. We are thinking about not allowing members of the Google group Erlang Programming to post to the group. This is why: Once the group was set up as a mirror of the mailing list erlang-questions. Then people could read the list in Google groups's forum like web interface, they could also join the group, and when posting, if they posted to the mailing list too and were members of the mailing list it all worked fine. Unfortunately discipline is hard, so some forgot to post to the list, forgot to subscribe to the list and so on. Then it was awkward having to post both to the list and the group. So I recently fixed a bridge from the group to the list. But now when someone posts to the group only and it shows up on the list, when you reply to such a post the list is not replied to but instead the group. So now you have to check that the list is replied to and manually add it if not when you reply to a post. This situation is perhaps even further from the ideal. So the clean back-to-basics solution is to not allow members of the group to post to the group, since they have to be members of the list anyway and just until now had to Cc the list when posting to the group. Why not make posting to the list the only possible way? How much would this disturb group users? Since I do not use the group myself I would not know... Best regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From essen@REDACTED Thu Aug 7 09:51:10 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 07 Aug 2014 09:51:10 +0200 Subject: [erlang-questions] List vs Group In-Reply-To: <20140807073836.GA3282@erix.ericsson.se> References: <20140807073836.GA3282@erix.ericsson.se> Message-ID: <53E32FEE.2090908@ninenines.eu> On 08/07/2014 09:38 AM, Raimo Niskanen wrote: > Hi all. > > We are thinking about not allowing members of the Google group > Erlang Programming to post to the group. I do not use Google groups but got annoyed by it a number of times. At some point it sent me back an email when it was in cc because I was not a member there. Since then I've been removing it from cc manually. And then there's the issue you describe. Finally, I don't really want my emails to end up on Google products with the exception of Search. So I welcome this idea. -- Lo?c Hoguin http://ninenines.eu From lenartlad@REDACTED Thu Aug 7 11:05:46 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Thu, 07 Aug 2014 11:05:46 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <53E23CD5.1030408@gandrade.net> Message-ID: <53E3416A.5050505@volny.cz> Hello. I would like to thank you for the links to various documents and blogs you posted. Very interesting stuff. Ladislav Lenart On 6.8.2014 17:08, Peer Stritzinger wrote: > Also recommend reading: > > > http://jlouisramblings.blogspot.de/2013/01/how-erlang-does-scheduling.html > > > -- Peer > > > On 2014-08-06 14:33:57 +0000, Guilherme Andrade said: > > > If you'd like more detail, I propose you read upon the low-level bells and > whistles the process scheduler consists of, and it should become more intuitive > by then. No need to look at source-code; a quick web search returns some > straightforward stuff[1][2] that seems to be what you're looking for. > > > Cheers, > > > > > [1]: http://www.erlang.org/euc/08/euc_smp.pdf > > [2]: http://erlang.org/pipermail/erlang-questions/2001-April/003132.html > > > > On 06/08/14 15:30, Guilherme Andrade wrote: > > Hello Ladislav, > > > On 06/08/14 15:15, Ladislav Lenart wrote: > > Is it because Erlang process occupies an order of magnitude less space than an > > OS process? > > Is it because a userspace scheduler such as Erlang VM is faster at process > > switching? If so, why is that? > > Is it somehow related to Erlang's share nothing philosophy? If so, how exactly? > > Something else? > > Partially, yes. Some reasons I can think of: > > > - Much smaller process footprint; Erlang processes aren't visible to > > the OS, their footprint is much lighter (the context they need to keep > > track of, etc.) OS processes are traditionally heavy, even more-so than > > OS threads, which are pretty big themselves. > > > - By not being visible to the OS, context & execution switching > > between different processes by the scheduler doesn't have to deal with > > userland/kernelspace shenanigans (for the most part, anyway.) > > > - By being shared-nothing, traditional concurrency control > > mechanisms (which have considerable overhead -- specially on SMP > > machines) are not needed; > > > - Shooting in the dark here, but the per-process GC might also help > > on this -- concerning stability and expectable availability variations, > > anyway. > > > > With some oversimplifications, of course; but this is the general idea. > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > Guilherme > > > https://www.gandrade.net/ > > PGP: 0x35CB8191 / 1968 5252 3901 B40F ED8A D67A 9330 79B1 35CB 8191 > > From lenartlad@REDACTED Thu Aug 7 11:11:58 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Thu, 07 Aug 2014 11:11:58 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> Message-ID: <53E342DE.6090302@volny.cz> Hello. On 7.8.2014 01:59, ok@REDACTED wrote: > Let me make an obvious point: > the Erlang VM is *NOT* better than operating systems > like Linux. Fair enough (bad e-mail subject on my part). > The Erlang VM is better at managing hundreds of thousands > of lightweight processes. Exactly. And I wanted to know the 'whys' of this. I guess the lightweight nature of Erlang processes is the main cause of this. > Linux (and Solaris and HP-UX and ...) are constrained by > having to present a C/POSIX ABI. And C is an amazingly > low-level language (operational definition: you cannot > shift the stack because you have no way of telling what > is in it). > > The two systems are simply solving different problems > under different constraints. > > There's no reason why Linux (or Solaris or HP-UX or ...) > could not offer an additional interface, call it an Elinuxir > interface, that was basically Erlang-like and support that > about as well as the Erlang VM does. > > Come to think of it, Linux and Solaris *do* offer an > Elinuxir interface: it's called running the Erlang VM. > > So the question is ill-posed. What exactly is it that > both Linux and the Erlang VM do and the Erlang VM is better > at? Both Linux and Erlang manage processes and Erlang is (much?) better at it. Again, I just wanted to know why... Thanks, Ladislav Lenart From lee.sylvester@REDACTED Thu Aug 7 11:15:39 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Thu, 7 Aug 2014 10:15:39 +0100 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E342DE.6090302@volny.cz> References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: On 7 Aug 2014, at 10:11, Ladislav Lenart wrote: > > Both Linux and Erlang manage processes and Erlang is (much?) better at it. > Again, I just wanted to know why... > No. The point to understand here is that an OS process and an Erlang process is not the same. An OS process is a chunk of memory reserved by the OS for running an application. It has overhead, as it provides communication and switching for playing nice with other OS apps. It is a beast in terms of resources. An Erlang process is simply a stack in the Erlang VM. It is lightweight because the Erlang VM does the heavy lifting, while the Erlang process does very little (outside of your own code). They are both called processes, and they both act like processes, but that?s where the similarity ends. They are otherwise completely different beasts. For example, the Erlang VM, which has its own processes, will sit in an OS process. Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Thu Aug 7 13:11:44 2014 From: roger@REDACTED (Roger Lipscombe) Date: Thu, 7 Aug 2014 12:11:44 +0100 Subject: [erlang-questions] What are the units for erlang:statistics(wall_clock)? Message-ID: I'm looking to find the uptime of an Erlang node, and I found erlang:statistics(wall_clock), but the documentation doesn't specify the units. I assume milliseconds, but the documentation (http://www.erlang.org/doc/man/erlang.html#statistics-1) doesn't specify it, and suggests for other statistics that the units are subject to change. (Further the documentation at erldocs.com for erlang:statistics is kind of messed up (for the R16B03-1 version, anyway...) From mfidelman@REDACTED Thu Aug 7 13:12:22 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 07 Aug 2014 07:12:22 -0400 Subject: [erlang-questions] List vs Group In-Reply-To: <20140807073836.GA3282@erix.ericsson.se> References: <20140807073836.GA3282@erix.ericsson.se> Message-ID: <53E35F16.1060803@meetinghouse.net> Raimo Niskanen wrote: > Hi all. > > We are thinking about not allowing members of the Google group > Erlang Programming to post to the group. > > This is why: > > Once the group was set up as a mirror of the mailing list erlang-questions. > > Then people could read the list in Google groups's forum like web > interface, they could also join the group, and when posting, if they > posted to the mailing list too and were members of the mailing list > it all worked fine. When I first read the subject line, I was expecting the standard "let's make this a web forum" post that shows up on every list, everywhere, about once a year. Glad to see that's not what this is about (I've yet to see that conversion end well). > How much would this disturb group users? Since I do not use the group > myself I would not know... > Wouldn't disturb me a bit - I subscribe to the list directly (except for the loss of information that might accrue if we end up with a fractured community). Just a thought: If there are significant numbers of list members who prefer a web interface, there are list managers that provide a web interface that's married at the hip to the list functions - which avoids the problems described here. Both google groups and yahoo groups do that - but I've personally found Sympa (www.sympa.org) to be a pretty powerful, open-source list manager that also has web functionality. There's also groupserver (groupserver.org). Then again, I've never quite understand why anybody prefers to read list traffic via a web interface - it's just so cumbersome compared to any reasonable email client. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From garazdawi@REDACTED Thu Aug 7 14:40:12 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Thu, 7 Aug 2014 14:40:12 +0200 Subject: [erlang-questions] What are the units for erlang:statistics(wall_clock)? In-Reply-To: References: Message-ID: Hello, It is indeed milliseconds. There is already a clarification of this merged into git so in the next release it will be possible to figure this out from the documentation :) Lukas On Thu, Aug 7, 2014 at 1:11 PM, Roger Lipscombe wrote: > I'm looking to find the uptime of an Erlang node, and I found > erlang:statistics(wall_clock), but the documentation doesn't specify > the units. > > I assume milliseconds, but the documentation > (http://www.erlang.org/doc/man/erlang.html#statistics-1) doesn't > specify it, and suggests for other statistics that the units are > subject to change. > > (Further the documentation at erldocs.com for erlang:statistics is > kind of messed up (for the R16B03-1 version, anyway...) > _______________________________________________ > 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 Thu Aug 7 19:30:19 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 7 Aug 2014 10:30:19 -0700 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: > For example, the Erlang VM, which has its own processes, will sit in an OS > process. http://www.xenproject.org/directory/directory/projects/90-erland-on-xen.html :-) From a.shneyderman@REDACTED Thu Aug 7 20:57:07 2014 From: a.shneyderman@REDACTED (Alex Shneyderman) Date: Thu, 7 Aug 2014 14:57:07 -0400 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E23B61.1080803@volny.cz> References: <53E23871.7090609@volny.cz> <53E23B61.1080803@volny.cz> Message-ID: the beginning of the talk is filled with answers to your question http://www.confreaks.com/videos/4127-elixirconf2014-erlang-rationale On Wed, Aug 6, 2014 at 10:27 AM, Ladislav Lenart wrote: > Hello. > > > On 6.8.2014 16:20, Lee Sylvester wrote: > > Hi Ladislav, > > > > Erlang processes aren?t the same as OS processes (or even threads). > > Erlang processes are simply a stack. Because Erlang uses the Actor > > model, sending data between them using messages, there is no > > corruption of memory, need for mutexes or locks, and as such, > > processes can be extremely small, extremely fast and easy to use. > > Thank you for the explanation, but I already know this. I guess I am > looking for > a more detailed explanation, if one is available... > > > Thank you, > > Ladislav Lenart > > > > I?m no expert myself, but that?s the general gist. > > > > Regards, > > Lee > > > > > > On 6 Aug 2014, at 15:15, Ladislav Lenart wrote: > > > >> Hello. > >> > >> A friend of mine asked me: > >> > >> Why is Erlang VM better at handling large volume of running processes > than > >> traditional OS like Linux? > >> > >> I have realized that I really don't know. > >> > >> Is it because Erlang process occupies an order of magnitude less space > than an > >> OS process? > >> Is it because a userspace scheduler such as Erlang VM is faster at > process > >> switching? If so, why is that? > >> Is it somehow related to Erlang's share nothing philosophy? If so, how > exactly? > >> Something else? > >> > >> > >> Thank you in advance for enlighten me (us), > >> > >> Ladislav Lenart > >> > >> _______________________________________________ > >> 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 paulo.ferraz.oliveira@REDACTED Fri Aug 8 00:09:53 2014 From: paulo.ferraz.oliveira@REDACTED (Paulo F. Oliveira) Date: Thu, 7 Aug 2014 23:09:53 +0100 Subject: [erlang-questions] List vs Group In-Reply-To: <53E35F16.1060803@meetinghouse.net> References: <20140807073836.GA3282@erix.ericsson.se> <53E35F16.1060803@meetinghouse.net> Message-ID: Wouldn't disturb me. I don't use the Google group, so... actually I thought it was a read-only mirror of this mailing list :D, but apparently not. - Paulo F. Oliveira On 7 August 2014 12:12, Miles Fidelman wrote: > Raimo Niskanen wrote: > >> Hi all. >> >> We are thinking about not allowing members of the Google group >> Erlang Programming to post to the group. >> >> This is why: >> >> Once the group was set up as a mirror of the mailing list >> erlang-questions. >> >> Then people could read the list in Google groups's forum like web >> interface, they could also join the group, and when posting, if they >> posted to the mailing list too and were members of the mailing list >> it all worked fine. >> > > When I first read the subject line, I was expecting the standard "let's > make this a web forum" post that shows up on every list, everywhere, about > once a year. Glad to see that's not what this is about (I've yet to see > that conversion end well). > > How much would this disturb group users? Since I do not use the group >> myself I would not know... >> >> > Wouldn't disturb me a bit - I subscribe to the list directly (except for > the loss of information that might accrue if we end up with a fractured > community). > > Just a thought: If there are significant numbers of list members who > prefer a web interface, there are list managers that provide a web > interface that's married at the hip to the list functions - which avoids > the problems described here. Both google groups and yahoo groups do that - > but I've personally found Sympa (www.sympa.org) to be a pretty powerful, > open-source list manager that also has web functionality. There's also > groupserver (groupserver.org). Then again, I've never quite understand > why anybody prefers to read list traffic via a web interface - it's just so > cumbersome compared to any reasonable email client. > > 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 lcastro@REDACTED Fri Aug 8 00:29:07 2014 From: lcastro@REDACTED (Laura M. Castro) Date: Fri, 8 Aug 2014 00:29:07 +0200 Subject: [erlang-questions] Erlang Workshop: Call for participation Message-ID: ==================================================================== CALL FOR PARTICIPATION ACM SIGPLAN Erlang Workshop 2014 Gothenburg, Sweden 5 September, 2014 http://www.erlang.org/workshop/2014/ ==================================================================== The purpose of the Erlang Workshop is to bring together the open source, academic, and industrial programming communities of Erlang. It provides a forum that enables participants to get the latest updates on recent developments, new techniques and tools tailored to Erlang, novel applications, lessons from users' experiences and current research problems relevant to the practice of Erlang and functional programming. These are the accepted papers and programme for this year (they should appear in the website shortly): 09:00 ? 09:10 Opening & Welcome 09:10 ? 10:00 Invited Keynote: "Functional Programming and the 'Megacore' Era" by Kevin Hammond 10:00 ? 10:30 Coffee Break 10:30 ? 11:20 CONCURRENCY and PARALELISM SESSION "More Scalable Ordered Set for ETS Using Adaptation" by Konstantinos Sagonas and Kjell Winblad "Discovering Parallel Pattern Candidates in Erlang" by Melinda T?th, Istv?n Boz?, Vikt?ria F?rd?s, Zolt?n Horv?th, D?niel Horp?csi, Judit K?szegi, Tam?s Kozsik, Chris Brown, Adam Barwell, Kevin Hammond 11:20 ? 11:40 Break 11:40 ? 12:30 TESTING SESSION "On Shrinking Randomly Generated Load Tests" by Thomas Arts "Jsongen: a QuickCheck Based Library for Testing JSON Web Services" by Clara Benac Earle, Lars-Ake Fredlund, Angel Herranz and Julio Mari?o 12:30 ? 14:00 Lunch 14:00 ? 14:50 DISTRIBUTION SESSION "Investigating the Scalability Limits of Distributed Erlang" by Amir Ghaffari "Derflow: Distributed deterministic dataflow programming for Erlang" by Manuel Bravo, Zhongmiao Li, Peter Van Roy and Christopher Meiklejohn 14:50 ? 15:10 Break 15:10 ? 16:00 RUNTIME SESSION "BEAMJIT -- A Just-in-Time Compiling Runtime for Erlang" by Frej Drejhammar and Lars Rasmusson LIGHTNING TALKS "Synapse: automatic behaviour inference and implementation comparison" by Pablo Lamela Seijas, Ramsay Taylor, Kirill Bogdanov, Simon Thompson and John Derrick "Faulterl: precise fault injection for Erlang NIFs and linked-in drivers" by Scott Fritchie 16:00 ? 16:30 Tea break 16:30 ? 17:00 ERLANG LATEST NEWS by Kenneth Lundin Farewell & Closing REGISTRATION IS OPEN: https://regmaster4.com/2014conf/ICFP14/register.php Local arrangements (including travel and accommodation): http://www.icfpconference.org/icfp2014/local.html We hope to see you in Gothenburg! -- Laura M. Castro and Hans Svensson Erlang Workshop 2014 Chairs From ok@REDACTED Fri Aug 8 01:58:05 2014 From: ok@REDACTED (ok@REDACTED) Date: Fri, 8 Aug 2014 11:58:05 +1200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: <53E342DE.6090302@volny.cz> References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: >>> Linux (and Solaris and HP-UX and ...) are constrained by >> having to present a C/POSIX ABI. And C is an amazingly >> low-level language (operational definition: you cannot >> shift the stack because you have no way of telling what >> is in it). >> >> The two systems are simply solving different problems >> under different constraints. > Both Linux and Erlang manage processes and Erlang is (much?) better at it. > Again, I just wanted to know why... Re-read what I said about C/POSIX ABI and "solving different problems". Linux and Erlang do *NOT* both manage processes, and Erlang is *NOT* better at what Linux does than Linux is. They both manage things *called* processes, and at a sufficiently abstract level the things are entitled to the name, but that's seriously misleading. Let me put it this way, marmosets and gorillas are both primates in good standing, but a marmoset weights about a quarter of a kilo and fits comfortably in your hand. I think you'll agree that it's going to be a LOT easier to house and feed 100 marmosets than 100 gorillas. Let's start with the very low level. A modern x86_64 has 16 64-bit general registers 16 256-bit vector registers 8 80-bit floating-point registers 1 32-bit flags register 1 64-bit program counter other assorted things like performance counters. Switching between *threads* in the same UNIX process could therefore involve storing 732 bytes of registers from the old thread and load 732 byte of registers from the new thread. Something like the Erlang VM can arrange to switch only at points where all of the floating point registers and the flags are known to be dead, so a context switch between Erlang processes only needs to save and restore about 18% of the information that a Linux *thread* switch does. (Oh wait, I forgot that threads in Linux use the FS segment register for thread-locals. The 732 byte figure is *definitely* low.) Here I've compared Erlang processes to Linux threads. Linux *processes* have even more hardware state to switch. Performance counters will definitely be there, as will memory management registers. Some machines have watchpoint registers for debugging. You'd be *amazed* at what has to be switched. As for process creation, think about the fact that every Linux process has its own page tables and no Erlang process does. Relying on software to prevent one process scribbling on the memory of another has good consequences. From steven.charles.davis@REDACTED Fri Aug 8 02:10:49 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 7 Aug 2014 17:10:49 -0700 (PDT) Subject: [erlang-questions] List vs Group In-Reply-To: <20140807073836.GA3282@erix.ericsson.se> References: <20140807073836.GA3282@erix.ericsson.se> Message-ID: Yea, after all, who uses the web nowadays? From steven.charles.davis@REDACTED Fri Aug 8 02:10:49 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 7 Aug 2014 17:10:49 -0700 (PDT) Subject: [erlang-questions] List vs Group In-Reply-To: <20140807073836.GA3282@erix.ericsson.se> References: <20140807073836.GA3282@erix.ericsson.se> Message-ID: Yea, after all, who uses the web nowadays? -- 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. From lenartlad@REDACTED Fri Aug 8 11:21:04 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Fri, 08 Aug 2014 11:21:04 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: <53E49680.9050704@volny.cz> Hello. Thank you. This, with other responses to this thread, answers my (perhaps ill-phrased) question. I knew that OS processes and Erlang processes are different beasts, but I did not realize that it is such a deal breaker. Again, thank you all for your valuable answers, Ladislav Lenart On 8.8.2014 01:58, ok@REDACTED wrote: >>>> Linux (and Solaris and HP-UX and ...) are constrained by >>> having to present a C/POSIX ABI. And C is an amazingly >>> low-level language (operational definition: you cannot >>> shift the stack because you have no way of telling what >>> is in it). >>> >>> The two systems are simply solving different problems >>> under different constraints. > > >> Both Linux and Erlang manage processes and Erlang is (much?) better at it. >> Again, I just wanted to know why... > > Re-read what I said about C/POSIX ABI and "solving different problems". > > Linux and Erlang do *NOT* both manage processes, > and Erlang is *NOT* better at what Linux does than Linux is. > They both manage things *called* processes, and at a > sufficiently abstract level the things are entitled to the > name, but that's seriously misleading. > Let me put it this way, marmosets and gorillas are both > primates in good standing, but a marmoset weights about > a quarter of a kilo and fits comfortably in your hand. > I think you'll agree that it's going to be a LOT easier > to house and feed 100 marmosets than 100 gorillas. > > Let's start with the very low level. A modern x86_64 has > 16 64-bit general registers > 16 256-bit vector registers > 8 80-bit floating-point registers > 1 32-bit flags register > 1 64-bit program counter > other assorted things like performance counters. > > Switching between *threads* in the same UNIX process > could therefore involve storing 732 bytes of registers > from the old thread and load 732 byte of registers > from the new thread. > > Something like the Erlang VM can arrange to switch only > at points where all of the floating point registers and > the flags are known to be dead, so a context switch > between Erlang processes only needs to save and restore > about 18% of the information that a Linux *thread* switch > does. (Oh wait, I forgot that threads in Linux use the > FS segment register for thread-locals. The 732 byte > figure is *definitely* low.) > > Here I've compared Erlang processes to Linux threads. > Linux *processes* have even more hardware state to switch. > Performance counters will definitely be there, as will > memory management registers. Some machines have > watchpoint registers for debugging. You'd be *amazed* > at what has to be switched. > > As for process creation, think about the fact that > every Linux process has its own page tables and no > Erlang process does. > > Relying on software to prevent one process scribbling > on the memory of another has good consequences. From imran.khan.joya@REDACTED Fri Aug 8 11:41:26 2014 From: imran.khan.joya@REDACTED (Imran Khan) Date: Fri, 8 Aug 2014 02:41:26 -0700 (PDT) Subject: [erlang-questions] Module:Function(SessionID, Env, Input)-> _ Message-ID: Hi friends I am new to erlang.. please help.. How erlang handles above variables like SessionID, Env and Input in function Module:Function(SessionID, Env, Input)-> _ . While making call from httpd, we pass only Input values. How does it works. What is flow from where does it pick Env and SessionID. Thanks -- 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. From bjorn@REDACTED Fri Aug 8 12:34:21 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 8 Aug 2014 12:34:21 +0200 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: On Fri, Aug 8, 2014 at 1:58 AM, wrote: > Let's start with the very low level. A modern x86_64 has > 16 64-bit general registers > 16 256-bit vector registers > 8 80-bit floating-point registers > 1 32-bit flags register > 1 64-bit program counter > other assorted things like performance counters. > > Switching between *threads* in the same UNIX process > could therefore involve storing 732 bytes of registers > from the old thread and load 732 byte of registers > from the new thread. > > Something like the Erlang VM can arrange to switch only > at points where all of the floating point registers and > the flags are known to be dead, so a context switch > between Erlang processes only needs to save and restore > about 18% of the information that a Linux *thread* switch > does. (Oh wait, I forgot that threads in Linux use the > FS segment register for thread-locals. The 732 byte > figure is *definitely* low.) > Here are some details about how BEAM does context switching. The state for an Erlang process is kept in a struct called Process. In principle, all you need to do when switching processes is to change the pointer to the current Process struct. In practice, however, the BEAM virtual machine keeps some of the state in local variables/CPU registers (for efficiency), so it will have to save that part to the Process struct. The following pieces of data need to be saved: the instruction pointer (I) the stack pointer (E) the heap top (HTOP) the reduction counter all X registers currently live and the number of live X registers When doing a context switch in a receive, there are no live X registers; when doing a context switch when calling a function, the number of live X registers is the number of arguments for the function being called. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From krzesimir.sarnecki@REDACTED Fri Aug 8 13:19:26 2014 From: krzesimir.sarnecki@REDACTED (Krzesimir Sarnecki) Date: Fri, 8 Aug 2014 06:19:26 -0500 Subject: [erlang-questions] dialyzer underspecs warning Message-ID: <20140808111926.GA9517@chopin.Belkin> Hello, I'm learning how to use -specs + dialyzer and I encountered a problem. I hope you could help me deal with it. This is my test function: test(Array, N, Value) -> array:set(N, Value, Array). And this ia a spec I wrote for it: -spec test(array:array(T), non_neg_integer(), T) -> array:array(T). When I run dialyzer with -Wunderspecs flag it gives me a warning: Type specification test:test(array:array(T),non_neg_integer(),T) -> array:array(T) is a supertype of the success typing: (very long typing) To my surprise when I change a spec to: -spec test(array:array(T), non_neg_integer(), _) -> array:array(T). Dialyzer doesn't give me the warning anymore. Am I missing something or dialyzer is telling me that T is a supertype of any()? I looked into the source code of array module in stdlib and the -spec for set function is the same as my original -spec. Running dialyzer with the same arguments on the array module doesn't give me warnings (at least for this function). What should the -spec for my function look like? And should I always run dialyzer with -Wunderspecs flag, given it is not a default flag? Thank you in advance, K. From kostis@REDACTED Fri Aug 8 16:13:08 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 08 Aug 2014 16:13:08 +0200 Subject: [erlang-questions] dialyzer underspecs warning In-Reply-To: <20140808111926.GA9517@chopin.Belkin> References: <20140808111926.GA9517@chopin.Belkin> Message-ID: <53E4DAF4.6050801@cs.ntua.gr> On 08/08/2014 01:19 PM, Krzesimir Sarnecki wrote: > I'm learning how to use -specs + dialyzer and I encountered a problem. > I hope you could help me deal with it. > > This is my test function: > > test(Array, N, Value) -> > array:set(N, Value, Array). > > And this ia a spec I wrote for it: > > -spec test(array:array(T), non_neg_integer(), T) -> array:array(T). > > When I run dialyzer with -Wunderspecs flag it gives me a warning: > > Type specification test:test(array:array(T),non_neg_integer(),T) > -> array:array(T) is a supertype of the success typing: (very long > typing) > > To my surprise when I change a spec to: > > -spec test(array:array(T), non_neg_integer(), _) -> array:array(T). > > Dialyzer doesn't give me the warning anymore. > > Am I missing something or dialyzer is telling me that T is a supertype > of any()? You are not missing anything. I looks like this is a bug that should be fixed. (*) Thanks for reporting the issue! Kostis (*) Most likely this has to do with the recent changes that allow polymorphic opaque data types to work considerably better than they used to, but obviously not perfectly yet. From raould@REDACTED Fri Aug 8 19:22:32 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 8 Aug 2014 10:22:32 -0700 Subject: [erlang-questions] [Q] Why is Erlang VM better than traditional OS like Linux? In-Reply-To: References: <53E23871.7090609@volny.cz> <53E23BEC.3000107@gandrade.net> <69b75ffd12dc56728bc76edafb9d669c.squirrel@chasm.otago.ac.nz> <53E342DE.6090302@volny.cz> Message-ID: huh https://dspace.cc.tut.fi/dpub/bitstream/handle/123456789/7919/jaaskelainen_reducing_context_switch_overhead.pdf?sequence=1 kinda neat, if drifting OT... From federico.carrone@REDACTED Fri Aug 8 22:06:54 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Fri, 8 Aug 2014 17:06:54 -0300 Subject: [erlang-questions] How to detect that spawn/4 did not work Message-ID: How can we detect that spawn/4 did not work (network split, host down, etc)? We get an error report but the function returns an invalid Pid and it is not possible to know if it is a real one or not. Why does it return a pid even if it did not work and if it can detect the error (since it generated an error report)? Regards, Federico. --- 1> spawn('this.is@REDACTED', erlang, display, [nothing]). <0.43.0> =ERROR REPORT==== 8-Aug-2014::16:50:52 === ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** 2> proc_lib:spawn('this.is@REDACTED', erlang, display, [nothing]). <0.56.0> 3> =ERROR REPORT==== 8-Aug-2014::16:52:21 === ** Can not start proc_lib:init_p,[<0.50.0>,[],erlang,display,[nothing]] on 'this.is@REDACTED' ** 4> is_process_alive(spawn('this.is@REDACTED', erlang, display, [nothing])). true 5> =ERROR REPORT==== 8-Aug-2014::16:53:27 === ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From elbrujohalcon@REDACTED Fri Aug 8 22:12:53 2014 From: elbrujohalcon@REDACTED (Brujo Benavides @ Inaka) Date: Fri, 8 Aug 2014 17:12:53 -0300 Subject: [erlang-questions] How to detect that spawn/4 did not work In-Reply-To: References: Message-ID: Digging further, you can try with spawn_link: 1> process_flag(trap_exit, true). false 2> spawn_link('this.is@REDACTED', erlang, display, [nothing]). <0.44.0> 3> =ERROR REPORT==== 8-Aug-2014::17:11:51 === ** Can not start erlang:display,[nothing] ([link]) on 'this.is@REDACTED' ** 3> flush(). Shell got {'EXIT',<0.44.0>,noconnection} ok 4> > On Aug 8, 2014, at 17:06, Federico Carrone wrote: > > How can we detect that spawn/4 did not work (network split, host down, etc)? We get an error report but the function returns an invalid Pid and it is not possible to know if it is a real one or not. > > Why does it return a pid even if it did not work and if it can detect the error (since it generated an error report)? > > Regards, > Federico. > > --- > > 1> spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.43.0> > > =ERROR REPORT==== 8-Aug-2014::16:50:52 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > 2> proc_lib:spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.56.0> > > 3> > =ERROR REPORT==== 8-Aug-2014::16:52:21 === > ** Can not start proc_lib:init_p,[<0.50.0>,[],erlang,display,[nothing]] on 'this.is@REDACTED' ** > > 4> is_process_alive(spawn('this.is@REDACTED', erlang, display, [nothing])). > true > 5> > =ERROR REPORT==== 8-Aug-2014::16:53:27 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > -- > 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 federico.carrone@REDACTED Fri Aug 8 22:12:51 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Fri, 8 Aug 2014 17:12:51 -0300 Subject: [erlang-questions] How to detect that spawn/4 did not work In-Reply-To: References: Message-ID: Well with spawn link it generates an ** exception exit: noconnection. However I still think it is strange that spawn/4 returns a Pid even when it is not working. On Fri, Aug 8, 2014 at 5:06 PM, Federico Carrone wrote: > How can we detect that spawn/4 did not work (network split, host down, > etc)? We get an error report but the function returns an invalid Pid and it > is not possible to know if it is a real one or not. > > Why does it return a pid even if it did not work and if it can detect the > error (since it generated an error report)? > > Regards, > Federico. > > --- > > 1> spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.43.0> > > =ERROR REPORT==== 8-Aug-2014::16:50:52 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > 2> proc_lib:spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.56.0> > > 3> > =ERROR REPORT==== 8-Aug-2014::16:52:21 === > ** Can not start proc_lib:init_p,[<0.50.0>,[],erlang,display,[nothing]] > on 'this.is@REDACTED' ** > > 4> is_process_alive(spawn('this.is@REDACTED', erlang, display, > [nothing])). > true > 5> > =ERROR REPORT==== 8-Aug-2014::16:53:27 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > -- > http://federicocarrone.com/ > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Aug 8 22:27:18 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 08 Aug 2014 22:27:18 +0200 Subject: [erlang-questions] How to detect that spawn/4 did not work In-Reply-To: References: Message-ID: <53E532A6.4090008@ninenines.eu> Well spawn is "start and forget". If you need to know that the process is alive as intended you need a link or a monitor. It's the same with local processes, even if the process starts it may immediately crash, and the only way to know that is by using monitors or links. On 08/08/2014 10:06 PM, Federico Carrone wrote: > How can we detect that spawn/4 did not work (network split, host down, > etc)? We get an error report but the function returns an invalid Pid and > it is not possible to know if it is a real one or not. > > Why does it return a pid even if it did not work and if it can detect > the error (since it generated an error report)? > > Regards, > Federico. > > --- > > 1> spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.43.0> > > =ERROR REPORT==== 8-Aug-2014::16:50:52 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > 2> proc_lib:spawn('this.is@REDACTED', erlang, display, [nothing]). > <0.56.0> > > 3> > =ERROR REPORT==== 8-Aug-2014::16:52:21 === > ** Can not start proc_lib:init_p,[<0.50.0>,[],erlang,display,[nothing]] > on 'this.is@REDACTED' ** > > 4> is_process_alive(spawn('this.is@REDACTED', erlang, display, > [nothing])). > true > 5> > =ERROR REPORT==== 8-Aug-2014::16:53:27 === > ** Can not start erlang:display,[nothing] on 'this.is@REDACTED' ** > > -- > http://federicocarrone.com/ > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Fri Aug 8 22:35:07 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 8 Aug 2014 16:35:07 -0400 Subject: [erlang-questions] How to detect that spawn/4 did not work In-Reply-To: References: Message-ID: <20140808203507.GC1955@ferdair.local> On 08/08, Federico Carrone wrote: > Well with spawn link it generates an ** exception exit: noconnection. > However I still think it is strange that spawn/4 returns a Pid even when it > is not working. > > On Fri, Aug 8, 2014 at 5:06 PM, Federico Carrone > Why does it return a pid even if it did not work and if it can detect the > > error (since it generated an error report)? > > The question to ask is what do you do if it doesn't work? The follow-up question to ask is what do you do if it works, but fails a microsecond later? What about 2,3,N microseconds? The spawn function calls are asynchronous. Whether they fail at creation or a microsecond later has little effect. What counts is that you detect the failure and it happened at some point (if you care about it). How differently can you handle a failure before the initialization, while it is taking place (but before the first function call succeeded), halfway through a chain of calls, or after it was done? How do you know when exactly it failed? What if the noconnect (split) happened after you indeed got the Pid, but before code could be run? You'll find out there is very little difference in what you can do as the spawner whether it managed to spawn or not, and the lack of atomicity may just mean it's as sensible to do what Erlang does right now than greedy detection. In practice, what you're gonna lose is granularity in what you get as a report, but nothing different from the worst case you will *have* to consider anyway when deciding how to handle your errors. If you can deal with the worst case, then the rest is not that bad. Regards, Fred. From krzesimir.sarnecki@REDACTED Sat Aug 9 08:24:11 2014 From: krzesimir.sarnecki@REDACTED (Krzesimir Sarnecki) Date: Sat, 9 Aug 2014 01:24:11 -0500 Subject: [erlang-questions] dialyzer underspecs warning In-Reply-To: <53E4DAF4.6050801@cs.ntua.gr> References: <20140808111926.GA9517@chopin.Belkin> <53E4DAF4.6050801@cs.ntua.gr> Message-ID: <20140809062411.GC11736@chopin.Belkin> Ok, thanks! K. On Fri, Aug 08, 2014 at 04:13:08PM +0200, Kostis Sagonas wrote: > On 08/08/2014 01:19 PM, Krzesimir Sarnecki wrote: > >I'm learning how to use -specs + dialyzer and I encountered a problem. > >I hope you could help me deal with it. > > > >This is my test function: > > > >test(Array, N, Value) -> > > array:set(N, Value, Array). > > > >And this ia a spec I wrote for it: > > > >-spec test(array:array(T), non_neg_integer(), T) -> array:array(T). > > > >When I run dialyzer with -Wunderspecs flag it gives me a warning: > > > >Type specification test:test(array:array(T),non_neg_integer(),T) > >-> array:array(T) is a supertype of the success typing: (very long > >typing) > > > >To my surprise when I change a spec to: > > > >-spec test(array:array(T), non_neg_integer(), _) -> array:array(T). > > > >Dialyzer doesn't give me the warning anymore. > > > >Am I missing something or dialyzer is telling me that T is a supertype > >of any()? > > You are not missing anything. I looks like this is a bug that should be > fixed. (*) > > Thanks for reporting the issue! > > Kostis > > (*) Most likely this has to do with the recent changes that allow > polymorphic opaque data types to work considerably better than they used to, > but obviously not perfectly yet. > From n.oxyde@REDACTED Sat Aug 9 10:44:53 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 9 Aug 2014 10:44:53 +0200 Subject: [erlang-questions] =?utf-8?q?Ch=C3=A9ri_Cart_-_Creating_a_Web_App?= =?utf-8?q?_in_Erlang_with_Chicago_Boss_and_Riak_from_Scratch_-_I?= In-Reply-To: <5dbea841-5b1b-4953-ae09-24d05e4a34b6@googlegroups.com> References: <5dbea841-5b1b-4953-ae09-24d05e4a34b6@googlegroups.com> Message-ID: <8C61585D-1D6D-4E14-87E3-3E1B52C269F5@gmail.com> Where exactly did you get the fact that "Most people code with Elixir nowadays"? -- Anthony Ramine Le 6 ao?t 2014 ? 16:01, ?brahim Y?lmaz a ?crit : > Many thanks for sharing bro. > > On Saturday, July 26, 2014 1:54:15 AM UTC+3, Kunthar wrote: >> http://blog.drlinux.org/creating-a-web-app-in-erlang-with-chicago-boss-and-riak-from-scratch-i/ >> >> just wanted to let you know. > > -- > 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. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Sat Aug 9 11:12:37 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 9 Aug 2014 13:12:37 +0400 Subject: [erlang-questions] [ANN] LeoFS 1.1 In-Reply-To: References: Message-ID: Hi, Yosuke. You are making a very important and interesting job. I was trying to find on leo-project.net some instructions: what to do when hard drive dies and haven't found it. It is most interesting thing: what to do when something breaks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Aug 9 11:13:38 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 9 Aug 2014 13:13:38 +0400 Subject: [erlang-questions] [ANN] NkSIP v0.4.0 In-Reply-To: References: Message-ID: Carlos! It is a really amazing work! Your code just works. Do you need help with adding RTP stuff? I'll try to use your code to implement rtmp - sip bridge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.koener@REDACTED Sat Aug 9 11:20:22 2014 From: antoine.koener@REDACTED (Antoine Koener) Date: Sat, 9 Aug 2014 11:20:22 +0200 Subject: [erlang-questions] [ANN] NkSIP v0.4.0 In-Reply-To: References: Message-ID: <068F9B90-D080-454C-94C6-3A677431070C@gmail.com> Or help on webrtc stuff ? > On 09 Aug 2014, at 11:13, Max Lapshin wrote: > > Carlos! > > It is a really amazing work! Your code just works. Do you need help with adding RTP stuff? > I'll try to use your code to implement rtmp - sip bridge. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From prehistorya@REDACTED Sat Aug 9 11:06:29 2014 From: prehistorya@REDACTED (Ibrahim YILMAZ) Date: Sat, 9 Aug 2014 12:06:29 +0300 Subject: [erlang-questions] =?iso-8859-1?q?Ch=E9ri_Cart_-_Creating_a_Web_A?= =?iso-8859-1?q?pp_in_Erlang_with_Chicago_Boss_and_Riak_from_Scratch_-_I?= In-Reply-To: <8C61585D-1D6D-4E14-87E3-3E1B52C269F5@gmail.com> References: <5dbea841-5b1b-4953-ae09-24d05e4a34b6@googlegroups.com> <8C61585D-1D6D-4E14-87E3-3E1B52C269F5@gmail.com> Message-ID: <20140809090626.GA27551@drlinux> Actually I've meant "Most of people who don't like to Erlang syntax / Who finds hard to Erlang syntax". BTW, thanks for the question. That warned me for the unexpected meanings. Will update the article soon. Cheers! On Sat, Aug 09, 2014 at 10:44:53AM +0200, Anthony Ramine wrote: > Where exactly did you get the fact that "Most people code with Elixir nowadays"? > > -- > Anthony Ramine > > Le 6 ao?t 2014 ? 16:01, ?brahim Y?lmaz a ?crit : > > > Many thanks for sharing bro. > > > > On Saturday, July 26, 2014 1:54:15 AM UTC+3, Kunthar wrote: > >> http://blog.drlinux.org/creating-a-web-app-in-erlang-with-chicago-boss-and-riak-from-scratch-i/ > >> > >> just wanted to let you know. > > > > -- > > 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. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -- ?The world is like a ride in an amusement park, and when you choose to go on it you think it's real because that's how powerful our minds are. The ride goes up and down, around and around, it has thrills and chills, and it's very brightly colored, and it's very loud, and it's fun for a while. Many people have been on the ride a long time, and they begin to wonder, "Hey, is this real, or is this just a ride?" And other people have remembered, and they come back to us and say, "Hey, don't worry; don't be afraid, ever, because this is just a ride." And we ? kill those people. "Shut him up! I've got a lot invested in this ride, shut him up! Look at my furrows of worry, look at my big bank account, and my family. This has to be real." It's just a ride. But we always kill the good guys who try and tell us that, you ever notice that? And let the demons run amok ? But it doesn't matter, because it's just a ride. And we can change it any time we want. It's only a choice. No effort, no work, no job, no savings of money. Just a simple choice, right now, between fear and love. The eyes of fear want you to put bigger locks on your doors, buy guns, close yourself off. The eyes of love instead see all of us as one. Here's what we can do to change the world, right now, to a better ride. Take all that money we spend on weapons and defenses each year and instead spend it feeding and clothing and educating the poor of the world, which it would pay for many times over, not one human being excluded, and we could explore space, together, both inner and outer, forever, in peace.? - Bill Hicks From rvirding@REDACTED Sat Aug 9 19:25:37 2014 From: rvirding@REDACTED (Robert Virding) Date: Sat, 9 Aug 2014 10:25:37 -0700 Subject: [erlang-questions] Potion: was "Erlang for youngsters" Message-ID: Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: - It would make it much easier for a large group of programmers to get into the erlang fold. - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. - Lua is a fun language to start with. So who would be interested in joining me to do Potion, a new language for the Erlang VM? Robert On 30 June 2014 23:57, Torben Hoffmann wrote: > Very interestning! > > Thx for sharing, > Torben > > Angel Alvarez (GMAIL) writes: > > > 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 > > > > > > > > > > _______________________________________________ > > 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 essen@REDACTED Sat Aug 9 19:33:51 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 09 Aug 2014 19:33:51 +0200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: <53E65B7F.3070608@ninenines.eu> Me. On 08/09/2014 07:25 PM, Robert Virding wrote: > Hi, have not really been following that thread and just now (yes, I > know) saw the reference in Torben's original message that his son > thought that elixir looked like Lua. While I don't really agree with > that there is an obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get > into the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its > idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language > for the Erlang VM? > > Robert > > > On 30 June 2014 23:57, Torben Hoffmann > > wrote: > > Very interestning! > > Thx for sharing, > Torben > > Angel Alvarez (GMAIL) writes: > > > 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 > > > > > > > > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From sean@REDACTED Sat Aug 9 19:35:01 2014 From: sean@REDACTED (Sean Cribbs) Date: Sat, 9 Aug 2014 12:35:01 -0500 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: Potion is already the name of a language created by "Why the Lucky Stiff" (aka _why): https://github.com/perl11/potion On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: > Hi, have not really been following that thread and just now (yes, I know) > saw the reference in Torben's original message that his son thought that > elixir looked like Lua. While I don't really agree with that there is an > obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into > the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its > idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for > the Erlang VM? > > Robert > > > On 30 June 2014 23:57, Torben Hoffmann > wrote: >> >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ From ivan@REDACTED Sat Aug 9 20:04:16 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sat, 9 Aug 2014 19:04:16 +0100 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: I don't know what I could do, but I'd be interested. Lua's a language I've been meaning to learn for a long time. Ivan -- festina lente > On 9 Aug 2014, at 18:25, Robert Virding wrote: > > Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for the Erlang VM? > > Robert > > >> On 30 June 2014 23:57, Torben Hoffmann wrote: >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > 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 Aug 9 20:23:06 2014 From: g@REDACTED (Garrett Smith) Date: Sat, 9 Aug 2014 13:23:06 -0500 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: I could be persuaded to donate the Lamprey name. As it was originally Roberts's suggestion, it would only cost him three beers. (lamprey.io is available btw) On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: > Potion is already the name of a language created by "Why the Lucky > Stiff" (aka _why): https://github.com/perl11/potion > > On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: >> Hi, have not really been following that thread and just now (yes, I know) >> saw the reference in Torben's original message that his son thought that >> elixir looked like Lua. While I don't really agree with that there is an >> obvious solution that will make it even better: >> >> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >> syntax instead. This would have many benefits: >> >> - It would make it much easier for a large group of programmers to get into >> the erlang fold. >> - The syntax would be simpler that elixir and would avoid some of its >> idiosyncrasies. >> - Lua is a fun language to start with. >> >> So who would be interested in joining me to do Potion, a new language for >> the Erlang VM? >> >> Robert >> >> >> On 30 June 2014 23:57, Torben Hoffmann >> wrote: >>> >>> Very interestning! >>> >>> Thx for sharing, >>> Torben >>> >>> Angel Alvarez (GMAIL) writes: >>> >>> > 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 >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mark.nijhof@REDACTED Sat Aug 9 20:31:40 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 9 Aug 2014 20:31:40 +0200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: It would be interesting to help, not sure how but that will work itself out I am sure. Also missed the blog post in the original post, thanks for bringing that back as well :) -Mark On Aug 9, 2014 8:23 PM, "Garrett Smith" wrote: > I could be persuaded to donate the Lamprey name. As it was originally > Roberts's suggestion, it would only cost him three beers. > > (lamprey.io is available btw) > > On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: > > Potion is already the name of a language created by "Why the Lucky > > Stiff" (aka _why): https://github.com/perl11/potion > > > > On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding > wrote: > >> Hi, have not really been following that thread and just now (yes, I > know) > >> saw the reference in Torben's original message that his son thought that > >> elixir looked like Lua. While I don't really agree with that there is an > >> obvious solution that will make it even better: > >> > >> We do Potion which is a new language on the BEAM+OTP with a Lua inspired > >> syntax instead. This would have many benefits: > >> > >> - It would make it much easier for a large group of programmers to get > into > >> the erlang fold. > >> - The syntax would be simpler that elixir and would avoid some of its > >> idiosyncrasies. > >> - Lua is a fun language to start with. > >> > >> So who would be interested in joining me to do Potion, a new language > for > >> the Erlang VM? > >> > >> Robert > >> > >> > >> On 30 June 2014 23:57, Torben Hoffmann > >> wrote: > >>> > >>> Very interestning! > >>> > >>> Thx for sharing, > >>> Torben > >>> > >>> Angel Alvarez (GMAIL) writes: > >>> > >>> > 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 > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > 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 > >> > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > _______________________________________________ > > 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 federico.carrone@REDACTED Sat Aug 9 21:27:29 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Sat, 9 Aug 2014 16:27:29 -0300 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: <53E65B7F.3070608@ninenines.eu> References: <53E65B7F.3070608@ninenines.eu> Message-ID: Me too :P On Sat, Aug 9, 2014 at 2:33 PM, Lo?c Hoguin wrote: > Me. > > > On 08/09/2014 07:25 PM, Robert Virding wrote: > >> Hi, have not really been following that thread and just now (yes, I >> know) saw the reference in Torben's original message that his son >> thought that elixir looked like Lua. While I don't really agree with >> that there is an obvious solution that will make it even better: >> >> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >> syntax instead. This would have many benefits: >> >> - It would make it much easier for a large group of programmers to get >> into the erlang fold. >> - The syntax would be simpler that elixir and would avoid some of its >> idiosyncrasies. >> - Lua is a fun language to start with. >> >> So who would be interested in joining me to do Potion, a new language >> for the Erlang VM? >> >> Robert >> >> >> On 30 June 2014 23:57, Torben Hoffmann >> > > wrote: >> >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> >> >> >> >> _______________________________________________ >> 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 > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Sat Aug 9 22:49:09 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sat, 9 Aug 2014 16:49:09 -0400 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: Hi Robert, How well do you think Potion would run on this? http://hardkernel.com/main/products/prdt_info.php Or, this? http://cubieboard.org/2013/06/19/cubieboard2-is-here/ Best wishes, Lloyd Sent from my iPad > On Aug 9, 2014, at 1:25 PM, Robert Virding wrote: > > Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for the Erlang VM? > > Robert > > >> On 30 June 2014 23:57, Torben Hoffmann wrote: >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > 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 Sat Aug 9 23:22:32 2014 From: bob@REDACTED (Bob Ippolito) Date: Sat, 9 Aug 2014 14:22:32 -0700 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: I'd be happy to help in some way, what do you need? On Sat, Aug 9, 2014 at 10:25 AM, Robert Virding wrote: > Hi, have not really been following that thread and just now (yes, I know) > saw the reference in Torben's original message that his son thought that > elixir looked like Lua. While I don't really agree with that there is an > obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get > into the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its > idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for > the Erlang VM? > > Robert > > > On 30 June 2014 23:57, Torben Hoffmann < > torben.hoffmann@REDACTED> wrote: > >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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 Aug 10 00:54:34 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 10 Aug 2014 00:54:34 +0200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: <20D92B80-8B2E-46B7-B979-D18965A6818B@gmail.com> Somewhat off-topic: Why is virtually no one trying to improve things in Erlang the language? I don?t think named fun expressions and maps were the last things to add to the language. Nor I think nothing can be done for youngsters and beginners. Honestly I don?t see how a new language for youngsters help, youngsters? state is blank, we can start with anything as long as the tooling is adequate enough to help you. For example, let me repeat myself, with smarter syntax errors. -- Anthony Ramine Le 9 ao?t 2014 ? 19:25, Robert Virding a ?crit : > So who would be interested in joining me to do Potion, a new language for the Erlang VM? From moxford@REDACTED Sun Aug 10 06:16:50 2014 From: moxford@REDACTED (Mike Oxford) Date: Sat, 9 Aug 2014 21:16:50 -0700 Subject: [erlang-questions] distel question Message-ID: When I compile in a buffer (C-c C-k), the first time it will pop up the erlang shell and swap focus to it. C-x 0 to get back to editing. The second time I compile it will show the buffer but NOT swap focus to it. C-x 1 to get back to editing. 1) Is there a setting to normalize this? So it always acts the same? Or better yet... 2) Is there a setting somewhere to auto-close the erlang shell when it's done compiling? Or will I need to dig into the Lisp directly? Ideally "C-c C-k" to compile it, wait for the erlang shell to close (maybe with additional 1s delay to see results), "C-c C-d L" to shove it into the node and go back to editing without having to close "popups." Thanks! -mox -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdavid.eisenberg@REDACTED Sun Aug 10 21:35:30 2014 From: jdavid.eisenberg@REDACTED (J David Eisenberg) Date: Sun, 10 Aug 2014 12:35:30 -0700 Subject: [erlang-questions] Potion: was "Erlang for youngsters" Message-ID: > Date: Sat, 9 Aug 2014 10:25:37 -0700 > From: Robert Virding > To: Torben Hoffmann > Cc: erlang-questions > Subject: [erlang-questions] Potion: was "Erlang for youngsters" > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi, have not really been following that thread and just now (yes, I know) > saw the reference in Torben's original message that his son thought that > elixir looked like Lua. While I don't really agree with that there is an > obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > syntax instead. This would have many benefits: I've been doing some thinking about this lately. One thing I liked about Erlang (and am liking about Clojure and Racket) is that they don't look like imperative languages, so I'm not tempted to think in imperative terms. Given that some of these youngsters may have programmed a Raspberry Pi in Python or JavaScript, that could be a source of "interference" when learning a functional language. Lua looks a lot like those imperative languages also. I think Lisp Flavored Erlang with a module that hides the complexities of wx might work quite well. It would also allow us to build on the efforts of what people teaching Racket have done; see http://www.bootstrapworld.org/materials/Fall2014/courses/bs1/main.shtml Using LFE also gives a clear path to Clojure/ClojureScript or Racket. ELM is also quite interesting, and is Haskell-based, but I don't think I want to go there quite yet! > > - It would make it much easier for a large group of programmers to get into > the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its > idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for > the Erlang VM? > > Robert > > > On 30 June 2014 23:57, Torben Hoffmann > wrote: > >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> [snip] From torben.hoffmann@REDACTED Sun Aug 10 21:43:25 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Sun, 10 Aug 2014 21:43:25 +0200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: I am normally very fund of animal names, but catering for Robert's original name I think something like Ointment or Unguent (http://dictionary.reference.com/browse/unguent) would capture the intend better. Unguent (n): an ointment or salve, usually liquid or semiliquid, for application to wounds, sores, etc. So Erlang hurts a bit, huh? Here's some Unguent for you! Please note that I am not implying that Erlang is an open wound ;-) Cheers, Torben Garrett Smith writes: > I could be persuaded to donate the Lamprey name. As it was originally > Roberts's suggestion, it would only cost him three beers. > > (lamprey.io is available btw) > > On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: >> Potion is already the name of a language created by "Why the Lucky >> Stiff" (aka _why): https://github.com/perl11/potion >> >> On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: >>> Hi, have not really been following that thread and just now (yes, I know) >>> saw the reference in Torben's original message that his son thought that >>> elixir looked like Lua. While I don't really agree with that there is an >>> obvious solution that will make it even better: >>> >>> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >>> syntax instead. This would have many benefits: >>> >>> - It would make it much easier for a large group of programmers to get into >>> the erlang fold. >>> - The syntax would be simpler that elixir and would avoid some of its >>> idiosyncrasies. >>> - Lua is a fun language to start with. >>> >>> So who would be interested in joining me to do Potion, a new language for >>> the Erlang VM? >>> >>> Robert >>> >>> >>> On 30 June 2014 23:57, Torben Hoffmann >>> wrote: >>>> >>>> Very interestning! >>>> >>>> Thx for sharing, >>>> Torben >>>> >>>> Angel Alvarez (GMAIL) writes: >>>> >>>> > 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 >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> >> -- >> Sean Cribbs >> Software Engineer >> Basho Technologies, Inc. >> http://basho.com/ >> _______________________________________________ >> 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 ivan@REDACTED Sun Aug 10 21:51:22 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sun, 10 Aug 2014 20:51:22 +0100 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: <4F404836-E1A8-4138-8C68-F8D26E993C87@llaisdy.com> How would Potion differ from Luerl? https://github.com/rvirding/luerl Ivan -- festina lente > On 9 Aug 2014, at 18:25, Robert Virding wrote: > > Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into the erlang fold. > - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for the Erlang VM? > > Robert > > >> On 30 June 2014 23:57, Torben Hoffmann wrote: >> Very interestning! >> >> Thx for sharing, >> Torben >> >> Angel Alvarez (GMAIL) writes: >> >> > 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 >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdavid.eisenberg@REDACTED Sun Aug 10 21:59:45 2014 From: jdavid.eisenberg@REDACTED (J David Eisenberg) Date: Sun, 10 Aug 2014 12:59:45 -0700 (PDT) Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: On Saturday, August 9, 2014 10:26:10 AM UTC-7, rvirding wrote: > Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: > > > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into the erlang fold. > > > - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for the Erlang VM? > > > > Robert > > I've been doing some thinking about this lately. One thing I liked about Erlang (and am liking about Clojure and Racket) is that they don't look like imperative languages, so I'm not tempted to think in imperative terms. Given that some of these youngsters may have programmed a Raspberry Pi in Python or JavaScript, that could be a source of "interference" when learning a functional language. Lua looks a lot like those imperative languages also. I think Lisp Flavored Erlang with a module that can do graphics but hides the complexities of wx might work quite well. It would also allow us to build on the efforts of what people teaching Racket have done; see http://www.bootstrapworld.org/materials/Fall2014/courses/bs1/main.shtml (although its license does not allow remixing) Using LFE also gives a clear path to Clojure/ClojureScript or Racket if learners want to go off in that direction. ELM is also quite interesting, and is Haskell-based, but I don't think I want to go there quite yet! > > > On 30 June 2014 23:57, Torben Hoffmann wrote: > > > Very interestning! > > > > Thx for sharing, > > Torben > > > > > > Angel Alvarez (GMAIL) writes: > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions [snip] From ivan@REDACTED Sun Aug 10 22:16:28 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sun, 10 Aug 2014 21:16:28 +0100 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: <9B28866A-3138-4BDE-8BE2-BCF9A8760DA5@llaisdy.com> Moonshine? -- festina lente > On 10 Aug 2014, at 20:43, Torben Hoffmann wrote: > > I am normally very fund of animal names, but catering for Robert's original name I > think something like Ointment or Unguent > (http://dictionary.reference.com/browse/unguent) would capture the intend better. > > Unguent (n): an ointment or salve, usually liquid or semiliquid, for application to > wounds, sores, etc. > > So Erlang hurts a bit, huh? Here's some Unguent for you! > > Please note that I am not implying that Erlang is an open wound ;-) > > Cheers, > Torben > > Garrett Smith writes: > >> I could be persuaded to donate the Lamprey name. As it was originally >> Roberts's suggestion, it would only cost him three beers. >> >> (lamprey.io is available btw) >> >>> On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: >>> Potion is already the name of a language created by "Why the Lucky >>> Stiff" (aka _why): https://github.com/perl11/potion >>> >>>> On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: >>>> Hi, have not really been following that thread and just now (yes, I know) >>>> saw the reference in Torben's original message that his son thought that >>>> elixir looked like Lua. While I don't really agree with that there is an >>>> obvious solution that will make it even better: >>>> >>>> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >>>> syntax instead. This would have many benefits: >>>> >>>> - It would make it much easier for a large group of programmers to get into >>>> the erlang fold. >>>> - The syntax would be simpler that elixir and would avoid some of its >>>> idiosyncrasies. >>>> - Lua is a fun language to start with. >>>> >>>> So who would be interested in joining me to do Potion, a new language for >>>> the Erlang VM? >>>> >>>> Robert >>>> >>>> >>>> On 30 June 2014 23:57, Torben Hoffmann >>>> wrote: >>>>> >>>>> Very interestning! >>>>> >>>>> Thx for sharing, >>>>> Torben >>>>> >>>>> Angel Alvarez (GMAIL) writes: >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> -- >>> Sean Cribbs >>> Software Engineer >>> Basho Technologies, Inc. >>> http://basho.com/ >>> _______________________________________________ >>> 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 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From torben.hoffmann@REDACTED Sun Aug 10 22:31:21 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Sun, 10 Aug 2014 22:31:21 +0200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: <9B28866A-3138-4BDE-8BE2-BCF9A8760DA5@llaisdy.com> References: <9B28866A-3138-4BDE-8BE2-BCF9A8760DA5@llaisdy.com> Message-ID: I can already see the marketing material... Tired of the way you think about programming? Do you want to forget it? Try Moonshine! After a few days you will not remember anything about the old and painful ways of programming. No! You will be having a blast with Moonshine as it is opening your mind to a new way of programming. Or maybe not... Ivan Uemlianin writes: > Moonshine? > > -- > festina lente > > >> On 10 Aug 2014, at 20:43, Torben Hoffmann wrote: >> >> I am normally very fund of animal names, but catering for Robert's original name I >> think something like Ointment or Unguent >> (http://dictionary.reference.com/browse/unguent) would capture the intend better. >> >> Unguent (n): an ointment or salve, usually liquid or semiliquid, for application to >> wounds, sores, etc. >> >> So Erlang hurts a bit, huh? Here's some Unguent for you! >> >> Please note that I am not implying that Erlang is an open wound ;-) >> >> Cheers, >> Torben >> >> Garrett Smith writes: >> >>> I could be persuaded to donate the Lamprey name. As it was originally >>> Roberts's suggestion, it would only cost him three beers. >>> >>> (lamprey.io is available btw) >>> >>>> On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: >>>> Potion is already the name of a language created by "Why the Lucky >>>> Stiff" (aka _why): https://github.com/perl11/potion >>>> >>>>> On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: >>>>> Hi, have not really been following that thread and just now (yes, I know) >>>>> saw the reference in Torben's original message that his son thought that >>>>> elixir looked like Lua. While I don't really agree with that there is an >>>>> obvious solution that will make it even better: >>>>> >>>>> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >>>>> syntax instead. This would have many benefits: >>>>> >>>>> - It would make it much easier for a large group of programmers to get into >>>>> the erlang fold. >>>>> - The syntax would be simpler that elixir and would avoid some of its >>>>> idiosyncrasies. >>>>> - Lua is a fun language to start with. >>>>> >>>>> So who would be interested in joining me to do Potion, a new language for >>>>> the Erlang VM? >>>>> >>>>> Robert >>>>> >>>>> >>>>> On 30 June 2014 23:57, Torben Hoffmann >>>>> wrote: >>>>>> >>>>>> Very interestning! >>>>>> >>>>>> Thx for sharing, >>>>>> Torben >>>>>> >>>>>> Angel Alvarez (GMAIL) writes: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> >>>> -- >>>> Sean Cribbs >>>> Software Engineer >>>> Basho Technologies, Inc. >>>> http://basho.com/ >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 fly@REDACTED Sun Aug 10 22:45:02 2014 From: fly@REDACTED (Fred Youhanaie) Date: Sun, 10 Aug 2014 21:45:02 +0100 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: <9B28866A-3138-4BDE-8BE2-BCF9A8760DA5@llaisdy.com> References: <9B28866A-3138-4BDE-8BE2-BCF9A8760DA5@llaisdy.com> Message-ID: <53E7D9CE.8010204@anydata.co.uk> or perhaps moonbeam? ;-) On 10/08/14 21:16, Ivan Uemlianin wrote: > Moonshine? > > -- > festina lente > > >> On 10 Aug 2014, at 20:43, Torben Hoffmann wrote: >> >> I am normally very fund of animal names, but catering for Robert's original name I >> think something like Ointment or Unguent >> (http://dictionary.reference.com/browse/unguent) would capture the intend better. >> >> Unguent (n): an ointment or salve, usually liquid or semiliquid, for application to >> wounds, sores, etc. >> >> So Erlang hurts a bit, huh? Here's some Unguent for you! >> >> Please note that I am not implying that Erlang is an open wound ;-) >> >> Cheers, >> Torben >> >> Garrett Smith writes: >> >>> I could be persuaded to donate the Lamprey name. As it was originally >>> Roberts's suggestion, it would only cost him three beers. >>> >>> (lamprey.io is available btw) >>> >>>> On Sat, Aug 9, 2014 at 12:35 PM, Sean Cribbs wrote: >>>> Potion is already the name of a language created by "Why the Lucky >>>> Stiff" (aka _why): https://github.com/perl11/potion >>>> >>>>> On Sat, Aug 9, 2014 at 12:25 PM, Robert Virding wrote: >>>>> Hi, have not really been following that thread and just now (yes, I know) >>>>> saw the reference in Torben's original message that his son thought that >>>>> elixir looked like Lua. While I don't really agree with that there is an >>>>> obvious solution that will make it even better: >>>>> >>>>> We do Potion which is a new language on the BEAM+OTP with a Lua inspired >>>>> syntax instead. This would have many benefits: >>>>> >>>>> - It would make it much easier for a large group of programmers to get into >>>>> the erlang fold. >>>>> - The syntax would be simpler that elixir and would avoid some of its >>>>> idiosyncrasies. >>>>> - Lua is a fun language to start with. >>>>> >>>>> So who would be interested in joining me to do Potion, a new language for >>>>> the Erlang VM? >>>>> >>>>> Robert >>>>> >>>>> >>>>> On 30 June 2014 23:57, Torben Hoffmann >>>>> wrote: >>>>>> >>>>>> Very interestning! >>>>>> >>>>>> Thx for sharing, >>>>>> Torben >>>>>> >>>>>> Angel Alvarez (GMAIL) writes: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> >>>> -- >>>> Sean Cribbs >>>> Software Engineer >>>> Basho Technologies, Inc. >>>> http://basho.com/ >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 ok@REDACTED Mon Aug 11 02:08:05 2014 From: ok@REDACTED (ok@REDACTED) Date: Mon, 11 Aug 2014 12:08:05 +1200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get > into > the erlang fold. Where is the evidence for this? If Luerl didn't achieve it, why would Potion? > - The syntax would be simpler that elixir and would avoid some of its > idiosyncrasies. > - Lua is a fun language to start with. Did you ever have the feeling that when you got up in the morning you stepped into the wrong parallel universe? I've had Lua on my Macs for years. About once a year I stumble across it by accident while searching for something else, and say "oh YEAH, I forgot about that, time to put it to use." I then download the latest release, re-read the manual, wake up, finish re-reading the manual, and when I've stopped yawning, go and do something more enjoyable, like marking or cleaning the bathroom. As far as I can see, the two virtues of Lua are (1) Lua the *language* is a small ho-hum language with a small embeddable implementation that you can easily hook into and use as an extension language. That's presumably why LuaTeX exists. (2) Lua the *system* comes with things like luarocks and a useful library of user-contributed extensions like i18n. This is the bit I personally find attractive, or would if I couldn't get the things I want in other languages. A language that is only Lua-*like* sacrifices pretty much all of (2), which is to say sacrifices most of the reason why I would ever consider using Lua for anything. Perhaps the most ho-hum aspect of Lua is its heavy dependence on mutable state, making error handling the familiar terror it was before Erlang. It might not be unfair to describe Lua as a small Javascript done right and luarocks as npm. If the same engineering work of making Javascript less of a dog had been put into Lua... From moxford@REDACTED Mon Aug 11 06:02:40 2014 From: moxford@REDACTED (Mike Oxford) Date: Sun, 10 Aug 2014 21:02:40 -0700 Subject: [erlang-questions] Of regexes and REs, and other irritating things... Message-ID: I need to so some input sanitizing for use against MySQL. "This isn't much of a \"test string\"; it'll have to do though." Tried using the RE modules (yes, quad escaping crap) but the replacement part for the back-references isn't working correctly. Instead of getting "\;" it's actually interpreting the backslash all the way down. At least it's not turtles all the way down. So I went with a replacement of <92,"\\\\1"> thinking I'd get around it, but it didn't work either. Closest I got was "\\;" in the string which is still incorrect. So regexp is deprecated in favor of RE, but yet RE's pretty shitty for this kind of thing. I suppose I can just walk the list directly but then it's incremental string-building. Anyone have a "here dummy, you missed this NIF/built-in ... just use that" to throw my way? TIA! 122> re:replace("This isn't much of a \"test string\"; it'll have to do though.", "([';\"])", <<92,"\\\\1">>, [global, {return, binary}]). <<"This isn\\'t much of a \\\"test string\\\"\\; it\\'ll have to do though.">> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdavid.eisenberg@REDACTED Sun Aug 10 21:59:45 2014 From: jdavid.eisenberg@REDACTED (J David Eisenberg) Date: Sun, 10 Aug 2014 12:59:45 -0700 (PDT) Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: On Saturday, August 9, 2014 10:26:10 AM UTC-7, rvirding wrote: > Hi, have not really been following that thread and just now (yes, I know) saw the reference in Torben's original message that his son thought that elixir looked like Lua. While I don't really agree with that there is an obvious solution that will make it even better: > > > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired syntax instead. This would have many benefits: > > - It would make it much easier for a large group of programmers to get into the erlang fold. > > > - The syntax would be simpler that elixir and would avoid some of its idiosyncrasies. > - Lua is a fun language to start with. > > So who would be interested in joining me to do Potion, a new language for the Erlang VM? > > > > Robert > > I've been doing some thinking about this lately. One thing I liked about Erlang (and am liking about Clojure and Racket) is that they don't look like imperative languages, so I'm not tempted to think in imperative terms. Given that some of these youngsters may have programmed a Raspberry Pi in Python or JavaScript, that could be a source of "interference" when learning a functional language. Lua looks a lot like those imperative languages also. I think Lisp Flavored Erlang with a module that can do graphics but hides the complexities of wx might work quite well. It would also allow us to build on the efforts of what people teaching Racket have done; see http://www.bootstrapworld.org/materials/Fall2014/courses/bs1/main.shtml (although its license does not allow remixing) Using LFE also gives a clear path to Clojure/ClojureScript or Racket if learners want to go off in that direction. ELM is also quite interesting, and is Haskell-based, but I don't think I want to go there quite yet! > > > On 30 June 2014 23:57, Torben Hoffmann wrote: > > > Very interestning! > > > > Thx for sharing, > > Torben > > > > > > Angel Alvarez (GMAIL) writes: > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions [snip] -- 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. From per@REDACTED Mon Aug 11 09:03:29 2014 From: per@REDACTED (Per Hedeland) Date: Mon, 11 Aug 2014 09:03:29 +0200 (CEST) Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: Message-ID: <201408110703.s7B73TEm023027@pluto.hedeland.org> >Mike Oxford wrote: > >I need to so some input sanitizing for use against MySQL. Well, you're not saying exactly what you want to achieve, so it's a bit difficult to comment, but... >122> re:replace("This isn't much of a \"test string\"; it'll have to do >though.", "([';\"])", <<92,"\\\\1">>, [global, {return, binary}]). ... it seems that you want to \-escape all occurences of ', ;, and "... ><<"This isn\\'t much of a \\\"test string\\\"\\; it\\'ll have to do >though.">> ... and it seems that you succeeded. >So I went with a replacement of <92,"\\\\1"> thinking I'd get around it, You can use "\\\\\\1" instead with same result - not saying it is any more readable:-), but avoids throwing in an ascii code and is actually a little shorter... >but it didn't work either. Closest I got was "\\;" in the string which is >still incorrect. I believe you are just confused by the "string rendering" - backslashes must also be backslash-escaped in the "string form", there is only one of them actually in there. Try this: 1> [97,92,59,98]. "a\\;b" --Per Hedeland From essen@REDACTED Mon Aug 11 09:51:40 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 11 Aug 2014 09:51:40 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: References: Message-ID: <53E8760C.3050303@ninenines.eu> On 08/11/2014 06:02 AM, Mike Oxford wrote: > I need to so some input sanitizing for use against MySQL. Are you saying you are going to take this data and put it inside a query string? This isn't going to protect anything, escaping doesn't prevent SQL injection. Why not use a prepared statement instead? This makes the data separate from the query, you don't need to do any escaping and MySQL takes care of everything for you. Also make sure you are using the *binary* protocol, not the *text* one, and you're pretty much set. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Mon Aug 11 11:51:44 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 11 Aug 2014 11:51:44 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: <53E8760C.3050303@ninenines.eu> References: <53E8760C.3050303@ninenines.eu> Message-ID: The only slight problem here is MySQL, which picked a protocol that is roughly impossible to handle correctly in any way, unless you parse the text strings you have to send to it. I have a hunch that the lack of good drivers is deeply tied into the problem of the protocols shortcomings. On Mon, Aug 11, 2014 at 9:51 AM, Lo?c Hoguin wrote: > On 08/11/2014 06:02 AM, Mike Oxford wrote: > >> I need to so some input sanitizing for use against MySQL. >> > > Are you saying you are going to take this data and put it inside a query > string? This isn't going to protect anything, escaping doesn't prevent SQL > injection. Why not use a prepared statement instead? This makes the data > separate from the query, you don't need to do any escaping and MySQL takes > care of everything for you. Also make sure you are using the *binary* > protocol, not the *text* one, and you're pretty much set. > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Aug 11 11:56:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 11 Aug 2014 11:56:32 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: References: <53E8760C.3050303@ninenines.eu> Message-ID: <53E89350.1030106@ninenines.eu> bank_mysql only offers the binary protocol and has a complete lack of bundling data inside the query string, or parsing the query string. I am not sure what you are talking about. On 08/11/2014 11:51 AM, Jesper Louis Andersen wrote: > The only slight problem here is MySQL, which picked a protocol that is > roughly impossible to handle correctly in any way, unless you parse the > text strings you have to send to it. I have a hunch that the lack of > good drivers is deeply tied into the problem of the protocols shortcomings. > > > On Mon, Aug 11, 2014 at 9:51 AM, Lo?c Hoguin > wrote: > > On 08/11/2014 06:02 AM, Mike Oxford wrote: > > I need to so some input sanitizing for use against MySQL. > > > Are you saying you are going to take this data and put it inside a > query string? This isn't going to protect anything, escaping doesn't > prevent SQL injection. Why not use a prepared statement instead? > This makes the data separate from the query, you don't need to do > any escaping and MySQL takes care of everything for you. Also make > sure you are using the *binary* protocol, not the *text* one, and > you're pretty much set. > > -- > Lo?c Hoguin > http://ninenines.eu > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > -- > J. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Mon Aug 11 13:06:16 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 11 Aug 2014 13:06:16 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: <53E89350.1030106@ninenines.eu> References: <53E8760C.3050303@ninenines.eu> <53E89350.1030106@ninenines.eu> Message-ID: On Mon, Aug 11, 2014 at 11:56 AM, Lo?c Hoguin wrote: > bank_mysql only offers the binary protocol and has a complete lack of > bundling data inside the query string, or parsing the query string. I am > not sure what you are talking about. > Try: CALL foo() What does this return? It returns either 1 or 2 packets, depending on the definition of foo() in the MySQL server :) Welcome to a really bad protocol design. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterke@REDACTED Mon Aug 11 15:13:41 2014 From: peterke@REDACTED (=?UTF-8?B?UMOpdGVyIFN6aWzDoWd5aQ==?=) Date: Mon, 11 Aug 2014 16:13:41 +0300 Subject: [erlang-questions] [ANN] Iris v0.3.0 and Erlang binding v1.0.0 Message-ID: Hi all, For a few years now I've been researching and working on a decentralized cloud messaging system called Iris. My goal with it was to bring the simplicity of cloud computing to the application layer, with the motto that if renting a batch of VMs can be done in one line of code, then assembling them into a communicating distributed system should be doable with another line. I'm proud to say, that Iris was voted as one of the most innovative open source projects related to scalability and devops, being nominated as a finalist for the dotScale prize . If I had to summarize the project in one sentence, it would be: "A completely decentralized messaging solution for simplifying the design and implementation of cloud services, featuring zero-configuration (i.e. start it up and it will do its magic), semantic addressing (i.e. application use textual names to address each other), clusters as units (i.e. automatic load balancing between apps of the same name) and perfect secrecy (i.e. all network traffic is encrypted)". And just to complete the above description, it is fast and language agnostic ;) Today marked the release of version v0.3.0 of the Iris core, and with it I'm very proud to release the first stable version of the Erlang API too, v1.0.0! The API follows the OTP design patterns, and specifically that of the gen_server, but takes it way beyond in capabilities :D Just as a teaser, this is how you can attach a micro-service instance to Iris through Erlang, which will then completely automatically integrate with other nodes and services written it arbitrary languages, and be able to communicate with them completely decentralized and completely secure! -behaviour(iris_server). -export([init/2, handle_broadcast/2, handle_request/3, handle_tunnel/2, handle_drop/2, terminate/2]). % Implement all the methods defined by iris_server. init(Conn, your_init_args) -> {ok, your_state}. terminate(Reason, State) -> ok. handle_broadcast(Message, State) -> {noreply, State}. handle_request(Request, From, State) -> {reply, Request, State}. handle_tunnel(Tunnel, State) -> {noreply, State}. handle_drop(Reason, State) -> {stop, Reason, State}. main() -> % Register a new service to the relay {ok, Server} = iris_server:start(55555, "cluster name", ?MODULE, your_init_args), % Unregister the service ok = iris_server:stop(Server). As you can see above, you can have broadcasts (received by *all* members of a particular micro-service cluster (the name specified during registration above), requests (load balanced between *all* members of a particular cluster), tunnels for ordered and throttled stream oriented communication between two nodes, and pub/sub (API through a different module). No networking code involved, period. Since seeing is believing, I invite anyone interested to look at the online Erlang playground , which is a short introductory presentation of Iris and its Erlang binding, walking over each communication primitive with modifiable and executable code segments. Should it wet your appetites, further infos can be found in the Erlang quick-start guide . Of course, the most valuable source of information is the Iris website itself , containing pre-built binaries and other language bindings on the downloads section , recordings from live presentations on the talks section (FOSDEM, dotScale), a work-in-progress guide called The book of Iris and last but not least, some research papers for the academically inclined. And if you really want to dive deep, all source code is available on GitHub (dev docs at edoc ). Hope you like it, and if you have any questions or feedback, I'm more than happy to answer/react :) Cheers, Peter PS: If you're interested enough, you are welcome into the Iris community at the project-iris mailing list or @iriscmf on Twitter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Mon Aug 11 16:05:56 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 11 Aug 2014 16:05:56 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: <53E8760C.3050303@ninenines.eu> References: <53E8760C.3050303@ninenines.eu> Message-ID: <53E8CDC4.7090100@wanadoo.fr> I agree . Note, what I like in Postgresql on contrary of Mysql, is the dollar quoting. In addition to usual SQL injection protections on data input, you can also use dynamic dollar quoting, to make more complexe SQL injection attempts : UPDATE users set password=$4896$new password hash$4896$ WHERE id=12345 ; 4896 is for instance the PID of the forked Apache process, or anything else with more entropy. The attacker can't guess this ID and injection is much much more complex... Le 11/08/2014 09:51, Lo?c Hoguin a ?crit : > On 08/11/2014 06:02 AM, Mike Oxford wrote: >> I need to so some input sanitizing for use against MySQL. > > Are you saying you are going to take this data and put it inside a query > string? This isn't going to protect anything, escaping doesn't prevent > SQL injection. Why not use a prepared statement instead? This makes the > data separate from the query, you don't need to do any escaping and > MySQL takes care of everything for you. Also make sure you are using the > *binary* protocol, not the *text* one, and you're pretty much set. > From benmmurphy@REDACTED Mon Aug 11 16:16:47 2014 From: benmmurphy@REDACTED (Ben Murphy) Date: Mon, 11 Aug 2014 15:16:47 +0100 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains Message-ID: (I originally sent this to erlang-bugs but it doesn't look like it made it there) We have a problem where an SSL server sends back a certificate chain that is invalid according to the TLS 1.2 specification and erlang rejects this chain with an unknown ca error. However, openssl and browsers will accept this chain because they are less strict about validation. The chain looks something like: 0. Server Cert issued by Intermediate Cert 1. Intermediate Cert issued by Root Cert 2. Root Cert issued by Root Cert 3. Unrelated certificate 4. Unrelated certificate Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case Looking at the openssl code they start at the beginning of the chain then recursively find the issuer in order to build up a chain. While the erlang ssl code assumes the last certificate in the chain is the root CA (ssl_certificate:trusted_cert_and_path). Maybe this is more of a feature request than a bug. But I was wondering if it would be possible for erlang to either accept these dodgy chains, provide an option when connecting to accept these dodgy chains or allow users to supply a function to modify the certificate chain before validation takes place. I have some code that I've been mucking around with to fix up chains but I haven't done thorough testing of it. fix_path(CertChain) -> DecodedCerts = [ {public_key:pkix_decode_cert(Cert, otp), Cert} || Cert <- CertChain ], [Peer | RestOfChain] = DecodedCerts, lists:reverse(make_chain(Peer, RestOfChain, [])). make_chain({OtpCert, Cert}, CertChain, ResultChain) -> case public_key:pkix_is_self_signed(OtpCert) of true -> [Cert | ResultChain ]; false -> case find_issuer(OtpCert, CertChain) of {ok, NewCert, NewCertChain} -> % we remove the cert that was found from the chain % to prevent infinite loops where a chain becomes % a loop make_chain(NewCert, NewCertChain, [Cert | ResultChain]); {error, issuer_not_found} -> % assume it is the 'trusted' certificate [Cert | ResultChain] end end. find_issuer(OtpCert, CertChain) -> {Not, Maybe} = lists:splitwith(fun({Candidate, _}) -> not public_key:pkix_is_issuer(OtpCert, Candidate) end, CertChain), case Maybe of [Issuer | Rest] -> {ok, Issuer, Not ++ Rest}; [] -> {error, issuer_not_found} end. From dmkolesnikov@REDACTED Mon Aug 11 16:22:18 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 11 Aug 2014 17:22:18 +0300 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: Message-ID: <091BFA4D-5A50-42DE-B6F7-D4A5C7CEF401@gmail.com> Hello, Have you tried to bypass an issue with custom verify_fun ? - Dmitry On 11 Aug 2014, at 17:16, Ben Murphy wrote: > (I originally sent this to erlang-bugs but it doesn't look like it > made it there) > > We have a problem where an SSL server sends back a certificate chain > that is invalid according to the TLS 1.2 specification and erlang > rejects this chain with an unknown ca error. However, openssl and > browsers will accept this chain because they are less strict about > validation. > > The chain looks something like: > > 0. Server Cert issued by Intermediate Cert > 1. Intermediate Cert issued by Root Cert > 2. Root Cert issued by Root Cert > 3. Unrelated certificate > 4. Unrelated certificate > > Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt > > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order to > validate it in any case > > Looking at the openssl code they start at the beginning of the chain > then recursively find the issuer in order to build up a chain. While > the erlang ssl code assumes the last certificate in the chain is the > root CA (ssl_certificate:trusted_cert_and_path). > > Maybe this is more of a feature request than a bug. But I was > wondering if it would be possible for erlang to either accept these > dodgy chains, provide an option when connecting to accept these dodgy > chains or allow users to supply a function to modify the certificate > chain before validation takes place. > > I have some code that I've been mucking around with to fix up chains > but I haven't done thorough testing of it. > > fix_path(CertChain) -> > DecodedCerts = [ {public_key:pkix_decode_cert(Cert, otp), Cert} || > Cert <- CertChain ], > [Peer | RestOfChain] = DecodedCerts, > lists:reverse(make_chain(Peer, RestOfChain, [])). > > make_chain({OtpCert, Cert}, CertChain, ResultChain) -> > case public_key:pkix_is_self_signed(OtpCert) of > true -> > [Cert | ResultChain ]; > false -> > case find_issuer(OtpCert, CertChain) of > {ok, NewCert, NewCertChain} -> > % we remove the cert that was found from the chain > % to prevent infinite loops where a chain becomes > % a loop > make_chain(NewCert, NewCertChain, [Cert | ResultChain]); > {error, issuer_not_found} -> > % assume it is the 'trusted' certificate > [Cert | ResultChain] > end > end. > > find_issuer(OtpCert, CertChain) -> > {Not, Maybe} = lists:splitwith(fun({Candidate, _}) -> > not public_key:pkix_is_issuer(OtpCert, Candidate) > end, CertChain), > > case Maybe of > [Issuer | Rest] -> > {ok, Issuer, Not ++ Rest}; > [] -> > {error, issuer_not_found} > end. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ingela.andin@REDACTED Mon Aug 11 16:59:36 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 11 Aug 2014 16:59:36 +0200 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: Message-ID: HI! 2014-08-11 16:16 GMT+02:00 Ben Murphy : > (I originally sent this to erlang-bugs but it doesn't look like it > made it there) > > We have a problem where an SSL server sends back a certificate chain > that is invalid according to the TLS 1.2 specification and erlang > rejects this chain with an unknown ca error. However, openssl and > browsers will accept this chain because they are less strict about > validation. > > The chain looks something like: > > 0. Server Cert issued by Intermediate Cert > 1. Intermediate Cert issued by Root Cert > 2. Root Cert issued by Root Cert > 3. Unrelated certificate > 4. Unrelated certificate > What server is sending such a chain? Could you give me a concrete example,maybe of list if you do not want to expose it to the world. > > Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt > > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order to > validate it in any case > > Looking at the openssl code they start at the beginning of the chain > then recursively find the issuer in order to build up a chain. While > the erlang ssl code assumes the last certificate in the chain is the > root CA (ssl_certificate:trusted_cert_and_path). > > It assumes that the last certificate is the ROOT or the certificate just before the ROOT (as the ROOT cert may be left out as you said above) and if the ROOT is left out it will try to find the ROOT in its database. If the ROOT is part of the chain it will still be looked up to make sure we already have it. Maybe this is more of a feature request than a bug. But I was > wondering if it would be possible for erlang to either accept these > dodgy chains, provide an option when connecting to accept these dodgy > chains or allow users to supply a function to modify the certificate > chain before validation takes place. > You can use the verify_fun to accept any path validation errors you want, at your own risk as you are lowering the security requirements by doing so. [...] Regards Ingela Erlang/OTP team - Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Mon Aug 11 18:00:01 2014 From: sean@REDACTED (Functional Jobs) Date: Mon, 11 Aug 2014 12:00:01 -0400 Subject: [erlang-questions] New Functional Programming Job Opportunities Message-ID: <53e8e88305cfd@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Big Data Engineer / Data Scientist at Recruit IT http://functionaljobs.com/jobs/8731-big-data-engineer-data-scientist-at-recruit-it Cheers, Sean Murphy FunctionalJobs.com From lee.sylvester@REDACTED Mon Aug 11 18:30:57 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 11 Aug 2014 17:30:57 +0100 Subject: [erlang-questions] [ANN] Iris v0.3.0 and Erlang binding v1.0.0 In-Reply-To: References: Message-ID: <418A0DE0-ABDB-4FE7-B4D2-71CAEACD2B89@gmail.com> Hi P?ter, This looks great. I have a couple of questions, though. 1. Is it possible to cluster brokers? Having a single broker would be a single point of failure. It would be better to cluster the brokers; or maybe even have one broker per physical VM. 2. What messaging protocol does this use? Thanks, Lee On 11 Aug 2014, at 14:13, P?ter Szil?gyi wrote: > Hi all, > > For a few years now I've been researching and working on a decentralized cloud messaging system called Iris. My goal with it was to bring the simplicity of cloud computing to the application layer, with the motto that if renting a batch of VMs can be done in one line of code, then assembling them into a communicating distributed system should be doable with another line. I'm proud to say, that Iris was voted as one of the most innovative open source projects related to scalability and devops, being nominated as a finalist for the dotScale prize. > > If I had to summarize the project in one sentence, it would be: "A completely decentralized messaging solution for simplifying the design and implementation of cloud services, featuring zero-configuration (i.e. start it up and it will do its magic), semantic addressing (i.e. application use textual names to address each other), clusters as units (i.e. automatic load balancing between apps of the same name) and perfect secrecy (i.e. all network traffic is encrypted)". And just to complete the above description, it is fast and language agnostic ;) > > Today marked the release of version v0.3.0 of the Iris core, and with it I'm very proud to release the first stable version of the Erlang API too, v1.0.0! The API follows the OTP design patterns, and specifically that of the gen_server, but takes it way beyond in capabilities :D Just as a teaser, this is how you can attach a micro-service instance to Iris through Erlang, which will then completely automatically integrate with other nodes and services written it arbitrary languages, and be able to communicate with them completely decentralized and completely secure! > > -behaviour(iris_server). > -export([init/2, handle_broadcast/2, handle_request/3, handle_tunnel/2, > handle_drop/2, terminate/2]). > > % Implement all the methods defined by iris_server. > init(Conn, your_init_args) -> {ok, your_state}. > terminate(Reason, State) -> ok. > > handle_broadcast(Message, State) -> {noreply, State}. > handle_request(Request, From, State) -> {reply, Request, State}. > handle_tunnel(Tunnel, State) -> {noreply, State}. > handle_drop(Reason, State) -> {stop, Reason, State}. > > main() -> > % Register a new service to the relay > {ok, Server} = iris_server:start(55555, "cluster name", ?MODULE, your_init_args), > > % Unregister the service > ok = iris_server:stop(Server). > > As you can see above, you can have broadcasts (received by *all* members of a particular micro-service cluster (the name specified during registration above), requests (load balanced between *all* members of a particular cluster), tunnels for ordered and throttled stream oriented communication between two nodes, and pub/sub (API through a different module). No networking code involved, period. > > Since seeing is believing, I invite anyone interested to look at the online Erlang playground, which is a short introductory presentation of Iris and its Erlang binding, walking over each communication primitive with modifiable and executable code segments. Should it wet your appetites, further infos can be found in the Erlang quick-start guide. Of course, the most valuable source of information is the Iris website itself, containing pre-built binaries and other language bindings on the downloads section, recordings from live presentations on the talks section (FOSDEM, dotScale), a work-in-progress guide called The book of Iris and last but not least, some research papers for the academically inclined. And if you really want to dive deep, all source code is available on GitHub (dev docs at edoc). > > Hope you like it, and if you have any questions or feedback, I'm more than happy to answer/react :) > > Cheers, > Peter > > PS: If you're interested enough, you are welcome into the Iris community at the project-iris mailing list or @iriscmf on Twitter. > _______________________________________________ > 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 Mon Aug 11 18:39:49 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 11 Aug 2014 17:39:49 +0100 Subject: [erlang-questions] [ANN] Iris v0.3.0 and Erlang binding v1.0.0 In-Reply-To: <418A0DE0-ABDB-4FE7-B4D2-71CAEACD2B89@gmail.com> References: <418A0DE0-ABDB-4FE7-B4D2-71CAEACD2B89@gmail.com> Message-ID: <27F8A628-538E-4B34-B530-FB95C5A684F3@gmail.com> I missed some questions :-) 3. ?When? a node is temporarily partitioned on the network, does it try to reconnect? If so, how often and for how long? 4. When sending a message to a cluster, how is the node selected? I?m assuming round robin. However, it would be good to be able to supply a callback for a node so that it can supply a value. This value could then be compared against its peers and the lowest value selected. For instance, I have a messaging transport cluster which can cater for a given number of clients. Currently, I ping all available nodes and they readily supply a count value of their connected peers. I can then educatedly choose the lowest value to always provide the least loaded node. This is a simple task, but one which would work well in this scenario, especially when tasks may take seconds or hours (video encoding). Cheers, Lee On 11 Aug 2014, at 17:30, Lee Sylvester wrote: > Hi P?ter, > > This looks great. I have a couple of questions, though. > > 1. Is it possible to cluster brokers? Having a single broker would be a single point of failure. It would be better to cluster the brokers; or maybe even have one broker per physical VM. > > 2. What messaging protocol does this use? > > Thanks, > Lee > > > On 11 Aug 2014, at 14:13, P?ter Szil?gyi wrote: > >> Hi all, >> >> For a few years now I've been researching and working on a decentralized cloud messaging system called Iris. My goal with it was to bring the simplicity of cloud computing to the application layer, with the motto that if renting a batch of VMs can be done in one line of code, then assembling them into a communicating distributed system should be doable with another line. I'm proud to say, that Iris was voted as one of the most innovative open source projects related to scalability and devops, being nominated as a finalist for the dotScale prize. >> >> If I had to summarize the project in one sentence, it would be: "A completely decentralized messaging solution for simplifying the design and implementation of cloud services, featuring zero-configuration (i.e. start it up and it will do its magic), semantic addressing (i.e. application use textual names to address each other), clusters as units (i.e. automatic load balancing between apps of the same name) and perfect secrecy (i.e. all network traffic is encrypted)". And just to complete the above description, it is fast and language agnostic ;) >> >> Today marked the release of version v0.3.0 of the Iris core, and with it I'm very proud to release the first stable version of the Erlang API too, v1.0.0! The API follows the OTP design patterns, and specifically that of the gen_server, but takes it way beyond in capabilities :D Just as a teaser, this is how you can attach a micro-service instance to Iris through Erlang, which will then completely automatically integrate with other nodes and services written it arbitrary languages, and be able to communicate with them completely decentralized and completely secure! >> >> -behaviour(iris_server). >> -export([init/2, handle_broadcast/2, handle_request/3, handle_tunnel/2, >> handle_drop/2, terminate/2]). >> >> % Implement all the methods defined by iris_server. >> init(Conn, your_init_args) -> {ok, your_state}. >> terminate(Reason, State) -> ok. >> >> handle_broadcast(Message, State) -> {noreply, State}. >> handle_request(Request, From, State) -> {reply, Request, State}. >> handle_tunnel(Tunnel, State) -> {noreply, State}. >> handle_drop(Reason, State) -> {stop, Reason, State}. >> >> main() -> >> % Register a new service to the relay >> {ok, Server} = iris_server:start(55555, "cluster name", ?MODULE, your_init_args), >> >> % Unregister the service >> ok = iris_server:stop(Server). >> >> As you can see above, you can have broadcasts (received by *all* members of a particular micro-service cluster (the name specified during registration above), requests (load balanced between *all* members of a particular cluster), tunnels for ordered and throttled stream oriented communication between two nodes, and pub/sub (API through a different module). No networking code involved, period. >> >> Since seeing is believing, I invite anyone interested to look at the online Erlang playground, which is a short introductory presentation of Iris and its Erlang binding, walking over each communication primitive with modifiable and executable code segments. Should it wet your appetites, further infos can be found in the Erlang quick-start guide. Of course, the most valuable source of information is the Iris website itself, containing pre-built binaries and other language bindings on the downloads section, recordings from live presentations on the talks section (FOSDEM, dotScale), a work-in-progress guide called The book of Iris and last but not least, some research papers for the academically inclined. And if you really want to dive deep, all source code is available on GitHub (dev docs at edoc). >> >> Hope you like it, and if you have any questions or feedback, I'm more than happy to answer/react :) >> >> Cheers, >> Peter >> >> PS: If you're interested enough, you are welcome into the Iris community at the project-iris mailing list or @iriscmf on Twitter. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benmmurphy@REDACTED Mon Aug 11 19:36:02 2014 From: benmmurphy@REDACTED (Ben Murphy) Date: Mon, 11 Aug 2014 18:36:02 +0100 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: Message-ID: Hi Ingela, So the real server I'm having trouble with is not public. But I have a made up server that is configured in a similar fashion. https://test.fonix.io/ I've just added an extra cert to the end of the chain. This validates correctly in chrome and with curl on the command line. https://test.fonix.io:444/ Where this is an extra cert added to the end of the chain and the order of the chain is broken. This validates correctly in chrome and with curl on the command line. I think some browsers/ssl implementations may also accept chains where the first certificate in chain is not the client certificate but nginx won't let me test this scenario :) I don't think I would be able to use verify_fun to safely ignore arbitrary extra certificates while not accepting untrusted chains. I believe I would need a whitelist of extra certificates to ignore which is problematic because things will explode when the server makes changes that they think are 'safe'. On Mon, Aug 11, 2014 at 3:59 PM, Ingela Andin wrote: > HI! > > 2014-08-11 16:16 GMT+02:00 Ben Murphy : > >> (I originally sent this to erlang-bugs but it doesn't look like it >> made it there) >> >> We have a problem where an SSL server sends back a certificate chain >> that is invalid according to the TLS 1.2 specification and erlang >> rejects this chain with an unknown ca error. However, openssl and >> browsers will accept this chain because they are less strict about >> validation. >> >> The chain looks something like: >> >> 0. Server Cert issued by Intermediate Cert >> 1. Intermediate Cert issued by Root Cert >> 2. Root Cert issued by Root Cert >> 3. Unrelated certificate >> 4. Unrelated certificate > > > > What server is sending such a chain? Could you give me a concrete > example,maybe of list if you do not want to expose > it to the world. > > > >> >> >> Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt >> >> certificate_list >> This is a sequence (chain) of certificates. The sender's >> certificate MUST come first in the list. Each following >> certificate MUST directly certify the one preceding it. Because >> certificate validation requires that root keys be distributed >> independently, the self-signed certificate that specifies the root >> certificate authority MAY be omitted from the chain, under the >> assumption that the remote end must already possess it in order to >> validate it in any case >> >> Looking at the openssl code they start at the beginning of the chain >> then recursively find the issuer in order to build up a chain. While >> the erlang ssl code assumes the last certificate in the chain is the >> root CA (ssl_certificate:trusted_cert_and_path). >> > > It assumes that the last certificate is the ROOT or the certificate just > before > the ROOT (as the ROOT cert may be left out as you said above) and if > the ROOT is left out it will try to find the ROOT in its database. If the > ROOT is part > of the chain it will still be looked up to make sure we already have it. > > >> Maybe this is more of a feature request than a bug. But I was >> wondering if it would be possible for erlang to either accept these >> dodgy chains, provide an option when connecting to accept these dodgy >> chains or allow users to supply a function to modify the certificate >> chain before validation takes place. > > > > You can use the verify_fun to accept any path validation errors you want, > at your own risk as you are lowering the security requirements by doing so. > > [...] > > > Regards Ingela Erlang/OTP team - Ericsson AB From peterke@REDACTED Mon Aug 11 20:02:17 2014 From: peterke@REDACTED (=?UTF-8?B?UMOpdGVyIFN6aWzDoWd5aQ==?=) Date: Mon, 11 Aug 2014 21:02:17 +0300 Subject: [erlang-questions] [project-iris] Re: Iris v0.3.0 out, with fresh new APIs In-Reply-To: <927bdb02-7523-4e72-adba-59bfe8451b07@googlegroups.com> References: <0cfd8342-1214-41b7-ba27-646de862c79c@googlegroups.com> <927bdb02-7523-4e72-adba-59bfe8451b07@googlegroups.com> Message-ID: Hey Lee, I'm cross replying to both the erlang-questions and the project-iris mailing list to have an answer at both sides. Just to have a complete answer to all raised questions: 1. Is it possible to cluster brokers? Having a single broker would be a single point of failure. It would be better to cluster the brokers; or maybe even have one broker per physical VM. As you probably found out, the brokers are actually local access points into the system. The routing itself is done in a decentralized way by the full collection of brokers (or relays). So, yes, Iris was meant to run one Iris node per VM, and all clients attach to that single node. But the Iris nodes in the network will form the P2P overlay itself. 2. What messaging protocol does this use? Completely custom one based on Go's gob encoding. Since Iris isn't meant to talk internally to anything else (client applications are free to do whatever they want), there is no need to standardize a protocol. This way it can evolve freely whenever needed (and it currently does so heavily since there are quite a lot of rough edges that need sorting out). 3. ?When? a node is temporarily partitioned on the network, does it try to reconnect? If so, how often and for how long? Each and every Iris node is constantly running a bootstrapping mechanism . In essence, it is based on two procedures: random address probing and local scanning. Local scanning finds nodes close by (IP wise), whereas the probing will discover clusters further away (again, IP wise). This mechanism is running constantly, even if the node is converged within the network. This ensures that in the case of partitioning and reconnecting, the network can converge quickly back into a single one. The bootstrapper will probably need some love in the future as it's still in its original state from a year ago, but you get the picture :) 4. When sending a message to a cluster, how is the node selected? [...] Actually it is neither round robin nor random. There was a minor logical flow when I designed the load balancer so it needs a bit of rework (if the nodes are 100% loaded, the balancer screws things up), but the way it works is that it is constantly measuring the CPU usage on the nodes and based on the load and the amount of requests it handled over the previous time cycle, Iris tries to approximate the processing capacity of the node (e.g. it can handle 100 "webserver" requests / sec), and based on that approximation distribute the arriving requests among the participants. This mechanism obviously only works for shorter tasks (i.e order ot 10s/100s ms), so the jury's still out of the best solution for running longer "tasks". All in all there is still a *lot* to do, but I'm hoping there is also enough to get people interested in it :) Cheers, Peter On Mon, Aug 11, 2014 at 8:39 PM, Lee Sylvester wrote: > Okay, so, for point two, the answer is "it shouldn't (and mustn't) > matter", which I would agree with. > > Point 4 is a little disappointing, though. From the source, it looks like > nodes are selected randomly. Personally, I think this is a good > opportunity for node clusters to specify their own choice of load > balancing. Since processes can be expensive and can be lengthy, choosing a > node which is otherwise under heavy load while other nodes are vacant is > not an option for resource intensive networks. On our own network, for > example, a single node may be in use for heavy resource intensive parsing > for a couple of hours at a time, while identical nodes may be parsing many > hundreds of small processes. A node will not know if it is being given a > heavy process or a light one, but it does know if it is available and it > knows the sum of its queue. > > Just a thought. > > I would still like to know about point 3 :-) > > Thanks, > Lee > > > > On Monday, 11 August 2014 17:53:20 UTC+1, Lee Sylvester wrote: >> >> Hi P?ter, >> >> This is excellent stuff. I must have missed this the first time around. >> I'm currently rebuilding a cloud infrastructure I wrote last year >> (properly this time) and I'm looking for a decent messaging system. A >> couple of years ago, I used Skynet when writing the platform in Go. At the >> time, I'd found Go to be too immature for my needs, and so migrated it to >> Erlang. It now works great, but it isn't flexible enough for my needs, >> hence the rewrite. Iris looks like a perfect fit, and exactly what I was >> looking for. >> >> To reiterate the questions I posted to the Erlang list: >> >> 1. Is it possible to cluster brokers? Having a single broker would be a >> single point of failure. It would be better to cluster the brokers; or >> maybe even have one broker per physical VM. >> >> 2. What messaging protocol does this use? >> >> 3. ?When? a node is temporarily partitioned on the network, does it try >> to reconnect? If so, how often and for how long? >> >> 4. When sending a message to a cluster, how is the node selected? I?m >> assuming round robin. However, it would be good to be able to supply a >> callback for a node so that it can supply a value. This value could then >> be compared against its peers and the lowest value selected. For instance, >> I have a messaging transport cluster which can cater for a given number of >> clients. Currently, I ping all available nodes and they readily supply a >> count value of their connected peers. I can then educatedly choose the >> lowest value to always provide the least loaded node. This is a simple >> task, but one which would work well in this scenario, especially when tasks >> may take seconds or hours (video encoding). >> >> Thanks, >> Lee >> > -- > You received this message because you are subscribed to the Google Groups > "Iris cloud messaging" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to project-iris+unsubscribe@REDACTED > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Mon Aug 11 20:48:01 2014 From: rvirding@REDACTED (Robert Virding) Date: Mon, 11 Aug 2014 11:48:01 -0700 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: Whoops, this discussion went a bit further than I thought it would. I know I like implementing languages but the original message should have been considered as one that was 4 months 8 days too late. :-) I happen to like the erlang syntax, it IS very simple and consistent and as Richard says a a big feature of Lua is the system around it and the very dynamic nature of it. Also it would never be a true Lua as that would not fit properly on top of erlang. Even apart from mutable data it does things in a very different way, for example code handling. No, for real Lua on erlang uses Luerl. But the Lua syntax is quite simple. I was just getting on the bandwagon of having another X influenced language on the BEAM. :-) Robert On 10 August 2014 17:08, wrote: > > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > > syntax instead. This would have many benefits: > > > > - It would make it much easier for a large group of programmers to get > > into > > the erlang fold. > > Where is the evidence for this? > > If Luerl didn't achieve it, why would Potion? > > > - The syntax would be simpler that elixir and would avoid some of its > > idiosyncrasies. > > > - Lua is a fun language to start with. > > Did you ever have the feeling that when you got up in the morning > you stepped into the wrong parallel universe? > I've had Lua on my Macs for years. > About once a year I stumble across it by accident while searching > for something else, and say "oh YEAH, I forgot about that, time to > put it to use." I then download the latest release, re-read the > manual, wake up, finish re-reading the manual, and when I've > stopped yawning, go and do something more enjoyable, like marking > or cleaning the bathroom. > > As far as I can see, the two virtues of Lua are > > (1) Lua the *language* is a small ho-hum language with a > small embeddable implementation that you can easily hook > into and use as an extension language. That's presumably > why LuaTeX exists. > > (2) Lua the *system* comes with things like luarocks and a > useful library of user-contributed extensions like i18n. > This is the bit I personally find attractive, or would > if I couldn't get the things I want in other languages. > > A language that is only Lua-*like* sacrifices pretty much all > of (2), which is to say sacrifices most of the reason why I > would ever consider using Lua for anything. > > Perhaps the most ho-hum aspect of Lua is its heavy dependence > on mutable state, making error handling the familiar terror it > was before Erlang. > > It might not be unfair to describe Lua as a small Javascript > done right and luarocks as npm. If the same engineering work > of making Javascript less of a dog had been put into Lua... > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.sylvester@REDACTED Mon Aug 11 23:15:24 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 11 Aug 2014 14:15:24 -0700 (PDT) Subject: [erlang-questions] [project-iris] Re: Iris v0.3.0 out, with fresh new APIs In-Reply-To: References: <0cfd8342-1214-41b7-ba27-646de862c79c@googlegroups.com> <927bdb02-7523-4e72-adba-59bfe8451b07@googlegroups.com> Message-ID: <5114a736-da9e-48bc-81a2-63113893d810@googlegroups.com> Hi P?ter, Thank you very much for your answers. I am very much interested in Iris and would like to contribute where possible. I have lots of experience with both Erlang and Go, and with messaging / cloud development in general, so I can hopefully provide a lot of support for this, whether directly or through supporting modules that help complement Iris. As I said, I've been looking for a prebuilt solution of this orientation for some time, so this is a good find for me. Kind regards, Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From wbin00@REDACTED Tue Aug 12 03:12:47 2014 From: wbin00@REDACTED (Bin Wang) Date: Tue, 12 Aug 2014 09:12:47 +0800 Subject: [erlang-questions] Does some system call block many processes? Message-ID: Hi, I know there are some system calls that will block the whole OS thread. While multi Erlang processes may running on one OS thread. So if one of the process call a block system call, will all the processes running on the same thread block? Thanks. --- Bin Wang From sean@REDACTED Tue Aug 12 03:25:57 2014 From: sean@REDACTED (Sean Cribbs) Date: Mon, 11 Aug 2014 20:25:57 -0500 Subject: [erlang-questions] Does some system call block many processes? In-Reply-To: References: Message-ID: Generally, no. The most expensive system calls (usually IO) will use kqueue, epoll, or select (the first two if you use the "+K true" flag on the command line). Other calls may use async threads so that they do not block the scheduler. What system calls are you trying to perform? On Mon, Aug 11, 2014 at 8:12 PM, Bin Wang wrote: > Hi, > > I know there are some system calls that will block the whole OS > thread. While multi Erlang processes may running on one OS thread. So > if one of the process call a block system call, will all the processes > running on the same thread block? > > Thanks. > > --- > Bin Wang > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ From wbin00@REDACTED Tue Aug 12 04:11:06 2014 From: wbin00@REDACTED (Bin Wang) Date: Tue, 12 Aug 2014 10:11:06 +0800 Subject: [erlang-questions] Does some system call block many processes? In-Reply-To: References: Message-ID: Such as database operations. Is it possible that the driver uses some IO calls that blocked the processes? 2014-08-12 9:25 GMT+08:00 Sean Cribbs : > Generally, no. The most expensive system calls (usually IO) will use > kqueue, epoll, or select (the first two if you use the "+K true" flag > on the command line). Other calls may use async threads so that they > do not block the scheduler. What system calls are you trying to > perform? > > On Mon, Aug 11, 2014 at 8:12 PM, Bin Wang wrote: >> Hi, >> >> I know there are some system calls that will block the whole OS >> thread. While multi Erlang processes may running on one OS thread. So >> if one of the process call a block system call, will all the processes >> running on the same thread block? >> >> Thanks. >> >> --- >> Bin Wang >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ From sean@REDACTED Tue Aug 12 04:54:51 2014 From: sean@REDACTED (Sean Cribbs) Date: Mon, 11 Aug 2014 21:54:51 -0500 Subject: [erlang-questions] Does some system call block many processes? In-Reply-To: References: Message-ID: What database are you referring to? If it's an external database, then it likely uses TCP sockets for communication, meaning that it will use the already non-blocking built-in inet driver. An improperly designed NIF or linked-in driver *could* block the scheduler. At Basho we have experienced this problem, and have the scars to show for it. Search the mailing list archives for "scheduler collapse" (especially the messages from Scott Fritchie) and you'll find a wealth of discussion on the matter. More recent versions of Erlang are less susceptible to this problem, thanks to interruptible BIFs and a host of other arcane scheduler tweaks I don't understand. Usually, other system problems cause Erlang nodes to be unresponsive. Is your system out of memory and using swap space? Do you have faulty disk drives? Is your network saturated? On Mon, Aug 11, 2014 at 9:11 PM, Bin Wang wrote: > Such as database operations. Is it possible that the driver uses some > IO calls that blocked the processes? > > 2014-08-12 9:25 GMT+08:00 Sean Cribbs : >> Generally, no. The most expensive system calls (usually IO) will use >> kqueue, epoll, or select (the first two if you use the "+K true" flag >> on the command line). Other calls may use async threads so that they >> do not block the scheduler. What system calls are you trying to >> perform? >> >> On Mon, Aug 11, 2014 at 8:12 PM, Bin Wang wrote: >>> Hi, >>> >>> I know there are some system calls that will block the whole OS >>> thread. While multi Erlang processes may running on one OS thread. So >>> if one of the process call a block system call, will all the processes >>> running on the same thread block? >>> >>> Thanks. >>> >>> --- >>> Bin Wang >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> Sean Cribbs >> Software Engineer >> Basho Technologies, Inc. >> http://basho.com/ -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ From rustompmody@REDACTED Tue Aug 12 07:23:08 2014 From: rustompmody@REDACTED (Rustom Mody) Date: Tue, 12 Aug 2014 10:53:08 +0530 Subject: [erlang-questions] Univs starting with Erlang Message-ID: Hi I am collecting material about univs starting programming with functional programming: http://blog.languager.org/2014/08/universities-starting-functional.html Erlang figures but only in 2nd/'advanced' courses. Are there any cases where Erlang is used to start teaching programming? Thanks Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson@REDACTED Tue Aug 12 07:59:37 2014 From: s.j.thompson@REDACTED (Simon Thompson) Date: Tue, 12 Aug 2014 06:59:37 +0100 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> We're teaching Erlang to our second year students in a course entitled "functional and concurrent programming". Erlang is the base language here, but we also introduce - briefly - other approaches to functional and concurrent programming. Simon On 12 Aug 2014, at 06:23, Rustom Mody wrote: > Hi > I am collecting material about univs starting programming with functional programming: > http://blog.languager.org/2014/08/universities-starting-functional.html > > Erlang figures but only in 2nd/'advanced' courses. > Are there any cases where Erlang is used to start teaching programming? > > Thanks > Rusi > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Tue Aug 12 08:20:30 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Tue, 12 Aug 2014 08:20:30 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> Message-ID: Uppsala Universitys computer science program teaches Earlang in a couple of courses during the second or third year. First year is dedicated to math and functional programming in SML (or atleast was when I attended). On Tue, Aug 12, 2014 at 7:59 AM, Simon Thompson wrote: > We're teaching Erlang to our second year students in a course entitled > "functional and concurrent programming". Erlang is the base language here, > but we also introduce - briefly - other approaches to functional and > concurrent programming. > > Simon > > > On 12 Aug 2014, at 06:23, Rustom Mody wrote: > > Hi > I am collecting material about univs starting programming with functional > programming: > http://blog.languager.org/2014/08/universities-starting-functional.html > > Erlang figures but only in 2nd/'advanced' courses. > Are there any cases where Erlang is used to start teaching programming? > > Thanks > Rusi > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > 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 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Tue Aug 12 09:23:05 2014 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Tue, 12 Aug 2014 09:23:05 +0200 Subject: [erlang-questions] List vs Group In-Reply-To: <20140807073836.GA3282@erix.ericsson.se> References: <20140807073836.GA3282@erix.ericsson.se> Message-ID: <20140812072305.GA22448@erix.ericsson.se> On Thu, Aug 07, 2014 at 09:38:36AM +0200, Raimo Niskanen wrote: > Hi all. > > We are thinking about not allowing members of the Google group > Erlang Programming to post to the group. Done. Google group users now have to be subscribed to the list and post to the list. The group is just a mirror. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From aschultz@REDACTED Tue Aug 12 10:40:25 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 12 Aug 2014 08:40:25 +0000 (UTC) Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: Message-ID: <1151586104.11805.1407832825589.JavaMail.zimbra@tpip.net> Hi Ben, ----- Original Message ----- > Hi Ingela, > > So the real server I'm having trouble with is not public. But I have a > made up server that is configured in a similar fashion. > > https://test.fonix.io/ > > I've just added an extra cert to the end of the chain. This validates > correctly in chrome and with curl on the command line. > > https://test.fonix.io:444/ > > Where this is an extra cert added to the end of the chain and the > order of the chain is broken. This validates correctly in chrome and > with curl on the command line. > > I think some browsers/ssl implementations may also accept chains where > the first certificate in chain is not the client certificate but nginx > won't let me test this scenario :) That would violate the standard. from RFC 2246 (TLS 1.0), Section 7.4.2: certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. RFC 5246 (TLS 1.2) adds this: The following rules apply to the certificates sent by the server: - The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]). - The end entity certificate's public key (and associated restrictions) MUST be compatible with the selected key exchange algorithm. So the ordering is strict, no unrelated certificates are permitted within the chain. This wording leaves it open whether a unrelated certificated is permitted at the end of the chain. However, I would rather choose the stricter interpretation and consider any unrelated certificate an error. The certificates on your server port 443 are: 0 s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca Digital Ltd/OU=IT/CN=*.fonix.io i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA The chain for Number 0, 1 and 2 seems to be ok. However the Number 3 certificate is obsolete and IMHO an error. The certificates on your server port 444 are: Certificate chain 0 s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca Digital Ltd/OU=IT/CN=*.fonix.io i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 2 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA So, Number 0 is ok, Number 1 is not the issuer of Number 0, so this IS invalid, Number 2 is the issuer of Number 0, and Number 3 is unrelated to any of them. To summarize: I believe Erlang is correct rejecting those certificate chains and Chrome and wget (or probably really OpenSSL) need to be fixed to properly reject those. Andreas > > I don't think I would be able to use verify_fun to safely ignore > arbitrary extra certificates while not accepting untrusted chains. I > believe I would need a whitelist of extra certificates to ignore which > is problematic because things will explode when the server makes > changes that they think are 'safe'. > > On Mon, Aug 11, 2014 at 3:59 PM, Ingela Andin wrote: > > HI! > > > > 2014-08-11 16:16 GMT+02:00 Ben Murphy : > > > >> (I originally sent this to erlang-bugs but it doesn't look like it > >> made it there) > >> > >> We have a problem where an SSL server sends back a certificate chain > >> that is invalid according to the TLS 1.2 specification and erlang > >> rejects this chain with an unknown ca error. However, openssl and > >> browsers will accept this chain because they are less strict about > >> validation. > >> > >> The chain looks something like: > >> > >> 0. Server Cert issued by Intermediate Cert > >> 1. Intermediate Cert issued by Root Cert > >> 2. Root Cert issued by Root Cert > >> 3. Unrelated certificate > >> 4. Unrelated certificate > > > > > > > > What server is sending such a chain? Could you give me a concrete > > example,maybe of list if you do not want to expose > > it to the world. > > > > > > > >> > >> > >> Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt > >> > >> certificate_list > >> This is a sequence (chain) of certificates. The sender's > >> certificate MUST come first in the list. Each following > >> certificate MUST directly certify the one preceding it. Because > >> certificate validation requires that root keys be distributed > >> independently, the self-signed certificate that specifies the root > >> certificate authority MAY be omitted from the chain, under the > >> assumption that the remote end must already possess it in order to > >> validate it in any case > >> > >> Looking at the openssl code they start at the beginning of the chain > >> then recursively find the issuer in order to build up a chain. While > >> the erlang ssl code assumes the last certificate in the chain is the > >> root CA (ssl_certificate:trusted_cert_and_path). > >> > > > > It assumes that the last certificate is the ROOT or the certificate just > > before > > the ROOT (as the ROOT cert may be left out as you said above) and if > > the ROOT is left out it will try to find the ROOT in its database. If the > > ROOT is part > > of the chain it will still be looked up to make sure we already have it. > > > > > >> Maybe this is more of a feature request than a bug. But I was > >> wondering if it would be possible for erlang to either accept these > >> dodgy chains, provide an option when connecting to accept these dodgy > >> chains or allow users to supply a function to modify the certificate > >> chain before validation takes place. > > > > > > > > You can use the verify_fun to accept any path validation errors you want, > > at your own risk as you are lowering the security requirements by doing so. > > > > [...] > > > > > > Regards Ingela Erlang/OTP team - Ericsson AB > _______________________________________________ > 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 benmmurphy@REDACTED Tue Aug 12 12:01:11 2014 From: benmmurphy@REDACTED (Ben Murphy) Date: Tue, 12 Aug 2014 11:01:11 +0100 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: <1151586104.11805.1407832825589.JavaMail.zimbra@tpip.net> References: <1151586104.11805.1407832825589.JavaMail.zimbra@tpip.net> Message-ID: I agree that these chains break the spec. The problem is almost everyone accepts these chains. So if you don't accept these chains then you are going to run into compatibility issues. I've tested safari/firefox/chrome/openssl/golang/java and all these implementations accept these chains. If you look at the implementations this is a deliberately coded feature: http://golang.org/src/pkg/crypto/x509/verify.go func (c *Certificate) Verify(opts VerifyOptions) (chains [][]*Certificate, err error) { I think most implementations treat the first certificate as the clients certificate and the rest of the certificates as possible intermediaries between the clients certificate and a trusted certificate and try to build a chain based on that. On Tue, Aug 12, 2014 at 9:40 AM, Andreas Schultz wrote: > Hi Ben, > > ----- Original Message ----- >> Hi Ingela, >> >> So the real server I'm having trouble with is not public. But I have a >> made up server that is configured in a similar fashion. >> >> https://test.fonix.io/ >> >> I've just added an extra cert to the end of the chain. This validates >> correctly in chrome and with curl on the command line. >> >> https://test.fonix.io:444/ >> >> Where this is an extra cert added to the end of the chain and the >> order of the chain is broken. This validates correctly in chrome and >> with curl on the command line. >> >> I think some browsers/ssl implementations may also accept chains where >> the first certificate in chain is not the client certificate but nginx >> won't let me test this scenario :) > > That would violate the standard. from RFC 2246 (TLS 1.0), Section 7.4.2: > > certificate_list > This is a sequence (chain) of X.509v3 certificates. The sender's > certificate must come first in the list. Each following > certificate must directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate which specifies the > root certificate authority may optionally be omitted from the > chain, under the assumption that the remote end must already > possess it in order to validate it in any case. > > RFC 5246 (TLS 1.2) adds this: > > The following rules apply to the certificates sent by the server: > > - The certificate type MUST be X.509v3, unless explicitly negotiated > otherwise (e.g., [TLSPGP]). > > - The end entity certificate's public key (and associated > restrictions) MUST be compatible with the selected key exchange > algorithm. > > So the ordering is strict, no unrelated certificates are permitted > within the chain. This wording leaves it open whether a unrelated > certificated is permitted at the end of the chain. However, I would > rather choose the stricter interpretation and consider any unrelated > certificate an error. > > The certificates on your server port 443 are: > > 0 s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca Digital Ltd/OU=IT/CN=*.fonix.io > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > The chain for Number 0, 1 and 2 seems to be ok. However the Number 3 > certificate is obsolete and IMHO an error. > > > The certificates on your server port 444 are: > > Certificate chain > 0 s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca Digital Ltd/OU=IT/CN=*.fonix.io > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > 2 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > So, Number 0 is ok, Number 1 is not the issuer of Number 0, so this IS > invalid, Number 2 is the issuer of Number 0, and Number 3 is unrelated > to any of them. > > To summarize: > > I believe Erlang is correct rejecting those certificate chains and > Chrome and wget (or probably really OpenSSL) need to be fixed to > properly reject those. > > Andreas > >> >> I don't think I would be able to use verify_fun to safely ignore >> arbitrary extra certificates while not accepting untrusted chains. I >> believe I would need a whitelist of extra certificates to ignore which >> is problematic because things will explode when the server makes >> changes that they think are 'safe'. >> >> On Mon, Aug 11, 2014 at 3:59 PM, Ingela Andin wrote: >> > HI! >> > >> > 2014-08-11 16:16 GMT+02:00 Ben Murphy : >> > >> >> (I originally sent this to erlang-bugs but it doesn't look like it >> >> made it there) >> >> >> >> We have a problem where an SSL server sends back a certificate chain >> >> that is invalid according to the TLS 1.2 specification and erlang >> >> rejects this chain with an unknown ca error. However, openssl and >> >> browsers will accept this chain because they are less strict about >> >> validation. >> >> >> >> The chain looks something like: >> >> >> >> 0. Server Cert issued by Intermediate Cert >> >> 1. Intermediate Cert issued by Root Cert >> >> 2. Root Cert issued by Root Cert >> >> 3. Unrelated certificate >> >> 4. Unrelated certificate >> > >> > >> > >> > What server is sending such a chain? Could you give me a concrete >> > example,maybe of list if you do not want to expose >> > it to the world. >> > >> > >> > >> >> >> >> >> >> Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt >> >> >> >> certificate_list >> >> This is a sequence (chain) of certificates. The sender's >> >> certificate MUST come first in the list. Each following >> >> certificate MUST directly certify the one preceding it. Because >> >> certificate validation requires that root keys be distributed >> >> independently, the self-signed certificate that specifies the root >> >> certificate authority MAY be omitted from the chain, under the >> >> assumption that the remote end must already possess it in order to >> >> validate it in any case >> >> >> >> Looking at the openssl code they start at the beginning of the chain >> >> then recursively find the issuer in order to build up a chain. While >> >> the erlang ssl code assumes the last certificate in the chain is the >> >> root CA (ssl_certificate:trusted_cert_and_path). >> >> >> > >> > It assumes that the last certificate is the ROOT or the certificate just >> > before >> > the ROOT (as the ROOT cert may be left out as you said above) and if >> > the ROOT is left out it will try to find the ROOT in its database. If the >> > ROOT is part >> > of the chain it will still be looked up to make sure we already have it. >> > >> > >> >> Maybe this is more of a feature request than a bug. But I was >> >> wondering if it would be possible for erlang to either accept these >> >> dodgy chains, provide an option when connecting to accept these dodgy >> >> chains or allow users to supply a function to modify the certificate >> >> chain before validation takes place. >> > >> > >> > >> > You can use the verify_fun to accept any path validation errors you want, >> > at your own risk as you are lowering the security requirements by doing so. >> > >> > [...] >> > >> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >> _______________________________________________ >> 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 erlangerintraining@REDACTED Tue Aug 12 17:58:55 2014 From: erlangerintraining@REDACTED (Kristoffer Brown) Date: Tue, 12 Aug 2014 09:58:55 -0600 Subject: [erlang-questions] How is the mnesia cookie created? Message-ID: I've run into many different scenarios where I have received mnesia "bad cookie" errors. Some make sense from my limited knowledge of mnesia. Some don't. So, I was hoping somebody could help me determine what the cookie contains. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Tue Aug 12 20:21:19 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 12 Aug 2014 20:21:19 +0200 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: <1151586104.11805.1407832825589.JavaMail.zimbra@tpip.net> Message-ID: Hi! 2014-08-12 12:01 GMT+02:00 Ben Murphy : > I agree that these chains break the spec. The problem is almost > everyone accepts these chains. So if you don't accept these chains > then you are going to run into compatibility issues. I've tested > safari/firefox/chrome/openssl/golang/java and all these > implementations accept these chains. > > If you look at the implementations this is a deliberately coded feature: > > http://golang.org/src/pkg/crypto/x509/verify.go > func (c *Certificate) Verify(opts VerifyOptions) (chains > [][]*Certificate, err error) { > > I think most implementations treat the first certificate as the > clients certificate and the rest of the certificates as possible > intermediaries between the clients certificate and a trusted > certificate and try to build a chain based on that. > > > Just because many people got it wrong does not make it right. If you want to interop with implementations that do not follow the spec, you can do it with help of the verify fun. It might not be a compelling solution and it might give some performance penalty, but it is doable. We do not desire to be bug-compatible with other implementations and make compromises that also might compromise with security. Regards Ingela Erlang/OTP team - Ericsson AB > On Tue, Aug 12, 2014 at 9:40 AM, Andreas Schultz > wrote: > > Hi Ben, > > > > ----- Original Message ----- > >> Hi Ingela, > >> > >> So the real server I'm having trouble with is not public. But I have a > >> made up server that is configured in a similar fashion. > >> > >> https://test.fonix.io/ > >> > >> I've just added an extra cert to the end of the chain. This validates > >> correctly in chrome and with curl on the command line. > >> > >> https://test.fonix.io:444/ > >> > >> Where this is an extra cert added to the end of the chain and the > >> order of the chain is broken. This validates correctly in chrome and > >> with curl on the command line. > >> > >> I think some browsers/ssl implementations may also accept chains where > >> the first certificate in chain is not the client certificate but nginx > >> won't let me test this scenario :) > > > > That would violate the standard. from RFC 2246 (TLS 1.0), Section 7.4.2: > > > > certificate_list > > This is a sequence (chain) of X.509v3 certificates. The sender's > > certificate must come first in the list. Each following > > certificate must directly certify the one preceding it. Because > > certificate validation requires that root keys be distributed > > independently, the self-signed certificate which specifies the > > root certificate authority may optionally be omitted from the > > chain, under the assumption that the remote end must already > > possess it in order to validate it in any case. > > > > RFC 5246 (TLS 1.2) adds this: > > > > The following rules apply to the certificates sent by the server: > > > > - The certificate type MUST be X.509v3, unless explicitly negotiated > > otherwise (e.g., [TLSPGP]). > > > > - The end entity certificate's public key (and associated > > restrictions) MUST be compatible with the selected key exchange > > algorithm. > > > > So the ordering is strict, no unrelated certificates are permitted > > within the chain. This wording leaves it open whether a unrelated > > certificated is permitted at the end of the chain. However, I would > > rather choose the stricter interpretation and consider any unrelated > > certificate an error. > > > > The certificates on your server port 443 are: > > > > 0 > s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca > Digital Ltd/OU=IT/CN=*.fonix.io > > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > > 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > > > The chain for Number 0, 1 and 2 seems to be ok. However the Number 3 > > certificate is obsolete and IMHO an error. > > > > > > The certificates on your server port 444 are: > > > > Certificate chain > > 0 > s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca > Digital Ltd/OU=IT/CN=*.fonix.io > > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > > 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > > 2 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA > > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 > > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA > > > > So, Number 0 is ok, Number 1 is not the issuer of Number 0, so this IS > > invalid, Number 2 is the issuer of Number 0, and Number 3 is unrelated > > to any of them. > > > > To summarize: > > > > I believe Erlang is correct rejecting those certificate chains and > > Chrome and wget (or probably really OpenSSL) need to be fixed to > > properly reject those. > > > > Andreas > > > >> > >> I don't think I would be able to use verify_fun to safely ignore > >> arbitrary extra certificates while not accepting untrusted chains. I > >> believe I would need a whitelist of extra certificates to ignore which > >> is problematic because things will explode when the server makes > >> changes that they think are 'safe'. > >> > >> On Mon, Aug 11, 2014 at 3:59 PM, Ingela Andin > wrote: > >> > HI! > >> > > >> > 2014-08-11 16:16 GMT+02:00 Ben Murphy : > >> > > >> >> (I originally sent this to erlang-bugs but it doesn't look like it > >> >> made it there) > >> >> > >> >> We have a problem where an SSL server sends back a certificate chain > >> >> that is invalid according to the TLS 1.2 specification and erlang > >> >> rejects this chain with an unknown ca error. However, openssl and > >> >> browsers will accept this chain because they are less strict about > >> >> validation. > >> >> > >> >> The chain looks something like: > >> >> > >> >> 0. Server Cert issued by Intermediate Cert > >> >> 1. Intermediate Cert issued by Root Cert > >> >> 2. Root Cert issued by Root Cert > >> >> 3. Unrelated certificate > >> >> 4. Unrelated certificate > >> > > >> > > >> > > >> > What server is sending such a chain? Could you give me a concrete > >> > example,maybe of list if you do not want to expose > >> > it to the world. > >> > > >> > > >> > > >> >> > >> >> > >> >> Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt > >> >> > >> >> certificate_list > >> >> This is a sequence (chain) of certificates. The sender's > >> >> certificate MUST come first in the list. Each following > >> >> certificate MUST directly certify the one preceding it. > Because > >> >> certificate validation requires that root keys be distributed > >> >> independently, the self-signed certificate that specifies the > root > >> >> certificate authority MAY be omitted from the chain, under the > >> >> assumption that the remote end must already possess it in > order to > >> >> validate it in any case > >> >> > >> >> Looking at the openssl code they start at the beginning of the chain > >> >> then recursively find the issuer in order to build up a chain. While > >> >> the erlang ssl code assumes the last certificate in the chain is the > >> >> root CA (ssl_certificate:trusted_cert_and_path). > >> >> > >> > > >> > It assumes that the last certificate is the ROOT or the certificate > just > >> > before > >> > the ROOT (as the ROOT cert may be left out as you said above) and if > >> > the ROOT is left out it will try to find the ROOT in its database. If > the > >> > ROOT is part > >> > of the chain it will still be looked up to make sure we already have > it. > >> > > >> > > >> >> Maybe this is more of a feature request than a bug. But I was > >> >> wondering if it would be possible for erlang to either accept these > >> >> dodgy chains, provide an option when connecting to accept these dodgy > >> >> chains or allow users to supply a function to modify the certificate > >> >> chain before validation takes place. > >> > > >> > > >> > > >> > You can use the verify_fun to accept any path validation errors you > want, > >> > at your own risk as you are lowering the security requirements by > doing so. > >> > > >> > [...] > >> > > >> > > >> > Regards Ingela Erlang/OTP team - Ericsson AB > >> _______________________________________________ > >> 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 > > -------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Tue Aug 12 20:22:34 2014 From: moxford@REDACTED (Mike Oxford) Date: Tue, 12 Aug 2014 11:22:34 -0700 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: <53E8CDC4.7090100@wanadoo.fr> References: <53E8760C.3050303@ninenines.eu> <53E8CDC4.7090100@wanadoo.fr> Message-ID: Thanks everyone. It's a small temporary app on a closed network with trusted clients. If you notice I'm not even fully protecting against SQL injection; no octals or whatnot are checked ... it's literally just for a few characters which people may type in (like O'Grady). Didn't know the internals of the MySQL protocol - I've just been using emysql and it seems to work fairly well. I've not done much postgres, but while it's always had a good reputation it never seemed to be quite as .... dynamic ... as the MySQL development process. I've been using MySQL, well, forever but I'm open to exploring postgres again after this project Which postgres clients (erlang) are considered solid and what's the consensus on their clustering compared to Galera/Percona? Thanks! On Mon, Aug 11, 2014 at 7:05 AM, PAILLEAU Eric wrote: > I agree . > > Note, what I like in Postgresql on contrary of Mysql, is the dollar > quoting. > > In addition to usual SQL injection protections on data input, > you can also use dynamic dollar quoting, to make more complexe SQL > injection attempts : > > UPDATE users set password=$4896$new password hash$4896$ WHERE id=12345 ; > > 4896 is for instance the PID of the forked Apache process, or anything > else with more entropy. > > The attacker can't guess this ID and injection is much much more complex... > > > Le 11/08/2014 09:51, Lo?c Hoguin a ?crit : > > On 08/11/2014 06:02 AM, Mike Oxford wrote: >> >>> I need to so some input sanitizing for use against MySQL. >>> >> >> Are you saying you are going to take this data and put it inside a query >> string? This isn't going to protect anything, escaping doesn't prevent >> SQL injection. Why not use a prepared statement instead? This makes the >> data separate from the query, you don't need to do any escaping and >> MySQL takes care of everything for you. Also make sure you are using the >> *binary* protocol, not the *text* one, and you're pretty much set. >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody@REDACTED Tue Aug 12 20:48:01 2014 From: rustompmody@REDACTED (Rustom Mody) Date: Wed, 13 Aug 2014 00:18:01 +0530 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> Message-ID: On Tue, Aug 12, 2014 at 11:29 AM, Simon Thompson wrote: > We're teaching Erlang to our second year students in a course entitled > "functional and concurrent programming". Erlang is the base language here, > but we also introduce - briefly - other approaches to functional and > concurrent programming. > > Simon > Hi Simon (and Frederik) After some time battling google I found http://www.kent.ac.uk/courses/modulecatalogue/modules/CO523 which seems to mention some topics in FP some in OOP... And no language!! So thanks your info is interesting to me personally but until I have links its not really usable in a public setting Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Tue Aug 12 22:13:35 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 12 Aug 2014 22:13:35 +0200 Subject: [erlang-questions] Of regexes and REs, and other irritating things... In-Reply-To: References: <53E8760C.3050303@ninenines.eu> <53E8CDC4.7090100@wanadoo.fr> Message-ID: <53EA756F.9090106@wanadoo.fr> Hi, https://github.com/epgsql/epgsql is well known. I know that Zotonic Erlang CMS use it, for instance. (sorry a bit off topic for this list) Yes, Postgresql native clustering was a long childbirth, while MySql had it a long time before. 9.x releases allow this. Development process at Postgres is always a bit long , but like Debian, stability is the key word. You can have a look to : http://www.repmgr.org/ https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling I can't give you any My/Post clustering comparisons, it is a long time I did not used Mysql. But maybe other can. Le 12/08/2014 20:22, Mike Oxford a ?crit : > Thanks everyone. It's a small temporary app on a closed network with > trusted clients. If you notice I'm not even fully protecting against > SQL injection; no octals or whatnot are checked ... it's literally just > for a few characters which people may type in (like O'Grady). > > Didn't know the internals of the MySQL protocol - I've just been using > emysql and it seems to work fairly well. I've not done much postgres, > but while it's always had a good reputation it never seemed to be quite > as .... dynamic ... as the MySQL development process. I've been using > MySQL, well, forever but I'm open to exploring postgres again after this > project > > Which postgres clients (erlang) are considered solid and what's the > consensus on their clustering compared to Galera/Percona? > > Thanks! > > > > > On Mon, Aug 11, 2014 at 7:05 AM, PAILLEAU Eric > wrote: > > I agree . > > Note, what I like in Postgresql on contrary of Mysql, is the dollar > quoting. > > In addition to usual SQL injection protections on data input, > you can also use dynamic dollar quoting, to make more complexe SQL > injection attempts : > > UPDATE users set password=$4896$new password hash$4896$ WHERE id=12345 ; > > 4896 is for instance the PID of the forked Apache process, or > anything else with more entropy. > > The attacker can't guess this ID and injection is much much more > complex... > > > Le 11/08/2014 09:51, Lo?c Hoguin a ?crit : > > On 08/11/2014 06:02 AM, Mike Oxford wrote: > > I need to so some input sanitizing for use against MySQL. > > > Are you saying you are going to take this data and put it inside > a query > string? This isn't going to protect anything, escaping doesn't > prevent > SQL injection. Why not use a prepared statement instead? This > makes the > data separate from the query, you don't need to do any escaping and > MySQL takes care of everything for you. Also make sure you are > using the > *binary* protocol, not the *text* one, and you're pretty much set. > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > From benmmurphy@REDACTED Tue Aug 12 22:24:15 2014 From: benmmurphy@REDACTED (Ben Murphy) Date: Tue, 12 Aug 2014 21:24:15 +0100 Subject: [erlang-questions] Erlang SSL and Invalid Certificate Chains In-Reply-To: References: <1151586104.11805.1407832825589.JavaMail.zimbra@tpip.net> Message-ID: Cheers, Do you know how I would go about writing the verify function? It looks like it is called for every certificate in the chain from the last certificate to the first certificate and I can either fail or pass at each step. If I could know which cert was the 'first' one then I could just succeed every certificate and then rebuild the chain when I reach the first certificate and return pass or fail depending on whether i thought it was valid. But it doesn't look like the verify function has any concept of where it is in the chain relative to the first certificate. I suspect the only safe way of doing it will be to always return success in the verify function and build up the cert chain in ets (or somewhere else) then after the ssl handshake is completed manually validate the certificate chain. On Tue, Aug 12, 2014 at 7:21 PM, Ingela Andin wrote: > Hi! > > 2014-08-12 12:01 GMT+02:00 Ben Murphy : > >> I agree that these chains break the spec. The problem is almost >> everyone accepts these chains. So if you don't accept these chains >> then you are going to run into compatibility issues. I've tested >> safari/firefox/chrome/openssl/golang/java and all these >> implementations accept these chains. >> >> If you look at the implementations this is a deliberately coded feature: >> >> http://golang.org/src/pkg/crypto/x509/verify.go >> func (c *Certificate) Verify(opts VerifyOptions) (chains >> [][]*Certificate, err error) { >> >> I think most implementations treat the first certificate as the >> clients certificate and the rest of the certificates as possible >> intermediaries between the clients certificate and a trusted >> certificate and try to build a chain based on that. >> >> > > Just because many people got it wrong does not make it right. > If you want to interop with implementations that do not follow the spec, you > can do it with > help of the verify fun. It might not be a compelling solution and it might > give some performance penalty, > but it is doable. We do not desire to be bug-compatible with other > implementations and make compromises that > also might compromise with security. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > >> >> On Tue, Aug 12, 2014 at 9:40 AM, Andreas Schultz >> wrote: >> > Hi Ben, >> > >> > ----- Original Message ----- >> >> Hi Ingela, >> >> >> >> So the real server I'm having trouble with is not public. But I have a >> >> made up server that is configured in a similar fashion. >> >> >> >> https://test.fonix.io/ >> >> >> >> I've just added an extra cert to the end of the chain. This validates >> >> correctly in chrome and with curl on the command line. >> >> >> >> https://test.fonix.io:444/ >> >> >> >> Where this is an extra cert added to the end of the chain and the >> >> order of the chain is broken. This validates correctly in chrome and >> >> with curl on the command line. >> >> >> >> I think some browsers/ssl implementations may also accept chains where >> >> the first certificate in chain is not the client certificate but nginx >> >> won't let me test this scenario :) >> > >> > That would violate the standard. from RFC 2246 (TLS 1.0), Section 7.4.2: >> > >> > certificate_list >> > This is a sequence (chain) of X.509v3 certificates. The sender's >> > certificate must come first in the list. Each following >> > certificate must directly certify the one preceding it. Because >> > certificate validation requires that root keys be distributed >> > independently, the self-signed certificate which specifies the >> > root certificate authority may optionally be omitted from the >> > chain, under the assumption that the remote end must already >> > possess it in order to validate it in any case. >> > >> > RFC 5246 (TLS 1.2) adds this: >> > >> > The following rules apply to the certificates sent by the server: >> > >> > - The certificate type MUST be X.509v3, unless explicitly negotiated >> > otherwise (e.g., [TLSPGP]). >> > >> > - The end entity certificate's public key (and associated >> > restrictions) MUST be compatible with the selected key exchange >> > algorithm. >> > >> > So the ordering is strict, no unrelated certificates are permitted >> > within the chain. This wording leaves it open whether a unrelated >> > certificated is permitted at the end of the chain. However, I would >> > rather choose the stricter interpretation and consider any unrelated >> > certificate an error. >> > >> > The certificates on your server port 443 are: >> > >> > 0 >> > s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca >> > Digital Ltd/OU=IT/CN=*.fonix.io >> > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> > 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority >> > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 >> > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > >> > The chain for Number 0, 1 and 2 seems to be ok. However the Number 3 >> > certificate is obsolete and IMHO an error. >> > >> > >> > The certificates on your server port 444 are: >> > >> > Certificate chain >> > 0 >> > s:/serialNumber=oVMlbmYif-Pcg7kbO6LFKlAd0LjtU6Uw/C=GB/ST=London/L=London/O=Orca >> > Digital Ltd/OU=IT/CN=*.fonix.io >> > i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> > 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority >> > 2 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > 3 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 >> > i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> > >> > So, Number 0 is ok, Number 1 is not the issuer of Number 0, so this IS >> > invalid, Number 2 is the issuer of Number 0, and Number 3 is unrelated >> > to any of them. >> > >> > To summarize: >> > >> > I believe Erlang is correct rejecting those certificate chains and >> > Chrome and wget (or probably really OpenSSL) need to be fixed to >> > properly reject those. >> > >> > Andreas >> > >> >> >> >> I don't think I would be able to use verify_fun to safely ignore >> >> arbitrary extra certificates while not accepting untrusted chains. I >> >> believe I would need a whitelist of extra certificates to ignore which >> >> is problematic because things will explode when the server makes >> >> changes that they think are 'safe'. >> >> >> >> On Mon, Aug 11, 2014 at 3:59 PM, Ingela Andin >> >> wrote: >> >> > HI! >> >> > >> >> > 2014-08-11 16:16 GMT+02:00 Ben Murphy : >> >> > >> >> >> (I originally sent this to erlang-bugs but it doesn't look like it >> >> >> made it there) >> >> >> >> >> >> We have a problem where an SSL server sends back a certificate chain >> >> >> that is invalid according to the TLS 1.2 specification and erlang >> >> >> rejects this chain with an unknown ca error. However, openssl and >> >> >> browsers will accept this chain because they are less strict about >> >> >> validation. >> >> >> >> >> >> The chain looks something like: >> >> >> >> >> >> 0. Server Cert issued by Intermediate Cert >> >> >> 1. Intermediate Cert issued by Root Cert >> >> >> 2. Root Cert issued by Root Cert >> >> >> 3. Unrelated certificate >> >> >> 4. Unrelated certificate >> >> > >> >> > >> >> > >> >> > What server is sending such a chain? Could you give me a concrete >> >> > example,maybe of list if you do not want to expose >> >> > it to the world. >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> >> Which is invalid according to: http://www.ietf.org/rfc/rfc5246.txt >> >> >> >> >> >> certificate_list >> >> >> This is a sequence (chain) of certificates. The sender's >> >> >> certificate MUST come first in the list. Each following >> >> >> certificate MUST directly certify the one preceding it. >> >> >> Because >> >> >> certificate validation requires that root keys be distributed >> >> >> independently, the self-signed certificate that specifies the >> >> >> root >> >> >> certificate authority MAY be omitted from the chain, under the >> >> >> assumption that the remote end must already possess it in >> >> >> order to >> >> >> validate it in any case >> >> >> >> >> >> Looking at the openssl code they start at the beginning of the chain >> >> >> then recursively find the issuer in order to build up a chain. While >> >> >> the erlang ssl code assumes the last certificate in the chain is the >> >> >> root CA (ssl_certificate:trusted_cert_and_path). >> >> >> >> >> > >> >> > It assumes that the last certificate is the ROOT or the certificate >> >> > just >> >> > before >> >> > the ROOT (as the ROOT cert may be left out as you said above) and if >> >> > the ROOT is left out it will try to find the ROOT in its database. If >> >> > the >> >> > ROOT is part >> >> > of the chain it will still be looked up to make sure we already have >> >> > it. >> >> > >> >> > >> >> >> Maybe this is more of a feature request than a bug. But I was >> >> >> wondering if it would be possible for erlang to either accept these >> >> >> dodgy chains, provide an option when connecting to accept these >> >> >> dodgy >> >> >> chains or allow users to supply a function to modify the certificate >> >> >> chain before validation takes place. >> >> > >> >> > >> >> > >> >> > You can use the verify_fun to accept any path validation errors you >> >> > want, >> >> > at your own risk as you are lowering the security requirements by >> >> > doing so. >> >> > >> >> > [...] >> >> > >> >> > >> >> > Regards Ingela Erlang/OTP team - Ericsson AB >> >> _______________________________________________ >> >> 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 max.lapshin@REDACTED Tue Aug 12 22:24:21 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 13 Aug 2014 00:24:21 +0400 Subject: [erlang-questions] [ANN] NkSIP v0.4.0 In-Reply-To: <068F9B90-D080-454C-94C6-3A677431070C@gmail.com> References: <068F9B90-D080-454C-94C6-3A677431070C@gmail.com> Message-ID: Antoine, are you working with webrtc? On Sat, Aug 9, 2014 at 1:20 PM, Antoine Koener wrote: > Or help on webrtc stuff ? > > > On 09 Aug 2014, at 11:13, Max Lapshin wrote: > > > > Carlos! > > > > It is a really amazing work! Your code just works. Do you need help > with adding RTP stuff? > > I'll try to use your code to implement rtmp - sip bridge. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hm@REDACTED Wed Aug 13 09:19:43 2014 From: hm@REDACTED (=?UTF-8?Q?H=C3=A5kan_Mattsson?=) Date: Wed, 13 Aug 2014 09:19:43 +0200 Subject: [erlang-questions] How is the mnesia cookie created? In-Reply-To: References: Message-ID: The cookie is created when the schema (database) is created. The purpose of the cookie is to prevent mixing different databases. /H?kan On Tue, Aug 12, 2014 at 5:58 PM, Kristoffer Brown < erlangerintraining@REDACTED> wrote: > I've run into many different scenarios where I have received mnesia "bad > cookie" errors. Some make sense from my limited knowledge of mnesia. Some > don't. > > So, I was hoping somebody could help me determine what the cookie contains. > > Thanks in advance. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Wed Aug 13 08:13:37 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Wed, 13 Aug 2014 08:13:37 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> Message-ID: Hi Rustomomom (yeah I can't read and spell names either..) I don't think you will find a course description in most serious computer science programs that mentions the languages being used as the main focus of a computer science program it to teach the theory and not how to use the tools (languages are tools not theories). I know for a fact that most course descriptions for Uppsala University does not mention the languages as that would lock the course to forcing students and instructors to use that language. PS: No offence about the name thing. On Tue, Aug 12, 2014 at 8:48 PM, Rustom Mody wrote: > > > > On Tue, Aug 12, 2014 at 11:29 AM, Simon Thompson > wrote: > >> We're teaching Erlang to our second year students in a course entitled >> "functional and concurrent programming". Erlang is the base language here, >> but we also introduce - briefly - other approaches to functional and >> concurrent programming. >> >> Simon >> > > Hi Simon (and Frederik) > > After some time battling google I found > http://www.kent.ac.uk/courses/modulecatalogue/modules/CO523 > which seems to mention some topics in FP some in OOP... > > And no language!! > > So thanks your info is interesting to me personally but until I have links > its not really usable in a public setting > > Rusi > > > > _______________________________________________ > 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 Wed Aug 13 12:49:33 2014 From: n.oxyde@REDACTED (Anthony) Date: Wed, 13 Aug 2014 12:49:33 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> Message-ID: <3B2D9FB5-E59D-4EA7-8217-C4C336FF6C2D@gmail.com> I think it depends the university, in UPMC where I went, a lot of units mentioned which languages will be used during the courses, and I won?t let you say that it is not a serious computer science program. ;) That being said, I contacted one of my old teachers to ask him if he would be interested teaching Erlang there, I hope he will reply. -- Anthony Ramine Le 13 ao?t 2014 ? 08:13, Fredrik Andersson a ?crit : > Hi Rustomomom (yeah I can't read and spell names either..) > > I don't think you will find a course description in most serious computer science programs that mentions the languages being used as the main focus of a computer science program it to teach the theory and not how to use the tools (languages are tools not theories). I know for a fact that most course descriptions for Uppsala University does not mention the languages as that would lock the course to forcing students and instructors to use that language. > > PS: No offence about the name thing. > > > On Tue, Aug 12, 2014 at 8:48 PM, Rustom Mody wrote: > > > > On Tue, Aug 12, 2014 at 11:29 AM, Simon Thompson wrote: > We're teaching Erlang to our second year students in a course entitled "functional and concurrent programming". Erlang is the base language here, but we also introduce - briefly - other approaches to functional and concurrent programming. > > Simon > > Hi Simon (and Frederik) > > After some time battling google I found > http://www.kent.ac.uk/courses/modulecatalogue/modules/CO523 > which seems to mention some topics in FP some in OOP... > > And no language!! > > So thanks your info is interesting to me personally but until I have links its not really usable in a public setting > > Rusi > > > > _______________________________________________ > 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 sedrik@REDACTED Wed Aug 13 12:53:09 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Wed, 13 Aug 2014 12:53:09 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: <3B2D9FB5-E59D-4EA7-8217-C4C336FF6C2D@gmail.com> References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> <3B2D9FB5-E59D-4EA7-8217-C4C336FF6C2D@gmail.com> Message-ID: On Wed, Aug 13, 2014 at 12:49 PM, Anthony wrote: > I think it depends the university, in UPMC where I went, a lot of units > mentioned which languages will be used during the courses, and I won?t let > you say that it is not a serious computer science program. ;) > True, might be more of a thing here in Sweden =) No intention of talking down other univs. > > That being said, I contacted one of my old teachers to ask him if he would > be interested teaching Erlang there, I hope he will reply. > > -- > Anthony Ramine > > Le 13 ao?t 2014 ? 08:13, Fredrik Andersson a ?crit : > > > Hi Rustomomom (yeah I can't read and spell names either..) > > > > I don't think you will find a course description in most serious > computer science programs that mentions the languages being used as the > main focus of a computer science program it to teach the theory and not how > to use the tools (languages are tools not theories). I know for a fact that > most course descriptions for Uppsala University does not mention the > languages as that would lock the course to forcing students and instructors > to use that language. > > > > PS: No offence about the name thing. > > > > > > On Tue, Aug 12, 2014 at 8:48 PM, Rustom Mody > wrote: > > > > > > > > On Tue, Aug 12, 2014 at 11:29 AM, Simon Thompson < > s.j.thompson@REDACTED> wrote: > > We're teaching Erlang to our second year students in a course entitled > "functional and concurrent programming". Erlang is the base language here, > but we also introduce - briefly - other approaches to functional and > concurrent programming. > > > > Simon > > > > Hi Simon (and Frederik) > > > > After some time battling google I found > > http://www.kent.ac.uk/courses/modulecatalogue/modules/CO523 > > which seems to mention some topics in FP some in OOP... > > > > And no language!! > > > > So thanks your info is interesting to me personally but until I have > links its not really usable in a public setting > > > > Rusi > > > > > > > > _______________________________________________ > > 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 eric.pailleau@REDACTED Wed Aug 13 13:56:15 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Wed, 13 Aug 2014 13:56:15 +0200 Subject: [erlang-questions] How is the mnesia cookie created? In-Reply-To: References: Message-ID: <53EB525F.4070209@wanadoo.fr> Hi, I suspect you are creating database schema at each node start. It is a symptom. Please read LYSE on the subject : http://learnyousomeerlang.com/mnesia#of-schemas-and-mnesia Regards Le 12/08/2014 17:58, Kristoffer Brown a ?crit : > I've run into many different scenarios where I have received mnesia "bad > cookie" errors. Some make sense from my limited knowledge of mnesia. > Some don't. > > So, I was hoping somebody could help me determine what the cookie contains. > > Thanks in advance. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From n.oxyde@REDACTED Wed Aug 13 20:27:09 2014 From: n.oxyde@REDACTED (Anthony) Date: Wed, 13 Aug 2014 20:27:09 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> <3B2D9FB5-E59D-4EA7-8217-C4C336FF6C2D@gmail.com> Message-ID: <3C50C6DB-629F-4C2B-BA06-B86CACE936C6@gmail.com> No offense taken, and to be fair I still remember that the Java units were insane. -- Anthony Ramine Le 13 ao?t 2014 ? 12:53, Fredrik Andersson a ?crit : > True, might be more of a thing here in Sweden =) No intention of talking down other univs. From rvirding@REDACTED Wed Aug 13 20:36:18 2014 From: rvirding@REDACTED (Robert Virding) Date: Wed, 13 Aug 2014 11:36:18 -0700 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: <55D4D810-A3B1-44A8-92C1-83D524A266B5@kent.ac.uk> Message-ID: Erlang is also used in the functional part of this course at KTH: http://www.kth.se/student/kurser/kurs/HI2011 The functional part goes through basic erlang and OTP and ends with a lab exercise using erlang. For the last two years I given the erlang part of the course. Robert On 12 August 2014 11:48, Rustom Mody wrote: > > > > On Tue, Aug 12, 2014 at 11:29 AM, Simon Thompson > wrote: > >> We're teaching Erlang to our second year students in a course entitled >> "functional and concurrent programming". Erlang is the base language here, >> but we also introduce - briefly - other approaches to functional and >> concurrent programming. >> >> Simon >> > > Hi Simon (and Frederik) > > After some time battling google I found > http://www.kent.ac.uk/courses/modulecatalogue/modules/CO523 > which seems to mention some topics in FP some in OOP... > > And no language!! > > So thanks your info is interesting to me personally but until I have links > its not really usable in a public setting > > Rusi > > > > _______________________________________________ > 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 Wed Aug 13 23:57:05 2014 From: rvirding@REDACTED (Robert Virding) Date: Wed, 13 Aug 2014 14:57:05 -0700 Subject: [erlang-questions] Gun and websockets Message-ID: I am having problems trying to open a websocket with gun https://github.com/extend/gun. So I have been trying: {ok,Pid} = gun:open("10.0.1.86", 8080, [{type,tcp}]), gun:ws_upgrade(Pid, "/content/chats/connect/"), and nothing happens, it just times out. Checking, the process Pid started by gun:open dies with an undef error but I don't see which function it is trying to call. Using http://www.websocket.org/echo.html and opening ws:// 10.0.1.86:8080/content/chats/connect works fine. Any suggestions? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvirding@REDACTED Thu Aug 14 00:20:59 2014 From: rvirding@REDACTED (Robert Virding) Date: Wed, 13 Aug 2014 15:20:59 -0700 Subject: [erlang-questions] Gun and websockets In-Reply-To: References: Message-ID: I had gotten the answer in #erlang chat but missed it. It is depressingly simple, it is not implemented yet. :-( Robert On 13 August 2014 14:57, Robert Virding wrote: > I am having problems trying to open a websocket with gun > https://github.com/extend/gun. So I have been trying: > > {ok,Pid} = gun:open("10.0.1.86", 8080, [{type,tcp}]), > gun:ws_upgrade(Pid, "/content/chats/connect/"), > > and nothing happens, it just times out. Checking, the process Pid started > by gun:open dies with an undef error but I don't see which function it is > trying to call. Using http://www.websocket.org/echo.html and opening ws:// > 10.0.1.86:8080/content/chats/connect works fine. > > Any suggestions? > > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido.rumi@REDACTED Wed Aug 13 23:38:10 2014 From: guido.rumi@REDACTED (Guido Rumi) Date: Wed, 13 Aug 2014 18:38:10 -0300 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: Universidad Nacional de Rosario (Rosario-Santa Fe, Argentina) also teaches Erlang. It's used to teach concurrency, message passing between processes, etc. as part of the first course of Operating Systems in Computer Science. To finish the course it's required to program a mock Distributed File System in Erlang and an other version in C. That made me realize the benefits of using Erlang in concurrent systems, the version coded in C was much more tedious to accomplish and debugging was an issue. Links: http://www.fceia.unr.edu.ar/lcc/r322/enlaces.php On Tue, Aug 12, 2014 at 2:23 AM, Rustom Mody wrote: > Hi > I am collecting material about univs starting programming with functional > programming: > http://blog.languager.org/2014/08/universities-starting-functional.html > > Erlang figures but only in 2nd/'advanced' courses. > Are there any cases where Erlang is used to start teaching programming? > > Thanks > Rusi > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bduggan@REDACTED Thu Aug 14 08:42:45 2014 From: bduggan@REDACTED (Bernard Duggan) Date: Thu, 14 Aug 2014 16:42:45 +1000 Subject: [erlang-questions] global:register_name/2 hang? Message-ID: <53EC5A65.3010706@shoretel.com> Hi list - it's been a while! Is everyone well? Excellent. We ran into a production issue the other day which I've been scratching my head over for the past three days: One of our supervised, 'permanent' processes crashed, which should have been fine (for some value of "fine"), but the problem is that it didn't restart for 37 minutes. After much coffee, staring and our logs and poring over both our and the OTP code, it looks like the only plausible culprit for this delay is a hang when the supervisor is restarting the process and gen_server goes to register the new process with the global nameserver (this particular process is globally registered). Now obviously crying "there's a bug in the OTP" should always be an option of last resort, but since the very first line of our gen_server's init function prints out a debug line, and that line doesn't appear until 37 minutes later, there's just not too much scope for looking elsewhere - believe me, I've tried :)). global:register_name/2 seems like an especially promising candidate since it ultimately makes a gen_server call with an infinite timeout (I'm using/looking at R16B01 here, but nothing in change logs from earlier/later versions suggests that anything significant has changed in this area). In looking for any kind of clues, I also came across these two posts: http://erlang.org/pipermail/erlang-questions/2010-November/054700.html http://erlang.org/pipermail/erlang-questions/2012-May/066369.html both of which seem to describe something very similar to what I think happened here. (And unfortunately neither of which garnered any response). So here are my questions, I guess: Has anyone else encountered anything similar? Can anyone with better knowledge than me of global's inner workings suggest a mechanism whereby this could occur (and even better, how to avoid it)? Alternatively, can anyone suggest any good candidates for looking at really closely within global (or elsewhere) to try to pin this problem down? It's probably worth mentioning that our system doesn't have many nodes - usually it's the main (Erlang) node, three JInterface nodes, one C node (created by erld) and one other native Erlang node that comes and goes on a regular basis (at something like 5 minute intervals). Thanks all. Cheers, Bernard ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From glasper9@REDACTED Thu Aug 14 11:21:04 2014 From: glasper9@REDACTED (Jason Stokes) Date: Thu, 14 Aug 2014 02:21:04 -0700 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: <1408008064.28500.YahooMailNeo@web125906.mail.ne1.yahoo.com> I don't know if this helps, but the Australian National University uses /Haskell/ as the introductory language in its COMP1100/1130 Data Structures and Algorithms I course. The ANU does cover Erlang, but in a later course on functional programming. The first year course material could easily be adapted to use Erlang, of course (and I've always felt Erlang would work better, since if one thing is certain, beginners struggle horribly with statically typed languages.) Course material is available here: http://cs.anu.edu.au/student/comp1100/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterke@REDACTED Thu Aug 14 13:12:38 2014 From: peterke@REDACTED (=?UTF-8?B?UMOpdGVyIFN6aWzDoWd5aQ==?=) Date: Thu, 14 Aug 2014 14:12:38 +0300 Subject: [erlang-questions] [project-iris] Re: Iris v0.3.0 out, with fresh new APIs In-Reply-To: <5114a736-da9e-48bc-81a2-63113893d810@googlegroups.com> References: <0cfd8342-1214-41b7-ba27-646de862c79c@googlegroups.com> <927bdb02-7523-4e72-adba-59bfe8451b07@googlegroups.com> <5114a736-da9e-48bc-81a2-63113893d810@googlegroups.com> Message-ID: Hi Lee, Help and contributions are always welcome and there are a lot of places which could use improvement (for example the Erlang binding is significantly slower that the Go version, the bootstrapper needs a rework, a new load balancer is needed, leveled logging, monitoring, etc), but if you really want to help out, then I'd suggest starting experimenting with Iris and you'll see your specific pain points and then we can start from there :) Cheers, Peter On Tue, Aug 12, 2014 at 12:15 AM, Lee Sylvester wrote: > Hi P?ter, > > Thank you very much for your answers. I am very much interested in Iris > and would like to contribute where possible. I have lots of experience > with both Erlang and Go, and with messaging / cloud development in general, > so I can hopefully provide a lot of support for this, whether directly or > through supporting modules that help complement Iris. As I said, I've been > looking for a prebuilt solution of this orientation for some time, so this > is a good find for me. > > Kind regards, > Lee > > > -- > You received this message because you are subscribed to the Google Groups > "Iris cloud messaging" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to project-iris+unsubscribe@REDACTED > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Aug 14 14:22:37 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 14 Aug 2014 08:22:37 -0400 Subject: [erlang-questions] global:register_name/2 hang? In-Reply-To: <53EC5A65.3010706@shoretel.com> References: <53EC5A65.3010706@shoretel.com> Message-ID: <20140814122236.GE27120@ferdair.local> On 08/14, Bernard Duggan wrote: > In looking for any kind of clues, I also came across these two posts: > http://erlang.org/pipermail/erlang-questions/2010-November/054700.html > http://erlang.org/pipermail/erlang-questions/2012-May/066369.html > > So here are my questions, I guess: Has anyone else encountered anything > similar? Can anyone with better knowledge than me of global's inner > workings suggest a mechanism whereby this could occur (and even better, > how to avoid it)? Alternatively, can anyone suggest any good candidates > for looking at really closely within global (or elsewhere) to try to pin > this problem down? There's also http://dieswaytoofast.blogspot.ca/2012/08/erlang-deep-bugs-at-least-one-of-which.html from Mahesh in here, who found about some weird use cases of global that would lock up code entirely while everything got serialized through a single overloaded/busy gen_server. This specific case was fixed back in R15B01, but maybe something similar is at play here? Regards, Fred. From schneider@REDACTED Thu Aug 14 16:48:36 2014 From: schneider@REDACTED (Schneider) Date: Thu, 14 Aug 2014 16:48:36 +0200 Subject: [erlang-questions] process hierarchy and passing references Message-ID: <53ECCC44.6010100@xs4all.nl> Hi list, Since I am very new to Erlang, I am not sure how to layout process hierarchies in the following case: Besides the domain specific functionality, every program has a RPC middleman and an XML-RPC interface, each implemented as gen_servers. In the current setup, the main gen_server process starts the RPC middleman, passing it its Pid, and the RPC gen_server starts the XML-RPC server which is passed the RPC middleman's Pid. Using the passed in Pid's, the XML-RPC server can do a gen_server:call()/cast() back to the RPC server which on its turn can call the main server. Works ok, but I would like to have the RPC middleman and XML-RPC controller under the control of a supervisor. The main supervisor should start the main gen_server process plus a supervisor that on its turn should start the RPC midleman and the XML-RPC handler. The thing I can't figure out is how the XML-RPC process should find the RPC middleman process and how that process should locate the main server when using supervision. Since there can be many RPC middlemen and XMP-RPC servers around, each belonging to different main servers, naming and registering seems a little hard. So how to pass references around? Any help will be very much appreciated. Frans From lenartlad@REDACTED Thu Aug 14 17:00:38 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Thu, 14 Aug 2014 17:00:38 +0200 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <53ECCC44.6010100@xs4all.nl> References: <53ECCC44.6010100@xs4all.nl> Message-ID: <53ECCF16.4060802@volny.cz> Hello. What about the following solution: * Put all three processes under one supervisor. * Set its restart strategy to one_for_all. * Pass supervisor's PID to its children. * Each worker process can lookup PID of its relevant sibling via supervisor:which_children/1. HTH, Ladislav Lenart On 14.8.2014 16:48, Schneider wrote: > Hi list, > > Since I am very new to Erlang, I am not sure how to layout process > hierarchies in the following case: > > Besides the domain specific functionality, every program has a RPC > middleman and an XML-RPC interface, each implemented as gen_servers. In > the current setup, the main gen_server process starts the RPC middleman, > passing it its Pid, and the RPC gen_server starts the XML-RPC server > which is passed the RPC middleman's Pid. > Using the passed in Pid's, the XML-RPC server can do a > gen_server:call()/cast() back to the RPC server which on its turn can > call the main server. Works ok, but I would like to have the RPC > middleman and XML-RPC controller under the control of a supervisor. The > main supervisor should start the main gen_server process plus a > supervisor that on its turn should start the RPC midleman and the > XML-RPC handler. > The thing I can't figure out is how the XML-RPC process should find the > RPC middleman process and how that process should locate the main server > when using supervision. Since there can be many RPC middlemen and > XMP-RPC servers around, each belonging to different main servers, naming > and registering seems a little hard. > So how to pass references around? > > Any help will be very much appreciated. > > Frans > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From lenartlad@REDACTED Thu Aug 14 17:16:55 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Thu, 14 Aug 2014 17:16:55 +0200 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <53ECCF16.4060802@volny.cz> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> Message-ID: <53ECD2E7.3050201@volny.cz> Hello again. On 14.8.2014 17:00, Ladislav Lenart wrote: > Hello. > > What about the following solution: > * Put all three processes under one supervisor. > * Set its restart strategy to one_for_all. Or rest_for_one. This one may better suite your needs. For more info, refer to the official documentation at: http://www.erlang.org/doc/man/supervisor.html > * Pass supervisor's PID to its children. > * Each worker process can lookup PID of its relevant sibling via > supervisor:which_children/1. HTH, Ladislav Lenart > On 14.8.2014 16:48, Schneider wrote: >> Hi list, >> >> Since I am very new to Erlang, I am not sure how to layout process >> hierarchies in the following case: >> >> Besides the domain specific functionality, every program has a RPC >> middleman and an XML-RPC interface, each implemented as gen_servers. In >> the current setup, the main gen_server process starts the RPC middleman, >> passing it its Pid, and the RPC gen_server starts the XML-RPC server >> which is passed the RPC middleman's Pid. >> Using the passed in Pid's, the XML-RPC server can do a >> gen_server:call()/cast() back to the RPC server which on its turn can >> call the main server. Works ok, but I would like to have the RPC >> middleman and XML-RPC controller under the control of a supervisor. The >> main supervisor should start the main gen_server process plus a >> supervisor that on its turn should start the RPC midleman and the >> XML-RPC handler. >> The thing I can't figure out is how the XML-RPC process should find the >> RPC middleman process and how that process should locate the main server >> when using supervision. Since there can be many RPC middlemen and >> XMP-RPC servers around, each belonging to different main servers, naming >> and registering seems a little hard. >> So how to pass references around? >> >> Any help will be very much appreciated. >> >> Frans >> _______________________________________________ >> 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 guido.rumi@REDACTED Thu Aug 14 17:41:45 2014 From: guido.rumi@REDACTED (Guido Rumi) Date: Thu, 14 Aug 2014 12:41:45 -0300 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: I forgot to mention Erlang it's not used to start teaching programming, Haskell is the main language used to teach functional programming and it's teached, at least, in three courses. On Tue, Aug 12, 2014 at 2:23 AM, Rustom Mody wrote: > Hi > I am collecting material about univs starting programming with functional > programming: > http://blog.languager.org/2014/08/universities-starting-functional.html > > Erlang figures but only in 2nd/'advanced' courses. > Are there any cases where Erlang is used to start teaching programming? > > Thanks > Rusi > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schneider@REDACTED Thu Aug 14 17:47:15 2014 From: schneider@REDACTED (Schneider) Date: Thu, 14 Aug 2014 17:47:15 +0200 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <53ECD2E7.3050201@volny.cz> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> Message-ID: <6E66F97A-E044-4CDF-B04B-A7D5CB374A48@xs4all.nl> Right, thanks. Looks good. So simple, as always. Frans > Op 14 aug. 2014 om 17:16 heeft Ladislav Lenart het volgende geschreven: > > Hello again. > > >> On 14.8.2014 17:00, Ladislav Lenart wrote: >> Hello. >> >> What about the following solution: >> * Put all three processes under one supervisor. >> * Set its restart strategy to one_for_all. > > Or rest_for_one. This one may better suite your needs. For more info, refer to > the official documentation at: http://www.erlang.org/doc/man/supervisor.html > >> * Pass supervisor's PID to its children. >> * Each worker process can lookup PID of its relevant sibling via >> supervisor:which_children/1. > > > HTH, > > Ladislav Lenart > > >>> On 14.8.2014 16:48, Schneider wrote: >>> Hi list, >>> >>> Since I am very new to Erlang, I am not sure how to layout process >>> hierarchies in the following case: >>> >>> Besides the domain specific functionality, every program has a RPC >>> middleman and an XML-RPC interface, each implemented as gen_servers. In >>> the current setup, the main gen_server process starts the RPC middleman, >>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>> which is passed the RPC middleman's Pid. >>> Using the passed in Pid's, the XML-RPC server can do a >>> gen_server:call()/cast() back to the RPC server which on its turn can >>> call the main server. Works ok, but I would like to have the RPC >>> middleman and XML-RPC controller under the control of a supervisor. The >>> main supervisor should start the main gen_server process plus a >>> supervisor that on its turn should start the RPC midleman and the >>> XML-RPC handler. >>> The thing I can't figure out is how the XML-RPC process should find the >>> RPC middleman process and how that process should locate the main server >>> when using supervision. Since there can be many RPC middlemen and >>> XMP-RPC servers around, each belonging to different main servers, naming >>> and registering seems a little hard. >>> So how to pass references around? >>> >>> Any help will be very much appreciated. >>> >>> Frans >>> _______________________________________________ >>> 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 pablo.platt@REDACTED Thu Aug 14 18:57:39 2014 From: pablo.platt@REDACTED (pablo platt) Date: Thu, 14 Aug 2014 19:57:39 +0300 Subject: [erlang-questions] zip:unzip/2 protect from escaping the working directory? Message-ID: Hi, Can a zip archive escape the working directory or cwd when extracting it? zip:unzip(Archive, [{cwd, CWD}]) Is it possible that a file will be extracted to ../working_dir or even /var/lib/some_file ? Same question for erl_tar:extract(Name, OptionList) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody@REDACTED Thu Aug 14 19:20:48 2014 From: rustompmody@REDACTED (Rustom Mody) Date: Thu, 14 Aug 2014 22:50:48 +0530 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: Thanks Jason, Guido As you will see my blog post: http://blog.languager.org/2014/08/universities-starting-functional.html links the the Haskell in education list http://www.haskell.org/haskellwiki/Haskell_in_education I see ANU there but not (perhaps) Universidad Nacional de Rosario. You may want to bring this to the Haskell folks and/or your friends at the university. Regards Rusi On Thu, Aug 14, 2014 at 9:11 PM, Guido Rumi wrote: > I forgot to mention Erlang it's not used to start teaching programming, > Haskell is the main language used to teach functional programming and it's > teached, at least, in three courses. > > > On Tue, Aug 12, 2014 at 2:23 AM, Rustom Mody > wrote: > >> Hi >> I am collecting material about univs starting programming with functional >> programming: >> http://blog.languager.org/2014/08/universities-starting-functional.html >> >> Erlang figures but only in 2nd/'advanced' courses. >> Are there any cases where Erlang is used to start teaching programming? >> >> Thanks >> Rusi >> >> _______________________________________________ >> 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 > > -- http://www.the-magus.in http://blog.languager.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Fri Aug 15 00:51:16 2014 From: juanjo@REDACTED (Juan Jose Comellas) Date: Thu, 14 Aug 2014 19:51:16 -0300 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: That is really cool! I've been working in Erlang for about 8 years in Argentina and I never knew a university there was using it as part of its curriculum. On Wed, Aug 13, 2014 at 6:38 PM, Guido Rumi wrote: > Universidad Nacional de Rosario (Rosario-Santa Fe, Argentina) also teaches > Erlang. It's used to teach concurrency, message passing between processes, > etc. as part of the first course of Operating Systems in Computer Science. > To finish the course it's required to program a mock Distributed File > System in Erlang and an other version in C. That made me realize the > benefits of using Erlang in concurrent systems, the version coded in C was > much more tedious to accomplish and debugging was an issue. > > Links: http://www.fceia.unr.edu.ar/lcc/r322/enlaces.php > > > > > On Tue, Aug 12, 2014 at 2:23 AM, Rustom Mody > wrote: > >> Hi >> I am collecting material about univs starting programming with functional >> programming: >> http://blog.languager.org/2014/08/universities-starting-functional.html >> >> Erlang figures but only in 2nd/'advanced' courses. >> Are there any cases where Erlang is used to start teaching programming? >> >> Thanks >> Rusi >> >> _______________________________________________ >> 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 schneider@REDACTED Fri Aug 15 11:49:53 2014 From: schneider@REDACTED (Frans Schneider) Date: Fri, 15 Aug 2014 11:49:53 +0200 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: <53ECD2E7.3050201@volny.cz> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> Message-ID: <53EDD7C1.2080109@xs4all.nl> Hi list, Now that I got the supervision working, I am looking for a way to implement a standard API for every "main" server. The API implements a way for the main gen_server to call the RPC middleman and should also define standard callbacks for the main server the middleman can use. The API would also use some internal state. In a previous life, I would have used inheritance to accomplish this, but how can I do this in Erlang? I had a look at the supervisor implementation, but was wondering if there is a easier way to accomplish this. Thanks Frans On 08/14/2014 05:16 PM, Ladislav Lenart wrote: > Hello again. > > > On 14.8.2014 17:00, Ladislav Lenart wrote: >> Hello. >> >> What about the following solution: >> * Put all three processes under one supervisor. >> * Set its restart strategy to one_for_all. > Or rest_for_one. This one may better suite your needs. For more info, refer to > the official documentation at: http://www.erlang.org/doc/man/supervisor.html > >> * Pass supervisor's PID to its children. >> * Each worker process can lookup PID of its relevant sibling via >> supervisor:which_children/1. > > HTH, > > Ladislav Lenart > > >> On 14.8.2014 16:48, Schneider wrote: >>> Hi list, >>> >>> Since I am very new to Erlang, I am not sure how to layout process >>> hierarchies in the following case: >>> >>> Besides the domain specific functionality, every program has a RPC >>> middleman and an XML-RPC interface, each implemented as gen_servers. In >>> the current setup, the main gen_server process starts the RPC middleman, >>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>> which is passed the RPC middleman's Pid. >>> Using the passed in Pid's, the XML-RPC server can do a >>> gen_server:call()/cast() back to the RPC server which on its turn can >>> call the main server. Works ok, but I would like to have the RPC >>> middleman and XML-RPC controller under the control of a supervisor. The >>> main supervisor should start the main gen_server process plus a >>> supervisor that on its turn should start the RPC midleman and the >>> XML-RPC handler. >>> The thing I can't figure out is how the XML-RPC process should find the >>> RPC middleman process and how that process should locate the main server >>> when using supervision. Since there can be many RPC middlemen and >>> XMP-RPC servers around, each belonging to different main servers, naming >>> and registering seems a little hard. >>> So how to pass references around? >>> >>> Any help will be very much appreciated. >>> >>> Frans >>> _______________________________________________ >>> 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 sperber@REDACTED Fri Aug 15 13:10:19 2014 From: sperber@REDACTED (Michael Sperber) Date: Fri, 15 Aug 2014 13:10:19 +0200 Subject: [erlang-questions] BOB 2015 - Call for Contributions (Berlin, Germany, January 23, 2015) Message-ID: The BOB conference will have a strong focus on functional programming, so Erlang submissions very welcome. Please consider submitting! BOB Conference 2015 Berlin 23.1.2015 http://bobkonf.de/2015/ CALL FOR CONTRIBUTIONS English: http://bobkonf.de/2015/cfp.html German: http://bobkonf.de/2015/cfp.html Deadline: September 30, 2014 You drive advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer you a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! We are looking for talks about best-of-breed software technology, e.g.: - functional programming - reactive programming - micro-service architectures - persistent data structures and databases - ? everything really that isn?t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. This could take the form of e.g.: - experience reports - introductory talks on technical background - demos and how-tos We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. It should include (in your presentation language of choice): - an abstract of max. 1500 characters. - a short bio/cv - contact information (including at least email) - a list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, ?) You can submit your proposal using the following form: https://docs.google.com/spreadsheet/viewform?formkey=dHJ0TjR1cEhUWmdBZFVITGVRVWN5VEE6MA - direct questions to bobkonf at active minus group dot de - proposal deadline: September 30, 2014 - notification: October 15, 2014 - program: October 2014, 2014 NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered. Program Committee - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Michael Sperber, Active Group - Stefan Wehr, factis research Wissenschaftlicher Beirat - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni T?bingen - Peter Thiemann, Uni Freiburg From mononcqc@REDACTED Fri Aug 15 14:40:04 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 15 Aug 2014 08:40:04 -0400 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <53ECCC44.6010100@xs4all.nl> References: <53ECCC44.6010100@xs4all.nl> Message-ID: <20140815124003.GB54532@ferdair.local> On 08/14, Schneider wrote: > Besides the domain specific functionality, every program has a RPC middleman > and an XML-RPC interface, each implemented as gen_servers. In the current > setup, the main gen_server process starts the RPC middleman, passing it its > Pid, and the RPC gen_server starts the XML-RPC server which is passed the > RPC middleman's Pid. What's the 'main gen_server process'? > Using the passed in Pid's, the XML-RPC server can do a > gen_server:call()/cast() back to the RPC server which on its turn can call > the main server. Works ok, but I would like to have the RPC middleman and > XML-RPC controller under the control of a supervisor. The main supervisor > should start the main gen_server process plus a supervisor that on its turn > should start the RPC midleman and the XML-RPC handler. Is there a reason why you can't use a named process and pass that name instead of having Pids returned? Is it because you risk having to many middlemen or XML-RPC servers? You've told us the kind of design you want to do, but not why you want to do it. That hides a lot of information if the objective is to get a good architecture going. For your specific case, you can very well have the supervisor pass its pid to the server, and have the server call the supervisor back (outside of its init function, or asynchronously) to start the child you want to know about. Or you could go an entirely different way and have an XML-RPC application that spawns a server ready to listen and can just be called from anywhere on the node, but that depends on what you plan on doing. Then the 'main gen_server', whatever it's doing, does not need to start the XML-RPC server -- it's another application on which it can depend, like stdlib or kernel. > The thing I can't figure out is how the XML-RPC process should find the RPC > middleman process and how that process should locate the main server when > using supervision. Since there can be many RPC middlemen and XMP-RPC servers > around, each belonging to different main servers, naming and registering > seems a little hard. > So how to pass references around? > There is a general theme here: if process A needs to know about process B, then process B is a dependency of A, and therefore B should be spawned before A. This yields any of the following approaches: - Give B a name, let A know the name. This works best if you have only one B needed for the entire node. - Put B and A under the same supervisor. Make sure B is spawned first in a rest_for_one. B can ask for A to be spawned later on. If there are many As, B can first spawn a supervisor S as its next sibling, and boot As under that supervisor. This works well if you have many pairs of processes like that in a node. They can even have dynamic names (say using gproc), but because they have a direct dependency, I only want the names to be used by outsiders. Between themselves, both processes should use their pids. This thread had the suggestion to keep asking the supervisor for who your siblings are. I hate this design, because it's confused and doesn't trace a clear path to dependencies. If you have B depending on A and A depending on B, this may be the only 'obvious' option, but I'd rather have an orchestrator process C that spawns both and lets them both know about each other as part of a negotiation sequence. Regards, Fred. From schneider@REDACTED Fri Aug 15 15:14:15 2014 From: schneider@REDACTED (Frans Schneider) Date: Fri, 15 Aug 2014 15:14:15 +0200 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <20140815124003.GB54532@ferdair.local> References: <53ECCC44.6010100@xs4all.nl> <20140815124003.GB54532@ferdair.local> Message-ID: <53EE07A7.7030007@xs4all.nl> Thanks for your help. I know I should have given more details about what I am trying to achieve, but I didn't want to bore everybody with to much detail... The suggestions by Ladislav Lenart worked out perfectly. Frans On 08/15/2014 02:40 PM, Fred Hebert wrote: > On 08/14, Schneider wrote: >> Besides the domain specific functionality, every program has a RPC middleman >> and an XML-RPC interface, each implemented as gen_servers. In the current >> setup, the main gen_server process starts the RPC middleman, passing it its >> Pid, and the RPC gen_server starts the XML-RPC server which is passed the >> RPC middleman's Pid. > What's the 'main gen_server process'? > >> Using the passed in Pid's, the XML-RPC server can do a >> gen_server:call()/cast() back to the RPC server which on its turn can call >> the main server. Works ok, but I would like to have the RPC middleman and >> XML-RPC controller under the control of a supervisor. The main supervisor >> should start the main gen_server process plus a supervisor that on its turn >> should start the RPC midleman and the XML-RPC handler. > Is there a reason why you can't use a named process and pass that name > instead of having Pids returned? Is it because you risk having to many > middlemen or XML-RPC servers? > > You've told us the kind of design you want to do, but not why you want > to do it. That hides a lot of information if the objective is to get a > good architecture going. > > For your specific case, you can very well have the supervisor pass its > pid to the server, and have the server call the supervisor back (outside > of its init function, or asynchronously) to start the child you want to > know about. > > Or you could go an entirely different way and have an XML-RPC > application that spawns a server ready to listen and can just be called > from anywhere on the node, but that depends on what you plan on doing. > Then the 'main gen_server', whatever it's doing, does not need to start > the XML-RPC server -- it's another application on which it can depend, > like stdlib or kernel. > >> The thing I can't figure out is how the XML-RPC process should find the RPC >> middleman process and how that process should locate the main server when >> using supervision. Since there can be many RPC middlemen and XMP-RPC servers >> around, each belonging to different main servers, naming and registering >> seems a little hard. >> So how to pass references around? >> > There is a general theme here: if process A needs to know about process > B, then process B is a dependency of A, and therefore B should be > spawned before A. > > This yields any of the following approaches: > > - Give B a name, let A know the name. This works best if you have only one B > needed for the entire node. > - Put B and A under the same supervisor. Make sure B is spawned first in > a rest_for_one. B can ask for A to be spawned later on. If there are > many As, B can first spawn a supervisor S as its next sibling, and > boot As under that supervisor. This works well if you have many pairs > of processes like that in a node. They can even have dynamic names > (say using gproc), but because they have a direct dependency, I only > want the names to be used by outsiders. Between themselves, both > processes should use their pids. > > This thread had the suggestion to keep asking the supervisor for who > your siblings are. I hate this design, because it's confused and doesn't > trace a clear path to dependencies. If you have B depending on A and A > depending on B, this may be the only 'obvious' option, but I'd rather > have an orchestrator process C that spawns both and lets them both know > about each other as part of a negotiation sequence. > > Regards, > Fred. From lenartlad@REDACTED Fri Aug 15 16:02:10 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Fri, 15 Aug 2014 16:02:10 +0200 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: <53EDD7C1.2080109@xs4all.nl> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> <53EDD7C1.2080109@xs4all.nl> Message-ID: <53EE12E2.8040902@volny.cz> Hello. On 15.8.2014 11:49, Frans Schneider wrote: > Hi list, > > Now that I got the supervision working, I am looking for a way to > implement a standard API for every "main" server. The API implements a > way for the main gen_server to call the RPC middleman and should also > define standard callbacks for the main server the middleman can use. The > API would also use some internal state. In a previous life, I would have > used inheritance to accomplish this, but how can I do this in Erlang? > I had a look at the supervisor implementation, but was wondering if > there is a easier way to accomplish this. I am not sure I follow you completely. However, if you want to parametrize process behavior in Erlang (i.e. something similar to OO inheritance that you mentioned), you can define your own behaviour (a module) and define different callback modules that all implement it. The pattern is the same as with a gen_server behaviour. If this is not what you need, please provide us with a concrete example(s) that you currently struggle with. HTH, Ladislav Lenart > Thanks > > Frans > > > On 08/14/2014 05:16 PM, Ladislav Lenart wrote: >> Hello again. >> >> >> On 14.8.2014 17:00, Ladislav Lenart wrote: >>> Hello. >>> >>> What about the following solution: >>> * Put all three processes under one supervisor. >>> * Set its restart strategy to one_for_all. >> Or rest_for_one. This one may better suite your needs. For more info, refer to >> the official documentation at: http://www.erlang.org/doc/man/supervisor.html >> >>> * Pass supervisor's PID to its children. >>> * Each worker process can lookup PID of its relevant sibling via >>> supervisor:which_children/1. >> >> HTH, >> >> Ladislav Lenart >> >> >>> On 14.8.2014 16:48, Schneider wrote: >>>> Hi list, >>>> >>>> Since I am very new to Erlang, I am not sure how to layout process >>>> hierarchies in the following case: >>>> >>>> Besides the domain specific functionality, every program has a RPC >>>> middleman and an XML-RPC interface, each implemented as gen_servers. In >>>> the current setup, the main gen_server process starts the RPC middleman, >>>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>>> which is passed the RPC middleman's Pid. >>>> Using the passed in Pid's, the XML-RPC server can do a >>>> gen_server:call()/cast() back to the RPC server which on its turn can >>>> call the main server. Works ok, but I would like to have the RPC >>>> middleman and XML-RPC controller under the control of a supervisor. The >>>> main supervisor should start the main gen_server process plus a >>>> supervisor that on its turn should start the RPC midleman and the >>>> XML-RPC handler. >>>> The thing I can't figure out is how the XML-RPC process should find the >>>> RPC middleman process and how that process should locate the main server >>>> when using supervision. Since there can be many RPC middlemen and >>>> XMP-RPC servers around, each belonging to different main servers, naming >>>> and registering seems a little hard. >>>> So how to pass references around? >>>> >>>> Any help will be very much appreciated. >>>> >>>> Frans >>>> _______________________________________________ >>>> 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 lenartlad@REDACTED Fri Aug 15 16:04:13 2014 From: lenartlad@REDACTED (Ladislav Lenart) Date: Fri, 15 Aug 2014 16:04:13 +0200 Subject: [erlang-questions] process hierarchy and passing references In-Reply-To: <20140815124003.GB54532@ferdair.local> References: <53ECCC44.6010100@xs4all.nl> <20140815124003.GB54532@ferdair.local> Message-ID: <53EE135D.4020003@volny.cz> Hello. All very good points. I like this approach: > Put B and A under the same supervisor. Make sure B is spawned first in > a rest_for_one. B can ask for A to be spawned later on. Ladislav Lenart On 15.8.2014 14:40, Fred Hebert wrote: > On 08/14, Schneider wrote: >> Besides the domain specific functionality, every program has a RPC middleman >> and an XML-RPC interface, each implemented as gen_servers. In the current >> setup, the main gen_server process starts the RPC middleman, passing it its >> Pid, and the RPC gen_server starts the XML-RPC server which is passed the >> RPC middleman's Pid. > > What's the 'main gen_server process'? > >> Using the passed in Pid's, the XML-RPC server can do a >> gen_server:call()/cast() back to the RPC server which on its turn can call >> the main server. Works ok, but I would like to have the RPC middleman and >> XML-RPC controller under the control of a supervisor. The main supervisor >> should start the main gen_server process plus a supervisor that on its turn >> should start the RPC midleman and the XML-RPC handler. > > Is there a reason why you can't use a named process and pass that name > instead of having Pids returned? Is it because you risk having to many > middlemen or XML-RPC servers? > > You've told us the kind of design you want to do, but not why you want > to do it. That hides a lot of information if the objective is to get a > good architecture going. > > For your specific case, you can very well have the supervisor pass its > pid to the server, and have the server call the supervisor back (outside > of its init function, or asynchronously) to start the child you want to > know about. > > Or you could go an entirely different way and have an XML-RPC > application that spawns a server ready to listen and can just be called > from anywhere on the node, but that depends on what you plan on doing. > Then the 'main gen_server', whatever it's doing, does not need to start > the XML-RPC server -- it's another application on which it can depend, > like stdlib or kernel. > >> The thing I can't figure out is how the XML-RPC process should find the RPC >> middleman process and how that process should locate the main server when >> using supervision. Since there can be many RPC middlemen and XMP-RPC servers >> around, each belonging to different main servers, naming and registering >> seems a little hard. >> So how to pass references around? >> > > There is a general theme here: if process A needs to know about process > B, then process B is a dependency of A, and therefore B should be > spawned before A. > > This yields any of the following approaches: > > - Give B a name, let A know the name. This works best if you have only one B > needed for the entire node. > - Put B and A under the same supervisor. Make sure B is spawned first in > a rest_for_one. B can ask for A to be spawned later on. If there are > many As, B can first spawn a supervisor S as its next sibling, and > boot As under that supervisor. This works well if you have many pairs > of processes like that in a node. They can even have dynamic names > (say using gproc), but because they have a direct dependency, I only > want the names to be used by outsiders. Between themselves, both > processes should use their pids. > > This thread had the suggestion to keep asking the supervisor for who > your siblings are. I hate this design, because it's confused and doesn't > trace a clear path to dependencies. If you have B depending on A and A > depending on B, this may be the only 'obvious' option, but I'd rather > have an orchestrator process C that spawns both and lets them both know > about each other as part of a negotiation sequence. > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From schneider@REDACTED Fri Aug 15 16:16:50 2014 From: schneider@REDACTED (Frans Schneider) Date: Fri, 15 Aug 2014 16:16:50 +0200 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: <53EE12E2.8040902@volny.cz> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> <53EDD7C1.2080109@xs4all.nl> <53EE12E2.8040902@volny.cz> Message-ID: <53EE1652.5020904@xs4all.nl> Yes, I guess defining my own behaviour is what I am looking for. Found Cascading Behaviours (http://erlangcentral.org/wiki/index.php?title=Cascading_Behaviours) which seems to do the trick. It is a little dated and still uses behaviour_info(). Is it possible to reuse the callback definitions from gen_server? Frans On 08/15/2014 04:02 PM, Ladislav Lenart wrote: > Hello. > > > On 15.8.2014 11:49, Frans Schneider wrote: >> Hi list, >> >> Now that I got the supervision working, I am looking for a way to >> implement a standard API for every "main" server. The API implements a >> way for the main gen_server to call the RPC middleman and should also >> define standard callbacks for the main server the middleman can use. The >> API would also use some internal state. In a previous life, I would have >> used inheritance to accomplish this, but how can I do this in Erlang? >> I had a look at the supervisor implementation, but was wondering if >> there is a easier way to accomplish this. > I am not sure I follow you completely. However, if you want to parametrize > process behavior in Erlang (i.e. something similar to OO inheritance that you > mentioned), you can define your own behaviour (a module) and define different > callback modules that all implement it. The pattern is the same as with a > gen_server behaviour. > > If this is not what you need, please provide us with a concrete example(s) that > you currently struggle with. > > > HTH, > Ladislav Lenart > > >> Thanks >> >> Frans >> >> >> On 08/14/2014 05:16 PM, Ladislav Lenart wrote: >>> Hello again. >>> >>> >>> On 14.8.2014 17:00, Ladislav Lenart wrote: >>>> Hello. >>>> >>>> What about the following solution: >>>> * Put all three processes under one supervisor. >>>> * Set its restart strategy to one_for_all. >>> Or rest_for_one. This one may better suite your needs. For more info, refer to >>> the official documentation at: http://www.erlang.org/doc/man/supervisor.html >>> >>>> * Pass supervisor's PID to its children. >>>> * Each worker process can lookup PID of its relevant sibling via >>>> supervisor:which_children/1. >>> HTH, >>> >>> Ladislav Lenart >>> >>> >>>> On 14.8.2014 16:48, Schneider wrote: >>>>> Hi list, >>>>> >>>>> Since I am very new to Erlang, I am not sure how to layout process >>>>> hierarchies in the following case: >>>>> >>>>> Besides the domain specific functionality, every program has a RPC >>>>> middleman and an XML-RPC interface, each implemented as gen_servers. In >>>>> the current setup, the main gen_server process starts the RPC middleman, >>>>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>>>> which is passed the RPC middleman's Pid. >>>>> Using the passed in Pid's, the XML-RPC server can do a >>>>> gen_server:call()/cast() back to the RPC server which on its turn can >>>>> call the main server. Works ok, but I would like to have the RPC >>>>> middleman and XML-RPC controller under the control of a supervisor. The >>>>> main supervisor should start the main gen_server process plus a >>>>> supervisor that on its turn should start the RPC midleman and the >>>>> XML-RPC handler. >>>>> The thing I can't figure out is how the XML-RPC process should find the >>>>> RPC middleman process and how that process should locate the main server >>>>> when using supervision. Since there can be many RPC middlemen and >>>>> XMP-RPC servers around, each belonging to different main servers, naming >>>>> and registering seems a little hard. >>>>> So how to pass references around? >>>>> >>>>> Any help will be very much appreciated. >>>>> >>>>> Frans >>>>> _______________________________________________ >>>>> 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 vances@REDACTED Fri Aug 15 19:10:08 2014 From: vances@REDACTED (Vance Shipley) Date: Fri, 15 Aug 2014 22:40:08 +0530 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: <53EE1652.5020904@xs4all.nl> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> <53EDD7C1.2080109@xs4all.nl> <53EE12E2.8040902@volny.cz> <53EE1652.5020904@xs4all.nl> Message-ID: Yes. ;) On Aug 15, 2014 7:46 PM, "Frans Schneider" wrote: > Yes, I guess defining my own behaviour is what I am looking for. > Found Cascading Behaviours (http://erlangcentral.org/wiki/index.php?title= > Cascading_Behaviours) which seems to do the trick. > It is a little dated and still uses behaviour_info(). Is it possible to > reuse the callback definitions from gen_server? > > Frans > > > On 08/15/2014 04:02 PM, Ladislav Lenart wrote: > >> Hello. >> >> >> On 15.8.2014 11:49, Frans Schneider wrote: >> >>> Hi list, >>> >>> Now that I got the supervision working, I am looking for a way to >>> implement a standard API for every "main" server. The API implements a >>> way for the main gen_server to call the RPC middleman and should also >>> define standard callbacks for the main server the middleman can use. The >>> API would also use some internal state. In a previous life, I would have >>> used inheritance to accomplish this, but how can I do this in Erlang? >>> I had a look at the supervisor implementation, but was wondering if >>> there is a easier way to accomplish this. >>> >> I am not sure I follow you completely. However, if you want to parametrize >> process behavior in Erlang (i.e. something similar to OO inheritance that >> you >> mentioned), you can define your own behaviour (a module) and define >> different >> callback modules that all implement it. The pattern is the same as with a >> gen_server behaviour. >> >> If this is not what you need, please provide us with a concrete >> example(s) that >> you currently struggle with. >> >> >> HTH, >> Ladislav Lenart >> >> >> Thanks >>> >>> Frans >>> >>> >>> On 08/14/2014 05:16 PM, Ladislav Lenart wrote: >>> >>>> Hello again. >>>> >>>> >>>> On 14.8.2014 17:00, Ladislav Lenart wrote: >>>> >>>>> Hello. >>>>> >>>>> What about the following solution: >>>>> * Put all three processes under one supervisor. >>>>> * Set its restart strategy to one_for_all. >>>>> >>>> Or rest_for_one. This one may better suite your needs. For more info, >>>> refer to >>>> the official documentation at: http://www.erlang.org/doc/man/ >>>> supervisor.html >>>> >>>> * Pass supervisor's PID to its children. >>>>> * Each worker process can lookup PID of its relevant sibling via >>>>> supervisor:which_children/1. >>>>> >>>> HTH, >>>> >>>> Ladislav Lenart >>>> >>>> >>>> On 14.8.2014 16:48, Schneider wrote: >>>>> >>>>>> Hi list, >>>>>> >>>>>> Since I am very new to Erlang, I am not sure how to layout process >>>>>> hierarchies in the following case: >>>>>> >>>>>> Besides the domain specific functionality, every program has a RPC >>>>>> middleman and an XML-RPC interface, each implemented as gen_servers. >>>>>> In >>>>>> the current setup, the main gen_server process starts the RPC >>>>>> middleman, >>>>>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>>>>> which is passed the RPC middleman's Pid. >>>>>> Using the passed in Pid's, the XML-RPC server can do a >>>>>> gen_server:call()/cast() back to the RPC server which on its turn can >>>>>> call the main server. Works ok, but I would like to have the RPC >>>>>> middleman and XML-RPC controller under the control of a supervisor. >>>>>> The >>>>>> main supervisor should start the main gen_server process plus a >>>>>> supervisor that on its turn should start the RPC midleman and the >>>>>> XML-RPC handler. >>>>>> The thing I can't figure out is how the XML-RPC process should find >>>>>> the >>>>>> RPC middleman process and how that process should locate the main >>>>>> server >>>>>> when using supervision. Since there can be many RPC middlemen and >>>>>> XMP-RPC servers around, each belonging to different main servers, >>>>>> naming >>>>>> and registering seems a little hard. >>>>>> So how to pass references around? >>>>>> >>>>>> Any help will be very much appreciated. >>>>>> >>>>>> Frans >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schneider@REDACTED Fri Aug 15 19:27:56 2014 From: schneider@REDACTED (Schneider) Date: Fri, 15 Aug 2014 19:27:56 +0200 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> <53EDD7C1.2080109@xs4all.nl> <53EE12E2.8040902@volny.cz> <53EE1652.5020904@xs4all.nl> Message-ID: <001901cfb8ae$419f4150$c4ddc3f0$@nl> I know I can cascade the gen_server behaviour, and I?ve got it working already with the new ?callback syntax. I was wondering if there is a way to ?import? the init, handle_call etc callback definitions from gen_server so I don?t have to retype them in my new behaviour and, most importantly, they will keep in sync with future updates of the gen_server behaviour. Also, what is the performance impact using the cascading approach? Thanks for the input, Frans Van: Vance Shipley [mailto:vances@REDACTED] Verzonden: vrijdag 15 augustus 2014 19:10 Aan: Frans Schneider CC: Ladislav Lenart; Questions erlang-questions Onderwerp: Re: [erlang-questions] Implement standard API (was process hierarchy and passing references) Yes. ;) On Aug 15, 2014 7:46 PM, "Frans Schneider" wrote: Yes, I guess defining my own behaviour is what I am looking for. Found Cascading Behaviours (http://erlangcentral.org/wiki/index.php?title=Cascading_Behaviours) which seems to do the trick. It is a little dated and still uses behaviour_info(). Is it possible to reuse the callback definitions from gen_server? Frans On 08/15/2014 04:02 PM, Ladislav Lenart wrote: Hello. On 15.8.2014 11:49, Frans Schneider wrote: Hi list, Now that I got the supervision working, I am looking for a way to implement a standard API for every "main" server. The API implements a way for the main gen_server to call the RPC middleman and should also define standard callbacks for the main server the middleman can use. The API would also use some internal state. In a previous life, I would have used inheritance to accomplish this, but how can I do this in Erlang? I had a look at the supervisor implementation, but was wondering if there is a easier way to accomplish this. I am not sure I follow you completely. However, if you want to parametrize process behavior in Erlang (i.e. something similar to OO inheritance that you mentioned), you can define your own behaviour (a module) and define different callback modules that all implement it. The pattern is the same as with a gen_server behaviour. If this is not what you need, please provide us with a concrete example(s) that you currently struggle with. HTH, Ladislav Lenart Thanks Frans On 08/14/2014 05:16 PM, Ladislav Lenart wrote: Hello again. On 14.8.2014 17:00, Ladislav Lenart wrote: Hello. What about the following solution: * Put all three processes under one supervisor. * Set its restart strategy to one_for_all. Or rest_for_one. This one may better suite your needs. For more info, refer to the official documentation at: http://www.erlang.org/doc/man/supervisor.html * Pass supervisor's PID to its children. * Each worker process can lookup PID of its relevant sibling via supervisor:which_children/1. HTH, Ladislav Lenart On 14.8.2014 16:48, Schneider wrote: Hi list, Since I am very new to Erlang, I am not sure how to layout process hierarchies in the following case: Besides the domain specific functionality, every program has a RPC middleman and an XML-RPC interface, each implemented as gen_servers. In the current setup, the main gen_server process starts the RPC middleman, passing it its Pid, and the RPC gen_server starts the XML-RPC server which is passed the RPC middleman's Pid. Using the passed in Pid's, the XML-RPC server can do a gen_server:call()/cast() back to the RPC server which on its turn can call the main server. Works ok, but I would like to have the RPC middleman and XML-RPC controller under the control of a supervisor. The main supervisor should start the main gen_server process plus a supervisor that on its turn should start the RPC midleman and the XML-RPC handler. The thing I can't figure out is how the XML-RPC process should find the RPC middleman process and how that process should locate the main server when using supervision. Since there can be many RPC middlemen and XMP-RPC servers around, each belonging to different main servers, naming and registering seems a little hard. So how to pass references around? Any help will be very much appreciated. Frans _______________________________________________ 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 _______________________________________________ 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 Fri Aug 15 22:04:33 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Fri, 15 Aug 2014 17:04:33 -0300 Subject: [erlang-questions] Implement standard API (was process hierarchy and passing references) In-Reply-To: <53EDD7C1.2080109@xs4all.nl> References: <53ECCC44.6010100@xs4all.nl> <53ECCF16.4060802@volny.cz> <53ECD2E7.3050201@volny.cz> <53EDD7C1.2080109@xs4all.nl> Message-ID: Even if in this case I would not use inheritance, I think you should check mixer: https://github.com/opscode/mixer. It let's you use mixins, aka do not type the same code for two different modules that share some functionality (cowboy endpoints for example). Regards, Federico. On Fri, Aug 15, 2014 at 6:49 AM, Frans Schneider wrote: > Hi list, > > Now that I got the supervision working, I am looking for a way to > implement a standard API for every "main" server. The API implements a way > for the main gen_server to call the RPC middleman and should also define > standard callbacks for the main server the middleman can use. The API would > also use some internal state. In a previous life, I would have used > inheritance to accomplish this, but how can I do this in Erlang? > I had a look at the supervisor implementation, but was wondering if there > is a easier way to accomplish this. > > Thanks > > Frans > > > On 08/14/2014 05:16 PM, Ladislav Lenart wrote: > >> Hello again. >> >> >> On 14.8.2014 17:00, Ladislav Lenart wrote: >> >>> Hello. >>> >>> What about the following solution: >>> * Put all three processes under one supervisor. >>> * Set its restart strategy to one_for_all. >>> >> Or rest_for_one. This one may better suite your needs. For more info, >> refer to >> the official documentation at: http://www.erlang.org/doc/man/ >> supervisor.html >> >> * Pass supervisor's PID to its children. >>> * Each worker process can lookup PID of its relevant sibling via >>> supervisor:which_children/1. >>> >> >> HTH, >> >> Ladislav Lenart >> >> >> On 14.8.2014 16:48, Schneider wrote: >>> >>>> Hi list, >>>> >>>> Since I am very new to Erlang, I am not sure how to layout process >>>> hierarchies in the following case: >>>> >>>> Besides the domain specific functionality, every program has a RPC >>>> middleman and an XML-RPC interface, each implemented as gen_servers. In >>>> the current setup, the main gen_server process starts the RPC middleman, >>>> passing it its Pid, and the RPC gen_server starts the XML-RPC server >>>> which is passed the RPC middleman's Pid. >>>> Using the passed in Pid's, the XML-RPC server can do a >>>> gen_server:call()/cast() back to the RPC server which on its turn can >>>> call the main server. Works ok, but I would like to have the RPC >>>> middleman and XML-RPC controller under the control of a supervisor. The >>>> main supervisor should start the main gen_server process plus a >>>> supervisor that on its turn should start the RPC midleman and the >>>> XML-RPC handler. >>>> The thing I can't figure out is how the XML-RPC process should find the >>>> RPC middleman process and how that process should locate the main server >>>> when using supervision. Since there can be many RPC middlemen and >>>> XMP-RPC servers around, each belonging to different main servers, naming >>>> and registering seems a little hard. >>>> So how to pass references around? >>>> >>>> Any help will be very much appreciated. >>>> >>>> Frans >>>> _______________________________________________ >>>> 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 > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Sat Aug 16 04:54:12 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Fri, 15 Aug 2014 22:54:12 -0400 Subject: [erlang-questions] Unable to call functions that are in a module in the same location Message-ID: Hello, This is my code: https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 When I run my code inside of erlang (17.0), this is the error that I get: 7> genotype:create_test(). {aborted,{undef,[{morphology,undefined,[sensors],[]}, {morphology,get_InitSensors,1, [{file,"morphology.erl"},{line,8}]}, {genotype,construct_Cortex,3, [{file,"genotype.erl"},{line,41}]}, {genotype,construct_Agent,3, [{file,"genotype.erl"},{line,20}]}, {genotype,'-create_test/0-fun-0-',0, [{file,"genotype.erl"},{line,434}]}, {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, {mnesia_tm,execute_transaction,5, [{file,"mnesia_tm.erl"},{line,813}]}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} genotype.erl and morphology.erl are in the directory, so why can't genotype's function call morphology's functions? Or am I missing something else entirely? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Sat Aug 16 08:35:10 2014 From: steve@REDACTED (Steve Strong) Date: Sat, 16 Aug 2014 08:35:10 +0200 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: I'm guessing that this: Morphology = SpecCon#constraint.morphology, Is setting Morphology to 'undefined' - that's what the stack trace looks to be saying. Cheers, Steve Sent from my iPhone > On 16 Aug 2014, at 04:54, "Yves S. Garret" wrote: > > Hello, > > This is my code: > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > When I run my code inside of erlang (17.0), this is the error that I get: > 7> genotype:create_test(). > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > {morphology,get_InitSensors,1, > [{file,"morphology.erl"},{line,8}]}, > {genotype,construct_Cortex,3, > [{file,"genotype.erl"},{line,41}]}, > {genotype,construct_Agent,3, > [{file,"genotype.erl"},{line,20}]}, > {genotype,'-create_test/0-fun-0-',0, > [{file,"genotype.erl"},{line,434}]}, > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > {mnesia_tm,execute_transaction,5, > [{file,"mnesia_tm.erl"},{line,813}]}, > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > genotype.erl and morphology.erl are in the directory, so why can't genotype's function call morphology's functions? Or am I missing something else entirely? > > Thanks. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From devgutt@REDACTED Sat Aug 16 06:08:16 2014 From: devgutt@REDACTED (Gustavo Pires) Date: Sat, 16 Aug 2014 01:08:16 -0300 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: What's the content of the record "constraint" in SpecCon? It seems the field SpecCon#constraint.morphology is undefined. On Fri, Aug 15, 2014 at 11:54 PM, Yves S. Garret wrote: > Hello, > > This is my code: > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > When I run my code inside of erlang (17.0), this is the error that I get: > 7> genotype:create_test(). > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > {morphology,get_InitSensors,1, > [{file,"morphology.erl"},{line,8}]}, > {genotype,construct_Cortex,3, > [{file,"genotype.erl"},{line,41}]}, > {genotype,construct_Agent,3, > [{file,"genotype.erl"},{line,20}]}, > {genotype,'-create_test/0-fun-0-',0, > [{file,"genotype.erl"},{line,434}]}, > > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > {mnesia_tm,execute_transaction,5, > [{file,"mnesia_tm.erl"},{line,813}]}, > > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > genotype.erl and morphology.erl are in the directory, so why can't > genotype's function call morphology's functions? Or am I missing something > else entirely? > > Thanks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Sun Aug 17 05:56:15 2014 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Sun, 17 Aug 2014 12:56:15 +0900 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: Has anyone ever done any /science/ on what makes a language easily learned, especially by children? Making language design decisions based on similarity to existing popular/trendy languages reminds me of that joke about the drunk looking for his keys under a lamppost. When asked where he might have dropped them, he gestures off into the darkness. When asked the obvious question about THAT, he defends his search strategy by saying that he's looking here because the light is stronger. To find the keys, we might be better off letting our eyes adjust to the dark. That's what science is for: controlling conditions so that something that's hypothesized can become distinguishable against background noise. One nice thing about such an approach is that we can often break out of habits of thought that have obscured reality by noticing something we didn't expect, popping out against that background. A very cool thing about the web is that enables this kind of research as never before. Iterating over the standard core concepts and styles in programming languages, one might propose syntax and semantics for each concept, provide a code snippet for it, throw it out to many untutored eyes and ask, "What do you guess this would do?" We might frame each of these snippets with a theory about what works, only to discover that the misconceptions that arise about it are telling us something very interesting about some other aspect of coding entirely, not the one we're trying to explore. The results of such experiments might finally put to rest (in the minds of the rational, anyway) many of these syntax religion conflicts, which are mostly about as silly as the war between Blefescu and Lilliput. Such a research program might also answer long-standing questions about much deeper issues in programming language design, such as why it's been so hard to pin down a definition of "object-orientation" that's both pleasingly intuitive and semantically rigorous. Regards, Michael Turner Executive Director Project Persephone K-1 bldg 3F 7-2-6 Nishishinjuku Shinjuku-ku Tokyo 160-0023 Tel: +81 (3) 6890-1140 Fax: +81 (3) 6890-1158 Mobile: +81 (90) 5203-8682 turner@REDACTED http://www.projectpersephone.org/ "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exup?ry On Mon, Aug 11, 2014 at 9:08 AM, wrote: > > > We do Potion which is a new language on the BEAM+OTP with a Lua inspired > > syntax instead. This would have many benefits: > > > > - It would make it much easier for a large group of programmers to get > > into > > the erlang fold. > > Where is the evidence for this? > > If Luerl didn't achieve it, why would Potion? > > > - The syntax would be simpler that elixir and would avoid some of its > > idiosyncrasies. > > > - Lua is a fun language to start with. > > Did you ever have the feeling that when you got up in the morning > you stepped into the wrong parallel universe? > I've had Lua on my Macs for years. > About once a year I stumble across it by accident while searching > for something else, and say "oh YEAH, I forgot about that, time to > put it to use." I then download the latest release, re-read the > manual, wake up, finish re-reading the manual, and when I've > stopped yawning, go and do something more enjoyable, like marking > or cleaning the bathroom. > > As far as I can see, the two virtues of Lua are > > (1) Lua the *language* is a small ho-hum language with a > small embeddable implementation that you can easily hook > into and use as an extension language. That's presumably > why LuaTeX exists. > > (2) Lua the *system* comes with things like luarocks and a > useful library of user-contributed extensions like i18n. > This is the bit I personally find attractive, or would > if I couldn't get the things I want in other languages. > > A language that is only Lua-*like* sacrifices pretty much all > of (2), which is to say sacrifices most of the reason why I > would ever consider using Lua for anything. > > Perhaps the most ho-hum aspect of Lua is its heavy dependence > on mutable state, making error handling the familiar terror it > was before Erlang. > > It might not be unfair to describe Lua as a small Javascript > done right and luarocks as npm. If the same engineering work > of making Javascript less of a dog had been put into Lua... > > > > _______________________________________________ > 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 Sun Aug 17 06:53:46 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Sun, 17 Aug 2014 16:53:46 +1200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: <655B3AD4-E2B5-4744-8EF1-EA30B5C2BBC7@cs.otago.ac.nz> On 17/08/2014, at 3:56 PM, Michael Turner wrote: > Has anyone ever done any /science/ on what makes a language easily learned, especially by children? The Psychology of Programming Interest Group would be the right people to ask about that. For example, the PPIG2014 conference in June had a paper "Educational Programming Languages: The Motivation to Learn with Sonic Pi" by Arabella Jane Sinclair. Check http://www.sussex.ac.uk/Users/bend/ppig2014/ > A very cool thing about the web is that enables this kind of research as never before. Iterating over the standard core concepts and styles in programming languages, one might propose syntax and semantics for each concept, provide a code snippet for it, throw it out to many untutored eyes and ask, "What do you guess this would do?" To be honest, I would not expect anything of value from that. When I was learning to program, three common mistakes made by others were - treating "IF (expr) stmt" as a declarative "WHENEVER expr becomes true, do stmt" - treating "WHILE (expr) stmt" as a declarative "AS SOON AS expr, stop doing stmt." - treating "var = expr" as a declarative and assuming that the order of such statements did not matter. "Untutored eyes" found no real concept in the brain behind them of what such things *might* mean. If someone doesn't "get" some syntax, maybe they don't have the concept and wouldn't "get" it no matter *what* the syntax was. To me it's obvious that prices := items par collect: [:each | each totalPrice] is a parallel map, but it *cannot* be understood by anyone who doesn't already know what a parallel map *is*, and such a one has already been exposed to some programming language, so dear old "familiar = better" lifts its hoary head and starts biting again. As a teenager, I was motivated to learn how to build ham radios and did learn enough electronics to do so. I was *not* motivated enough to learn Morse Code -- I could transmit on 144 MHz and above without that -- so I didn't. (My licence lapsed years ago, but I was ZL1TQW for a little while.) I and some others in the school computer club were sufficiently motivated to learn portapunch Fortran, *not* something ever designed to be child-friendly. LOGO was learnable by schoolchildren, even ones sufficiently immature to think that naming variables and procedures with swearwords was funny. For that matter, micro-PROLOG was learnable by schoolchildren. With the possible exception of joke languages like Intercal and Brain*uck, I suspect that "youngsters" can learn *any* programming language their elders would be willing to use *IF* they want to, and they'll want to if they believe that something of value to *them* will be the outcome. I hate saying this. No, it makes me *SICK* to say this, but there is a sense in which the most learnable language at the moment is Javascript. There's pretty much immediate payoff from putting even a modest amount of Javascript into a web page. > We might frame each of these snippets with a theory about what works, only to discover that the misconceptions that arise about it are telling us something very interesting about some other aspect of coding entirely, not the one we're trying to explore. Now *that* I believe. The one software engineering experiment I tried, where the research question "are nice_identifiers easier to read than uglyNastyOnes" didn't get answered, but "are students willing to read 2 pages of code without a syntax-colouring editor and a debugger" was. (The answer was "no.") > The results of such experiments might finally put to rest (in the minds of the rational, anyway) many of these syntax religion conflicts, Bet you $50 it doesn't happen in my lifetime? One problem is that programming languages are tangled up with libraries and application areas. People are always going to think "Foo [which happens to provide extensive high-quality libraries for the things I mostly do] is easy to use and understand for my purposes, therefore Foo syntax is the best." From ivan@REDACTED Sun Aug 17 11:42:11 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sun, 17 Aug 2014 10:42:11 +0100 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: <655B3AD4-E2B5-4744-8EF1-EA30B5C2BBC7@cs.otago.ac.nz> References: <655B3AD4-E2B5-4744-8EF1-EA30B5C2BBC7@cs.otago.ac.nz> Message-ID: <9D95CC09-18C5-4675-AE16-D55D995E281D@llaisdy.com> I agree with Richard about Javascript. It's like teaching human languages to school children. In the UK they tend to teach French, & maybe Spanish. The choice is not about "easy to learn" it's about motivation (or learner parent motivation --- i.e., holiday destinations. Some schools will teach think more about "jobs" and teach German, Japanese or nowadays Mandarin. Again the consideration is learner motivation). Targetting the browser platform is an easy way to provide motivation. It also promotes independent learning - as every computer has a web browser and a text editor. Ivan -- festina lente > On 17 Aug 2014, at 05:53, "Richard A. O'Keefe" wrote: > > >> On 17/08/2014, at 3:56 PM, Michael Turner wrote: >> Has anyone ever done any /science/ on what makes a language easily learned, especially by children? > > The Psychology of Programming Interest Group would be the right > people to ask about that. > > For example, the PPIG2014 conference in June had a paper > "Educational Programming Languages: The Motivation to Learn > with Sonic Pi" by Arabella Jane Sinclair. > Check http://www.sussex.ac.uk/Users/bend/ppig2014/ > > >> A very cool thing about the web is that enables this kind of research as never before. Iterating over the standard core concepts and styles in programming languages, one might propose syntax and semantics for each concept, provide a code snippet for it, throw it out to many untutored eyes and ask, "What do you guess this would do?" > > To be honest, I would not expect anything of value from that. > When I was learning to program, three common mistakes made by > others were > - treating "IF (expr) stmt" as a declarative "WHENEVER > expr becomes true, do stmt" > - treating "WHILE (expr) stmt" as a declarative "AS SOON AS > expr, stop doing stmt." > - treating "var = expr" as a declarative and assuming that > the order of such statements did not matter. > "Untutored eyes" found no real concept in the brain behind them > of what such things *might* mean. If someone doesn't "get" some > syntax, maybe they don't have the concept and wouldn't "get" it > no matter *what* the syntax was. To me it's obvious that > prices := items par collect: [:each | each totalPrice] > is a parallel map, but it *cannot* be understood by anyone who > doesn't already know what a parallel map *is*, and such a one > has already been exposed to some programming language, so dear > old "familiar = better" lifts its hoary head and starts biting again. > > As a teenager, I was motivated to learn how to build ham radios > and did learn enough electronics to do so. I was *not* motivated > enough to learn Morse Code -- I could transmit on 144 MHz and > above without that -- so I didn't. (My licence lapsed years ago, > but I was ZL1TQW for a little while.) I and some others in the > school computer club were sufficiently motivated to learn > portapunch Fortran, *not* something ever designed to be child-friendly. > > LOGO was learnable by schoolchildren, even ones sufficiently > immature to think that naming variables and procedures with > swearwords was funny. For that matter, micro-PROLOG was learnable > by schoolchildren. > > With the possible exception of joke languages like Intercal and > Brain*uck, I suspect that "youngsters" can learn *any* programming > language their elders would be willing to use *IF* they want to, > and they'll want to if they believe that something of value to > *them* will be the outcome. > > I hate saying this. No, it makes me *SICK* to say this, but > there is a sense in which the most learnable language at the > moment is Javascript. There's pretty much immediate payoff > from putting even a modest amount of Javascript into a web page. > >> We might frame each of these snippets with a theory about what works, only to discover that the misconceptions that arise about it are telling us something very interesting about some other aspect of coding entirely, not the one we're trying to explore. > > Now *that* I believe. The one software engineering experiment I > tried, where the research question "are nice_identifiers easier > to read than uglyNastyOnes" didn't get answered, but "are students > willing to read 2 pages of code without a syntax-colouring editor > and a debugger" was. (The answer was "no.") > >> The results of such experiments might finally put to rest (in the minds of the rational, anyway) many of these syntax religion conflicts, > > Bet you $50 it doesn't happen in my lifetime? > > One problem is that programming languages are tangled up > with libraries and application areas. People are always > going to think "Foo [which happens to provide extensive > high-quality libraries for the things I mostly do] is easy > to use and understand for my purposes, therefore Foo syntax > is the best." > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mahesh@REDACTED Sun Aug 17 13:33:59 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Sun, 17 Aug 2014 07:33:59 -0400 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: <9D95CC09-18C5-4675-AE16-D55D995E281D@llaisdy.com> References: <655B3AD4-E2B5-4744-8EF1-EA30B5C2BBC7@cs.otago.ac.nz> <9D95CC09-18C5-4675-AE16-D55D995E281D@llaisdy.com> Message-ID: In this vein, take a peek at Sam Aaron's talk from CodeMesh 2013 --> http://vimeo.com/85930562 TL;DR --> The ability to generate music has kids writing Clojure in Emacs in virtually no time. Ok. its a bit more than that - the kids don't particularly care about the "Clojure" part or the "Emacs" part - but they do, deeply, care about the "generating music" part - and the "Clojure" / "Emacs" part is just the means to the end. As Ivan pointed out, the key is learner motivation, something that a lot of us have forgotten along the way. Remember the awesomeness of Apple II and BASIC? Especially when you discovered what you could do with PEEK, POKE, and sprites? (Yes, dating myself) Or the equivalent awesomeness of ASCII art and line-printers (Yes, more dating). The point is - in both case, you didn't give a s**t about the _computer_ - it was computer games, and art, that was the key... Cheers p.s. For bonus dating-credit, the sheer-joy of realizing that the line-printers could be used to play music - depending on the line that was printerd, you could get different frequencies. Awesome! (The Indian National Anthem was one of the first things that you'd learn to play...) On Sun, Aug 17, 2014 at 5:42 AM, Ivan Uemlianin wrote: > I agree with Richard about Javascript. > > It's like teaching human languages to school children. In the UK they tend > to teach French, & maybe Spanish. The choice is not about "easy to learn" > it's about motivation (or learner parent motivation --- i.e., holiday > destinations. Some schools will teach think more about "jobs" and teach > German, Japanese or nowadays Mandarin. Again the consideration is learner > motivation). > > Targetting the browser platform is an easy way to provide motivation. It > also promotes independent learning - as every computer has a web browser > and a text editor. > > Ivan > > -- > festina lente > > > > On 17 Aug 2014, at 05:53, "Richard A. O'Keefe" > wrote: > > > > > >> On 17/08/2014, at 3:56 PM, Michael Turner wrote: > >> Has anyone ever done any /science/ on what makes a language easily > learned, especially by children? > > > > The Psychology of Programming Interest Group would be the right > > people to ask about that. > > > > For example, the PPIG2014 conference in June had a paper > > "Educational Programming Languages: The Motivation to Learn > > with Sonic Pi" by Arabella Jane Sinclair. > > Check http://www.sussex.ac.uk/Users/bend/ppig2014/ > > > > > >> A very cool thing about the web is that enables this kind of research > as never before. Iterating over the standard core concepts and styles in > programming languages, one might propose syntax and semantics for each > concept, provide a code snippet for it, throw it out to many untutored eyes > and ask, "What do you guess this would do?" > > > > To be honest, I would not expect anything of value from that. > > When I was learning to program, three common mistakes made by > > others were > > - treating "IF (expr) stmt" as a declarative "WHENEVER > > expr becomes true, do stmt" > > - treating "WHILE (expr) stmt" as a declarative "AS SOON AS > > expr, stop doing stmt." > > - treating "var = expr" as a declarative and assuming that > > the order of such statements did not matter. > > "Untutored eyes" found no real concept in the brain behind them > > of what such things *might* mean. If someone doesn't "get" some > > syntax, maybe they don't have the concept and wouldn't "get" it > > no matter *what* the syntax was. To me it's obvious that > > prices := items par collect: [:each | each totalPrice] > > is a parallel map, but it *cannot* be understood by anyone who > > doesn't already know what a parallel map *is*, and such a one > > has already been exposed to some programming language, so dear > > old "familiar = better" lifts its hoary head and starts biting again. > > > > As a teenager, I was motivated to learn how to build ham radios > > and did learn enough electronics to do so. I was *not* motivated > > enough to learn Morse Code -- I could transmit on 144 MHz and > > above without that -- so I didn't. (My licence lapsed years ago, > > but I was ZL1TQW for a little while.) I and some others in the > > school computer club were sufficiently motivated to learn > > portapunch Fortran, *not* something ever designed to be child-friendly. > > > > LOGO was learnable by schoolchildren, even ones sufficiently > > immature to think that naming variables and procedures with > > swearwords was funny. For that matter, micro-PROLOG was learnable > > by schoolchildren. > > > > With the possible exception of joke languages like Intercal and > > Brain*uck, I suspect that "youngsters" can learn *any* programming > > language their elders would be willing to use *IF* they want to, > > and they'll want to if they believe that something of value to > > *them* will be the outcome. > > > > I hate saying this. No, it makes me *SICK* to say this, but > > there is a sense in which the most learnable language at the > > moment is Javascript. There's pretty much immediate payoff > > from putting even a modest amount of Javascript into a web page. > > > >> We might frame each of these snippets with a theory about what works, > only to discover that the misconceptions that arise about it are telling us > something very interesting about some other aspect of coding entirely, not > the one we're trying to explore. > > > > Now *that* I believe. The one software engineering experiment I > > tried, where the research question "are nice_identifiers easier > > to read than uglyNastyOnes" didn't get answered, but "are students > > willing to read 2 pages of code without a syntax-colouring editor > > and a debugger" was. (The answer was "no.") > > > >> The results of such experiments might finally put to rest (in the minds > of the rational, anyway) many of these syntax religion conflicts, > > > > Bet you $50 it doesn't happen in my lifetime? > > > > One problem is that programming languages are tangled up > > with libraries and application areas. People are always > > going to think "Foo [which happens to provide extensive > > high-quality libraries for the things I mostly do] is easy > > to use and understand for my purposes, therefore Foo syntax > > is the best." > > > > _______________________________________________ > > 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 lloyd@REDACTED Sun Aug 17 15:30:55 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 17 Aug 2014 09:30:55 -0400 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: <655B3AD4-E2B5-4744-8EF1-EA30B5C2BBC7@cs.otago.ac.nz> <9D95CC09-18C5-4675-AE16-D55D995E281D@llaisdy.com> Message-ID: Hello, Dr. Seymour Pappert has done seminal work that may be well worth looking at: Seymour Papert's Vision for Early Childhood Education? A Descriptive Study of Head Start and Kindergarten Students in Discovery-based, Logo-rich Classrooms http://ecrp.uiuc.edu/v6n1/gillespie.html All the best, LRP Sent from my iPad > On Aug 17, 2014, at 7:33 AM, Mahesh Paolini-Subramanya wrote: > > In this vein, take a peek at Sam Aaron's talk from CodeMesh 2013 --> http://vimeo.com/85930562 > TL;DR --> The ability to generate music has kids writing Clojure in Emacs in virtually no time. > Ok. its a bit more than that - the kids don't particularly care about the "Clojure" part or the "Emacs" part - but they do, deeply, care about the "generating music" part - and the "Clojure" / "Emacs" part is just the means to the end. > > As Ivan pointed out, the key is learner motivation, something that a lot of us have forgotten along the way. > Remember the awesomeness of Apple II and BASIC? Especially when you discovered what you could do with PEEK, POKE, and sprites? (Yes, dating myself) > Or the equivalent awesomeness of ASCII art and line-printers (Yes, more dating). > The point is - in both case, you didn't give a s**t about the _computer_ - it was computer games, and art, that was the key... > > Cheers > > p.s. For bonus dating-credit, the sheer-joy of realizing that the line-printers could be used to play music - depending on the line that was printerd, you could get different frequencies. Awesome! (The Indian National Anthem was one of the first things that you'd learn to play...) > > >> On Sun, Aug 17, 2014 at 5:42 AM, Ivan Uemlianin wrote: >> I agree with Richard about Javascript. >> >> It's like teaching human languages to school children. In the UK they tend to teach French, & maybe Spanish. The choice is not about "easy to learn" it's about motivation (or learner parent motivation --- i.e., holiday destinations. Some schools will teach think more about "jobs" and teach German, Japanese or nowadays Mandarin. Again the consideration is learner motivation). >> >> Targetting the browser platform is an easy way to provide motivation. It also promotes independent learning - as every computer has a web browser and a text editor. >> >> Ivan >> >> -- >> festina lente >> >> >> > On 17 Aug 2014, at 05:53, "Richard A. O'Keefe" wrote: >> > >> > >> >> On 17/08/2014, at 3:56 PM, Michael Turner wrote: >> >> Has anyone ever done any /science/ on what makes a language easily learned, especially by children? >> > >> > The Psychology of Programming Interest Group would be the right >> > people to ask about that. >> > >> > For example, the PPIG2014 conference in June had a paper >> > "Educational Programming Languages: The Motivation to Learn >> > with Sonic Pi" by Arabella Jane Sinclair. >> > Check http://www.sussex.ac.uk/Users/bend/ppig2014/ >> > >> > >> >> A very cool thing about the web is that enables this kind of research as never before. Iterating over the standard core concepts and styles in programming languages, one might propose syntax and semantics for each concept, provide a code snippet for it, throw it out to many untutored eyes and ask, "What do you guess this would do?" >> > >> > To be honest, I would not expect anything of value from that. >> > When I was learning to program, three common mistakes made by >> > others were >> > - treating "IF (expr) stmt" as a declarative "WHENEVER >> > expr becomes true, do stmt" >> > - treating "WHILE (expr) stmt" as a declarative "AS SOON AS >> > expr, stop doing stmt." >> > - treating "var = expr" as a declarative and assuming that >> > the order of such statements did not matter. >> > "Untutored eyes" found no real concept in the brain behind them >> > of what such things *might* mean. If someone doesn't "get" some >> > syntax, maybe they don't have the concept and wouldn't "get" it >> > no matter *what* the syntax was. To me it's obvious that >> > prices := items par collect: [:each | each totalPrice] >> > is a parallel map, but it *cannot* be understood by anyone who >> > doesn't already know what a parallel map *is*, and such a one >> > has already been exposed to some programming language, so dear >> > old "familiar = better" lifts its hoary head and starts biting again. >> > >> > As a teenager, I was motivated to learn how to build ham radios >> > and did learn enough electronics to do so. I was *not* motivated >> > enough to learn Morse Code -- I could transmit on 144 MHz and >> > above without that -- so I didn't. (My licence lapsed years ago, >> > but I was ZL1TQW for a little while.) I and some others in the >> > school computer club were sufficiently motivated to learn >> > portapunch Fortran, *not* something ever designed to be child-friendly. >> > >> > LOGO was learnable by schoolchildren, even ones sufficiently >> > immature to think that naming variables and procedures with >> > swearwords was funny. For that matter, micro-PROLOG was learnable >> > by schoolchildren. >> > >> > With the possible exception of joke languages like Intercal and >> > Brain*uck, I suspect that "youngsters" can learn *any* programming >> > language their elders would be willing to use *IF* they want to, >> > and they'll want to if they believe that something of value to >> > *them* will be the outcome. >> > >> > I hate saying this. No, it makes me *SICK* to say this, but >> > there is a sense in which the most learnable language at the >> > moment is Javascript. There's pretty much immediate payoff >> > from putting even a modest amount of Javascript into a web page. >> > >> >> We might frame each of these snippets with a theory about what works, only to discover that the misconceptions that arise about it are telling us something very interesting about some other aspect of coding entirely, not the one we're trying to explore. >> > >> > Now *that* I believe. The one software engineering experiment I >> > tried, where the research question "are nice_identifiers easier >> > to read than uglyNastyOnes" didn't get answered, but "are students >> > willing to read 2 pages of code without a syntax-colouring editor >> > and a debugger" was. (The answer was "no.") >> > >> >> The results of such experiments might finally put to rest (in the minds of the rational, anyway) many of these syntax religion conflicts, >> > >> > Bet you $50 it doesn't happen in my lifetime? >> > >> > One problem is that programming languages are tangled up >> > with libraries and application areas. People are always >> > going to think "Foo [which happens to provide extensive >> > high-quality libraries for the things I mostly do] is easy >> > to use and understand for my purposes, therefore Foo syntax >> > is the best." >> > >> > _______________________________________________ >> > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Sun Aug 17 15:33:21 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Sun, 17 Aug 2014 09:33:21 -0400 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: This is it: -record(sensor, {id, name, cx_id, scape, vl, fanout_ids = [], generation}). -record(actuator, {id, name, cx_id, scape, vl, fanin_ids = [], generation}). -record(neuron, {id, generation, cx_id, af, input_idps = [], output_ids = [], ro_ids = []}). -record(cortex, {id, agent_id, neuron_ids = [], sensor_ids = [], actuator_ids = []}). -record(agent, {id, generation, population_id, specie_id, cx_id, fingerprint, constraint, evo_hist = [], fitness, innovation_factor = 0, pattern = []}). -record(specie, {id, population_id, fingerprint, constraint, agent_ids = [], champion_ids = [], dead_pool = [], fitness, innovation_factor = 0}). -record(population, {id, polis_id, specie_ids = [], morphologies = [], innovation_factor}). -record(constraint, {morphology = xor_mimic, neural_afs = [tanh, cos, gauss, abs]}). On Sat, Aug 16, 2014 at 2:35 AM, Steve Strong wrote: > I'm guessing that this: > > Morphology = SpecCon#constraint.morphology, > > > Is setting Morphology to 'undefined' - that's what the stack trace looks > to be saying. > > Cheers, > > Steve > > Sent from my iPhone > > On 16 Aug 2014, at 04:54, "Yves S. Garret" > wrote: > > Hello, > > This is my code: > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > When I run my code inside of erlang (17.0), this is the error that I get: > 7> genotype:create_test(). > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > {morphology,get_InitSensors,1, > [{file,"morphology.erl"},{line,8}]}, > {genotype,construct_Cortex,3, > [{file,"genotype.erl"},{line,41}]}, > {genotype,construct_Agent,3, > [{file,"genotype.erl"},{line,20}]}, > {genotype,'-create_test/0-fun-0-',0, > [{file,"genotype.erl"},{line,434}]}, > > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > {mnesia_tm,execute_transaction,5, > [{file,"mnesia_tm.erl"},{line,813}]}, > > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > genotype.erl and morphology.erl are in the directory, so why can't > genotype's function call morphology's functions? Or am I missing something > else entirely? > > Thanks. > > _______________________________________________ > > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Sun Aug 17 15:36:37 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Sun, 17 Aug 2014 09:36:37 -0400 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: The record in question is "constraint". The thing is, when I call it, it looks like this with none of the values initialized: test() -> Specie_Id = test, Agent_Id = test, CloneAgent_Id = test_clone, SpecCon = #constraint{}, % <---- HERE IS WHERE THE FIRST INSTANCE IS CREATED F = fun() -> construct_Agent(Specie_Id, Agent_Id, SpecCon), clone_Agent(Specie_Id, CloneAgent_Id), print(Agent_Id), print(CloneAgent_Id), delete_Agent(Agent_Id), delete_Agent(CloneAgent_Id) end, mnesia:transaction(F). My question is thus, if I make a record with #constraint{}, does that mean that all of its values are by default set to undefined or the default values that were specified in records.hrl? On Sat, Aug 16, 2014 at 2:35 AM, Steve Strong wrote: > I'm guessing that this: > > Morphology = SpecCon#constraint.morphology, > > > Is setting Morphology to 'undefined' - that's what the stack trace looks > to be saying. > > Cheers, > > Steve > > Sent from my iPhone > > On 16 Aug 2014, at 04:54, "Yves S. Garret" > wrote: > > Hello, > > This is my code: > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > When I run my code inside of erlang (17.0), this is the error that I get: > 7> genotype:create_test(). > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > {morphology,get_InitSensors,1, > [{file,"morphology.erl"},{line,8}]}, > {genotype,construct_Cortex,3, > [{file,"genotype.erl"},{line,41}]}, > {genotype,construct_Agent,3, > [{file,"genotype.erl"},{line,20}]}, > {genotype,'-create_test/0-fun-0-',0, > [{file,"genotype.erl"},{line,434}]}, > > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > {mnesia_tm,execute_transaction,5, > [{file,"mnesia_tm.erl"},{line,813}]}, > > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > genotype.erl and morphology.erl are in the directory, so why can't > genotype's function call morphology's functions? Or am I missing something > else entirely? > > Thanks. > > _______________________________________________ > > 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 Aug 17 15:44:18 2014 From: n.oxyde@REDACTED (Anthony) Date: Sun, 17 Aug 2014 15:44:18 +0200 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: <56A85D5B-7A5E-48DF-B9E9-ADD2C4CCB22B@gmail.com> The latter. -- Anthony Ramine Le 17 ao?t 2014 ? 15:36, Yves S. Garret a ?crit : > My question is thus, if I make a record with #constraint{}, does that mean that all of its values are by default set to undefined or the default values that were specified in records.hrl? From francesco@REDACTED Sun Aug 17 16:38:18 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sun, 17 Aug 2014 15:38:18 +0100 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: References: Message-ID: <53F0BE5A.2040609@erlang-solutions.com> The IT University of Gothenburg started using it as a second language (after Java) in 2003. It was as part of the second year project term, and at one point, also used in the AI course. Francesco On 14/08/2014 23:51, Juan Jose Comellas wrote: > That is really cool! I've been working in Erlang for about 8 years in > Argentina and I never knew a university there was using it as part of > its curriculum. > > > On Wed, Aug 13, 2014 at 6:38 PM, Guido Rumi > wrote: > > Universidad Nacional de Rosario (Rosario-Santa Fe, Argentina) also > teaches Erlang. It's used to teach concurrency, message passing > between processes, etc. as part of the first course of Operating > Systems in Computer Science. To finish the course it's required to > program a mock Distributed File System in Erlang and an other > version in C. That made me realize the benefits of using Erlang in > concurrent systems, the version coded in C was much more tedious > to accomplish and debugging was an issue. > > Links: http://www.fceia.unr.edu.ar/lcc/r322/enlaces.php > > > > > On Tue, Aug 12, 2014 at 2:23 AM, Rustom Mody > > wrote: > > Hi > I am collecting material about univs starting programming with > functional programming: > http://blog.languager.org/2014/08/universities-starting-functional.html > > Erlang figures but only in 2nd/'advanced' courses. > Are there any cases where Erlang is used to start teaching > programming? > > Thanks > Rusi > > _______________________________________________ > 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 -- Founder & Technical Director Erlang Solutions Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Sun Aug 17 18:07:23 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sun, 17 Aug 2014 17:07:23 +0100 Subject: [erlang-questions] Reltool anyone? Message-ID: <53F0D33B.4050308@erlang-solutions.com> Hi, I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. Feel free to reply to the list or ping me privately. Thanks, F -- Founder & Technical Director Erlang Solutions Ltd. From essen@REDACTED Sun Aug 17 18:15:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 17 Aug 2014 18:15:41 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D33B.4050308@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <53F0D52D.1030503@ninenines.eu> Releases were a real pain until relx appeared. Teaching reltool today seems quite counter productive, it is the kind of knowledge that you want tool implementors to have, but not normal users. On 08/17/2014 06:07 PM, Francesco Cesarini wrote: > Hi, > > I was wrapping up the chapter on release handling for the OTP book and > never having used it before, decided to take a look at reltool. Is > anyone using it? I am finding it counter intuitive and struggling to see > how it simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > -- Lo?c Hoguin http://ninenines.eu From ulf@REDACTED Sun Aug 17 18:23:09 2014 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 17 Aug 2014 18:23:09 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D52D.1030503@ninenines.eu> References: <53F0D33B.4050308@erlang-solutions.com> <53F0D52D.1030503@ninenines.eu> Message-ID: On 17 Aug 2014, at 18:15, Lo?c Hoguin wrote: > Teaching reltool today seems quite counter productive, it is the kind of knowledge that you want tool implementors to have, but not normal users. True, but even when using reltool via rebar, you end up having to understand quite a lot about reltool. The only things rebar actually helps with are (1) generating a template for you to modify, and (2) actually starting reltool. But extending the reltool.config and understanding why it bombs tend to throw you deep into the mysteries of reltool, and rebar does practically nothing to buffer this. If something needs to be documented in this area, it would be Troubleshooting Reltool, IMHO: what are the typical errors, and how do they manifest themselves? BR, Ulf W (I was quite instrumental in advising Dizzy to use reltool in rebar at the time, so for those of you who are unhappy about that choice, feel free to blame me. The thinking was that rebar should rely on core OTP functionality rather than compete with it.) Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From tristan.sloughter@REDACTED Sun Aug 17 18:23:25 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 17 Aug 2014 11:23:25 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D33B.4050308@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: I'm pretty sure "counter intuitive" and "will make your struggle" are reltool's best known features. Which is why relx (https://github.com/erlware/relx) has been catching on :) On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini < francesco@REDACTED> wrote: > Hi, > > I was wrapping up the chapter on release handling for the OTP book and > never having used it before, decided to take a look at reltool. Is anyone > using it? I am finding it counter intuitive and struggling to see how it > simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > _______________________________________________ > 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 Sun Aug 17 18:23:53 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 17 Aug 2014 12:23:53 -0400 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D33B.4050308@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <20140817162352.GB71984@ferdmbp.local> As said before, Reltool is really more complex. Rebar, by default, wraps around reltool, so that's what a lot of people use, but as far as I know, everyone seems to be doing what is more or less copy/pasting. I've personally re-documented Reltool in Learn You Some Erlang, including a few recipes: http://learnyousomeerlang.com/release-is-the-word#releases-with-reltool Regards, Fred. On 08/17, Francesco Cesarini wrote: > Hi, > > I was wrapping up the chapter on release handling for the OTP book and never > having used it before, decided to take a look at reltool. Is anyone using > it? I am finding it counter intuitive and struggling to see how it > simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tristan.sloughter@REDACTED Sun Aug 17 18:24:38 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 17 Aug 2014 11:24:38 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <53F0D52D.1030503@ninenines.eu> Message-ID: Yes, rebar does nothing to help with reltool. And I'd argue it almost makes it worse. Loic points to https://github.com/erlware/relx not to rebar. Though hopefully rebar will use relx instead of reltool soon enough. On Sun, Aug 17, 2014 at 11:23 AM, Ulf Wiger wrote: > > On 17 Aug 2014, at 18:15, Lo?c Hoguin wrote: > > > Teaching reltool today seems quite counter productive, it is the kind of > knowledge that you want tool implementors to have, but not normal users. > > True, but even when using reltool via rebar, you end up having to > understand quite a lot about reltool. The only things rebar actually helps > with are (1) generating a template for you to modify, and (2) actually > starting reltool. But extending the reltool.config and understanding why it > bombs tend to throw you deep into the mysteries of reltool, and rebar does > practically nothing to buffer this. > > If something needs to be documented in this area, it would be > Troubleshooting Reltool, IMHO: what are the typical errors, and how do they > manifest themselves? > > BR, > Ulf W > > (I was quite instrumental in advising Dizzy to use reltool in rebar at the > time, so for those of you who are unhappy about that choice, feel free to > blame me. The thinking was that rebar should rely on core OTP functionality > rather than compete with it.) > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Sun Aug 17 18:31:28 2014 From: steve@REDACTED (Steve Strong) Date: Sun, 17 Aug 2014 18:31:28 +0200 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: The record will be initialised with the defaults as specified in the hrl. The code and stacktrace in the gist still suggest that SpecCon#constraint.morphology is ?undefined? - so something between the record construction below and the crash within the gist must be modifying the record. -- Steve Strong Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Sunday, 17 August 2014 at 15:36, Yves S. Garret wrote: > The record in question is "constraint". The thing is, when I call it, it looks like this with none of the values initialized: > > test() -> > Specie_Id = test, > Agent_Id = test, > CloneAgent_Id = test_clone, > SpecCon = #constraint{}, % <---- HERE IS WHERE THE FIRST INSTANCE IS CREATED > F = fun() -> > construct_Agent(Specie_Id, Agent_Id, SpecCon), > clone_Agent(Specie_Id, CloneAgent_Id), > print(Agent_Id), > print(CloneAgent_Id), > delete_Agent(Agent_Id), > delete_Agent(CloneAgent_Id) > end, > > mnesia:transaction(F). > > My question is thus, if I make a record with #constraint{}, does that mean that all of its values are by default set to undefined or the default values that were specified in records.hrl? > > > > > On Sat, Aug 16, 2014 at 2:35 AM, Steve Strong wrote: > > I'm guessing that this: > > > > Morphology = SpecCon#constraint.morphology, > > > > Is setting Morphology to 'undefined' - that's what the stack trace looks to be saying. > > > > Cheers, > > > > Steve > > > > Sent from my iPhone > > > > On 16 Aug 2014, at 04:54, "Yves S. Garret" wrote: > > > > > Hello, > > > > > > This is my code: > > > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > > > > > When I run my code inside of erlang (17.0), this is the error that I get: > > > 7> genotype:create_test(). > > > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > > > {morphology,get_InitSensors,1, > > > [{file,"morphology.erl"},{line,8}]}, > > > {genotype,construct_Cortex,3, > > > [{file,"genotype.erl"},{line,41}]}, > > > {genotype,construct_Agent,3, > > > [{file,"genotype.erl"},{line,20}]}, > > > {genotype,'-create_test/0-fun-0-',0, > > > [{file,"genotype.erl"},{line,434}]}, > > > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > > > {mnesia_tm,execute_transaction,5, > > > [{file,"mnesia_tm.erl"},{line,813}]}, > > > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > > > > > genotype.erl and morphology.erl are in the directory, so why can't genotype's function call morphology's functions? Or am I missing something else entirely? > > > > > > Thanks. > > > _______________________________________________ > > > > > > 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 g@REDACTED Sun Aug 17 18:37:16 2014 From: g@REDACTED (Garrett Smith) Date: Sun, 17 Aug 2014 11:37:16 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: I always had the impression that the work on reltool was never completed. A chapter on reltool could highlight the fact that the core release tool that ships with Erlang [sic] is fubar, but I don't know how much value that would be to readers. The *only* release tool I've ever seen do anything useful - without causing me to punch a wall - is relx. It's useful. It has traction. I think it should get a chapter, somewhere. On Sun, Aug 17, 2014 at 11:23 AM, Tristan Sloughter wrote: > I'm pretty sure "counter intuitive" and "will make your struggle" are > reltool's best known features. > > Which is why relx (https://github.com/erlware/relx) has been catching on :) > > > On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini > wrote: >> >> Hi, >> >> I was wrapping up the chapter on release handling for the OTP book and >> never having used it before, decided to take a look at reltool. Is anyone >> using it? I am finding it counter intuitive and struggling to see how it >> simplifies the task of creating releases. >> >> Feel free to reply to the list or ping me privately. >> >> Thanks, >> F >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. >> >> _______________________________________________ >> 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 francesco@REDACTED Sun Aug 17 18:39:58 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sun, 17 Aug 2014 17:39:58 +0100 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <53F0DADE.6070404@erlang-solutions.com> We are covering relx and rebar and might add more tools based on feedback we receive from the reviewers. Also for those wondering - So far, we have about 30 pages on release handling. In line with the rest of the book, we are explaining in detail what is happening behind the scenes and how to manually create a release. From there, we show you how to automate it and use the tools. /F On 17/08/2014 17:23, Tristan Sloughter wrote: > I'm pretty sure "counter intuitive" and "will make your struggle" are > reltool's best known features. > > Which is why relx (https://github.com/erlware/relx) has been catching > on :) > > On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini > > wrote: > > Hi, > > I was wrapping up the chapter on release handling for the OTP book > and never having used it before, decided to take a look at > reltool. Is anyone using it? I am finding it counter intuitive and > struggling to see how it simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Founder & Technical Director Erlang Solutions Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sun Aug 17 18:58:51 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 17 Aug 2014 11:58:51 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0DADE.6070404@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> <53F0DADE.6070404@erlang-solutions.com> Message-ID: I find it confusing when books spend so much time on what should be considered more of an internals matter, like manually building a release, which is found in an appendix or online docs It isn't something you'd do in real life, but yes it is something you would benefit from knowing once you are dealing with building and deploying releases even when using a higher level tool like reltool or relx. Just my 2 cents :) On Sun, Aug 17, 2014 at 11:39 AM, Francesco Cesarini < francesco@REDACTED> wrote: > We are covering relx and rebar and might add more tools based on feedback > we receive from the reviewers. > > Also for those wondering - So far, we have about 30 pages on release > handling. In line with the rest of the book, we are explaining in detail > what is happening behind the scenes and how to manually create a release. > From there, we show you how to automate it and use the tools. > > /F > > > On 17/08/2014 17:23, Tristan Sloughter wrote: > > I'm pretty sure "counter intuitive" and "will make your struggle" are > reltool's best known features. > > Which is why relx (https://github.com/erlware/relx) has been catching on > :) > > On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini < > francesco@REDACTED> wrote: > >> Hi, >> >> I was wrapping up the chapter on release handling for the OTP book and >> never having used it before, decided to take a look at reltool. Is anyone >> using it? I am finding it counter intuitive and struggling to see how it >> simplifies the task of creating releases. >> >> Feel free to reply to the list or ping me privately. >> >> Thanks, >> F >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Sun Aug 17 19:47:38 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sun, 17 Aug 2014 19:47:38 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <53F0DADE.6070404@erlang-solutions.com> Message-ID: We are explaining how OTP works by explaining what is going on behind the scenes. A different approach I found out worked better when teaching behaviours than diving straight into callback hell. Release handling, on the other hand, has always been the black sheep because of the lack of a unified approach. Everyone has historically reached (potentially different) goals in different ways, often depending on what they were used to and comfortable with from previous (non Erlang) jobs. Buy me or Ulf a beer and we will tell you how release handling was done with the Axd301. You must have a strong stomach, as it is not for the faint of heart :-) F > On 17 Aug 2014, at 18:58, Tristan Sloughter wrote: > > I find it confusing when books spend so much time on what should be considered more of an internals matter, like manually building a release, which is found in an appendix or online docs > > It isn't something you'd do in real life, but yes it is something you would benefit from knowing once you are dealing with building and deploying releases even when using a higher level tool like reltool or relx. > > Just my 2 cents :) > > >> On Sun, Aug 17, 2014 at 11:39 AM, Francesco Cesarini wrote: >> We are covering relx and rebar and might add more tools based on feedback we receive from the reviewers. >> >> Also for those wondering - So far, we have about 30 pages on release handling. In line with the rest of the book, we are explaining in detail what is happening behind the scenes and how to manually create a release. From there, we show you how to automate it and use the tools. >> >> /F >> >> >>> On 17/08/2014 17:23, Tristan Sloughter wrote: >>> I'm pretty sure "counter intuitive" and "will make your struggle" are reltool's best known features. >>> >>> Which is why relx (https://github.com/erlware/relx) has been catching on :) >>> >>>> On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini wrote: >>>> Hi, >>>> >>>> I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. >>>> >>>> Feel free to reply to the list or ping me privately. >>>> >>>> Thanks, >>>> F >>>> >>>> -- >>>> Founder & Technical Director >>>> Erlang Solutions Ltd. >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Sun Aug 17 21:26:24 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 17 Aug 2014 21:26:24 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: I got a confirmation of that when I had a chat with the original author at EUC in June. He got moved to some other project, and Reltool has been in this kinda-mostly-working state since then. /Richard On Sun, Aug 17, 2014 at 6:37 PM, Garrett Smith wrote: > I always had the impression that the work on reltool was never > completed. A chapter on reltool could highlight the fact that the core > release tool that ships with Erlang [sic] is fubar, but I don't know > how much value that would be to readers. > > The *only* release tool I've ever seen do anything useful - without > causing me to punch a wall - is relx. It's useful. It has traction. I > think it should get a chapter, somewhere. > > On Sun, Aug 17, 2014 at 11:23 AM, Tristan Sloughter > wrote: > > I'm pretty sure "counter intuitive" and "will make your struggle" are > > reltool's best known features. > > > > Which is why relx (https://github.com/erlware/relx) has been catching > on :) > > > > > > On Sun, Aug 17, 2014 at 11:07 AM, Francesco Cesarini > > wrote: > >> > >> Hi, > >> > >> I was wrapping up the chapter on release handling for the OTP book and > >> never having used it before, decided to take a look at reltool. Is > anyone > >> using it? I am finding it counter intuitive and struggling to see how it > >> simplifies the task of creating releases. > >> > >> Feel free to reply to the list or ping me privately. > >> > >> Thanks, > >> F > >> > >> -- > >> Founder & Technical Director > >> Erlang Solutions Ltd. > >> > >> _______________________________________________ > >> 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 devgutt@REDACTED Mon Aug 18 03:59:20 2014 From: devgutt@REDACTED (Gustavo Pires) Date: Sun, 17 Aug 2014 22:59:20 -0300 Subject: [erlang-questions] Unable to call functions that are in a module in the same location In-Reply-To: References: Message-ID: Where's the code of construct_Agent(Specie_Id, Agent_Id, SpecCon)? You only sent construct_Cortex. Probably the problem is there. On Sun, Aug 17, 2014 at 1:31 PM, Steve Strong wrote: > The record will be initialised with the defaults as specified in the hrl. > The code and stacktrace in the gist still suggest that > SpecCon#constraint.morphology is ?undefined? - so something between the > record construction below and the crash within the gist must be modifying > the record. > > -- > Steve Strong > Sent with Sparrow > > On Sunday, 17 August 2014 at 15:36, Yves S. Garret wrote: > > The record in question is "constraint". The thing is, when I call it, it > looks like this with none of the values initialized: > > test() -> > Specie_Id = test, > Agent_Id = test, > CloneAgent_Id = test_clone, > SpecCon = #constraint{}, % <---- HERE IS WHERE THE FIRST INSTANCE IS > CREATED > F = fun() -> > construct_Agent(Specie_Id, Agent_Id, SpecCon), > clone_Agent(Specie_Id, CloneAgent_Id), > print(Agent_Id), > print(CloneAgent_Id), > delete_Agent(Agent_Id), > delete_Agent(CloneAgent_Id) > end, > > mnesia:transaction(F). > > My question is thus, if I make a record with #constraint{}, does that mean > that all of its values are by default set to undefined or the default > values that were specified in records.hrl? > > > > > On Sat, Aug 16, 2014 at 2:35 AM, Steve Strong wrote: > > I'm guessing that this: > > Morphology = SpecCon#constraint.morphology, > > > Is setting Morphology to 'undefined' - that's what the stack trace looks > to be saying. > > Cheers, > > Steve > > Sent from my iPhone > > On 16 Aug 2014, at 04:54, "Yves S. Garret" > wrote: > > Hello, > > This is my code: > https://gist.github.com/anonymous/5b9b2c55a7684f5386e2 > > When I run my code inside of erlang (17.0), this is the error that I get: > 7> genotype:create_test(). > {aborted,{undef,[{morphology,undefined,[sensors],[]}, > {morphology,get_InitSensors,1, > [{file,"morphology.erl"},{line,8}]}, > {genotype,construct_Cortex,3, > [{file,"genotype.erl"},{line,41}]}, > {genotype,construct_Agent,3, > [{file,"genotype.erl"},{line,20}]}, > {genotype,'-create_test/0-fun-0-',0, > [{file,"genotype.erl"},{line,434}]}, > > {mnesia_tm,apply_fun,3,[{file,"mnesia_tm.erl"},{line,833}]}, > {mnesia_tm,execute_transaction,5, > [{file,"mnesia_tm.erl"},{line,813}]}, > > {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]}]}} > > genotype.erl and morphology.erl are in the directory, so why can't > genotype's function call morphology's functions? Or am I missing something > else entirely? > > Thanks. > > _______________________________________________ > > 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 dmkolesnikov@REDACTED Mon Aug 18 08:43:57 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 09:43:57 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D33B.4050308@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Hello, There is a needs to build standalone Erlang software service deployable to hosts on network. There was an multiple attempt to use various build solution such as GNU autotools with custom M4 macros, application packaging as depicted by Erlang OTP In Action, rebar, reltool and other. However, there is set of requirements which needs to be addressed to simplify production operation, see section below. Rebar and reltool with naive Makefile glue allows to achieve then. Requirements: 1. The production deployment of Erlang application performed on hosts running vanilla Linux distribution. The major assumption -- Erlang/OTP runtime is not installed on target host. The application needs to package and deliver Erlang runtime along with its code. 2. The application life-cycle management is performed using service management tools supplied by Linux distribution. The operation team can start / stop target application as a daemons using unified approach (e.g. service xxx start). 3. The application development and operation is performed on various environment; the development environment is built on Mac OS; the production system uses Linux distributions. The developer shall have ability to assemble of production image without access to dedicated build machines. 4. The assembly of production images always managed from source code repository either private or public git. It slows down procedure of package assembly but ensure consistency of delivered code. I found reltool + rebar + Makefile is perfect approach to address those requirements. These tools gives you enough customisation power with very simple semantic. Best Regards, Dmitry On 17 Aug 2014, at 19:07, Francesco Cesarini wrote: > Hi, > > I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Mon Aug 18 08:48:28 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 09:48:28 +0300 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: On 17 Aug 2014, at 06:56, Michael Turner wrote: > Has anyone ever done any /science/ on what makes a language easily learned, especially by children? Ruby :-D https://www.kickstarter.com/projects/lindaliukas/hello-ruby http://www.helloruby.com and Rails is also good for girls http://railsgirls.com Best Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Aug 18 09:12:10 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 18 Aug 2014 08:12:10 +0100 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: Dear Dmitry Is (3) possible now? Build on a Mac; deploy to a linux/bsd machine? Thanks Ivan -- festina lente > On 18 Aug 2014, at 07:43, Dmitry Kolesnikov wrote: > > Hello, > > There is a needs to build standalone Erlang software service deployable to hosts on network. There was an multiple attempt to use various build solution such as GNU autotools with custom M4 macros, application packaging as depicted by Erlang OTP In Action, rebar, reltool and other. However, there is set of requirements which needs to be addressed to simplify production operation, see section below. Rebar and reltool with naive Makefile glue allows to achieve then. > > Requirements: > > 1. The production deployment of Erlang application performed on hosts running vanilla Linux distribution. The major assumption -- Erlang/OTP runtime is not installed on target host. The application needs to package and deliver Erlang runtime along with its code. > > 2. The application life-cycle management is performed using service management tools supplied by Linux distribution. The operation team can start / stop target application as a daemons using unified approach (e.g. service xxx start). > > 3. The application development and operation is performed on various environment; the development environment is built on Mac OS; the production system uses Linux distributions. The developer shall have ability to assemble of production image without access to dedicated build machines. > > 4. The assembly of production images always managed from source code repository either private or public git. It slows down procedure of package assembly but ensure consistency of delivered code. > > I found reltool + rebar + Makefile is perfect approach to address those requirements. These tools gives you enough customisation power with very simple semantic. > > Best Regards, > Dmitry > >> On 17 Aug 2014, at 19:07, Francesco Cesarini wrote: >> >> Hi, >> >> I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. >> >> Feel free to reply to the list or ping me privately. >> >> Thanks, >> F >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. >> >> _______________________________________________ >> 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 dmkolesnikov@REDACTED Mon Aug 18 09:24:02 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 10:24:02 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: Hello, Yes, there are two options: a) use pure retool, you need to have a cross compiled OTP. The reltool allows you to define OTP root_dir at sys section, e.g: {root_dir, "/usr/local/otp_R16B03_arm"} {root_dir, "/usr/local/otp_R16B03_linux"} The reltool assembles an application at inject ?cross-compiled? binaries for VM. This option would not work if you are using native flag. b) use dockers. I?ve made a Makefile to ?wrap? rebar, reltool and dockers work-flow. https://github.com/fogfish/makefile Personally, I am using option A for Erlang/ARM deployment, the option B is used for production deployment to AWS EC2 Best Regards, Dmitry On 18 Aug 2014, at 10:12, Ivan Uemlianin wrote: > Dear Dmitry > > Is (3) possible now? Build on a Mac; deploy to a linux/bsd machine? > > Thanks > > Ivan > > -- > festina lente > > >> On 18 Aug 2014, at 07:43, Dmitry Kolesnikov wrote: >> >> Hello, >> >> There is a needs to build standalone Erlang software service deployable to hosts on network. There was an multiple attempt to use various build solution such as GNU autotools with custom M4 macros, application packaging as depicted by Erlang OTP In Action, rebar, reltool and other. However, there is set of requirements which needs to be addressed to simplify production operation, see section below. Rebar and reltool with naive Makefile glue allows to achieve then. >> >> Requirements: >> >> 1. The production deployment of Erlang application performed on hosts running vanilla Linux distribution. The major assumption -- Erlang/OTP runtime is not installed on target host. The application needs to package and deliver Erlang runtime along with its code. >> >> 2. The application life-cycle management is performed using service management tools supplied by Linux distribution. The operation team can start / stop target application as a daemons using unified approach (e.g. service xxx start). >> >> 3. The application development and operation is performed on various environment; the development environment is built on Mac OS; the production system uses Linux distributions. The developer shall have ability to assemble of production image without access to dedicated build machines. >> >> 4. The assembly of production images always managed from source code repository either private or public git. It slows down procedure of package assembly but ensure consistency of delivered code. >> >> I found reltool + rebar + Makefile is perfect approach to address those requirements. These tools gives you enough customisation power with very simple semantic. >> >> Best Regards, >> Dmitry >> >>> On 17 Aug 2014, at 19:07, Francesco Cesarini wrote: >>> >>> Hi, >>> >>> I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. >>> >>> Feel free to reply to the list or ping me privately. >>> >>> Thanks, >>> F >>> >>> -- >>> Founder & Technical Director >>> Erlang Solutions Ltd. >>> >>> _______________________________________________ >>> 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 ok@REDACTED Mon Aug 18 09:40:49 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 18 Aug 2014 19:40:49 +1200 Subject: [erlang-questions] Potion: was "Erlang for youngsters" In-Reply-To: References: Message-ID: On 18/08/2014, at 6:48 PM, Dmitry Kolesnikov wrote: > > On 17 Aug 2014, at 06:56, Michael Turner wrote: > >> Has anyone ever done any /science/ on what makes a language easily learned, especially by children? > > Ruby :-D > > https://www.kickstarter.com/projects/lindaliukas/hello-ruby That link points to someone who has written a kickstarter-funded book about the programming language Ruby. Doubtless it would be possible to *use* this book to do some experiments -- although would be hard to disentable "great book" from "great language". (Assuming for the sake of argument, and forgetting everything I know about the core Ruby libraries, that Ruby *is* a great language.) I suspect Linda Liukas could produce an attractive PL/I book if she tried. I didn't see any links there pointing to *science* that showed Ruby has any special merits. (For what it's worth, Python *does* have roots in teaching-language research.) The video doesn't provide any evidence that Ruby is any *better* for this purpose than Python, or Javascript, or Racket (n? PLT Scheme). > http://www.helloruby.com > > and Rails is also good for girls > http://railsgirls.com I see this *asserted*, but we used to be told this about BASIC and Pascal and Java and .... I don't see any evidence offered that Ruby is *better* than Javascript as an introductory language (though how could it *not* be (:-)?) or than anything else, nor is any evidence offered that Rails is better for girls than for boys or better for girls than Cowboy. I haven't the least doubt that girls *can* achieve high competence in Ruby and in Rails if they given half a chance. Michael Turner's question was whether anyone has done any *science* on what makes a language easily learned. The kind of science is experimental education with informed consent and ideally replication. As well as PPIG, there's probably something useful in SIGCSE conference proceedings. We have a couple of people here who do CSE research. It's flaming HARD, and there are all sorts of confounding factors, and it's actually hard to get unambiguous results. I'm not even sure that the question "is language X easier to learn than language Y" has an answer; maybe it's "is it easier to learn to solve problems in class P using language X than it is to learn to solve such problems using language X", which tangles up language and library issues. For example, whether Ruby is better for girls than Groovy might depend on whether they will end up using Rails or Grails, which is hardly a *language* learnability issue. So if you want to tease *language* issues apart from *library* issues, you have to give your experimental subjects the *same* library in both languages (for some handwavy notion of "same"). As a personal example, I regard F# syntax as having warts piled on warts, where some of the warts are disguised pharyngeal teeth. (You know those small jaws that stick out in Alien? Teleost fish really have those. Functional, but scary ugly.) It is for me markedly less learnable than Haskell. But if I wanted to do e.g., graphics on .NET, I'd find *that* easier to learn in F# than in Haskell. From lcastro@REDACTED Mon Aug 18 09:42:06 2014 From: lcastro@REDACTED (Laura M. Castro) Date: Mon, 18 Aug 2014 09:42:06 +0200 Subject: [erlang-questions] Univs starting with Erlang In-Reply-To: <53F0BE5A.2040609@erlang-solutions.com> References: <53F0BE5A.2040609@erlang-solutions.com> Message-ID: For the record (since this thread seems useful for information compilation/search purposes) the University of A Coru?a has been teaching Erlang for a number of years now, although not to all CS students. In the old study plans (that became extinct this year), there was a 2nd year 'Declarative Programming' subject, compulsory, in which we learned Caml and Prolog, and then a 4th year 'Functional Programming' subject, optative, where we were taught Haskell and Erlang (I took this back in 2002). In the new plans, already in place, we went from a 5-year scheme to a 4-year scheme, so a handful of subjects were removed/merged/created. We 'lost' Functional Programming, and the successor of 'Declarative Programming', now named 'Programming Paradigms' had no room for teaching Erlang. Instead, we have introduced Erlang as teaching tool in two subjects: 'Concurrence and Paralelism' (2nd year, compulsory), and 'Software Architecture' (3rd/4th year, compulsory for students with a 'Software Engineering' specialization, optative for students with a 'Computer Science' specialization). From cjsvance@REDACTED Mon Aug 18 11:13:36 2014 From: cjsvance@REDACTED (Christopher Vance) Date: Mon, 18 Aug 2014 19:13:36 +1000 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: Some Erlang applications use compiled binaries, so any cross-build using those apps will need to handle that situation too. Where I work, I tend to edit and prototype on Mac OSX, but builds for deployment are made on Linux virtual machines running on the OSX machine. Our deployment is on amd64 Linux, so there's no problem running the VMs on VMware. I have no idea how useful this would be for ARM work. If your ARM Linux OS has Erlang packages (even if only for a different architecture) I'd suggest the closer you get to native build the better. On Mon, Aug 18, 2014 at 5:24 PM, Dmitry Kolesnikov wrote: > Hello, > > Yes, there are two options: > > a) use pure retool, you need to have a cross compiled OTP. The reltool > allows you to define OTP root_dir at sys section, e.g: > {root_dir, "/usr/local/otp_R16B03_arm"} > {root_dir, "/usr/local/otp_R16B03_linux"} > > The reltool assembles an application at inject ?cross-compiled? binaries > for VM. This option would not work if you are using native flag. > > b) use dockers. I?ve made a Makefile to ?wrap? rebar, reltool and dockers > work-flow. https://github.com/fogfish/makefile > > Personally, I am using option A for Erlang/ARM deployment, the option B is > used for production deployment to AWS EC2 > > Best Regards, > Dmitry > > > On 18 Aug 2014, at 10:12, Ivan Uemlianin wrote: > > > Dear Dmitry > > > > Is (3) possible now? Build on a Mac; deploy to a linux/bsd machine? > > > > Thanks > > > > Ivan > > > > -- > > festina lente > > > > > >> On 18 Aug 2014, at 07:43, Dmitry Kolesnikov > wrote: > >> > >> Hello, > >> > >> There is a needs to build standalone Erlang software service deployable > to hosts on network. There was an multiple attempt to use various build > solution such as GNU autotools with custom M4 macros, application packaging > as depicted by Erlang OTP In Action, rebar, reltool and other. However, > there is set of requirements which needs to be addressed to simplify > production operation, see section below. Rebar and reltool with naive > Makefile glue allows to achieve then. > >> > >> Requirements: > >> > >> 1. The production deployment of Erlang application performed on hosts > running vanilla Linux distribution. The major assumption -- Erlang/OTP > runtime is not installed on target host. The application needs to package > and deliver Erlang runtime along with its code. > >> > >> 2. The application life-cycle management is performed using service > management tools supplied by Linux distribution. The operation team can > start / stop target application as a daemons using unified approach (e.g. > service xxx start). > >> > >> 3. The application development and operation is performed on various > environment; the development environment is built on Mac OS; the production > system uses Linux distributions. The developer shall have ability to > assemble of production image without access to dedicated build machines. > >> > >> 4. The assembly of production images always managed from source code > repository either private or public git. It slows down procedure of package > assembly but ensure consistency of delivered code. > >> > >> I found reltool + rebar + Makefile is perfect approach to address those > requirements. These tools gives you enough customisation power with very > simple semantic. > >> > >> Best Regards, > >> Dmitry > >> > >>> On 17 Aug 2014, at 19:07, Francesco Cesarini < > francesco@REDACTED> wrote: > >>> > >>> Hi, > >>> > >>> I was wrapping up the chapter on release handling for the OTP book and > never having used it before, decided to take a look at reltool. Is anyone > using it? I am finding it counter intuitive and struggling to see how it > simplifies the task of creating releases. > >>> > >>> Feel free to reply to the list or ping me privately. > >>> > >>> Thanks, > >>> F > >>> > >>> -- > >>> Founder & Technical Director > >>> Erlang Solutions Ltd. > >>> > >>> _______________________________________________ > >>> 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 > -- Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Aug 18 12:41:56 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 13:41:56 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: There is very good support of cross-platform assembly of prots and drivers at rebar. You can assemble Erlang release on Mac if you have configured your tool chain properly. In principle, you can do it with magic and tambourine. I?ve manage to achieve it for ARM (used Andorid SDK) but x86_64 is easy to handle through VirtualBox. The usage of dockers allows to script you the assemble procedure while vanilla guest linux will require manual operation. - Dmitry On 18 Aug 2014, at 12:13, Christopher Vance wrote: > Some Erlang applications use compiled binaries, so any cross-build using those apps will need to handle that situation too. > > Where I work, I tend to edit and prototype on Mac OSX, but builds for deployment are made on Linux virtual machines running on the OSX machine. > > Our deployment is on amd64 Linux, so there's no problem running the VMs on VMware. > > I have no idea how useful this would be for ARM work. > > If your ARM Linux OS has Erlang packages (even if only for a different architecture) I'd suggest the closer you get to native build the better. > > > On Mon, Aug 18, 2014 at 5:24 PM, Dmitry Kolesnikov wrote: > Hello, > > Yes, there are two options: > > a) use pure retool, you need to have a cross compiled OTP. The reltool allows you to define OTP root_dir at sys section, e.g: > {root_dir, "/usr/local/otp_R16B03_arm"} > {root_dir, "/usr/local/otp_R16B03_linux"} > > The reltool assembles an application at inject ?cross-compiled? binaries for VM. This option would not work if you are using native flag. > > b) use dockers. I?ve made a Makefile to ?wrap? rebar, reltool and dockers work-flow. https://github.com/fogfish/makefile > > Personally, I am using option A for Erlang/ARM deployment, the option B is used for production deployment to AWS EC2 > > Best Regards, > Dmitry > > > On 18 Aug 2014, at 10:12, Ivan Uemlianin wrote: > > > Dear Dmitry > > > > Is (3) possible now? Build on a Mac; deploy to a linux/bsd machine? > > > > Thanks > > > > Ivan > > > > -- > > festina lente > > > > > >> On 18 Aug 2014, at 07:43, Dmitry Kolesnikov wrote: > >> > >> Hello, > >> > >> There is a needs to build standalone Erlang software service deployable to hosts on network. There was an multiple attempt to use various build solution such as GNU autotools with custom M4 macros, application packaging as depicted by Erlang OTP In Action, rebar, reltool and other. However, there is set of requirements which needs to be addressed to simplify production operation, see section below. Rebar and reltool with naive Makefile glue allows to achieve then. > >> > >> Requirements: > >> > >> 1. The production deployment of Erlang application performed on hosts running vanilla Linux distribution. The major assumption -- Erlang/OTP runtime is not installed on target host. The application needs to package and deliver Erlang runtime along with its code. > >> > >> 2. The application life-cycle management is performed using service management tools supplied by Linux distribution. The operation team can start / stop target application as a daemons using unified approach (e.g. service xxx start). > >> > >> 3. The application development and operation is performed on various environment; the development environment is built on Mac OS; the production system uses Linux distributions. The developer shall have ability to assemble of production image without access to dedicated build machines. > >> > >> 4. The assembly of production images always managed from source code repository either private or public git. It slows down procedure of package assembly but ensure consistency of delivered code. > >> > >> I found reltool + rebar + Makefile is perfect approach to address those requirements. These tools gives you enough customisation power with very simple semantic. > >> > >> Best Regards, > >> Dmitry > >> > >>> On 17 Aug 2014, at 19:07, Francesco Cesarini wrote: > >>> > >>> Hi, > >>> > >>> I was wrapping up the chapter on release handling for the OTP book and never having used it before, decided to take a look at reltool. Is anyone using it? I am finding it counter intuitive and struggling to see how it simplifies the task of creating releases. > >>> > >>> Feel free to reply to the list or ping me privately. > >>> > >>> Thanks, > >>> F > >>> > >>> -- > >>> Founder & Technical Director > >>> Erlang Solutions Ltd. > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > Christopher Vance -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Mon Aug 18 15:07:04 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Mon, 18 Aug 2014 08:07:04 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: > I found reltool + rebar + Makefile is perfect approach to address those > requirements. These tools gives you enough customisation power with very > simple semantic. > I never thought I'd see the word perfect and rebar, reltool or Makefile in the same sentence :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Aug 18 16:29:37 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 17:29:37 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: Hello, I am sharing your sarcasm? however, these tools fulfils my requirments (defined in previous email). If you know a better solution to address them, I?d be glad to look on it. - Dmitry On 18 Aug 2014, at 16:07, Tristan Sloughter wrote: > > I found reltool + rebar + Makefile is perfect approach to address those requirements. These tools gives you enough customisation power with very simple semantic. > > I never thought I'd see the word perfect and rebar, reltool or Makefile in the same sentence :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Aug 18 16:41:26 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 18 Aug 2014 16:41:26 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> Message-ID: <53F21096.9000802@ninenines.eu> Hijacking this thread, can relx build releases for different target platforms? Like being on Linux and building OSX and Windows releases? On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: > Hello, > > I am sharing your sarcasm? however, these tools fulfils my requirments > (defined in previous email). > If you know a better solution to address them, I?d be glad to look on it. > > - Dmitry > > > On 18 Aug 2014, at 16:07, Tristan Sloughter > wrote: > >> >> I found reltool + rebar + Makefile is perfect approach to address >> those requirements. These tools gives you enough customisation >> power with very simple semantic. >> >> >> I never thought I'd see the word perfect and rebar, reltool or >> Makefile in the same sentence :) > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From tristan.sloughter@REDACTED Mon Aug 18 16:44:02 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Mon, 18 Aug 2014 09:44:02 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F21096.9000802@ninenines.eu> References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> Message-ID: Yea, same way as reltool basically. The include_erts config option takes either true, false or a path to the location of the erts to include: {include_erts, "/path/to/alternate/erlang"}. https://github.com/erlware/relx/wiki/configuration On Mon, Aug 18, 2014 at 9:41 AM, Lo?c Hoguin wrote: > Hijacking this thread, can relx build releases for different target > platforms? Like being on Linux and building OSX and Windows releases? > > > On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: > >> Hello, >> >> I am sharing your sarcasm? however, these tools fulfils my requirments >> (defined in previous email). >> If you know a better solution to address them, I?d be glad to look on it. >> >> - Dmitry >> >> >> On 18 Aug 2014, at 16:07, Tristan Sloughter > > wrote: >> >> >>> I found reltool + rebar + Makefile is perfect approach to address >>> those requirements. These tools gives you enough customisation >>> power with very simple semantic. >>> >>> >>> I never thought I'd see the word perfect and rebar, reltool or >>> Makefile in the same sentence :) >>> >> >> >> >> _______________________________________________ >> 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 dmkolesnikov@REDACTED Mon Aug 18 16:46:10 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 18 Aug 2014 17:46:10 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> Message-ID: <32E61522-2175-44AE-940E-FFBEA29CEEF0@gmail.com> what about building ports and drivers? - D. On 18 Aug 2014, at 17:44, Tristan Sloughter wrote: > Yea, same way as reltool basically. > > The include_erts config option takes either true, false or a path to the location of the erts to include: > > {include_erts, "/path/to/alternate/erlang"}. > > https://github.com/erlware/relx/wiki/configuration > > > On Mon, Aug 18, 2014 at 9:41 AM, Lo?c Hoguin wrote: > Hijacking this thread, can relx build releases for different target platforms? Like being on Linux and building OSX and Windows releases? > > > On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: > Hello, > > I am sharing your sarcasm? however, these tools fulfils my requirments > (defined in previous email). > If you know a better solution to address them, I?d be glad to look on it. > > - Dmitry > > > On 18 Aug 2014, at 16:07, Tristan Sloughter > wrote: > > > I found reltool + rebar + Makefile is perfect approach to address > those requirements. These tools gives you enough customisation > power with very simple semantic. > > > I never thought I'd see the word perfect and rebar, reltool or > Makefile in the same sentence :) > > > > _______________________________________________ > 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 tristan.sloughter@REDACTED Mon Aug 18 16:47:17 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Mon, 18 Aug 2014 09:47:17 -0500 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <32E61522-2175-44AE-940E-FFBEA29CEEF0@gmail.com> References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> <32E61522-2175-44AE-940E-FFBEA29CEEF0@gmail.com> Message-ID: You can use overrides for where to include apps from. So if you have the app built for another platform you can tell relx where it is. Relx is only a release and target system builder, so it just assembles what you give it. On Mon, Aug 18, 2014 at 9:46 AM, Dmitry Kolesnikov wrote: > what about building ports and drivers? > > - D. > > On 18 Aug 2014, at 17:44, Tristan Sloughter > wrote: > > Yea, same way as reltool basically. > > The include_erts config option takes either true, false or a path to the > location of the erts to include: > > {include_erts, "/path/to/alternate/erlang"}. > > > https://github.com/erlware/relx/wiki/configuration > > > On Mon, Aug 18, 2014 at 9:41 AM, Lo?c Hoguin wrote: > >> Hijacking this thread, can relx build releases for different target >> platforms? Like being on Linux and building OSX and Windows releases? >> >> >> On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: >> >>> Hello, >>> >>> I am sharing your sarcasm? however, these tools fulfils my requirments >>> (defined in previous email). >>> If you know a better solution to address them, I?d be glad to look on it. >>> >>> - Dmitry >>> >>> >>> On 18 Aug 2014, at 16:07, Tristan Sloughter >> > wrote: >>> >>> >>>> I found reltool + rebar + Makefile is perfect approach to address >>>> those requirements. These tools gives you enough customisation >>>> power with very simple semantic. >>>> >>>> >>>> I never thought I'd see the word perfect and rebar, reltool or >>>> Makefile in the same sentence :) >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 Mon Aug 18 17:05:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 18 Aug 2014 17:05:22 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> Message-ID: <53F21632.5020509@ninenines.eu> Right I wasn't sure about that, thanks. Sounds like it could be useful to add cross compile support to erlang.mk's c_src plugin to easily build releases targeting many different platforms. On 08/18/2014 04:44 PM, Tristan Sloughter wrote: > Yea, same way as reltool basically. > > The include_erts config option takes either true, false or a path to the > location of the erts to include: > > |{include_erts, "/path/to/alternate/erlang"}.| > > > https://github.com/erlware/relx/wiki/configuration > > > On Mon, Aug 18, 2014 at 9:41 AM, Lo?c Hoguin > wrote: > > Hijacking this thread, can relx build releases for different target > platforms? Like being on Linux and building OSX and Windows releases? > > > On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: > > Hello, > > I am sharing your sarcasm? however, these tools fulfils my > requirments > (defined in previous email). > If you know a better solution to address them, I?d be glad to > look on it. > > - Dmitry > > > On 18 Aug 2014, at 16:07, Tristan Sloughter > > >> wrote: > > > I found reltool + rebar + Makefile is perfect approach > to address > those requirements. These tools gives you enough > customisation > power with very simple semantic. > > > I never thought I'd see the word perfect and rebar, reltool or > Makefile in the same sentence :) > > > > > _________________________________________________ > 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 carlosj.gf@REDACTED Mon Aug 18 17:45:11 2014 From: carlosj.gf@REDACTED (=?ISO-8859-1?Q?Carlos_Gonz=E1lez_Florido?=) Date: Mon, 18 Aug 2014 17:45:11 +0200 Subject: [erlang-questions] [ANN] NkSIP v0.4.0 In-Reply-To: References: <068F9B90-D080-454C-94C6-3A677431070C@gmail.com> Message-ID: Hi Max, Antoine Max, NkSIP is a pure SIP stack, and does not include any RTP capability. It should be a good option to develop an anything-to-SIP proxy or similar, from the signaling point of view. However, we are just starting a new project, NkCore, that will use the NkSIP core but without SIP. NkCore will be a generic, distributed Erlang application server, and NkSIP will become just a plugin of many available. It should be a great platform to develop any kind of distributed application, with special focus on networking (SDN, NFV) applications. NkCore will be able to start and control any other application (using Docker), so that it could start and monitor instances of FFMpeg or Freeswitch, for example, with the same easy of use, only starting a new plugin. Antoine, the webrtc part is not well tested. Any help here is appreciated. Carlos On Tue, Aug 12, 2014 at 10:24 PM, Max Lapshin wrote: > Antoine, are you working with webrtc? > > > On Sat, Aug 9, 2014 at 1:20 PM, Antoine Koener > wrote: > >> Or help on webrtc stuff ? >> >> > On 09 Aug 2014, at 11:13, Max Lapshin wrote: >> > >> > Carlos! >> > >> > It is a really amazing work! Your code just works. Do you need help >> with adding RTP stuff? >> > I'll try to use your code to implement rtmp - sip bridge. >> > _______________________________________________ >> > 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 k.petrauskas@REDACTED Mon Aug 18 18:45:35 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Mon, 18 Aug 2014 19:45:35 +0300 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F21632.5020509@ninenines.eu> References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> <53F21632.5020509@ninenines.eu> Message-ID: I'm using rebar + reltool + make for building releases and have no problems with that, at least for my current requirements. I'm using vbox to run builds on proper OS. Karolis On Mon, Aug 18, 2014 at 6:05 PM, Lo?c Hoguin wrote: > Right I wasn't sure about that, thanks. > > Sounds like it could be useful to add cross compile support to erlang.mk's > c_src plugin to easily build releases targeting many different platforms. > > > On 08/18/2014 04:44 PM, Tristan Sloughter wrote: >> >> Yea, same way as reltool basically. >> >> The include_erts config option takes either true, false or a path to the >> location of the erts to include: >> >> |{include_erts, "/path/to/alternate/erlang"}.| >> >> >> https://github.com/erlware/relx/wiki/configuration >> >> >> On Mon, Aug 18, 2014 at 9:41 AM, Lo?c Hoguin > > wrote: >> >> Hijacking this thread, can relx build releases for different target >> platforms? Like being on Linux and building OSX and Windows releases? >> >> >> On 08/18/2014 04:29 PM, Dmitry Kolesnikov wrote: >> >> Hello, >> >> I am sharing your sarcasm? however, these tools fulfils my >> requirments >> (defined in previous email). >> If you know a better solution to address them, I?d be glad to >> look on it. >> >> - Dmitry >> >> >> On 18 Aug 2014, at 16:07, Tristan Sloughter >> >> > >> >> wrote: >> >> >> I found reltool + rebar + Makefile is perfect approach >> to address >> those requirements. These tools gives you enough >> customisation >> power with very simple semantic. >> >> >> I never thought I'd see the word perfect and rebar, reltool or >> Makefile in the same sentence :) >> >> >> >> >> _________________________________________________ >> 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 From lee.sylvester@REDACTED Mon Aug 18 19:16:08 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 18 Aug 2014 10:16:08 -0700 (PDT) Subject: [erlang-questions] [project-iris] Re: Iris v0.3.0 out, with fresh new APIs In-Reply-To: References: <0cfd8342-1214-41b7-ba27-646de862c79c@googlegroups.com> <927bdb02-7523-4e72-adba-59bfe8451b07@googlegroups.com> <5114a736-da9e-48bc-81a2-63113893d810@googlegroups.com> Message-ID: Sounds like a plan, P?ter. I've already agreed with my colleagues to use it. We'll let you know what we find, and if we improve it, we'll let you know that, too :-) Thanks, Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Mon Aug 18 20:59:58 2014 From: ryankbrown@REDACTED (Ryan Brown) Date: Mon, 18 Aug 2014 12:59:58 -0600 Subject: [erlang-questions] Observer for the web? Message-ID: Hi all, I have been looking at various different monitoring options for erlang applications. There a re a number of good ones out there but, for my needs, observer offers the best insight. However, since it is a desktop app, it is not ideal for long-running monitoring or for say, sending a link to somebody else and saying "hey, can you take a look at this?" It would also be nice to be able to have playback capabilities. So, if you have a node failure, it would be nice to roll-back to just prior to this failure to see what is happening on that node. So, is there something like this available currently? Something close that I could possibly contribute to that will help the entire community? It seems like recon https://github.com/ferd/recon Could be used as a good starting point for such a monitoring tool. And I may do that. But, the last thing i want is to re-invent the wheel. -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From cian@REDACTED Mon Aug 18 21:48:18 2014 From: cian@REDACTED (Cian Synnott) Date: Mon, 18 Aug 2014 15:48:18 -0400 Subject: [erlang-questions] Observer for the web? In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 2:59 PM, Ryan Brown wrote: > So, is there something like this available currently? Something close that I > could possibly contribute to that will help the entire community? > https://github.com/beamspirit/bigwig seems relevant, but it looks like it stalled. Cian From ryankbrown@REDACTED Tue Aug 19 04:31:26 2014 From: ryankbrown@REDACTED (Ryan Brown) Date: Mon, 18 Aug 2014 20:31:26 -0600 Subject: [erlang-questions] Trouble getting bigwig to run Message-ID: I am testing-out bigwig for a possible monitoring solution for my application. When I attempt to hook it up to my application I get the following cowboy error. I am having trouble deciphering it. Any help would be greatly appreciated. =INFO REPORT==== 18-Aug-2014::20:23:37 === Bigwig listening on http://127.0.0.1:40829/ =CRASH REPORT==== 18-Aug-2014::20:23:37 === crasher: initial call: bigwig_http:init/1 pid: <0.4861.0> registered_name: [] exception exit: {undef, [{cowboy,start_listener, [http,16,cowboy_tcp_transport, [{port,40829}], cowboy_http_protocol, [{dispatch, [{'_', [{[],bigwig_http_static, [<<"html">>,<<"index.html">>]}, {[<<"static">>,'...'],bigwig_http_static,[]}, {[<<"vm">>],bigwig_http_vm,[]}, {[<<"rb">>,<<"stream">>], bigwig_http_rb_stream,[]}, {[<<"rb">>,'...'],bigwig_http_rb,[]}, {[<<"pid">>,'...'],bigwig_http_pid,[]}, {[<<"module">>,'...'],bigwig_http_module,[]}, {[<<"top">>,'...'],bigwig_http_etop2,[]}, {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, {[<<"stats-stream">>], bigwig_http_stats_stream,[]}, {'_',bigwig_http_catchall,[]}]}]}]], []}, {bigwig_http,init,1, [{file,"src/bigwig_http.erl"},{line,54}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,304}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]} in function gen_server:init_it/6 (gen_server.erl, line 328) ancestors: [bigwig_sup,<0.4853.0>] messages: [] links: [<0.4854.0>] dictionary: [] trap_exit: false status: running heap_size: 610 stack_size: 24 reductions: 911 neighbours: =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === Supervisor: {local,bigwig_sup} Context: start_error Reason: {undef, [{cowboy,start_listener, [http,16,cowboy_tcp_transport, [{port,40829}], cowboy_http_protocol, [{dispatch, [{'_', [{[],bigwig_http_static, [<<"html">>,<<"index.html">>]}, {[<<"static">>,'...'], bigwig_http_static,[]}, {[<<"vm">>],bigwig_http_vm,[]}, {[<<"rb">>,<<"stream">>], bigwig_http_rb_stream,[]}, {[<<"rb">>,'...'],bigwig_http_rb,[]}, {[<<"pid">>,'...'],bigwig_http_pid,[]}, {[<<"module">>,'...'], bigwig_http_module,[]}, {[<<"top">>,'...'],bigwig_http_etop2,[]}, {[<<"appmon">>,'...'], bigwig_http_appmon,[]}, {[<<"stats-stream">>], bigwig_http_stats_stream,[]}, {'_',bigwig_http_catchall,[]}]}]}]], []}, {bigwig_http,init,1, [{file,"src/bigwig_http.erl"},{line,54}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,304}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]} Offender: [{pid,undefined}, {name,bigwig_http}, {mfargs,{bigwig_http,start_link,[]}}, {restart_type,permanent}, {shutdown,5000}, {child_type,worker}] =INFO REPORT==== 18-Aug-2014::20:23:37 === application: bigwig exited: {shutdown,{bigwig_app,start,[normal,[]]}} type: temporary {error,{shutdown,{bigwig_app,start,[normal,[]]}}} -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Tue Aug 19 07:44:44 2014 From: ryankbrown@REDACTED (Ryan Brown) Date: Mon, 18 Aug 2014 23:44:44 -0600 Subject: [erlang-questions] Trouble getting bigwig to run In-Reply-To: References: Message-ID: Figured it out. Not that hard with clear eyes really. Bigwig still refers to an older version of cowboy. I could revery back to that compatible version. But, what I would really like is to upgrade my fork to be compatible with the latest. So, what I am looking for is documentation or changelogs to help me with this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http migration. I'll keep fumbling my way through but any insight from those whom have been through it would be greatly appreciated. Thanks. On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: > I am testing-out bigwig for a possible monitoring solution for my > application. When I attempt to hook it up to my application I get the > following cowboy error. I am having trouble deciphering it. Any help would > be greatly appreciated. > > =INFO REPORT==== 18-Aug-2014::20:23:37 === > Bigwig listening on http://127.0.0.1:40829/ > > =CRASH REPORT==== 18-Aug-2014::20:23:37 === > crasher: > initial call: bigwig_http:init/1 > pid: <0.4861.0> > registered_name: [] > exception exit: {undef, > [{cowboy,start_listener, > [http,16,cowboy_tcp_transport, > [{port,40829}], > cowboy_http_protocol, > [{dispatch, > [{'_', > [{[],bigwig_http_static, > [<<"html">>,<<"index.html">>]}, > {[<<"static">>,'...'],bigwig_http_static,[]}, > {[<<"vm">>],bigwig_http_vm,[]}, > {[<<"rb">>,<<"stream">>], > bigwig_http_rb_stream,[]}, > {[<<"rb">>,'...'],bigwig_http_rb,[]}, > {[<<"pid">>,'...'],bigwig_http_pid,[]}, > {[<<"module">>,'...'],bigwig_http_module,[]}, > {[<<"top">>,'...'],bigwig_http_etop2,[]}, > {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, > {[<<"stats-stream">>], > bigwig_http_stats_stream,[]}, > {'_',bigwig_http_catchall,[]}]}]}]], > []}, > {bigwig_http,init,1, > [{file,"src/bigwig_http.erl"},{line,54}]}, > {gen_server,init_it,6, > [{file,"gen_server.erl"},{line,304}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,227}]}]} > in function gen_server:init_it/6 (gen_server.erl, line 328) > ancestors: [bigwig_sup,<0.4853.0>] > messages: [] > links: [<0.4854.0>] > dictionary: [] > trap_exit: false > status: running > heap_size: 610 > stack_size: 24 > reductions: 911 > neighbours: > > =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === > Supervisor: {local,bigwig_sup} > Context: start_error > Reason: {undef, > [{cowboy,start_listener, > [http,16,cowboy_tcp_transport, > [{port,40829}], > cowboy_http_protocol, > [{dispatch, > [{'_', > [{[],bigwig_http_static, > [<<"html">>,<<"index.html">>]}, > {[<<"static">>,'...'], > bigwig_http_static,[]}, > {[<<"vm">>],bigwig_http_vm,[]}, > {[<<"rb">>,<<"stream">>], > bigwig_http_rb_stream,[]}, > {[<<"rb">>,'...'],bigwig_http_rb,[]}, > > {[<<"pid">>,'...'],bigwig_http_pid,[]}, > {[<<"module">>,'...'], > bigwig_http_module,[]}, > > {[<<"top">>,'...'],bigwig_http_etop2,[]}, > {[<<"appmon">>,'...'], > bigwig_http_appmon,[]}, > {[<<"stats-stream">>], > bigwig_http_stats_stream,[]}, > {'_',bigwig_http_catchall,[]}]}]}]], > []}, > {bigwig_http,init,1, > [{file,"src/bigwig_http.erl"},{line,54}]}, > {gen_server,init_it,6, > [{file,"gen_server.erl"},{line,304}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,227}]}]} > Offender: [{pid,undefined}, > {name,bigwig_http}, > {mfargs,{bigwig_http,start_link,[]}}, > {restart_type,permanent}, > {shutdown,5000}, > {child_type,worker}] > > > =INFO REPORT==== 18-Aug-2014::20:23:37 === > application: bigwig > exited: {shutdown,{bigwig_app,start,[normal,[]]}} > type: temporary > {error,{shutdown,{bigwig_app,start,[normal,[]]}}} > > -- > -rb > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maxim.Minin@REDACTED Tue Aug 19 08:41:31 2014 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Tue, 19 Aug 2014 08:41:31 +0200 Subject: [erlang-questions] Reltool anyone? Message-ID: Hi All, I also have a question to reltool. Is it possible to generate boot file, which load all application but don't start them? Thanks Maxim From essen@REDACTED Tue Aug 19 11:27:32 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 19 Aug 2014 11:27:32 +0200 Subject: [erlang-questions] Trouble getting bigwig to run Message-ID: Bigwig was written against a very old version of Cowboy. It shouldn't be impossible to port but a lot changed since. Cowboy has a changelog file in the repository. That said, I had started working on a replacement called Shaman (extend/shaman) that handles multiple nodes and uses D3 for rendering/updates, but I stopped working on it for now because I do not have a production system to use it with (so the values I output may not be interesting). I am going to resume as soon as I find something to develop against. That said, contributions are always welcome. It shouldn't take much more work to add the missing features bigwig had either. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Ryan Brown Sent:Tue, 19 Aug 2014 07:44:44 +0200 To:Erlang Questions Subject:Re: [erlang-questions] Trouble getting bigwig to run >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Tue Aug 19 11:57:12 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 19 Aug 2014 17:57:12 +0800 Subject: [erlang-questions] linking to remote process on network failure Message-ID: If a local proc P1 links to a remote P2. What should happen under various network conditions? for example, when the network cable is disconnected and reconnected. Are these behaviours documented somewhere? Thanks. Leo From mononcqc@REDACTED Tue Aug 19 14:34:31 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 19 Aug 2014 08:34:31 -0400 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: Message-ID: <20140819123430.GF54532@ferdair.local> On 08/19, Minin Maxim wrote: > Hi All, > I also have a question to reltool. Is it possible to generate boot file, which load all application but don't start them? That can generally be done with all release tools by specifyign the app as 'load' for its supervision strategy. For example, in Reltool this would be: {sys, [ {lib_dirs, ["some/path"]}, {rel, "my-release", "1.0.0", [kernel, stdlib, {app1, permanent}, {app2, load} ... ]}, ... In this one, app1 is to be started as a permanent application, while app2 will just be loaded. Relx supports the same. From their wiki: {release, {sexpr, "0.0.2"}, [sexpr, "erlware_commons>=0.8.1", {neotoma, load}]}. The neotoma app will be loaded but not booted. I however have doubts on the validity of wanting to do that for *all* applications. What's the main objective there? If the idea is just to have the applications be visible in your path so they're always around, you may also try playing with the ERL_LIBS environment variable. You point it to a directory containing OTP applications and the VM will pick them up. Regards, Fred. From ulf@REDACTED Tue Aug 19 15:04:32 2014 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 19 Aug 2014 15:04:32 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <20140819123430.GF54532@ferdair.local> References: <20140819123430.GF54532@ferdair.local> Message-ID: <912D0AFB-7161-445D-9A20-EBBA0D9F5572@feuerlabs.com> On 19 Aug 2014, at 14:34, Fred Hebert wrote: > I however have doubts on the validity of wanting to do that for *all* > applications. What's the main objective there? I have tended to do this ever since I wrote ?builder? many years ago: Have a script that builds a proper boot script, then makes a corresponding ?setup? script with all applications as load-only. The ?setup? utility [1] does this automatically. The purpose is to provide an environment for running installation code. The paths are set, and app files loaded, and special install hooks can be executed automatically. From the README.md: "If the option -install true is given, the setup_gen utility will generate an installation boot script, and install.config file, which can be used to install the system, using a command like: erl -sys install -boot install This boot script will run kernel, stdlib and sasl, then load all other applications, and finally run the setup application, which will find and execute any setup hooks. If the option -setup stop_when_done true is added to the command line, the setup application will automatically shut down all running nodes after running the setup hooks. Otherwise (default), it will hand over control to the shell rather than terminate the Erlang VM." When installing via rebar/reltool, I have a {rel_apps, Rel, Apps} option in the rebar.config, which is used by a rebar plugin to expand a reltool.config.src file. This plugin also creates a _setup release with all apps (except kernel, stdlib & setup) to load-only). BR, Ulf W [1] https://github.com/uwiger/setup/ Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From yjh0502@REDACTED Tue Aug 19 14:59:03 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Tue, 19 Aug 2014 21:59:03 +0900 Subject: [erlang-questions] Inter-node communication bottleneck Message-ID: <20140819125903.GA4902@debian> Hi, There is a prior discusson[1] about inter-node communication bottleneck, and I experienced same issue on inter-node messaging. I dig into the issue and it found that there is a lock on inter-node messaging[2] which causes bottleneck on sending messages to single node. With simple experiment, I found that there is a limitation on number of messages per second, not bandwidth. 1Gbps link could be easily satuated by messaging betweeen two erlang nodes if message size is large enough, e.g. 4KB binary message. However if message is small, e.g. single integer term, number of messages per seconds is limited about 200~300k/sec. Is there any effort to solve the problem? In fact the problem could be solved by using external channel like multiple TCP connection pool for rpc, but I believe using erlang messaging keeps code much simpler. Actually for me the problem is quite embrassing, because I thought scalable messaging is a key feature and strength of Erlang. [1] http://erlang.org/pipermail/erlang-questions/2013-December/076232.html [2] https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 From maxim@REDACTED Tue Aug 19 23:48:46 2014 From: maxim@REDACTED (Maxim Sokhatsky) Date: Wed, 20 Aug 2014 00:48:46 +0300 Subject: [erlang-questions] [ANN} MAD: Erlang Build and Deploy Tool Message-ID: Sounds like one more rebar replacement :-) History We came to conclusion that no matter how perfect your libraries are, the comfort and ease come mostly from developing tools. Everything got started when Vladimir Kirillov[1] decided to replace Rusty?s sync beam reloader. As you know sync uses filesystem polling which is neither energy-efficient nor elegant. Also sync is only able to recompile separate modules while common use-case in N2O is to recompile DTL templates and LESS/SCSS stylesheets. That is why we need to recompile the whole project. That?s the story how active emerged. Under the hood active is a client subscriber of fs library, native filesystem listener for Linux, Windows and Mac. De-facto standard in Erlang world is rebar. We love rebar interface despite its implementation. First we plugged rebar into active and then decided to drop its support, it was slow, especially in cold recompilation. It was designed to be a stand-alone tool, so it has some glitches while using as embedded library. Later we switched to Makefile-based build tool otp.mk. The idea to build rebar replacement was up in the air for a long time. The best minimal approach was picked up by Sina Samavati[2], who implemented the first prototype called mad[3]. Initially mad was able to compile DTL templated, YECC files, escript (like bundled in gproc), also it had support for caching with side-effects. In a month I forked mad and took over the development under the same name. Listing 1: Example of building N2O sample ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Cold ? ? ? Hot ? ? rebar get-deps compile ? ? ? ? 53.156s ? ?4.714s ? ? mad deps compile ? ? ? ? ? ? ? 54.097s ? ?0.899s Listing 2: Example of building Cowboy ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Hot ? ? make (erlang.mk) ? ? ? ? ? ? ? 2.588s ? ? mad compile ? ? ? ? ? ? ? ? ? ?2.521s Introduction We were trying to make something minimalistic that fits out Web Stack. Besides we wanted to use our knowledge of other build tools like lein, sbt etc. Also for sure we tried sinan, ebt, Makefile-based scripts. Synrc mad has a simple interface as follows: ? BNF: ? ? ? invoke := mad params ? ? ? params := [] | run params ? ? ? ? ?run := command [ options ] ? ? ?command := app | lib | deps | compile | bundle ? ? ? ? ? ? ? ? start | stop | repl Single-File Bundling The key feature of mad is ability to create single-file bundled web sites. Thus making dream to boot simpler than node.js come true. This target escript is ready to run on Windows, Linux and Mac with Erlang installed. To make this possible we implemented a zip filesytem inside escript. mad packages priv directories along with ebin and configs. You can redefine each file in zip fs inside target escript by creation the copy with same path locally near escript. After launch all files are copied to ETS. N2O also comes with custom cowboy static handler that is able to read static files from this cached ETS filesystem. Also bundle are compatible with active online realoading and recompilation. Templates mad also comes with N2O templates. So you can bootstrap a N2O-based site just having a single copy of mad binary. ? ? # mad app sample ? ? # cd sample ? ? # mad deps compile plan bundle web_app After that you can just run escript web_app under Windows, Linux and Mac and open http://localhost:8000. ? C:\> escript web_app ? ? Applications: [kernel,stdlib,crypto,cowlib,ranch,cowboy,compiler,syntax_tools, ? ? ? ? ? ? ? ? ? ?erlydtl,gproc,xmerl,n2o,n2o_sample,fs,active,mad,sh] ? ? Configuration: [{n2o,[{port,8000},{route,routes}]}, ? ? ? ? ? ? ? ? ? ? {kvs,[{dba,store_mnesia}, ? ? ? ? ? ? ? ? ? ? ? ? ? {schema,[kvs_user,kvs_acl,kvs_feed,kvs_subscription]}]}] ? ? Erlang/OTP 17 [erts-6.0] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false] ? ? Eshell V6.0 ?(abort with ^G) ? ? 1> Also you can create OTP releases with reltool, rebar configure or relx. Internally mad uses reltool to order your dependencies and generation of reltool.config. ? ? # mad plan ? ? Ordered: [kernel,stdlib,mnesia,kvs,crypto,cowlib,ranch, ? ? ? ? ? ? ? cowboy,compiler,syntax_tools,erlydtl,gproc, ? ? ? ? ? ? ? xmerl,n2o,n2o_sample,fs,active,mad,rest,sh] And the good part: ? ? ? ? ? ? ? ? ? ? ? Sources ? ? ? ?Binary ? ? mad ? ? ? ? ? ? ? 567 LOC ? ? ? ?39 KB ? ? rebar ? ? ? ? ? ? 7717 LOC ? ? ? 181 KB Cheers! [1]?https://twitter.com/darkproger [2]?https://twitter.com/sinasamavati [3] https://github.com/synrc/mad [4] https://github.com/synrc/active [5] https://github.com/synrc/fs [6] https://github.com/synrc/active -- Maxim Sokhatsky https://synrc.com From g@REDACTED Tue Aug 19 23:33:11 2014 From: g@REDACTED (Garrett Smith) Date: Tue, 19 Aug 2014 16:33:11 -0500 Subject: [erlang-questions] [ANN] Chicago Erlang Conference - Sept 22 - aka "Best Lineup Ever" Message-ID: For a single day, September 22, Chicago will become the center of know Erlang universe: http://www.chicagoerlang.com This is a single track conference organized by the Chicago Erlang User Group and Erlang Solutions that is focusing on "Real World Erlang". The talks are very technical and practical: - Joe Armstrong: Modeling the World with Processes, Objects, Functions or Relations - Francesco Cesarini: Thinking in a Concurrent Language - Steve Vinoski: Optimizing Native Code for Erlang - Fred Hebert: Keeping a System Running Forever - Irina Guberman: Maximizing Throughput On Multicore Systems - Reid Draper: Building Fault Tolerant Teams At Basho - Brian Troutwine: Monitoring Complex Systems - Jesse Gumm: Building Web Scale Apps with Nitrogen - Garrett Smith: Writing Quality Code in Erlang Zach Kessin will be hosting the Mostly Erlang podcast live at the after party. Even if you're not in Chicago, really, this is worth a trip. If you are in Chicago, you are simple required to go. It's a requirement. Seriously, come to this conference. Garrett From vladdu55@REDACTED Wed Aug 20 10:26:13 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Aug 2014 10:26:13 +0200 Subject: [erlang-questions] hanging nodes Message-ID: Hi! I have some nodes that don't want to terminate and that I can't connect to. Most of the times the nodes unregister from epmd, but even when they don't they still are inaccessible. I was hoping that by connecting to the node I can see why it is hanging, but I get the feeling that the hanging is not inside user code (because epmd detects the socket being closed, so the shutdown process is started). This is on Windows, but I have some reports for something that looks similar from Linux too. I'm not used to debugging this kind of situations, so I hope that someone has some advice for me. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Aug 20 11:18:07 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Aug 2014 11:18:07 +0200 Subject: [erlang-questions] hanging nodes In-Reply-To: References: Message-ID: Some details: the beam process seems to have a thread that sits and does something. I don't know if the following example stack helps. best regards, Vlad wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x42a ntdll.dll!RtlIsDosDeviceName_U+0x23a27 ntdll.dll!LdrInitializeThunk+0xe kernel32.dll!SetEvent+0x2 beam.smp.dll!fd_stop+0x4f beam.smp.dll!terminate_port+0x64 beam.smp.dll!erts_deliver_port_exit+0x225 beam.smp.dll!driver_failure_atom+0x93 beam.smp.dll!ready_output+0xa9 beam.smp.dll!erts_port_task_execute+0x28d beam.smp.dll!schedule+0xb24 beam.smp.dll!_process_main+0x125 ntdll.dll!RtlImageNtHeader+0x716 beam.smp.dll!do_erts_alcu_free+0x5f beam.smp.dll!erts_alcu_free_thr_spec+0x58 beam.smp.dll!thr_wrapper+0xa6 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu wrote: > Hi! > > I have some nodes that don't want to terminate and that I can't connect > to. Most of the times the nodes unregister from epmd, but even when they > don't they still are inaccessible. > > I was hoping that by connecting to the node I can see why it is hanging, > but I get the feeling that the hanging is not inside user code (because > epmd detects the socket being closed, so the shutdown process is started). > > This is on Windows, but I have some reports for something that looks > similar from Linux too. > I'm not used to debugging this kind of situations, so I hope that someone > has some advice for me. > > best regards, > Vlad > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Wed Aug 20 12:11:07 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Wed, 20 Aug 2014 14:11:07 +0400 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140819125903.GA4902@debian> References: <20140819125903.GA4902@debian> Message-ID: Hello! Have you tried to use: # erl ... inet_default_connect_options '[{delay_send, true}]' inet_default_listen_options '[{delay_send, true}]' ? 2014-08-19 16:59 GMT+04:00 Jihyun Yu : > Hi, > > There is a prior discusson[1] about inter-node communication bottleneck, > and I experienced same issue on inter-node messaging. I dig into the > issue and it found that there is a lock on inter-node messaging[2] which > causes bottleneck on sending messages to single node. With simple > experiment, I found that there is a limitation on number of messages per > second, not bandwidth. 1Gbps link could be easily satuated by messaging > betweeen two erlang nodes if message size is large enough, e.g. 4KB > binary message. However if message is small, e.g. single integer term, > number of messages per seconds is limited about 200~300k/sec. > > Is there any effort to solve the problem? In fact the problem could be > solved by using external channel like multiple TCP connection pool for > rpc, but I believe using erlang messaging keeps code much simpler. > Actually for me the problem is quite embrassing, because I thought > scalable messaging is a key feature and strength of Erlang. > > > [1] http://erlang.org/pipermail/erlang-questions/2013-December/076232.html > [2] > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 > _______________________________________________ > 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 yjh0502@REDACTED Wed Aug 20 13:08:45 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Wed, 20 Aug 2014 20:08:45 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: References: <20140819125903.GA4902@debian> Message-ID: <20140820110845.GA7620@debian> Hi, Thanks for reply! I just tried, but it seems that there is no signigicant difference on performance. Here's script which used on benchmarking. https://gist.github.com/yjh0502/68d6ffce93bcbc425435 On Wed, Aug 20, 2014 at 02:11:07PM +0400, Alexander Petrovsky wrote: > Hello! > > Have you tried to use: > > # erl ... inet_default_connect_options '[{delay_send, true}]' > inet_default_listen_options '[{delay_send, true}]' > > ? > > > 2014-08-19 16:59 GMT+04:00 Jihyun Yu : > > > Hi, > > > > There is a prior discusson[1] about inter-node communication bottleneck, > > and I experienced same issue on inter-node messaging. I dig into the > > issue and it found that there is a lock on inter-node messaging[2] which > > causes bottleneck on sending messages to single node. With simple > > experiment, I found that there is a limitation on number of messages per > > second, not bandwidth. 1Gbps link could be easily satuated by messaging > > betweeen two erlang nodes if message size is large enough, e.g. 4KB > > binary message. However if message is small, e.g. single integer term, > > number of messages per seconds is limited about 200~300k/sec. > > > > Is there any effort to solve the problem? In fact the problem could be > > solved by using external channel like multiple TCP connection pool for > > rpc, but I believe using erlang messaging keeps code much simpler. > > Actually for me the problem is quite embrassing, because I thought > > scalable messaging is a key feature and strength of Erlang. > > > > > > [1] http://erlang.org/pipermail/erlang-questions/2013-December/076232.html > > [2] > > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 914 8 820 815 From jon@REDACTED Wed Aug 20 13:37:02 2014 From: jon@REDACTED (Jon Schneider) Date: Wed, 20 Aug 2014 12:37:02 +0100 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140820110845.GA7620@debian> References: <20140819125903.GA4902@debian> <20140820110845.GA7620@debian> Message-ID: <89b70e08b2d8962c8a00e42a5b209f0c.squirrel@mail.jschneider.net> Isn't this simply pushing the performance of Erlang regardless of networking ? I'm sitting at a machine which yes is several years old and running Windows XP but with a simple ping-pong atom message test between a pair of processes I get around 125k messages/second. Compiling with [hipe] doesn't seem to make any difference. Jon > Hi, Thanks for reply! > > I just tried, but it seems that there is no signigicant difference > on performance. Here's script which used on benchmarking. > > https://gist.github.com/yjh0502/68d6ffce93bcbc425435 > > > > On Wed, Aug 20, 2014 at 02:11:07PM +0400, Alexander Petrovsky wrote: >> Hello! >> >> Have you tried to use: >> >> # erl ... inet_default_connect_options '[{delay_send, true}]' >> inet_default_listen_options '[{delay_send, true}]' >> >> ? >> >> >> 2014-08-19 16:59 GMT+04:00 Jihyun Yu : >> >> > Hi, >> > >> > There is a prior discusson[1] about inter-node communication >> bottleneck, >> > and I experienced same issue on inter-node messaging. I dig into the >> > issue and it found that there is a lock on inter-node messaging[2] >> which >> > causes bottleneck on sending messages to single node. With simple >> > experiment, I found that there is a limitation on number of messages >> per >> > second, not bandwidth. 1Gbps link could be easily satuated by >> messaging >> > betweeen two erlang nodes if message size is large enough, e.g. 4KB >> > binary message. However if message is small, e.g. single integer term, >> > number of messages per seconds is limited about 200~300k/sec. >> > >> > Is there any effort to solve the problem? In fact the problem could be >> > solved by using external channel like multiple TCP connection pool for >> > rpc, but I believe using erlang messaging keeps code much simpler. >> > Actually for me the problem is quite embrassing, because I thought >> > scalable messaging is a key feature and strength of Erlang. >> > >> > >> > [1] >> http://erlang.org/pipermail/erlang-questions/2013-December/076232.html >> > [2] >> > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> >> >> -- >> ???????????????????? ?????????????????? / 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 yjh0502@REDACTED Wed Aug 20 13:49:50 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Wed, 20 Aug 2014 20:49:50 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <89b70e08b2d8962c8a00e42a5b209f0c.squirrel@mail.jschneider.net> References: <20140819125903.GA4902@debian> <20140820110845.GA7620@debian> <89b70e08b2d8962c8a00e42a5b209f0c.squirrel@mail.jschneider.net> Message-ID: <20140820114949.GB7620@debian> What I want to say is, the benchmark does not scale on multi-core machine while it uses multiple erlang processes to send message. I ran the benchmark with two erlang VM instances, on quad-core laptop. It couldn't saturate all CPU cores, AFAIK because of lock in erlang VM. The benchmark scales when it runs on single erlang VM instance, which shows message passing on single erlang VM scales as expected. On Wed, Aug 20, 2014 at 12:37:02PM +0100, Jon Schneider wrote: > Isn't this simply pushing the performance of Erlang regardless of > networking ? > > I'm sitting at a machine which yes is several years old and running > Windows XP but with a simple ping-pong atom message test between a pair of > processes I get around 125k messages/second. > > Compiling with [hipe] doesn't seem to make any difference. > > Jon > > > Hi, Thanks for reply! > > > > I just tried, but it seems that there is no signigicant difference > > on performance. Here's script which used on benchmarking. > > > > https://gist.github.com/yjh0502/68d6ffce93bcbc425435 > > > > > > > > On Wed, Aug 20, 2014 at 02:11:07PM +0400, Alexander Petrovsky wrote: > >> Hello! > >> > >> Have you tried to use: > >> > >> # erl ... inet_default_connect_options '[{delay_send, true}]' > >> inet_default_listen_options '[{delay_send, true}]' > >> > >> ? > >> > >> > >> 2014-08-19 16:59 GMT+04:00 Jihyun Yu : > >> > >> > Hi, > >> > > >> > There is a prior discusson[1] about inter-node communication > >> bottleneck, > >> > and I experienced same issue on inter-node messaging. I dig into the > >> > issue and it found that there is a lock on inter-node messaging[2] > >> which > >> > causes bottleneck on sending messages to single node. With simple > >> > experiment, I found that there is a limitation on number of messages > >> per > >> > second, not bandwidth. 1Gbps link could be easily satuated by > >> messaging > >> > betweeen two erlang nodes if message size is large enough, e.g. 4KB > >> > binary message. However if message is small, e.g. single integer term, > >> > number of messages per seconds is limited about 200~300k/sec. > >> > > >> > Is there any effort to solve the problem? In fact the problem could be > >> > solved by using external channel like multiple TCP connection pool for > >> > rpc, but I believe using erlang messaging keeps code much simpler. > >> > Actually for me the problem is quite embrassing, because I thought > >> > scalable messaging is a key feature and strength of Erlang. > >> > > >> > > >> > [1] > >> http://erlang.org/pipermail/erlang-questions/2013-December/076232.html > >> > [2] > >> > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > > >> > >> > >> > >> -- > >> ???????????????????? ?????????????????? / 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 lukas@REDACTED Wed Aug 20 15:08:55 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 20 Aug 2014 15:08:55 +0200 Subject: [erlang-questions] hanging nodes In-Reply-To: References: Message-ID: Hello Vlad, This is most probably a windows only issue as the code in the stacktrace runs through a lot of windows specific code. I guess the easiest way would be if you are able to write a testcase that can reproduce the error so that I can debug it here. If that is not possible, maybe you can attach to the process and send me a windows "core file"? To do this you have to install WinDbg[1] and then do "File->Attach to a Process". After this you open the WinDbg console and type ".dump /ma c:\beam.smp.dmp" and then upload that file on a server where I can download it. Also I assume you have used one of the installers on erlang.org? Which version of windows+Erlang/OTP are you using? Lukas On Wed, Aug 20, 2014 at 11:18 AM, Vlad Dumitrescu wrote: > Some details: the beam process seems to have a thread that sits and does > something. I don't know if the following example stack helps. > > best regards, > Vlad > > wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b > wow64.dll!Wow64SystemServiceEx+0x1ce > wow64.dll!Wow64LdrpInitialize+0x42a > ntdll.dll!RtlIsDosDeviceName_U+0x23a27 > ntdll.dll!LdrInitializeThunk+0xe > > kernel32.dll!SetEvent+0x2 > beam.smp.dll!fd_stop+0x4f > beam.smp.dll!terminate_port+0x64 > beam.smp.dll!erts_deliver_port_exit+0x225 > beam.smp.dll!driver_failure_atom+0x93 > beam.smp.dll!ready_output+0xa9 > beam.smp.dll!erts_port_task_execute+0x28d > beam.smp.dll!schedule+0xb24 > beam.smp.dll!_process_main+0x125 > ntdll.dll!RtlImageNtHeader+0x716 > beam.smp.dll!do_erts_alcu_free+0x5f > beam.smp.dll!erts_alcu_free_thr_spec+0x58 > beam.smp.dll!thr_wrapper+0xa6 > kernel32.dll!BaseThreadInitThunk+0x12 > ntdll.dll!RtlInitializeExceptionChain+0x63 > ntdll.dll!RtlInitializeExceptionChain+0x36 > > > > On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu > wrote: > >> Hi! >> >> I have some nodes that don't want to terminate and that I can't connect >> to. Most of the times the nodes unregister from epmd, but even when they >> don't they still are inaccessible. >> >> I was hoping that by connecting to the node I can see why it is hanging, >> but I get the feeling that the hanging is not inside user code (because >> epmd detects the socket being closed, so the shutdown process is started). >> >> This is on Windows, but I have some reports for something that looks >> similar from Linux too. >> I'm not used to debugging this kind of situations, so I hope that someone >> has some advice for me. >> >> best regards, >> Vlad >> >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Wed Aug 20 15:16:22 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Wed, 20 Aug 2014 17:16:22 +0400 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140820114949.GB7620@debian> References: <20140819125903.GA4902@debian> <20140820110845.GA7620@debian> <89b70e08b2d8962c8a00e42a5b209f0c.squirrel@mail.jschneider.net> <20140820114949.GB7620@debian> Message-ID: Looks like pg2 may affect you network performance. Could you try get rid of it, and make bech again? 2014-08-20 15:49 GMT+04:00 Jihyun Yu : > What I want to say is, the benchmark does not scale on multi-core > machine while it uses multiple erlang processes to send message. > > I ran the benchmark with two erlang VM instances, on quad-core > laptop. It couldn't saturate all CPU cores, AFAIK because of lock > in erlang VM. The benchmark scales when it runs on single erlang > VM instance, which shows message passing on single erlang VM > scales as expected. > > > On Wed, Aug 20, 2014 at 12:37:02PM +0100, Jon Schneider wrote: > > Isn't this simply pushing the performance of Erlang regardless of > > networking ? > > > > I'm sitting at a machine which yes is several years old and running > > Windows XP but with a simple ping-pong atom message test between a pair > of > > processes I get around 125k messages/second. > > > > Compiling with [hipe] doesn't seem to make any difference. > > > > Jon > > > > > Hi, Thanks for reply! > > > > > > I just tried, but it seems that there is no signigicant difference > > > on performance. Here's script which used on benchmarking. > > > > > > https://gist.github.com/yjh0502/68d6ffce93bcbc425435 > > > > > > > > > > > > On Wed, Aug 20, 2014 at 02:11:07PM +0400, Alexander Petrovsky wrote: > > >> Hello! > > >> > > >> Have you tried to use: > > >> > > >> # erl ... inet_default_connect_options '[{delay_send, true}]' > > >> inet_default_listen_options '[{delay_send, true}]' > > >> > > >> ? > > >> > > >> > > >> 2014-08-19 16:59 GMT+04:00 Jihyun Yu : > > >> > > >> > Hi, > > >> > > > >> > There is a prior discusson[1] about inter-node communication > > >> bottleneck, > > >> > and I experienced same issue on inter-node messaging. I dig into the > > >> > issue and it found that there is a lock on inter-node messaging[2] > > >> which > > >> > causes bottleneck on sending messages to single node. With simple > > >> > experiment, I found that there is a limitation on number of messages > > >> per > > >> > second, not bandwidth. 1Gbps link could be easily satuated by > > >> messaging > > >> > betweeen two erlang nodes if message size is large enough, e.g. 4KB > > >> > binary message. However if message is small, e.g. single integer > term, > > >> > number of messages per seconds is limited about 200~300k/sec. > > >> > > > >> > Is there any effort to solve the problem? In fact the problem could > be > > >> > solved by using external channel like multiple TCP connection pool > for > > >> > rpc, but I believe using erlang messaging keeps code much simpler. > > >> > Actually for me the problem is quite embrassing, because I thought > > >> > scalable messaging is a key feature and strength of Erlang. > > >> > > > >> > > > >> > [1] > > >> > http://erlang.org/pipermail/erlang-questions/2013-December/076232.html > > >> > [2] > > >> > > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 > > >> > _______________________________________________ > > >> > erlang-questions mailing list > > >> > erlang-questions@REDACTED > > >> > http://erlang.org/mailman/listinfo/erlang-questions > > >> > > > >> > > >> > > >> > > >> -- > > >> ?????????? ????????? / 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 lukas@REDACTED Wed Aug 20 15:19:15 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 20 Aug 2014 15:19:15 +0200 Subject: [erlang-questions] hanging nodes In-Reply-To: References: Message-ID: Forgot the link to WinDbg[1]. [1]: http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx On Wed, Aug 20, 2014 at 3:08 PM, Lukas Larsson wrote: > Hello Vlad, > > This is most probably a windows only issue as the code in the stacktrace > runs through a lot of windows specific code. I guess the easiest way would > be if you are able to write a testcase that can reproduce the error so that > I can debug it here. If that is not possible, maybe you can attach to the > process and send me a windows "core file"? > > To do this you have to install WinDbg[1] and then do "File->Attach to a > Process". After this you open the WinDbg console and type ".dump /ma > c:\beam.smp.dmp" and then upload that file on a server where I can download > it. Also I assume you have used one of the installers on erlang.org? > Which version of windows+Erlang/OTP are you using? > > Lukas > > > On Wed, Aug 20, 2014 at 11:18 AM, Vlad Dumitrescu > wrote: > >> Some details: the beam process seems to have a thread that sits and does >> something. I don't know if the following example stack helps. >> >> best regards, >> Vlad >> >> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b >> wow64.dll!Wow64SystemServiceEx+0x1ce >> wow64.dll!Wow64LdrpInitialize+0x42a >> ntdll.dll!RtlIsDosDeviceName_U+0x23a27 >> ntdll.dll!LdrInitializeThunk+0xe >> >> kernel32.dll!SetEvent+0x2 >> beam.smp.dll!fd_stop+0x4f >> beam.smp.dll!terminate_port+0x64 >> beam.smp.dll!erts_deliver_port_exit+0x225 >> beam.smp.dll!driver_failure_atom+0x93 >> beam.smp.dll!ready_output+0xa9 >> beam.smp.dll!erts_port_task_execute+0x28d >> beam.smp.dll!schedule+0xb24 >> beam.smp.dll!_process_main+0x125 >> ntdll.dll!RtlImageNtHeader+0x716 >> beam.smp.dll!do_erts_alcu_free+0x5f >> beam.smp.dll!erts_alcu_free_thr_spec+0x58 >> beam.smp.dll!thr_wrapper+0xa6 >> kernel32.dll!BaseThreadInitThunk+0x12 >> ntdll.dll!RtlInitializeExceptionChain+0x63 >> ntdll.dll!RtlInitializeExceptionChain+0x36 >> >> >> >> On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu >> wrote: >> >>> Hi! >>> >>> I have some nodes that don't want to terminate and that I can't connect >>> to. Most of the times the nodes unregister from epmd, but even when they >>> don't they still are inaccessible. >>> >>> I was hoping that by connecting to the node I can see why it is hanging, >>> but I get the feeling that the hanging is not inside user code (because >>> epmd detects the socket being closed, so the shutdown process is started). >>> >>> This is on Windows, but I have some reports for something that looks >>> similar from Linux too. >>> I'm not used to debugging this kind of situations, so I hope that >>> someone has some advice for me. >>> >>> best regards, >>> Vlad >>> >>> >>> >>> >> >> _______________________________________________ >> 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 Wed Aug 20 15:20:21 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Aug 2014 15:20:21 +0200 Subject: [erlang-questions] hanging nodes In-Reply-To: References: Message-ID: Hi Lukas, I was about to send this anyway. Maybe this is enough from the dump? If not i will send the whole of it. You can also see it's R16B03-1, but it's the same for 15 and 17. The stacktrace is 0523f644 0f528254 02b40e88 000140cb 02b40d40 beam_smp!fd_stop+0x5a [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c @ 2351] 0523f660 0f529fe5 fffffffb 02b40d40 000140cb beam_smp!terminate_port+0x64 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 3417] 0523f678 0f52ad53 0000001b 00014607 000140cb beam_smp!erts_deliver_port_exit+0x225 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 3651] 0523f694 0f5cdd99 02b40d40 0f64099c 000000e8 beam_smp!driver_failure_atom+0x93 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 6948] 0523f6bc 0f543c5d 00000000 0000027c 03700580 beam_smp!ready_output+0xa9 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c @ 2850] 0523f700 0f53dba4 03700580 0370719c 000007d0 beam_smp!erts_port_task_execute+0x28d [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_port_task.c @ 1689] 0523f740 0f5a9255 03700580 000007d1 02723fe0 beam_smp!schedule+0xb24 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_process.c @ 7065] 0523f790 77bf38aa 00000017 03707100 00000f4b beam_smp!process_main+0x125 And the code is sys.c static void fd_stop(ErlDrvData data) { DriverData * dp = (DriverData *) data; /* * There's no way we can terminate an fd port in a consistent way. * Instead we let it live until it's opened again (which it is, * as the only FD-drivers are for 0,1 and 2 adn the only time they * get closed is by init:reboot). * So - just deselect them and let everything be as is. * They get woken up in fd_start again, where the DriverData is * remembered. /PaN */ if (dp->in.ov.hEvent != NULL) { (void) driver_select(dp->port_num, (ErlDrvEvent)dp->in.ov.hEvent, ERL_DRV_READ, 0); } if (dp->out.ov.hEvent != NULL) { (void) driver_select(dp->port_num, (ErlDrvEvent)dp->out.ov.hEvent, ERL_DRV_WRITE, 0); do { ASSERT(dp->out.flushEvent); SetEvent(dp->out.flushEvent); } while (WaitForSingleObject(dp->out.flushReplyEvent, 10) == WAIT_TIMEOUT || !(dp->out.flags & DF_THREAD_FLUSHED)); // this is line 2351 } } The code is not really hung, but it looks like the do/while loop is never exited. (It's possible that there's another loop at a higher level, in any case looking at the stacktrace et different moments it is most often like the one above). The use case is that the erlang node is started from java and the problem happens when the java process is killed mercilessly. I will try to create a simple test to reproduce this. regards, Vlad On Wed, Aug 20, 2014 at 3:08 PM, Lukas Larsson wrote: > Hello Vlad, > > This is most probably a windows only issue as the code in the stacktrace > runs through a lot of windows specific code. I guess the easiest way would > be if you are able to write a testcase that can reproduce the error so that > I can debug it here. If that is not possible, maybe you can attach to the > process and send me a windows "core file"? > > To do this you have to install WinDbg[1] and then do "File->Attach to a > Process". After this you open the WinDbg console and type ".dump /ma > c:\beam.smp.dmp" and then upload that file on a server where I can download > it. Also I assume you have used one of the installers on erlang.org? > Which version of windows+Erlang/OTP are you using? > > Lukas > > > On Wed, Aug 20, 2014 at 11:18 AM, Vlad Dumitrescu > wrote: > >> Some details: the beam process seems to have a thread that sits and does >> something. I don't know if the following example stack helps. >> >> best regards, >> Vlad >> >> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b >> wow64.dll!Wow64SystemServiceEx+0x1ce >> wow64.dll!Wow64LdrpInitialize+0x42a >> ntdll.dll!RtlIsDosDeviceName_U+0x23a27 >> ntdll.dll!LdrInitializeThunk+0xe >> >> kernel32.dll!SetEvent+0x2 >> beam.smp.dll!fd_stop+0x4f >> beam.smp.dll!terminate_port+0x64 >> beam.smp.dll!erts_deliver_port_exit+0x225 >> beam.smp.dll!driver_failure_atom+0x93 >> beam.smp.dll!ready_output+0xa9 >> beam.smp.dll!erts_port_task_execute+0x28d >> beam.smp.dll!schedule+0xb24 >> beam.smp.dll!_process_main+0x125 >> ntdll.dll!RtlImageNtHeader+0x716 >> beam.smp.dll!do_erts_alcu_free+0x5f >> beam.smp.dll!erts_alcu_free_thr_spec+0x58 >> beam.smp.dll!thr_wrapper+0xa6 >> kernel32.dll!BaseThreadInitThunk+0x12 >> ntdll.dll!RtlInitializeExceptionChain+0x63 >> ntdll.dll!RtlInitializeExceptionChain+0x36 >> >> >> >> On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu >> wrote: >> >>> Hi! >>> >>> I have some nodes that don't want to terminate and that I can't connect >>> to. Most of the times the nodes unregister from epmd, but even when they >>> don't they still are inaccessible. >>> >>> I was hoping that by connecting to the node I can see why it is hanging, >>> but I get the feeling that the hanging is not inside user code (because >>> epmd detects the socket being closed, so the shutdown process is started). >>> >>> This is on Windows, but I have some reports for something that looks >>> similar from Linux too. >>> I'm not used to debugging this kind of situations, so I hope that >>> someone has some advice for me. >>> >>> best regards, >>> Vlad >>> >>> >>> >>> >> >> _______________________________________________ >> 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 Wed Aug 20 15:25:54 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 20 Aug 2014 15:25:54 +0200 Subject: [erlang-questions] hanging nodes In-Reply-To: References: Message-ID: I think the dump would be very helpful. I need to know what the overlapped io threads are doing and what values are set in the dp->out struct. Lukas On Wed, Aug 20, 2014 at 3:20 PM, Vlad Dumitrescu wrote: > Hi Lukas, > > I was about to send this anyway. Maybe this is enough from the dump? If > not i will send the whole of it. You can also see it's R16B03-1, but it's > the same for 15 and 17. > > The stacktrace is > > 0523f644 0f528254 02b40e88 000140cb 02b40d40 beam_smp!fd_stop+0x5a > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c > @ 2351] > 0523f660 0f529fe5 fffffffb 02b40d40 000140cb beam_smp!terminate_port+0x64 > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c > @ 3417] > 0523f678 0f52ad53 0000001b 00014607 000140cb > beam_smp!erts_deliver_port_exit+0x225 > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c > @ 3651] > 0523f694 0f5cdd99 02b40d40 0f64099c 000000e8 > beam_smp!driver_failure_atom+0x93 > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c > @ 6948] > 0523f6bc 0f543c5d 00000000 0000027c 03700580 beam_smp!ready_output+0xa9 > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c > @ 2850] > 0523f700 0f53dba4 03700580 0370719c 000007d0 > beam_smp!erts_port_task_execute+0x28d > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_port_task.c > @ 1689] > 0523f740 0f5a9255 03700580 000007d1 02723fe0 beam_smp!schedule+0xb24 > [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_process.c > @ 7065] > 0523f790 77bf38aa 00000017 03707100 00000f4b beam_smp!process_main+0x125 > > And the code is sys.c > > static void fd_stop(ErlDrvData data) > { > DriverData * dp = (DriverData *) data; > /* > * There's no way we can terminate an fd port in a consistent way. > * Instead we let it live until it's opened again (which it is, > * as the only FD-drivers are for 0,1 and 2 adn the only time they > * get closed is by init:reboot). > * So - just deselect them and let everything be as is. > * They get woken up in fd_start again, where the DriverData is > * remembered. /PaN > */ > if (dp->in.ov.hEvent != NULL) { > (void) driver_select(dp->port_num, > (ErlDrvEvent)dp->in.ov.hEvent, > ERL_DRV_READ, 0); > } > if (dp->out.ov.hEvent != NULL) { > (void) driver_select(dp->port_num, > (ErlDrvEvent)dp->out.ov.hEvent, > ERL_DRV_WRITE, 0); > do { > ASSERT(dp->out.flushEvent); > SetEvent(dp->out.flushEvent); > } while (WaitForSingleObject(dp->out.flushReplyEvent, 10) == > WAIT_TIMEOUT > || !(dp->out.flags & DF_THREAD_FLUSHED)); // this is line 2351 > } > > } > > The code is not really hung, but it looks like the do/while loop is never > exited. (It's possible that there's another loop at a higher level, in any > case looking at the stacktrace et different moments it is most often like > the one above). > > The use case is that the erlang node is started from java and the problem > happens when the java process is killed mercilessly. I will try to create a > simple test to reproduce this. > > regards, > Vlad > > > > On Wed, Aug 20, 2014 at 3:08 PM, Lukas Larsson wrote: > >> Hello Vlad, >> >> This is most probably a windows only issue as the code in the stacktrace >> runs through a lot of windows specific code. I guess the easiest way would >> be if you are able to write a testcase that can reproduce the error so that >> I can debug it here. If that is not possible, maybe you can attach to the >> process and send me a windows "core file"? >> >> To do this you have to install WinDbg[1] and then do "File->Attach to a >> Process". After this you open the WinDbg console and type ".dump /ma >> c:\beam.smp.dmp" and then upload that file on a server where I can download >> it. Also I assume you have used one of the installers on erlang.org? >> Which version of windows+Erlang/OTP are you using? >> >> Lukas >> >> >> On Wed, Aug 20, 2014 at 11:18 AM, Vlad Dumitrescu >> wrote: >> >>> Some details: the beam process seems to have a thread that sits and does >>> something. I don't know if the following example stack helps. >>> >>> best regards, >>> Vlad >>> >>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b >>> wow64.dll!Wow64SystemServiceEx+0x1ce >>> wow64.dll!Wow64LdrpInitialize+0x42a >>> ntdll.dll!RtlIsDosDeviceName_U+0x23a27 >>> ntdll.dll!LdrInitializeThunk+0xe >>> >>> kernel32.dll!SetEvent+0x2 >>> beam.smp.dll!fd_stop+0x4f >>> beam.smp.dll!terminate_port+0x64 >>> beam.smp.dll!erts_deliver_port_exit+0x225 >>> beam.smp.dll!driver_failure_atom+0x93 >>> beam.smp.dll!ready_output+0xa9 >>> beam.smp.dll!erts_port_task_execute+0x28d >>> beam.smp.dll!schedule+0xb24 >>> beam.smp.dll!_process_main+0x125 >>> ntdll.dll!RtlImageNtHeader+0x716 >>> beam.smp.dll!do_erts_alcu_free+0x5f >>> beam.smp.dll!erts_alcu_free_thr_spec+0x58 >>> beam.smp.dll!thr_wrapper+0xa6 >>> kernel32.dll!BaseThreadInitThunk+0x12 >>> ntdll.dll!RtlInitializeExceptionChain+0x63 >>> ntdll.dll!RtlInitializeExceptionChain+0x36 >>> >>> >>> >>> On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu >>> wrote: >>> >>>> Hi! >>>> >>>> I have some nodes that don't want to terminate and that I can't connect >>>> to. Most of the times the nodes unregister from epmd, but even when they >>>> don't they still are inaccessible. >>>> >>>> I was hoping that by connecting to the node I can see why it is >>>> hanging, but I get the feeling that the hanging is not inside user code >>>> (because epmd detects the socket being closed, so the shutdown process is >>>> started). >>>> >>>> This is on Windows, but I have some reports for something that looks >>>> similar from Linux too. >>>> I'm not used to debugging this kind of situations, so I hope that >>>> someone has some advice for me. >>>> >>>> best 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Aug 20 15:28:36 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 20 Aug 2014 16:28:36 +0300 Subject: [erlang-questions] [ANN] erlang.mk 1.0 In-Reply-To: <53DB9120.3070904@ninenines.eu> References: <53DB9120.3070904@ninenines.eu> Message-ID: <53F4A284.1020808@ninenines.eu> Hello! Just a quick heads up: erlang.mk 1.1 has been released. I want to thank everyone for the huge amount of interest there has been since the 1.0 announcement. This release is mostly bug fixes. Makefiles do not need to be changed. The minor version got increased due to behavior changing slightly as described below. New packages in the index: neo4j, pegjs, epgsql, jiffy, lager, resource_discovery, katja, tinymt-erlang and erwa. Thanks to everyone who submitted them. We now have 19 packages listed, with more to come. You can help too: https://gist.github.com/essen/9ef9342e7dea993889c3 Other than help/error messages and documentation tweaks, fixes include: * relx was being downloaded on all rel builds; this was corrected * relx targets are now defined regardless of relx.config presence * fix handling of RELX_OUTPUT_DIR variable * .hrl files modification now forces all project to recompile * .plt files are now automatically generated on 'make dialyze' * fix compatibility with FreeBSD and some Linux environments Thanks to everyone who contributed with bug reports and fixes! On 08/01/2014 04:07 PM, Lo?c Hoguin wrote: > Hello! > > erlang.mk 1.0 has been released. > > erlang.mk is a GNU Make based build system with bootstrap and package > index features that make life so much better. > > https://github.com/ninenines/erlang.mk > > Going from 0 to release is a 5 steps process with erlang.mk. > > * # Create a directory for your application > * # Download erlang.mk into that directory > * make -f erlang.mk bootstrap bootstrap-rel > * make > * ./_rel/your_release/bin/your_release console > > And if you want to use a third party project, like Cowboy, you simply > need to add this one line to your Makefile and then run make again: > > * DEPS = cowboy > > That's really it! > > A note for previous users: a few small things changed since the previous > version. You can take a look at the Cowboy or Ranch repositories for > details. It's mostly a number of things you don't have to do anymore so > it's a quick upgrade, just delete a few lines! This new version is > compatible with projects using an older erlang.mk so you can update at > your own pace. > > Don't forget to add your Make-powered projects to the package index file > and send a PR to make everyone's life better! > > Enjoy! > -- Lo?c Hoguin http://ninenines.eu From yjh0502@REDACTED Wed Aug 20 15:39:58 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Wed, 20 Aug 2014 22:39:58 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: References: <20140819125903.GA4902@debian> <20140820110845.GA7620@debian> <89b70e08b2d8962c8a00e42a5b209f0c.squirrel@mail.jschneider.net> <20140820114949.GB7620@debian> Message-ID: <20140820133958.GA8442@debian> I don't think so. pg2 functions are just helper function to pass pid to other node, and called only once or twice per sender/receiver process. To make sure, I made new benchmark program without pg2 functions, and results are same. I tested with N=4 and Count=1000000. Updated benchmark program is attached. On Wed, Aug 20, 2014 at 05:16:22PM +0400, Alexander Petrovsky wrote: > Looks like pg2 may affect you network performance. Could you try get rid of > it, and make bech again? > > > 2014-08-20 15:49 GMT+04:00 Jihyun Yu : > > > What I want to say is, the benchmark does not scale on multi-core > > machine while it uses multiple erlang processes to send message. > > > > I ran the benchmark with two erlang VM instances, on quad-core > > laptop. It couldn't saturate all CPU cores, AFAIK because of lock > > in erlang VM. The benchmark scales when it runs on single erlang > > VM instance, which shows message passing on single erlang VM > > scales as expected. > > > > > > On Wed, Aug 20, 2014 at 12:37:02PM +0100, Jon Schneider wrote: > > > Isn't this simply pushing the performance of Erlang regardless of > > > networking ? > > > > > > I'm sitting at a machine which yes is several years old and running > > > Windows XP but with a simple ping-pong atom message test between a pair > > of > > > processes I get around 125k messages/second. > > > > > > Compiling with [hipe] doesn't seem to make any difference. > > > > > > Jon > > > > > > > Hi, Thanks for reply! > > > > > > > > I just tried, but it seems that there is no signigicant difference > > > > on performance. Here's script which used on benchmarking. > > > > > > > > https://gist.github.com/yjh0502/68d6ffce93bcbc425435 > > > > > > > > > > > > > > > > On Wed, Aug 20, 2014 at 02:11:07PM +0400, Alexander Petrovsky wrote: > > > >> Hello! > > > >> > > > >> Have you tried to use: > > > >> > > > >> # erl ... inet_default_connect_options '[{delay_send, true}]' > > > >> inet_default_listen_options '[{delay_send, true}]' > > > >> > > > >> ? > > > >> > > > >> > > > >> 2014-08-19 16:59 GMT+04:00 Jihyun Yu : > > > >> > > > >> > Hi, > > > >> > > > > >> > There is a prior discusson[1] about inter-node communication > > > >> bottleneck, > > > >> > and I experienced same issue on inter-node messaging. I dig into the > > > >> > issue and it found that there is a lock on inter-node messaging[2] > > > >> which > > > >> > causes bottleneck on sending messages to single node. With simple > > > >> > experiment, I found that there is a limitation on number of messages > > > >> per > > > >> > second, not bandwidth. 1Gbps link could be easily satuated by > > > >> messaging > > > >> > betweeen two erlang nodes if message size is large enough, e.g. 4KB > > > >> > binary message. However if message is small, e.g. single integer > > term, > > > >> > number of messages per seconds is limited about 200~300k/sec. > > > >> > > > > >> > Is there any effort to solve the problem? In fact the problem could > > be > > > >> > solved by using external channel like multiple TCP connection pool > > for > > > >> > rpc, but I believe using erlang messaging keeps code much simpler. > > > >> > Actually for me the problem is quite embrassing, because I thought > > > >> > scalable messaging is a key feature and strength of Erlang. > > > >> > > > > >> > > > > >> > [1] > > > >> > > http://erlang.org/pipermail/erlang-questions/2013-December/076232.html > > > >> > [2] > > > >> > > > https://github.com/erlang/otp/blob/OTP-17.1/erts/emulator/beam/dist.c#L1768-L1826 > > > >> > _______________________________________________ > > > >> > erlang-questions mailing list > > > >> > erlang-questions@REDACTED > > > >> > http://erlang.org/mailman/listinfo/erlang-questions > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> ?????????? ????????? / 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 -------------- -module(test2). -compile([export_all]). recv(N, Count) -> lists:map(fun(_) -> spawn_link(fun() -> (fun Recvmsg(0) -> ok; Recvmsg(Remain) -> receive _ -> Recvmsg(Remain-1) end end)(Count) end) end, lists:seq(1, N)). send(Pids, Count) -> lists:map(fun(Pid) -> spawn_link(fun() -> (fun Sendmsg(0) -> ok; Sendmsg(Remain) -> Pid ! Remain, Sendmsg(Remain - 1) end)(Count) end) end, Pids). % Spawn N processes, each process sends/receives Count messages % Sender runs on 'From' node, receiver runs on 'To' node % % Following code runs sender on 'foo@REDACTED', receiver on % 'bar@REDACTED'. Four processes are uses to send/receive messages, % and each process sends/receives 1,000,000 messages. % % run('foo@REDACTED', 'bar@REDACTED', 4, 1000 * 1000). run(From, To, N, Count) -> Pid = self(), spawn_link(To, fun() -> Pid ! recv(N, Count) end), receive Pids -> spawn_link(From, fun() -> send(Pids, Count) end) end. From federico.carrone@REDACTED Wed Aug 20 15:52:04 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Wed, 20 Aug 2014 10:52:04 -0300 Subject: [erlang-questions] [ANN] Chicago Erlang Conference - Sept 22 - aka "Best Lineup Ever" In-Reply-To: References: Message-ID: I am too far away (Buenos Aires) to go. It would be AWESOME if somebody could record the talks. Regards, Federico. On Tue, Aug 19, 2014 at 6:33 PM, Garrett Smith wrote: > For a single day, September 22, Chicago will become the center of know > Erlang universe: > > http://www.chicagoerlang.com > > This is a single track conference organized by the Chicago Erlang User > Group and Erlang Solutions that is focusing on "Real World Erlang". > The talks are very technical and practical: > > - Joe Armstrong: Modeling the World with Processes, Objects, Functions > or Relations > > - Francesco Cesarini: Thinking in a Concurrent Language > > - Steve Vinoski: Optimizing Native Code for Erlang > > - Fred Hebert: Keeping a System Running Forever > > - Irina Guberman: Maximizing Throughput On Multicore Systems > > - Reid Draper: Building Fault Tolerant Teams At Basho > > - Brian Troutwine: Monitoring Complex Systems > > - Jesse Gumm: Building Web Scale Apps with Nitrogen > > - Garrett Smith: Writing Quality Code in Erlang > > Zach Kessin will be hosting the Mostly Erlang podcast live at the after > party. > > Even if you're not in Chicago, really, this is worth a trip. If you > are in Chicago, you are simple required to go. It's a requirement. > > Seriously, come to this conference. > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.quesadas@REDACTED Wed Aug 20 16:05:07 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Wed, 20 Aug 2014 16:05:07 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Hi there! Sorry about the delay, summertime.... I've tests *to append or substitute -pa to -pz*, without any positive results, if i've check which paths are loaded, using: code:get_path(). there's no difference between pa or pz, as a result,still getting the same error: {value, {badrpc, {'EXIT', * {undef,* * [{cluster,join,[...],...},* * {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]}* Anyone coould give me any clue? If i'm not worng, this error is answering that join function is undefined on cluster module, as you see all those methods are exported, in fact, if join wasn't exported * cluster_test:cluster_formation() * will ever fail. -export([start/0, stop/0, join/1, leave/0, status/0, get_ring/0, get_timestamp/0]). -export([ping/1, get/1, set/2, register/2]). Thank you! 2014-08-04 23:51 GMT+02:00 T Ty : > -pa adds to front of the path. -pz to the end of the path. > > > On Mon, Aug 4, 2014 at 4:14 PM, marcos quesada > wrote: > >> Nop, didn't find it. Maybe i'm missing something, but I think that slaves >> nodes are getting right the path to find all required beams. All slaves are >> initialized using: >> Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", >> In fact when I execute cluster_test:cluster_formation() works fine. >> >> What's the difference to use -pz from -pa? >> >> Thank you! >> >> El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie >> escribi?: >> > marcos quesada wrote: >> > >> > >> > >> > mq> **error:{assertEqual_failed, >> > >> > mq> [{module,cluster_test}, >> > >> > mq> {line,43}, >> > >> > mq> {expression,"Result1"}, >> > >> > mq> {expected,ok}, >> > >> > mq> {value, >> > >> > mq> {badrpc, >> > >> > mq> {'EXIT', >> > >> > mq> {undef, >> > >> > mq> [{cluster,join,[...],...}, >> > >> > mq> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} >> > >> > >> > >> > Have you found the cause of this error? If I had to guess, the slave >> > >> > node's code_server doesn't know the path to your cluster.beam module. >> > >> > If that's true, then appending ["-pz", PathToYourModule] to the Args >> > >> > list of slave:start/3 can correct it. >> > >> > >> > >> > -Scott >> > >> > _______________________________________________ >> > >> > 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 g@REDACTED Wed Aug 20 16:18:12 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 20 Aug 2014 09:18:12 -0500 Subject: [erlang-questions] Trouble getting posts through Message-ID: I think I saw this in an earlier thread - but I still don't understand something. I'm starting to get this reply for certain messages to the list: "Your message to erlang-questions awaits moderator approval" Is it the "[ANN]" in the subject? (Oh shoot, did me typing that there make this a suspicious email?) I did see a "[ANN}" hack. Clever, but is this really necessary in a civilized world? Garrett From g@REDACTED Wed Aug 20 16:14:38 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 20 Aug 2014 09:14:38 -0500 Subject: [erlang-questions] [ANN] Chicago Erlang Conference - Sept 22 - aka "Best Lineup Ever" In-Reply-To: References: Message-ID: We will likely have video recordings as we did last year. That's the plan. However, if you live around Chicago or within easy flight access (O'Hare is generally a cheaper ticket), we'll be blocking your IP range for the videos, thereby forcing you to come. [1] Garrett [1] We won't do this. On Wed, Aug 20, 2014 at 8:52 AM, Federico Carrone wrote: > I am too far away (Buenos Aires) to go. It would be AWESOME if somebody > could record the talks. > > Regards, > Federico. > > > On Tue, Aug 19, 2014 at 6:33 PM, Garrett Smith wrote: >> >> For a single day, September 22, Chicago will become the center of know >> Erlang universe: >> >> http://www.chicagoerlang.com >> >> This is a single track conference organized by the Chicago Erlang User >> Group and Erlang Solutions that is focusing on "Real World Erlang". >> The talks are very technical and practical: >> >> - Joe Armstrong: Modeling the World with Processes, Objects, Functions >> or Relations >> >> - Francesco Cesarini: Thinking in a Concurrent Language >> >> - Steve Vinoski: Optimizing Native Code for Erlang >> >> - Fred Hebert: Keeping a System Running Forever >> >> - Irina Guberman: Maximizing Throughput On Multicore Systems >> >> - Reid Draper: Building Fault Tolerant Teams At Basho >> >> - Brian Troutwine: Monitoring Complex Systems >> >> - Jesse Gumm: Building Web Scale Apps with Nitrogen >> >> - Garrett Smith: Writing Quality Code in Erlang >> >> Zach Kessin will be hosting the Mostly Erlang podcast live at the after >> party. >> >> Even if you're not in Chicago, really, this is worth a trip. If you >> are in Chicago, you are simple required to go. It's a requirement. >> >> Seriously, come to this conference. >> >> Garrett >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > http://federicocarrone.com/ From sverker.eriksson@REDACTED Wed Aug 20 16:29:19 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 20 Aug 2014 16:29:19 +0200 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140819125903.GA4902@debian> References: <20140819125903.GA4902@debian> Message-ID: <53F4B0BF.5060309@erix.ericsson.se> On 08/19/2014 02:59 PM, Jihyun Yu wrote: > Hi, > > There is a prior discusson[1] about inter-node communication bottleneck, > and I experienced same issue on inter-node messaging. I dig into the > issue and it found that there is a lock on inter-node messaging[2] which > causes bottleneck on sending messages to single node. How did you draw conclusion about the distribution lock queue being a bottleneck? Did you use the lock counting[1], and if so what was the profiling stats? /Sverker, Erlang/OTP [1] http://www.erlang.org/doc/apps/tools/lcnt_chapter.html From marcos.quesadas@REDACTED Wed Aug 20 17:16:03 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Wed, 20 Aug 2014 17:16:03 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Hi there! Adding more debug to understand what is happening, I've found that there's somehting wrong from the included path, so that, using make quicktests (that fires the whole testsuite), executing path: filename:absname("") equals ~/cluster/.eunit . Executinng eunit:test(cluster_test) manually the execution path belongs to cluster app, so that, now its completed succesfully. So, now i'm able to pass eunit:test(cluster_test), but if I try to execute from the whole suite test, it fails (undefined , timeout), at least the problem seems to belong to some missconfigured path. 2014-08-20 16:05 GMT+02:00 marcos quesada : > Hi there! > > Sorry about the delay, summertime.... > > I've tests *to append or substitute -pa to -pz*, without any positive > results, if i've check which paths are loaded, using: code:get_path(). > there's no difference between pa or pz, as a result,still getting the same > error: > > {value, > {badrpc, > {'EXIT', > * {undef,* > * [{cluster,join,[...],...},* > * {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]}* > > Anyone coould give me any clue? > If i'm not worng, this error is answering that join function is undefined > on cluster module, as you see all those methods are exported, in fact, if > join wasn't exported * cluster_test:cluster_formation() * will ever fail. > > > -export([start/0, stop/0, join/1, leave/0, status/0, get_ring/0, > get_timestamp/0]). > -export([ping/1, get/1, set/2, register/2]). > > > Thank you! > > > > 2014-08-04 23:51 GMT+02:00 T Ty : > > -pa adds to front of the path. -pz to the end of the path. >> >> >> On Mon, Aug 4, 2014 at 4:14 PM, marcos quesada > > wrote: >> >>> Nop, didn't find it. Maybe i'm missing something, but I think that >>> slaves nodes are getting right the path to find all required beams. All >>> slaves are initialized using: >>> Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", >>> In fact when I execute cluster_test:cluster_formation() works fine. >>> >>> What's the difference to use -pz from -pa? >>> >>> Thank you! >>> >>> El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie >>> escribi?: >>> > marcos quesada wrote: >>> > >>> > >>> > >>> > mq> **error:{assertEqual_failed, >>> > >>> > mq> [{module,cluster_test}, >>> > >>> > mq> {line,43}, >>> > >>> > mq> {expression,"Result1"}, >>> > >>> > mq> {expected,ok}, >>> > >>> > mq> {value, >>> > >>> > mq> {badrpc, >>> > >>> > mq> {'EXIT', >>> > >>> > mq> {undef, >>> > >>> > mq> [{cluster,join,[...],...}, >>> > >>> > mq> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} >>> > >>> > >>> > >>> > Have you found the cause of this error? If I had to guess, the slave >>> > >>> > node's code_server doesn't know the path to your cluster.beam module. >>> > >>> > If that's true, then appending ["-pz", PathToYourModule] to the Args >>> > >>> > list of slave:start/3 can correct it. >>> > >>> > >>> > >>> > -Scott >>> > >>> > _______________________________________________ >>> > >>> > 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 erlangerintraining@REDACTED Wed Aug 20 17:38:55 2014 From: erlangerintraining@REDACTED (Kristoffer Brown) Date: Wed, 20 Aug 2014 09:38:55 -0600 Subject: [erlang-questions] Trouble getting bigwig to run In-Reply-To: References: Message-ID: Lo?c, Thank you. Shaman looks like an excellent start. It appears to depend on R16 which we have not updated to yet. But, I may be able to get in running with a few changes. I will let you know. Thank you! Best -rb On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > Bigwig was written against a very old version of Cowboy. It shouldn't be > impossible to port but a lot changed since. Cowboy has a changelog file in > the repository. > > That said, I had started working on a replacement called Shaman > (extend/shaman) that handles multiple nodes and uses D3 for > rendering/updates, but I stopped working on it for now because I do not > have a production system to use it with (so the values I output may not be > interesting). I am going to resume as soon as I find something to develop > against. That said, contributions are always welcome. It shouldn't take > much more work to add the missing features bigwig had either. > > -- > Lo?c Hoguin > http://ninenines.eu > > > > -------- Original Message -------- > From:Ryan Brown > Sent:Tue, 19 Aug 2014 07:44:44 +0200 > To:Erlang Questions > Subject:Re: [erlang-questions] Trouble getting bigwig to run > > Figured it out. Not that hard with clear eyes really. Bigwig still refers > to an older version of cowboy. I could revery back to that compatible > version. But, what I would really like is to upgrade my fork to be > compatible with the latest. > > So, what I am looking for is documentation or changelogs to help me with > this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http > migration. > > I'll keep fumbling my way through but any insight from those whom have > been through it would be greatly appreciated. > > Thanks. > > > On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: > >> I am testing-out bigwig for a possible monitoring solution for my >> application. When I attempt to hook it up to my application I get the >> following cowboy error. I am having trouble deciphering it. Any help would >> be greatly appreciated. >> >> =INFO REPORT==== 18-Aug-2014::20:23:37 === >> Bigwig listening on http://127.0.0.1:40829/ >> >> >> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >> crasher: >> initial call: bigwig_http:init/1 >> pid: <0.4861.0> >> registered_name: [] >> exception exit: {undef, >> [{cowboy,start_listener, >> [http,16,cowboy_tcp_transport, >> [{port,40829}], >> cowboy_http_protocol, >> [{dispatch, >> [{'_', >> [{[],bigwig_http_static, >> [<<"html">>,<<"index.html">>]}, >> {[<<"static">>,'...'],bigwig_http_static,[]}, >> {[<<"vm">>],bigwig_http_vm,[]}, >> {[<<"rb">>,<<"stream">>], >> bigwig_http_rb_stream,[]}, >> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >> {[<<"module">>,'...'],bigwig_http_module,[]}, >> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >> {[<<"stats-stream">>], >> bigwig_http_stats_stream,[]}, >> {'_',bigwig_http_catchall,[]}]}]}]], >> []}, >> {bigwig_http,init,1, >> [{file,"src/bigwig_http.erl"},{line,54}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,304}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]} >> in function gen_server:init_it/6 (gen_server.erl, line 328) >> ancestors: [bigwig_sup,<0.4853.0>] >> messages: [] >> links: [<0.4854.0>] >> dictionary: [] >> trap_exit: false >> status: running >> heap_size: 610 >> stack_size: 24 >> reductions: 911 >> neighbours: >> >> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >> Supervisor: {local,bigwig_sup} >> Context: start_error >> Reason: {undef, >> [{cowboy,start_listener, >> [http,16,cowboy_tcp_transport, >> [{port,40829}], >> cowboy_http_protocol, >> [{dispatch, >> [{'_', >> [{[],bigwig_http_static, >> [<<"html">>,<<"index.html">>]}, >> {[<<"static">>,'...'], >> bigwig_http_static,[]}, >> {[<<"vm">>],bigwig_http_vm,[]}, >> {[<<"rb">>,<<"stream">>], >> bigwig_http_rb_stream,[]}, >> >> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >> >> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >> {[<<"module">>,'...'], >> bigwig_http_module,[]}, >> >> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >> {[<<"appmon">>,'...'], >> bigwig_http_appmon,[]}, >> {[<<"stats-stream">>], >> bigwig_http_stats_stream,[]}, >> {'_',bigwig_http_catchall,[]}]}]}]], >> []}, >> {bigwig_http,init,1, >> [{file,"src/bigwig_http.erl"},{line,54}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,304}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]} >> Offender: [{pid,undefined}, >> {name,bigwig_http}, >> {mfargs,{bigwig_http,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,5000}, >> {child_type,worker}] >> >> >> =INFO REPORT==== 18-Aug-2014::20:23:37 === >> application: bigwig >> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >> type: temporary >> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >> >> -- >> -rb >> > > > > -- > -rb > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > Bigwig was written against a very old version of Cowboy. It shouldn't be > impossible to port but a lot changed since. Cowboy has a changelog file in > the repository. > > That said, I had started working on a replacement called Shaman > (extend/shaman) that handles multiple nodes and uses D3 for > rendering/updates, but I stopped working on it for now because I do not > have a production system to use it with (so the values I output may not be > interesting). I am going to resume as soon as I find something to develop > against. That said, contributions are always welcome. It shouldn't take > much more work to add the missing features bigwig had either. > > -- > Lo?c Hoguin > http://ninenines.eu > > > -------- Original Message -------- > From:Ryan Brown > Sent:Tue, 19 Aug 2014 07:44:44 +0200 > To:Erlang Questions > Subject:Re: [erlang-questions] Trouble getting bigwig to run > > Figured it out. Not that hard with clear eyes really. Bigwig still refers > to an older version of cowboy. I could revery back to that compatible > version. But, what I would really like is to upgrade my fork to be > compatible with the latest. > > So, what I am looking for is documentation or changelogs to help me with > this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http > migration. > > I'll keep fumbling my way through but any insight from those whom have > been through it would be greatly appreciated. > > Thanks. > > > On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: > >> I am testing-out bigwig for a possible monitoring solution for my >> application. When I attempt to hook it up to my application I get the >> following cowboy error. I am having trouble deciphering it. Any help would >> be greatly appreciated. >> >> =INFO REPORT==== 18-Aug-2014::20:23:37 === >> Bigwig listening on http://127.0.0.1:40829/ >> >> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >> crasher: >> initial call: bigwig_http:init/1 >> pid: <0.4861.0> >> registered_name: [] >> exception exit: {undef, >> [{cowboy,start_listener, >> [http,16,cowboy_tcp_transport, >> [{port,40829}], >> cowboy_http_protocol, >> [{dispatch, >> [{'_', >> [{[],bigwig_http_static, >> [<<"html">>,<<"index.html">>]}, >> {[<<"static">>,'...'],bigwig_http_static,[]}, >> {[<<"vm">>],bigwig_http_vm,[]}, >> {[<<"rb">>,<<"stream">>], >> bigwig_http_rb_stream,[]}, >> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >> {[<<"module">>,'...'],bigwig_http_module,[]}, >> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >> {[<<"stats-stream">>], >> bigwig_http_stats_stream,[]}, >> {'_',bigwig_http_catchall,[]}]}]}]], >> []}, >> {bigwig_http,init,1, >> [{file,"src/bigwig_http.erl"},{line,54}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,304}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]} >> in function gen_server:init_it/6 (gen_server.erl, line 328) >> ancestors: [bigwig_sup,<0.4853.0>] >> messages: [] >> links: [<0.4854.0>] >> dictionary: [] >> trap_exit: false >> status: running >> heap_size: 610 >> stack_size: 24 >> reductions: 911 >> neighbours: >> >> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >> Supervisor: {local,bigwig_sup} >> Context: start_error >> Reason: {undef, >> [{cowboy,start_listener, >> [http,16,cowboy_tcp_transport, >> [{port,40829}], >> cowboy_http_protocol, >> [{dispatch, >> [{'_', >> [{[],bigwig_http_static, >> [<<"html">>,<<"index.html">>]}, >> {[<<"static">>,'...'], >> bigwig_http_static,[]}, >> {[<<"vm">>],bigwig_http_vm,[]}, >> {[<<"rb">>,<<"stream">>], >> bigwig_http_rb_stream,[]}, >> >> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >> >> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >> {[<<"module">>,'...'], >> bigwig_http_module,[]}, >> >> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >> {[<<"appmon">>,'...'], >> bigwig_http_appmon,[]}, >> {[<<"stats-stream">>], >> bigwig_http_stats_stream,[]}, >> {'_',bigwig_http_catchall,[]}]}]}]], >> []}, >> {bigwig_http,init,1, >> [{file,"src/bigwig_http.erl"},{line,54}]}, >> {gen_server,init_it,6, >> [{file,"gen_server.erl"},{line,304}]}, >> {proc_lib,init_p_do_apply,3, >> [{file,"proc_lib.erl"},{line,227}]}]} >> Offender: [{pid,undefined}, >> {name,bigwig_http}, >> {mfargs,{bigwig_http,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,5000}, >> {child_type,worker}] >> >> >> =INFO REPORT==== 18-Aug-2014::20:23:37 === >> application: bigwig >> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >> type: temporary >> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >> >> -- >> -rb >> > > > > -- > -rb > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yjh0502@REDACTED Wed Aug 20 18:01:35 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Thu, 21 Aug 2014 01:01:35 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <53F4B0BF.5060309@erix.ericsson.se> References: <20140819125903.GA4902@debian> <53F4B0BF.5060309@erix.ericsson.se> Message-ID: <20140820160135.GA10399@debian> First, I assume that elang VM itself is scalable because there is no problem when I ran benchmark on single Erlang instance. During benchmark, Erlang instance couldn't saturate CPU while it had enough number of threads and erlang processes. Bandwidth also couldn't be a problem because the result can be reproducible on single machine with loopback interface, which is not a bottleneck at least on ~100Mbps throughput. So I thought that lock is a problem. I profiled erlang VM with systemtap, collect userspace stacktraces when lock collides. It showed two frequently colliding locks: one is from schedular_wait(), another one is from erts_dsig_send_msg(). schedular_wait() couldn't be a problem because benchmark works as expected without inter-node communication. Here's example stacktrace I got during experiment. __lll_lock_wait+0x1d/0x30 [/usr/lib64/libpthread-2.17.so] _L_lock_790+0xf/0x1b [/usr/lib64/libpthread-2.17.so] __pthread_mutex_lock+0x37/0x122 [/usr/lib64/libpthread-2.17.so] erts_dsig_send_msg+0x3c5/0x640 [erts-6.1/bin/beam.smp] remote_send+0xc7/0x220 [erts-6.1/bin/beam.smp] erl_send+0x581/0xa60 [erts-6.1/bin/beam.smp] process_main+0x80f2/0xba80 [erts-6.1/bin/beam.smp] sched_thread_func+0xe2/0x1d0 [erts-6.1/bin/beam.smp] thr_wrapper+0x65/0xb0 [erts-6.1/bin/beam.smp] start_thread+0xc3/0x310 [/usr/lib64/libpthread-2.17.so] clone+0x6d/0x90 [/usr/lib64/libc-2.17.so] The experiment is done on 2-cpu 12-core HP machine with CentOS 7. I attached systemtap script and a result. On Wed, Aug 20, 2014 at 04:29:19PM +0200, Sverker Eriksson wrote: > On 08/19/2014 02:59 PM, Jihyun Yu wrote: > >Hi, > > > >There is a prior discusson[1] about inter-node communication bottleneck, > >and I experienced same issue on inter-node messaging. I dig into the > >issue and it found that there is a lock on inter-node messaging[2] which > >causes bottleneck on sending messages to single node. > > How did you draw conclusion about the distribution lock queue being a > bottleneck? > Did you use the lock counting[1], and if so what was the profiling stats? > > > /Sverker, Erlang/OTP > > > [1] http://www.erlang.org/doc/apps/tools/lcnt_chapter.html > -------------- next part -------------- #! /usr/bin/env stap # This script tries to identify contended user-space locks by hooking # into the futex system call. global FUTEX_WAIT = 0 /*, FUTEX_WAKE = 1 */ global FUTEX_PRIVATE_FLAG = 128 /* linux 2.6.22+ */ global FUTEX_CLOCK_REALTIME = 256 /* linux 2.6.29+ */ global lock_waits # long-lived stats on (tid,lock) blockage elapsed time probe syscall.futex.return { if (($op & ~(FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME)) != FUTEX_WAIT) next if (pid() != target()) next elapsed = gettimeofday_us() - @entry(gettimeofday_us()) lock_waits[tid(), $uaddr] <<< elapsed print_usyms(ubacktrace()); printf("\n"); } probe end { foreach ([tid+, lock] in lock_waits) printf ("[%d] lock %p contended %d times, %d avg us\n", tid, lock, @count(lock_waits[tid,lock]), @avg(lock_waits[tid,lock])) } -------------- next part -------------- A non-text attachment was scrubbed... Name: samples.xz Type: application/octet-stream Size: 6380 bytes Desc: not available URL: From marcos.quesadas@REDACTED Wed Aug 20 18:03:29 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Wed, 20 Aug 2014 18:03:29 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Thin i've found something related: "slave:start/3 time out when EUnit started with ERL_FLAGS" http://erlang.org/pipermail/erlang-questions/2011-September/061010.html Makefile is: start: *(it works)* @$(ERL) -config test/conf/app.eunit.config -args_file test/conf/vm.eunit.args \ -pa $PWD ebin deps/*/ebin -rsh ssh -boot start_sasl -s cluster quicktests: *(it fails)* rm -rf .eunit/ ERL_AFLAGS="-config test/conf/app.eunit.config -args_file test/conf/vm.eunit.args -pa $PWD ebin deps/*/ebin -rsh ssh" \ ./rebar skip_deps=true compile eunit --verbose 2014-08-20 17:16 GMT+02:00 marcos quesada : > Hi there! > > Adding more debug to understand what is happening, I've found that > there's somehting wrong from the included path, so that, using make > quicktests (that fires the whole testsuite), executing path: > filename:absname("") equals ~/cluster/.eunit . Executinng > eunit:test(cluster_test) manually the execution path belongs to cluster > app, so that, now its completed succesfully. > > So, now i'm able to pass eunit:test(cluster_test), but if I try to > execute from the whole suite test, it fails (undefined , timeout), at least > the problem seems to belong to some missconfigured path. > > > > > 2014-08-20 16:05 GMT+02:00 marcos quesada : > > Hi there! >> >> Sorry about the delay, summertime.... >> >> I've tests *to append or substitute -pa to -pz*, without any positive >> results, if i've check which paths are loaded, using: code:get_path(). >> there's no difference between pa or pz, as a result,still getting the same >> error: >> >> {value, >> {badrpc, >> {'EXIT', >> * {undef,* >> * [{cluster,join,[...],...},* >> * {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]}* >> >> Anyone coould give me any clue? >> If i'm not worng, this error is answering that join function is undefined >> on cluster module, as you see all those methods are exported, in fact, if >> join wasn't exported * cluster_test:cluster_formation() * will ever fail. >> >> >> -export([start/0, stop/0, join/1, leave/0, status/0, get_ring/0, >> get_timestamp/0]). >> -export([ping/1, get/1, set/2, register/2]). >> >> >> Thank you! >> >> >> >> 2014-08-04 23:51 GMT+02:00 T Ty : >> >> -pa adds to front of the path. -pz to the end of the path. >>> >>> >>> On Mon, Aug 4, 2014 at 4:14 PM, marcos quesada < >>> marcos.quesadas@REDACTED> wrote: >>> >>>> Nop, didn't find it. Maybe i'm missing something, but I think that >>>> slaves nodes are getting right the path to find all required beams. All >>>> slaves are initialized using: >>>> Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", >>>> In fact when I execute cluster_test:cluster_formation() works fine. >>>> >>>> What's the difference to use -pz from -pa? >>>> >>>> Thank you! >>>> >>>> El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie >>>> escribi?: >>>> > marcos quesada wrote: >>>> > >>>> > >>>> > >>>> > mq> **error:{assertEqual_failed, >>>> > >>>> > mq> [{module,cluster_test}, >>>> > >>>> > mq> {line,43}, >>>> > >>>> > mq> {expression,"Result1"}, >>>> > >>>> > mq> {expected,ok}, >>>> > >>>> > mq> {value, >>>> > >>>> > mq> {badrpc, >>>> > >>>> > mq> {'EXIT', >>>> > >>>> > mq> {undef, >>>> > >>>> > mq> [{cluster,join,[...],...}, >>>> > >>>> > mq> >>>> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} >>>> > >>>> > >>>> > >>>> > Have you found the cause of this error? If I had to guess, the slave >>>> > >>>> > node's code_server doesn't know the path to your cluster.beam module. >>>> > >>>> > If that's true, then appending ["-pz", PathToYourModule] to the Args >>>> > >>>> > list of slave:start/3 can correct it. >>>> > >>>> > >>>> > >>>> > -Scott >>>> > >>>> > _______________________________________________ >>>> > >>>> > 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 essen@REDACTED Wed Aug 20 18:08:26 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 20 Aug 2014 19:08:26 +0300 Subject: [erlang-questions] Trouble getting bigwig to run Message-ID: <3h3g1er2v927ra9w20qd7d7t.1408550906995@email.android.com> Note that only the Shaman node requires that. The idea is that Shaman receives data from other nodes which may run their own Erlang version. A bit like how Observer works. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Kristoffer Brown Sent:Wed, 20 Aug 2014 18:38:57 +0300 To:Lo?c Hoguin Cc:Ryan Brown ,Erlang Questions Subject:Re: [erlang-questions] Trouble getting bigwig to run >Lo?c, > > >Thank you. Shaman looks like an excellent start. It appears to depend on R16 which we have not updated to yet. But, I may be able to get in running with a few changes. I will let you know. Thank you! > > >Best > > >-rb > > >? > > > >On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >Bigwig was written against a very old version of Cowboy. It shouldn't be impossible to port but a lot changed since. Cowboy has a changelog file in the repository. > >That said, I had started working on a replacement called Shaman (extend/shaman) that handles multiple nodes and uses D3 for rendering/updates, but I stopped working on it for now because I do not have a production system to use it with (so the values I output may not be interesting). I am going to resume as soon as I find something to develop against. That said, contributions are always welcome. It shouldn't take much more work to add the missing features bigwig had either. > >-- >Lo?c Hoguin >http://ninenines.eu > > > >-------- Original Message -------- >From:Ryan Brown >Sent:Tue, 19 Aug 2014 07:44:44 +0200 >To:Erlang Questions >Subject:Re: [erlang-questions] Trouble getting bigwig to run > >Figured it out. Not that hard with clear eyes really. Bigwig still refers to an older version of cowboy. I could revery back to that compatible version. But, what I would really like is to upgrade my fork to be compatible with the latest.? > > >So, what I am looking for is documentation or changelogs to help me with this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http migration. > > >I'll keep fumbling my way through but any insight from those whom have been through it would be greatly appreciated. > > >Thanks. > > > >On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: > >I am testing-out bigwig for a possible monitoring solution for my application. When I attempt to hook it up to my application I get the following cowboy error. I am having trouble deciphering it. Any help would be greatly appreciated. > > >=INFO REPORT==== 18-Aug-2014::20:23:37 === > >Bigwig listening on http://127.0.0.1:40829/ > > >=CRASH REPORT==== 18-Aug-2014::20:23:37 === > >? crasher: > >? ? initial call: bigwig_http:init/1 > >? ? pid: <0.4861.0> > >? ? registered_name: [] > >? ? exception exit: {undef, > >? ? ? ? ? ? ? ? ? ? ?[{cowboy,start_listener, > >? ? ? ? ? ? ? ? ? ? ? ?[http,16,cowboy_tcp_transport, > >? ? ? ? ? ? ? ? ? ? ? ? [{port,40829}], > >? ? ? ? ? ? ? ? ? ? ? ? cowboy_http_protocol, > >? ? ? ? ? ? ? ? ? ? ? ? [{dispatch, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{'_', > >? ? ? ? ? ? ? ? ? ? ? ? ? ? [{[],bigwig_http_static, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [<<"html">>,<<"index.html">>]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"static">>,'...'],bigwig_http_static,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"vm">>],bigwig_http_vm,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"rb">>,<<"stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigwig_http_rb_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"rb">>,'...'],bigwig_http_rb,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"pid">>,'...'],bigwig_http_pid,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"module">>,'...'],bigwig_http_module,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"top">>,'...'],bigwig_http_etop2,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"appmon">>,'...'],bigwig_http_appmon,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"stats-stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigwig_http_stats_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{'_',bigwig_http_catchall,[]}]}]}]], > >? ? ? ? ? ? ? ? ? ? ? ?[]}, > >? ? ? ? ? ? ? ? ? ? ? {bigwig_http,init,1, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"src/bigwig_http.erl"},{line,54}]}, > >? ? ? ? ? ? ? ? ? ? ? {gen_server,init_it,6, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"gen_server.erl"},{line,304}]}, > >? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"proc_lib.erl"},{line,227}]}]} > >? ? ? in function ?gen_server:init_it/6 (gen_server.erl, line 328) > >? ? ancestors: [bigwig_sup,<0.4853.0>] > >? ? messages: [] > >? ? links: [<0.4854.0>] > >? ? dictionary: [] > >? ? trap_exit: false > >? ? status: running > >? ? heap_size: 610 > >? ? stack_size: 24 > >? ? reductions: 911 > >? neighbours: > > >=SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === > >? ? ?Supervisor: {local,bigwig_sup} > >? ? ?Context: ? ?start_error > >? ? ?Reason: ? ? {undef, > >? ? ? ? ? ? ? ? ? ? ?[{cowboy,start_listener, > >? ? ? ? ? ? ? ? ? ? ? ? ? [http,16,cowboy_tcp_transport, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?[{port,40829}], > >? ? ? ? ? ? ? ? ? ? ? ? ? ?cowboy_http_protocol, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?[{dispatch, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{'_', > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{[],bigwig_http_static, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[<<"html">>,<<"index.html">>]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"static">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_static,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"vm">>],bigwig_http_vm,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"rb">>,<<"stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_rb_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"rb">>,'...'],bigwig_http_rb,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"pid">>,'...'],bigwig_http_pid,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"module">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_module,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"top">>,'...'],bigwig_http_etop2,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"appmon">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_appmon,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"stats-stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_stats_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {'_',bigwig_http_catchall,[]}]}]}]], > >? ? ? ? ? ? ? ? ? ? ? ? ? []}, > >? ? ? ? ? ? ? ? ? ? ? {bigwig_http,init,1, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"src/bigwig_http.erl"},{line,54}]}, > >? ? ? ? ? ? ? ? ? ? ? {gen_server,init_it,6, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"gen_server.erl"},{line,304}]}, > >? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"proc_lib.erl"},{line,227}]}]} > >? ? ?Offender: ? [{pid,undefined}, > >? ? ? ? ? ? ? ? ? {name,bigwig_http}, > >? ? ? ? ? ? ? ? ? {mfargs,{bigwig_http,start_link,[]}}, > >? ? ? ? ? ? ? ? ? {restart_type,permanent}, > >? ? ? ? ? ? ? ? ? {shutdown,5000}, > >? ? ? ? ? ? ? ? ? {child_type,worker}] > > > >=INFO REPORT==== 18-Aug-2014::20:23:37 === > >? ? application: bigwig > >? ? exited: {shutdown,{bigwig_app,start,[normal,[]]}} > >? ? type: temporary > >{error,{shutdown,{bigwig_app,start,[normal,[]]}}} > > >-- >-rb > > > > >-- >-rb > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > >? > > > >On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >Bigwig was written against a very old version of Cowboy. It shouldn't be impossible to port but a lot changed since. Cowboy has a changelog file in the repository. > >That said, I had started working on a replacement called Shaman (extend/shaman) that handles multiple nodes and uses D3 for rendering/updates, but I stopped working on it for now because I do not have a production system to use it with (so the values I output may not be interesting). I am going to resume as soon as I find something to develop against. That said, contributions are always welcome. It shouldn't take much more work to add the missing features bigwig had either. > >-- >Lo?c Hoguin >http://ninenines.eu > > > >-------- Original Message -------- >From:Ryan Brown >Sent:Tue, 19 Aug 2014 07:44:44 +0200 >To:Erlang Questions >Subject:Re: [erlang-questions] Trouble getting bigwig to run > >Figured it out. Not that hard with clear eyes really. Bigwig still refers to an older version of cowboy. I could revery back to that compatible version. But, what I would really like is to upgrade my fork to be compatible with the latest.? > > >So, what I am looking for is documentation or changelogs to help me with this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http migration. > > >I'll keep fumbling my way through but any insight from those whom have been through it would be greatly appreciated. > > >Thanks. > > > >On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: > >I am testing-out bigwig for a possible monitoring solution for my application. When I attempt to hook it up to my application I get the following cowboy error. I am having trouble deciphering it. Any help would be greatly appreciated. > > >=INFO REPORT==== 18-Aug-2014::20:23:37 === > >Bigwig listening on http://127.0.0.1:40829/ > > >=CRASH REPORT==== 18-Aug-2014::20:23:37 === > >? crasher: > >? ? initial call: bigwig_http:init/1 > >? ? pid: <0.4861.0> > >? ? registered_name: [] > >? ? exception exit: {undef, > >? ? ? ? ? ? ? ? ? ? ?[{cowboy,start_listener, > >? ? ? ? ? ? ? ? ? ? ? ?[http,16,cowboy_tcp_transport, > >? ? ? ? ? ? ? ? ? ? ? ? [{port,40829}], > >? ? ? ? ? ? ? ? ? ? ? ? cowboy_http_protocol, > >? ? ? ? ? ? ? ? ? ? ? ? [{dispatch, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{'_', > >? ? ? ? ? ? ? ? ? ? ? ? ? ? [{[],bigwig_http_static, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [<<"html">>,<<"index.html">>]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"static">>,'...'],bigwig_http_static,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"vm">>],bigwig_http_vm,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"rb">>,<<"stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigwig_http_rb_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"rb">>,'...'],bigwig_http_rb,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"pid">>,'...'],bigwig_http_pid,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"module">>,'...'],bigwig_http_module,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"top">>,'...'],bigwig_http_etop2,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"appmon">>,'...'],bigwig_http_appmon,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{[<<"stats-stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigwig_http_stats_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{'_',bigwig_http_catchall,[]}]}]}]], > >? ? ? ? ? ? ? ? ? ? ? ?[]}, > >? ? ? ? ? ? ? ? ? ? ? {bigwig_http,init,1, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"src/bigwig_http.erl"},{line,54}]}, > >? ? ? ? ? ? ? ? ? ? ? {gen_server,init_it,6, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"gen_server.erl"},{line,304}]}, > >? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > >? ? ? ? ? ? ? ? ? ? ? ?[{file,"proc_lib.erl"},{line,227}]}]} > >? ? ? in function ?gen_server:init_it/6 (gen_server.erl, line 328) > >? ? ancestors: [bigwig_sup,<0.4853.0>] > >? ? messages: [] > >? ? links: [<0.4854.0>] > >? ? dictionary: [] > >? ? trap_exit: false > >? ? status: running > >? ? heap_size: 610 > >? ? stack_size: 24 > >? ? reductions: 911 > >? neighbours: > > >=SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === > >? ? ?Supervisor: {local,bigwig_sup} > >? ? ?Context: ? ?start_error > >? ? ?Reason: ? ? {undef, > >? ? ? ? ? ? ? ? ? ? ?[{cowboy,start_listener, > >? ? ? ? ? ? ? ? ? ? ? ? ? [http,16,cowboy_tcp_transport, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?[{port,40829}], > >? ? ? ? ? ? ? ? ? ? ? ? ? ?cowboy_http_protocol, > >? ? ? ? ? ? ? ? ? ? ? ? ? ?[{dispatch, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{'_', > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[{[],bigwig_http_static, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[<<"html">>,<<"index.html">>]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"static">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_static,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"vm">>],bigwig_http_vm,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"rb">>,<<"stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_rb_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"rb">>,'...'],bigwig_http_rb,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"pid">>,'...'],bigwig_http_pid,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"module">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_module,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"top">>,'...'],bigwig_http_etop2,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"appmon">>,'...'], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_appmon,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {[<<"stats-stream">>], > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bigwig_http_stats_stream,[]}, > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {'_',bigwig_http_catchall,[]}]}]}]], > >? ? ? ? ? ? ? ? ? ? ? ? ? []}, > >? ? ? ? ? ? ? ? ? ? ? {bigwig_http,init,1, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"src/bigwig_http.erl"},{line,54}]}, > >? ? ? ? ? ? ? ? ? ? ? {gen_server,init_it,6, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"gen_server.erl"},{line,304}]}, > >? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3, > >? ? ? ? ? ? ? ? ? ? ? ? ? [{file,"proc_lib.erl"},{line,227}]}]} > >? ? ?Offender: ? [{pid,undefined}, > >? ? ? ? ? ? ? ? ? {name,bigwig_http}, > >? ? ? ? ? ? ? ? ? {mfargs,{bigwig_http,start_link,[]}}, > >? ? ? ? ? ? ? ? ? {restart_type,permanent}, > >? ? ? ? ? ? ? ? ? {shutdown,5000}, > >? ? ? ? ? ? ? ? ? {child_type,worker}] > > > >=INFO REPORT==== 18-Aug-2014::20:23:37 === > >? ? application: bigwig > >? ? exited: {shutdown,{bigwig_app,start,[normal,[]]}} > >? ? type: temporary > >{error,{shutdown,{bigwig_app,start,[normal,[]]}}} > > >-- >-rb > > > > >-- >-rb > > >_______________________________________________ >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 Wed Aug 20 18:52:52 2014 From: i.vysniauskas@REDACTED (=?UTF-8?Q?Ignas_Vy=C5=A1niauskas?=) Date: Wed, 20 Aug 2014 19:52:52 +0300 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Hi Marcos, I see you dug up an ancient email I wrote. Spawning slave nodes is notoriously horrible and unfortunately I already forgot how I fixed the issue in question. A shot in the dark: have you tried adding something like this: net_kernel:start(['eunit_test_node@REDACTED', longnames]) before performing `slave:start(..)`? I remember that occasionally the issue was that `net_kernel` was not running. Also make sure you have `epmd` running in the OS. -- Ignas On Wed, Aug 20, 2014 at 7:03 PM, marcos quesada wrote: > Thin i've found something related: "slave:start/3 time out when EUnit > started with ERL_FLAGS" > > http://erlang.org/pipermail/erlang-questions/2011-September/061010.html > > > Makefile is: > > start: *(it works)* > @$(ERL) -config test/conf/app.eunit.config -args_file > test/conf/vm.eunit.args \ > -pa $PWD ebin deps/*/ebin -rsh ssh -boot start_sasl -s cluster > > quicktests: *(it fails)* > rm -rf .eunit/ > ERL_AFLAGS="-config test/conf/app.eunit.config -args_file > test/conf/vm.eunit.args -pa $PWD ebin deps/*/ebin -rsh ssh" \ > ./rebar skip_deps=true compile eunit --verbose > > > 2014-08-20 17:16 GMT+02:00 marcos quesada : > > Hi there! >> >> Adding more debug to understand what is happening, I've found that >> there's somehting wrong from the included path, so that, using make >> quicktests (that fires the whole testsuite), executing path: >> filename:absname("") equals ~/cluster/.eunit . Executinng >> eunit:test(cluster_test) manually the execution path belongs to cluster >> app, so that, now its completed succesfully. >> >> So, now i'm able to pass eunit:test(cluster_test), but if I try to >> execute from the whole suite test, it fails (undefined , timeout), at least >> the problem seems to belong to some missconfigured path. >> >> >> >> >> 2014-08-20 16:05 GMT+02:00 marcos quesada : >> >> Hi there! >>> >>> Sorry about the delay, summertime.... >>> >>> I've tests *to append or substitute -pa to -pz*, without any positive >>> results, if i've check which paths are loaded, using: code:get_path(). >>> there's no difference between pa or pz, as a result,still getting the same >>> error: >>> >>> {value, >>> {badrpc, >>> {'EXIT', >>> * {undef,* >>> * [{cluster,join,[...],...},* >>> * {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]}* >>> >>> Anyone coould give me any clue? >>> If i'm not worng, this error is answering that join function is >>> undefined on cluster module, as you see all those methods are exported, in >>> fact, if join wasn't exported * cluster_test:cluster_formation() * will >>> ever fail. >>> >>> >>> -export([start/0, stop/0, join/1, leave/0, status/0, get_ring/0, >>> get_timestamp/0]). >>> -export([ping/1, get/1, set/2, register/2]). >>> >>> >>> Thank you! >>> >>> >>> >>> 2014-08-04 23:51 GMT+02:00 T Ty : >>> >>> -pa adds to front of the path. -pz to the end of the path. >>>> >>>> >>>> On Mon, Aug 4, 2014 at 4:14 PM, marcos quesada < >>>> marcos.quesadas@REDACTED> wrote: >>>> >>>>> Nop, didn't find it. Maybe i'm missing something, but I think that >>>>> slaves nodes are getting right the path to find all required beams. All >>>>> slaves are initialized using: >>>>> Args = " -pa apps/*/ebin deps/*/ebin -setcookie secret -rsh ssh", >>>>> In fact when I execute cluster_test:cluster_formation() works fine. >>>>> >>>>> What's the difference to use -pz from -pa? >>>>> >>>>> Thank you! >>>>> >>>>> El lunes, 4 de agosto de 2014 03:01:06 UTC+2, Scott Lystig Fritchie >>>>> escribi?: >>>>> > marcos quesada wrote: >>>>> > >>>>> > >>>>> > >>>>> > mq> **error:{assertEqual_failed, >>>>> > >>>>> > mq> [{module,cluster_test}, >>>>> > >>>>> > mq> {line,43}, >>>>> > >>>>> > mq> {expression,"Result1"}, >>>>> > >>>>> > mq> {expected,ok}, >>>>> > >>>>> > mq> {value, >>>>> > >>>>> > mq> {badrpc, >>>>> > >>>>> > mq> {'EXIT', >>>>> > >>>>> > mq> {undef, >>>>> > >>>>> > mq> [{cluster,join,[...],...}, >>>>> > >>>>> > mq> >>>>> {rpc,'-handle_call_call/6-fun-0-',...}]}}}}]} >>>>> > >>>>> > >>>>> > >>>>> > Have you found the cause of this error? If I had to guess, the slave >>>>> > >>>>> > node's code_server doesn't know the path to your cluster.beam module. >>>>> > >>>>> > If that's true, then appending ["-pz", PathToYourModule] to the Args >>>>> > >>>>> > list of slave:start/3 can correct it. >>>>> > >>>>> > >>>>> > >>>>> > -Scott >>>>> > >>>>> > _______________________________________________ >>>>> > >>>>> > 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 baliulia@REDACTED Wed Aug 20 18:53:37 2014 From: baliulia@REDACTED (=?UTF-8?Q?Ignas_Vy=C5=A1niauskas?=) Date: Wed, 20 Aug 2014 19:53:37 +0300 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Hi Marcos, I see you dug up an ancient email I wrote. Spawning slave nodes is notoriously horrible and unfortunately I already forgot how I fixed the issue in question. A shot in the dark: have you tried adding something like this: net_kernel:start(['eunit_test_node@REDACTED', longnames]) before performing `slave:start(..)`? I remember that occasionally the issue was that `net_kernel` was not running. Also make sure you have `epmd` running in the OS. -- Ignas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Wed Aug 20 19:41:37 2014 From: tony@REDACTED (Tony Rogvall) Date: Wed, 20 Aug 2014 19:41:37 +0200 Subject: [erlang-questions] divrem eep? Message-ID: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Hi list. I have been playing with a new BIF called divrem today. Calling erlang:divrem(A,B) has the the same result as calling {A div B, A rem B}. (possibly with some strange exceptional cases that remain to be found :-) Since the bignum div operation has always calculated the remainder as a "waste product" I thought it was about time to pick it up and make use if it. The speedup when comparing calculation of {Q,R} = erlang:divrem(A,B) and Q=A div B, R=A rem B, is about 70-80% already around 60 bit arguments (64bit platform) (max speedup is of course 100%), currently the downside is that divrem for small numbers are a bit slower, since a tuple {Q,R} is constructed and the emulator have instructions for div and rem. The above could probably be handle by regarding divrem as a builtin function with a multiple return value and have the compiler to generate an instruction for some instances of divrem. I remember some work for handling multiple return values? What about it ? eep? /Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Wed Aug 20 20:04:28 2014 From: wallentin.dahlberg@REDACTED (=?UTF-8?Q?Bj=C3=B6rn=2DEgil_Dahlberg?=) Date: Wed, 20 Aug 2014 20:04:28 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Message-ID: It should probably be an instruction instead. The compiler should recognize if div and rem is used and combine them to one instruction. You have no issue with multiple return values if you do it in core for instance. I did some doodling with this on my previous summer vacation .. along with sub-expr-elim .. I stopped after the doodling phase =) No eep necessary if you do it as an optimization pass, only light-eep. // Bj?rn-Egil 2014-08-20 19:41 GMT+02:00 Tony Rogvall : > Hi list. > > I have been playing with a new BIF called divrem today. Calling > erlang:divrem(A,B) has the the same result > as calling {A div B, A rem B}. (possibly with some strange exceptional > cases that remain to be found :-) > > Since the bignum div operation has always calculated the remainder as a > "waste product" I thought it was > about time to pick it up and make use if it. > > The speedup when comparing calculation of {Q,R} = erlang:divrem(A,B) and > Q=A div B, R=A rem B, > is about 70-80% already around 60 bit arguments (64bit platform) (max > speedup is of course 100%), > currently the downside is that divrem for small numbers are a bit slower, > since a tuple {Q,R} is constructed > and the emulator have instructions for div and rem. > > The above could probably be handle by regarding divrem as a builtin > function with a multiple return value > and have the compiler to generate an instruction for some instances of > divrem. > > I remember some work for handling multiple return values? > > What about it ? eep? > > /Tony > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.quesadas@REDACTED Wed Aug 20 20:49:06 2014 From: marcos.quesadas@REDACTED (marcos quesada) Date: Wed, 20 Aug 2014 20:49:06 +0200 Subject: [erlang-questions] Cluster Functional test using Slave Nodes In-Reply-To: References: <96561.1407114044@snookles.snookles.com> Message-ID: Thanks Ignas! I've tried what you suggest, but unfortunately the result still the same: - executing eunit:test('cluster_test') from a started node results in success - executed cluster_test from the test suite: module 'cluster_test' cluster_test: cluster_formation_suite_test_...*timed out* undefined What is driving me nuts is the reason about this different behavior, from start manually the node and execute the test, and in the other hand eunit test execution environment. Both execution ways are using the same vm.args and sys.config. 2014-08-20 18:53 GMT+02:00 Ignas Vy?niauskas : > Hi Marcos, > > I see you dug up an ancient email I wrote. Spawning slave nodes is > notoriously horrible and unfortunately I already forgot how I fixed the > issue in question. > > A shot in the dark: have you tried adding something like this: > > net_kernel:start(['eunit_test_node@REDACTED', longnames]) > > before performing `slave:start(..)`? I remember that occasionally the > issue was that `net_kernel` was not running. Also make sure you have `epmd` > running in the OS. > > -- > Ignas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryankbrown@REDACTED Thu Aug 21 03:19:20 2014 From: ryankbrown@REDACTED (Ryan Brown) Date: Wed, 20 Aug 2014 19:19:20 -0600 Subject: [erlang-questions] Trouble getting bigwig to run In-Reply-To: <3h3g1er2v927ra9w20qd7d7t.1408550906995@email.android.com> References: <3h3g1er2v927ra9w20qd7d7t.1408550906995@email.android.com> Message-ID: Forgive my ignorance. I thought I needed to run shaman on any node I wanted to monitor? Do I need to hook alien into my node? Best. On Wed, Aug 20, 2014 at 10:08 AM, Lo?c Hoguin wrote: > Note that only the Shaman node requires that. The idea is that Shaman > receives data from other nodes which may run their own Erlang version. A > bit like how Observer works. > > > -- > Lo?c Hoguin > http://ninenines.eu > > > > -------- Original Message -------- > From:Kristoffer Brown > Sent:Wed, 20 Aug 2014 18:38:57 +0300 > To:Lo?c Hoguin > Cc:Ryan Brown ,Erlang Questions < > erlang-questions@REDACTED> > Subject:Re: [erlang-questions] Trouble getting bigwig to run > > Lo?c, > > Thank you. Shaman looks like an excellent start. It appears to depend on > R16 which we have not updated to yet. But, I may be able to get in running > with a few changes. I will let you know. Thank you! > > Best > > -rb > > > > > On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >> Bigwig was written against a very old version of Cowboy. It shouldn't be >> impossible to port but a lot changed since. Cowboy has a changelog file in >> the repository. >> >> That said, I had started working on a replacement called Shaman >> (extend/shaman) that handles multiple nodes and uses D3 for >> rendering/updates, but I stopped working on it for now because I do not >> have a production system to use it with (so the values I output may not be >> interesting). I am going to resume as soon as I find something to develop >> against. That said, contributions are always welcome. It shouldn't take >> much more work to add the missing features bigwig had either. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> >> >> -------- Original Message -------- >> From:Ryan Brown >> Sent:Tue, 19 Aug 2014 07:44:44 +0200 >> To:Erlang Questions >> Subject:Re: [erlang-questions] Trouble getting bigwig to run >> >> Figured it out. Not that hard with clear eyes really. Bigwig still refers >> to an older version of cowboy. I could revery back to that compatible >> version. But, what I would really like is to upgrade my fork to be >> compatible with the latest. >> >> So, what I am looking for is documentation or changelogs to help me with >> this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http >> migration. >> >> I'll keep fumbling my way through but any insight from those whom have >> been through it would be greatly appreciated. >> >> Thanks. >> >> >> On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: >> >>> I am testing-out bigwig for a possible monitoring solution for my >>> application. When I attempt to hook it up to my application I get the >>> following cowboy error. I am having trouble deciphering it. Any help would >>> be greatly appreciated. >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> Bigwig listening on http://127.0.0.1:40829/ >>> >>> >>> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >>> crasher: >>> initial call: bigwig_http:init/1 >>> pid: <0.4861.0> >>> registered_name: [] >>> exception exit: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> >>> {[<<"static">>,'...'],bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> >>> {[<<"module">>,'...'],bigwig_http_module,[]}, >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> >>> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> in function gen_server:init_it/6 (gen_server.erl, line 328) >>> ancestors: [bigwig_sup,<0.4853.0>] >>> messages: [] >>> links: [<0.4854.0>] >>> dictionary: [] >>> trap_exit: false >>> status: running >>> heap_size: 610 >>> stack_size: 24 >>> reductions: 911 >>> neighbours: >>> >>> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >>> Supervisor: {local,bigwig_sup} >>> Context: start_error >>> Reason: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> {[<<"static">>,'...'], >>> bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> {[<<"module">>,'...'], >>> bigwig_http_module,[]}, >>> >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> {[<<"appmon">>,'...'], >>> bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> Offender: [{pid,undefined}, >>> {name,bigwig_http}, >>> {mfargs,{bigwig_http,start_link,[]}}, >>> {restart_type,permanent}, >>> {shutdown,5000}, >>> {child_type,worker}] >>> >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> application: bigwig >>> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >>> type: temporary >>> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >>> >>> -- >>> -rb >>> >> >> >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > > On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >> Bigwig was written against a very old version of Cowboy. It shouldn't be >> impossible to port but a lot changed since. Cowboy has a changelog file in >> the repository. >> >> That said, I had started working on a replacement called Shaman >> (extend/shaman) that handles multiple nodes and uses D3 for >> rendering/updates, but I stopped working on it for now because I do not >> have a production system to use it with (so the values I output may not be >> interesting). I am going to resume as soon as I find something to develop >> against. That said, contributions are always welcome. It shouldn't take >> much more work to add the missing features bigwig had either. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> >> >> -------- Original Message -------- >> From:Ryan Brown >> Sent:Tue, 19 Aug 2014 07:44:44 +0200 >> To:Erlang Questions >> Subject:Re: [erlang-questions] Trouble getting bigwig to run >> >> Figured it out. Not that hard with clear eyes really. Bigwig still refers >> to an older version of cowboy. I could revery back to that compatible >> version. But, what I would really like is to upgrade my fork to be >> compatible with the latest. >> >> So, what I am looking for is documentation or changelogs to help me with >> this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http >> migration. >> >> I'll keep fumbling my way through but any insight from those whom have >> been through it would be greatly appreciated. >> >> Thanks. >> >> >> On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: >> >>> I am testing-out bigwig for a possible monitoring solution for my >>> application. When I attempt to hook it up to my application I get the >>> following cowboy error. I am having trouble deciphering it. Any help would >>> be greatly appreciated. >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> Bigwig listening on http://127.0.0.1:40829/ >>> >>> >>> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >>> crasher: >>> initial call: bigwig_http:init/1 >>> pid: <0.4861.0> >>> registered_name: [] >>> exception exit: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> >>> {[<<"static">>,'...'],bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> >>> {[<<"module">>,'...'],bigwig_http_module,[]}, >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> >>> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> in function gen_server:init_it/6 (gen_server.erl, line 328) >>> ancestors: [bigwig_sup,<0.4853.0>] >>> messages: [] >>> links: [<0.4854.0>] >>> dictionary: [] >>> trap_exit: false >>> status: running >>> heap_size: 610 >>> stack_size: 24 >>> reductions: 911 >>> neighbours: >>> >>> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >>> Supervisor: {local,bigwig_sup} >>> Context: start_error >>> Reason: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> {[<<"static">>,'...'], >>> bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> {[<<"module">>,'...'], >>> bigwig_http_module,[]}, >>> >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> {[<<"appmon">>,'...'], >>> bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> Offender: [{pid,undefined}, >>> {name,bigwig_http}, >>> {mfargs,{bigwig_http,start_link,[]}}, >>> {restart_type,permanent}, >>> {shutdown,5000}, >>> {child_type,worker}] >>> >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> application: bigwig >>> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >>> type: temporary >>> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >>> >>> -- >>> -rb >>> >> >> >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > -- -rb On Wed, Aug 20, 2014 at 10:08 AM, Lo?c Hoguin wrote: > Note that only the Shaman node requires that. The idea is that Shaman > receives data from other nodes which may run their own Erlang version. A > bit like how Observer works. > > > -- > Lo?c Hoguin > http://ninenines.eu > > > -------- Original Message -------- > From:Kristoffer Brown > Sent:Wed, 20 Aug 2014 18:38:57 +0300 > To:Lo?c Hoguin > Cc:Ryan Brown ,Erlang Questions < > erlang-questions@REDACTED> > Subject:Re: [erlang-questions] Trouble getting bigwig to run > > Lo?c, > > Thank you. Shaman looks like an excellent start. It appears to depend on > R16 which we have not updated to yet. But, I may be able to get in running > with a few changes. I will let you know. Thank you! > > Best > > -rb > > > > > On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >> Bigwig was written against a very old version of Cowboy. It shouldn't be >> impossible to port but a lot changed since. Cowboy has a changelog file in >> the repository. >> >> That said, I had started working on a replacement called Shaman >> (extend/shaman) that handles multiple nodes and uses D3 for >> rendering/updates, but I stopped working on it for now because I do not >> have a production system to use it with (so the values I output may not be >> interesting). I am going to resume as soon as I find something to develop >> against. That said, contributions are always welcome. It shouldn't take >> much more work to add the missing features bigwig had either. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> >> >> -------- Original Message -------- >> From:Ryan Brown >> Sent:Tue, 19 Aug 2014 07:44:44 +0200 >> To:Erlang Questions >> Subject:Re: [erlang-questions] Trouble getting bigwig to run >> >> Figured it out. Not that hard with clear eyes really. Bigwig still refers >> to an older version of cowboy. I could revery back to that compatible >> version. But, what I would really like is to upgrade my fork to be >> compatible with the latest. >> >> So, what I am looking for is documentation or changelogs to help me with >> this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http >> migration. >> >> I'll keep fumbling my way through but any insight from those whom have >> been through it would be greatly appreciated. >> >> Thanks. >> >> >> On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: >> >>> I am testing-out bigwig for a possible monitoring solution for my >>> application. When I attempt to hook it up to my application I get the >>> following cowboy error. I am having trouble deciphering it. Any help would >>> be greatly appreciated. >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> Bigwig listening on http://127.0.0.1:40829/ >>> >>> >>> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >>> crasher: >>> initial call: bigwig_http:init/1 >>> pid: <0.4861.0> >>> registered_name: [] >>> exception exit: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> >>> {[<<"static">>,'...'],bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> >>> {[<<"module">>,'...'],bigwig_http_module,[]}, >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> >>> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> in function gen_server:init_it/6 (gen_server.erl, line 328) >>> ancestors: [bigwig_sup,<0.4853.0>] >>> messages: [] >>> links: [<0.4854.0>] >>> dictionary: [] >>> trap_exit: false >>> status: running >>> heap_size: 610 >>> stack_size: 24 >>> reductions: 911 >>> neighbours: >>> >>> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >>> Supervisor: {local,bigwig_sup} >>> Context: start_error >>> Reason: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> {[<<"static">>,'...'], >>> bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> {[<<"module">>,'...'], >>> bigwig_http_module,[]}, >>> >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> {[<<"appmon">>,'...'], >>> bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> Offender: [{pid,undefined}, >>> {name,bigwig_http}, >>> {mfargs,{bigwig_http,start_link,[]}}, >>> {restart_type,permanent}, >>> {shutdown,5000}, >>> {child_type,worker}] >>> >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> application: bigwig >>> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >>> type: temporary >>> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >>> >>> -- >>> -rb >>> >> >> >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > > On Tue, Aug 19, 2014 at 3:27 AM, Lo?c Hoguin wrote: > >> Bigwig was written against a very old version of Cowboy. It shouldn't be >> impossible to port but a lot changed since. Cowboy has a changelog file in >> the repository. >> >> That said, I had started working on a replacement called Shaman >> (extend/shaman) that handles multiple nodes and uses D3 for >> rendering/updates, but I stopped working on it for now because I do not >> have a production system to use it with (so the values I output may not be >> interesting). I am going to resume as soon as I find something to develop >> against. That said, contributions are always welcome. It shouldn't take >> much more work to add the missing features bigwig had either. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> >> -------- Original Message -------- >> From:Ryan Brown >> Sent:Tue, 19 Aug 2014 07:44:44 +0200 >> To:Erlang Questions >> Subject:Re: [erlang-questions] Trouble getting bigwig to run >> >> Figured it out. Not that hard with clear eyes really. Bigwig still refers >> to an older version of cowboy. I could revery back to that compatible >> version. But, what I would really like is to upgrade my fork to be >> compatible with the latest. >> >> So, what I am looking for is documentation or changelogs to help me with >> this upgrade. like the cowboy:start_listener/6 -> cowboy:start_http >> migration. >> >> I'll keep fumbling my way through but any insight from those whom have >> been through it would be greatly appreciated. >> >> Thanks. >> >> >> On Mon, Aug 18, 2014 at 8:31 PM, Ryan Brown wrote: >> >>> I am testing-out bigwig for a possible monitoring solution for my >>> application. When I attempt to hook it up to my application I get the >>> following cowboy error. I am having trouble deciphering it. Any help would >>> be greatly appreciated. >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> Bigwig listening on http://127.0.0.1:40829/ >>> >>> =CRASH REPORT==== 18-Aug-2014::20:23:37 === >>> crasher: >>> initial call: bigwig_http:init/1 >>> pid: <0.4861.0> >>> registered_name: [] >>> exception exit: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> >>> {[<<"static">>,'...'],bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> >>> {[<<"module">>,'...'],bigwig_http_module,[]}, >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> >>> {[<<"appmon">>,'...'],bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> in function gen_server:init_it/6 (gen_server.erl, line 328) >>> ancestors: [bigwig_sup,<0.4853.0>] >>> messages: [] >>> links: [<0.4854.0>] >>> dictionary: [] >>> trap_exit: false >>> status: running >>> heap_size: 610 >>> stack_size: 24 >>> reductions: 911 >>> neighbours: >>> >>> =SUPERVISOR REPORT==== 18-Aug-2014::20:23:37 === >>> Supervisor: {local,bigwig_sup} >>> Context: start_error >>> Reason: {undef, >>> [{cowboy,start_listener, >>> [http,16,cowboy_tcp_transport, >>> [{port,40829}], >>> cowboy_http_protocol, >>> [{dispatch, >>> [{'_', >>> [{[],bigwig_http_static, >>> [<<"html">>,<<"index.html">>]}, >>> {[<<"static">>,'...'], >>> bigwig_http_static,[]}, >>> {[<<"vm">>],bigwig_http_vm,[]}, >>> {[<<"rb">>,<<"stream">>], >>> bigwig_http_rb_stream,[]}, >>> >>> {[<<"rb">>,'...'],bigwig_http_rb,[]}, >>> >>> {[<<"pid">>,'...'],bigwig_http_pid,[]}, >>> {[<<"module">>,'...'], >>> bigwig_http_module,[]}, >>> >>> {[<<"top">>,'...'],bigwig_http_etop2,[]}, >>> {[<<"appmon">>,'...'], >>> bigwig_http_appmon,[]}, >>> {[<<"stats-stream">>], >>> bigwig_http_stats_stream,[]}, >>> >>> {'_',bigwig_http_catchall,[]}]}]}]], >>> []}, >>> {bigwig_http,init,1, >>> [{file,"src/bigwig_http.erl"},{line,54}]}, >>> {gen_server,init_it,6, >>> [{file,"gen_server.erl"},{line,304}]}, >>> {proc_lib,init_p_do_apply,3, >>> [{file,"proc_lib.erl"},{line,227}]}]} >>> Offender: [{pid,undefined}, >>> {name,bigwig_http}, >>> {mfargs,{bigwig_http,start_link,[]}}, >>> {restart_type,permanent}, >>> {shutdown,5000}, >>> {child_type,worker}] >>> >>> >>> =INFO REPORT==== 18-Aug-2014::20:23:37 === >>> application: bigwig >>> exited: {shutdown,{bigwig_app,start,[normal,[]]}} >>> type: temporary >>> {error,{shutdown,{bigwig_app,start,[normal,[]]}}} >>> >>> -- >>> -rb >>> >> >> >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Aug 21 05:21:50 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 21 Aug 2014 15:21:50 +1200 Subject: [erlang-questions] In praise of Erlang's 'if' Message-ID: <6A40C846-66B1-4838-9804-049306D23B75@cs.otago.ac.nz> Erlang's 'if' is often criticised, so I thought it would be nice to show an example where it's just right. In connection with the recent thread on Potion, I've been re-reading Visual Programming Languages and the Empirical Evidence For and Against K.N.Whitley, October 1996, submitted to the Journal of Visual Languages and Computing. Amongst other evidence for visual programming languages, this paper cites Scanlan's "Structured flowcharts outperform pseudocode: An experimental comparison", IEEE Software, June 1989. Scanlan's article is, it seems to me, a classic case of claiming too much. The title suggests, and the text clearly states, that 'structured flowcharts' are superior to 'pseudocode', where what was established was that one particular form of flowchart was superior to one particular form of pseudocode. Here's one of the pseudo-code examples: IF GREEN THEN IF CRISPY THEN STEAM ELSE CHOP ENDIF ELSE FRY IF LEAFY THEN IF HARD THEN GRILL ELSE BOIL ENDIF ELSE BAKE ENDIF ENDIF The weird layout is none of my invention. Now, suppose we used Erlang as the pseudocode: if Green, Crispy -> steam() ; Green, not Crispy -> chop() ; not Green, Leafy, Hard -> fry(), grill() ; not Green, Leafy, not Hard -> fry(), boil() ; not Green, not Leafy -> fry(), bake() end How do you think the comparison would have come out then? There is an old experiment that showed that if X ... ifnot X ... end was easier to understand than if X ... else ... end, and oddly enough the 'hungry hare' examples in Scanlan appear to have been taken from it, without learning its lesson. It is at least possible that Scanlan's results were entirely due to this factor, not the 'visual' aspect per se.) The irony is that an Erlang 'if', laid out the way I've laid it out, would in Whitley's paper have been classified as a 'visual' notation (subclass 'matrix'). We could also do it as a 'case': case {Green, Crispy, Leafy, Hard } of {true, true, _, _ } -> steam() ; {true, false, _, _ } -> chop() ; {false, _, true, true } -> fry(), grill() ; {false, _, true, false} -> fry(), boil() ; {false, _, false, _ } -> fry(), bake() end but in this case I think 'if' is easier to read. You might want to object that Scanlan could not have been expected to think of this kind of layout in 1986, but this is just a 'decision table', and decision tables are much older than that and were well known in the 70s. What this illustrates above all is that proving that some particular language or language feature is better or worse than some other can be much harder than you think, and that even classic results in the field can collapse under a little inspection. From kukhyun@REDACTED Thu Aug 21 05:28:06 2014 From: kukhyun@REDACTED (KukHyun Lee) Date: Thu, 21 Aug 2014 12:28:06 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140820160135.GA10399@debian> References: <20140819125903.GA4902@debian> <53F4B0BF.5060309@erix.ericsson.se> <20140820160135.GA10399@debian> Message-ID: Hi, I think it's Ethernet Card's performance problem, not erlang vm. What kind of Ethernet card used? loopback and real interface are different. Very high spec ethernet card is required for the 1000k packets per second. 2014-08-21 1:01 GMT+09:00 Jihyun Yu : > First, I assume that elang VM itself is scalable because there is no > problem when I ran benchmark on single Erlang instance. During > benchmark, Erlang instance couldn't saturate CPU while it had enough > number of threads and erlang processes. Bandwidth also couldn't be a > problem because the result can be reproducible on single machine with > loopback interface, which is not a bottleneck at least on ~100Mbps > throughput. > > So I thought that lock is a problem. I profiled erlang VM with > systemtap, collect userspace stacktraces when lock collides. It showed > two frequently colliding locks: one is from schedular_wait(), another > one is from erts_dsig_send_msg(). schedular_wait() couldn't be a problem > because benchmark works as expected without inter-node communication. > > > Here's example stacktrace I got during experiment. > > __lll_lock_wait+0x1d/0x30 [/usr/lib64/libpthread-2.17.so] > _L_lock_790+0xf/0x1b [/usr/lib64/libpthread-2.17.so] > __pthread_mutex_lock+0x37/0x122 [/usr/lib64/libpthread-2.17.so] > erts_dsig_send_msg+0x3c5/0x640 [erts-6.1/bin/beam.smp] > remote_send+0xc7/0x220 [erts-6.1/bin/beam.smp] > erl_send+0x581/0xa60 [erts-6.1/bin/beam.smp] > process_main+0x80f2/0xba80 [erts-6.1/bin/beam.smp] > sched_thread_func+0xe2/0x1d0 [erts-6.1/bin/beam.smp] > thr_wrapper+0x65/0xb0 [erts-6.1/bin/beam.smp] > start_thread+0xc3/0x310 [/usr/lib64/libpthread-2.17.so] > clone+0x6d/0x90 [/usr/lib64/libc-2.17.so] > > > The experiment is done on 2-cpu 12-core HP machine with CentOS 7. > I attached systemtap script and a result. > > > On Wed, Aug 20, 2014 at 04:29:19PM +0200, Sverker Eriksson wrote: >> On 08/19/2014 02:59 PM, Jihyun Yu wrote: >> >Hi, >> > >> >There is a prior discusson[1] about inter-node communication bottleneck, >> >and I experienced same issue on inter-node messaging. I dig into the >> >issue and it found that there is a lock on inter-node messaging[2] which >> >causes bottleneck on sending messages to single node. >> >> How did you draw conclusion about the distribution lock queue being a >> bottleneck? >> Did you use the lock counting[1], and if so what was the profiling stats? >> >> >> /Sverker, Erlang/OTP >> >> >> [1] http://www.erlang.org/doc/apps/tools/lcnt_chapter.html >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From yjh0502@REDACTED Thu Aug 21 06:05:02 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Thu, 21 Aug 2014 13:05:02 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: References: <20140819125903.GA4902@debian> <53F4B0BF.5060309@erix.ericsson.se> <20140820160135.GA10399@debian> Message-ID: <20140821040502.GA10732@debian> The problem is reproducable *with loopback interface*. I tested with two Erlang instances on same machine, communicating via loopback interface, and results are same. I changed contented lock - qlock in DistEntry - to spinlock, but it does not affact on throughput(messages per second). 'perf' profiling tool [1] shows that CPU cycle is moved from kernel to userspace. I attach patch and 10-seconds sampling result on mutex and spinlock. [1] https://perf.wiki.kernel.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: spinlock.patch Type: text/x-diff Size: 9161 bytes Desc: not available URL: -------------- next part -------------- # Event count (approx.): 92786792854 # # Overhead Command Shared Object Symbol # ........ ............... ..................... ............................................... # 24.69% beam.smp beam.smp [.] erts_dsig_send_msg 5.97% beam.smp beam.smp [.] scheduler_wait 2.05% beam.smp [ip_tables] [k] ipt_do_table 1.74% beam.smp [kernel.kallsyms] [k] nf_iterate 1.14% beam.smp [nf_conntrack] [k] ____nf_conntrack_find 1.11% swapper [kernel.kallsyms] [k] intel_idle 0.96% beam.smp [nf_conntrack] [k] tcp_packet 0.95% beam.smp [kernel.kallsyms] [k] tcp_recvmsg 0.93% beam.smp [kernel.kallsyms] [k] _raw_read_lock_bh 0.89% beam.smp [kernel.kallsyms] [k] _raw_spin_lock 0.85% beam.smp [kernel.kallsyms] [k] _raw_spin_lock_bh 0.81% beam.smp beam.smp [.] process_main 0.80% beam.smp [kernel.kallsyms] [k] tcp_ack 0.73% beam.smp [kernel.kallsyms] [k] default_send_IPI_mask_sequence_phys 0.69% beam.smp beam.smp [.] schedule 0.67% beam.smp [kernel.kallsyms] [k] tcp_transmit_skb 0.67% beam.smp [kernel.kallsyms] [k] __netif_receive_skb_core 0.65% beam.smp [kernel.kallsyms] [k] system_call 0.64% beam.smp [nf_conntrack] [k] tcp_in_window 0.59% beam.smp [kernel.kallsyms] [k] __inet_lookup_established 0.58% beam.smp [nf_conntrack] [k] nf_conntrack_in 0.57% beam.smp [kernel.kallsyms] [k] tcp_v4_rcv 0.57% beam.smp [kernel.kallsyms] [k] release_sock 0.56% beam.smp [kernel.kallsyms] [k] skb_release_data 0.55% beam.smp [kernel.kallsyms] [k] tcp_sendmsg 0.53% beam.smp [kernel.kallsyms] [k] local_bh_enable 0.51% beam.smp [kernel.kallsyms] [k] fget_light 0.48% beam.smp [bridge] [k] br_fdb_update 0.48% beam.smp [kernel.kallsyms] [k] put_prev_task_fair 0.48% beam.smp [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.47% beam.smp [kernel.kallsyms] [k] __alloc_skb 0.47% beam.smp [ebtables] [k] ebt_do_table 0.45% beam.smp [kernel.kallsyms] [k] __audit_syscall_exit 0.43% beam.smp [kernel.kallsyms] [k] tcp_rcv_established 0.43% beam.smp [kernel.kallsyms] [k] __ip_local_out 0.42% beam.smp [bridge] [k] br_handle_frame 0.41% beam.smp [nf_conntrack] [k] __nf_ct_refresh_acct 0.41% beam.smp [kernel.kallsyms] [k] net_rx_action 0.40% beam.smp [kernel.kallsyms] [k] copy_user_generic_string 0.39% beam.smp [iptable_nat] [k] nf_nat_ipv4_fn 0.39% beam.smp [kernel.kallsyms] [k] local_bh_enable_ip 0.39% beam.smp beam.smp [.] erts_thr_progress_leader_update 0.37% beam.smp [kernel.kallsyms] [k] ipv4_dst_check 0.37% beam.smp [kernel.kallsyms] [k] ip_finish_output -------------- next part -------------- # Event count (approx.): 85477634040 # # Overhead Command Shared Object Symbol # ........ ............... ..................... ............................................... # 14.05% beam.smp [kernel.kallsyms] [k] _raw_spin_lock 6.53% beam.smp beam.smp [.] scheduler_wait 2.58% beam.smp [ip_tables] [k] ipt_do_table 2.03% beam.smp [kernel.kallsyms] [k] nf_iterate 1.32% swapper [kernel.kallsyms] [k] intel_idle 1.07% beam.smp beam.smp [.] process_main 1.04% beam.smp [kernel.kallsyms] [k] default_send_IPI_mask_sequence_phys 0.89% beam.smp [kernel.kallsyms] [k] system_call 0.89% beam.smp [kernel.kallsyms] [k] _raw_spin_lock_bh 0.87% beam.smp [kernel.kallsyms] [k] __netif_receive_skb_core 0.77% beam.smp beam.smp [.] schedule 0.77% beam.smp [nf_conntrack] [k] ____nf_conntrack_find 0.74% beam.smp [kernel.kallsyms] [k] _raw_read_lock_bh 0.72% beam.smp [nf_conntrack] [k] tcp_packet 0.69% beam.smp [nf_conntrack] [k] tcp_in_window 0.67% beam.smp libpthread-2.17.so [.] pthread_mutex_unlock 0.66% beam.smp [ebtables] [k] ebt_do_table 0.65% beam.smp [kernel.kallsyms] [k] tcp_transmit_skb 0.65% beam.smp libpthread-2.17.so [.] pthread_mutex_lock 0.64% beam.smp [kernel.kallsyms] [k] tcp_recvmsg 0.60% beam.smp [kernel.kallsyms] [k] __audit_syscall_exit 0.59% beam.smp [kernel.kallsyms] [k] local_bh_enable 0.58% beam.smp [nf_conntrack] [k] nf_conntrack_in 0.57% beam.smp [kernel.kallsyms] [k] tcp_ack 0.56% beam.smp [kernel.kallsyms] [k] put_prev_task_fair 0.56% beam.smp beam.smp [.] erts_thr_progress_leader_update 0.54% beam.smp [kernel.kallsyms] [k] net_rx_action 0.54% beam.smp [kernel.kallsyms] [k] futex_wait_setup 0.53% beam.smp [kernel.kallsyms] [k] tcp_sendmsg 0.51% beam.smp [kernel.kallsyms] [k] tcp_v4_rcv 0.49% beam.smp [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.49% beam.smp [kernel.kallsyms] [k] copy_user_generic_string 0.49% beam.smp [kernel.kallsyms] [k] fget_light 0.48% beam.smp [kernel.kallsyms] [k] __do_softirq 0.48% beam.smp [kernel.kallsyms] [k] local_bh_enable_ip 0.47% beam.smp [bridge] [k] br_handle_frame 0.46% beam.smp [kernel.kallsyms] [k] __inet_lookup_established 0.44% beam.smp [kernel.kallsyms] [k] __schedule 0.43% beam.smp [kernel.kallsyms] [k] ip_rcv 0.42% beam.smp [kernel.kallsyms] [k] ip_finish_output 0.42% beam.smp beam.smp [.] erts_dsig_send_msg 0.42% beam.smp [kernel.kallsyms] [k] futex_wake 0.41% beam.smp beam.smp [.] encode_size_struct_int 0.40% beam.smp [kernel.kallsyms] [k] process_backlog From n.oxyde@REDACTED Thu Aug 21 10:37:13 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 21 Aug 2014 10:37:13 +0200 Subject: [erlang-questions] In praise of Erlang's 'if' In-Reply-To: <6A40C846-66B1-4838-9804-049306D23B75@cs.otago.ac.nz> References: <6A40C846-66B1-4838-9804-049306D23B75@cs.otago.ac.nz> Message-ID: <1D51BC06-E118-47CB-B91B-76D9204929C9@gmail.com> Hello Richard, Then, let?s assume the user wants to finally use guard disjunctions in if clauses: if Green, Crispy -> steam() ; Green, not Crispy -> chop() ; not Green; Leafy, Hard -> fry(), grill() ; not Green, Leafy, not Hard -> fry(), boil() ; not Green, not Leafy -> fry(), bake() end Now you have a guard disjunction quite hidden in the middle of a guard, and it?s tolerable only with your nonstandard indentation scheme, because in real life here is what happens: https://github.com/tuncer/rebar/commit/2c4d7d1d9bdc2a11d3f485f844500bf4c2aa77a2 Since that design flaw (which is what it is to my eyes) of the Erlang syntax was demonstrated to me, I want guard sequences to be deprecated in ?if? clauses? heads. Or maybe ?if? in its entirety, replaced by ?cond?, if I want to be fancy. Regards, -- Anthony Ramine Le 21 ao?t 2014 ? 05:21, Richard A. O'Keefe a ?crit : > Erlang's 'if' is often criticised, so I thought it would > be nice to show an example where it's just right. > > In connection with the recent thread on Potion, > I've been re-reading > Visual Programming Languages and the > Empirical Evidence For and Against > K.N.Whitley, October 1996, > submitted to the Journal of Visual Languages and Computing. > > Amongst other evidence for visual programming languages, this > paper cites Scanlan's "Structured flowcharts outperform > pseudocode: An experimental comparison", IEEE Software, June 1989. > Scanlan's article is, it seems to me, a classic case of > claiming too much. The title suggests, and the text clearly > states, that 'structured flowcharts' are superior to 'pseudocode', > where what was established was that one particular form of > flowchart was superior to one particular form of pseudocode. > > Here's one of the pseudo-code examples: > > IF GREEN > THEN > IF CRISPY > THEN > STEAM > ELSE > CHOP > ENDIF > ELSE > FRY > IF LEAFY > THEN > IF HARD > THEN > GRILL > ELSE > BOIL > ENDIF > ELSE > BAKE > ENDIF > ENDIF > > The weird layout is none of my invention. > Now, suppose we used Erlang as the pseudocode: > > > > if Green, Crispy -> steam() > ; Green, not Crispy -> chop() > ; not Green, Leafy, Hard -> fry(), grill() > ; not Green, Leafy, not Hard -> fry(), boil() > ; not Green, not Leafy -> fry(), bake() > end > > How do you think the comparison would have come out then? > > There is an old experiment that showed that > if X ... ifnot X ... end > was easier to understand than if X ... else ... end, and > oddly enough the 'hungry hare' examples in Scanlan appear > to have been taken from it, without learning its lesson. > It is at least possible that Scanlan's results were entirely > due to this factor, not the 'visual' aspect per se.) > > The irony is that an Erlang 'if', laid out the way I've > laid it out, would in Whitley's paper have been classified > as a 'visual' notation (subclass 'matrix'). > > We could also do it as a 'case': > > case {Green, Crispy, Leafy, Hard } > of {true, true, _, _ } -> steam() > ; {true, false, _, _ } -> chop() > ; {false, _, true, true } -> fry(), grill() > ; {false, _, true, false} -> fry(), boil() > ; {false, _, false, _ } -> fry(), bake() > end > > but in this case I think 'if' is easier to read. > > You might want to object that Scanlan could not have been > expected to think of this kind of layout in 1986, but this > is just a 'decision table', and decision tables are much > older than that and were well known in the 70s. > > What this illustrates above all is that proving that some > particular language or language feature is better or worse > than some other can be much harder than you think, and > that even classic results in the field can collapse under > a little inspection. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From raimo+erlang-questions@REDACTED Thu Aug 21 10:37:23 2014 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 21 Aug 2014 10:37:23 +0200 Subject: [erlang-questions] Trouble getting posts through In-Reply-To: References: Message-ID: <20140821083723.GA17987@erix.ericsson.se> On Wed, Aug 20, 2014 at 09:18:12AM -0500, Garrett Smith wrote: > I think I saw this in an earlier thread - but I still don't understand > something. > > I'm starting to get this reply for certain messages to the list: > > "Your message to erlang-questions awaits moderator approval" > > Is it the "[ANN]" in the subject? (Oh shoot, did me typing that there > make this a suspicious email?) I did see a "[ANN}" hack. Clever, but > is this really necessary in a civilized world? I think it is something else. Mailman suspects it is spam so it gets to moderation. But other [ANN] threads do not. There must be something else in the post. I try to approve them as soon as possible. > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From tony@REDACTED Thu Aug 21 12:11:08 2014 From: tony@REDACTED (Tony Rogvall) Date: Thu, 21 Aug 2014 12:11:08 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Message-ID: May I suggest a two stage commit, in the good old OTP way? - First step is to implement a fairly simple bif that call the functionality I really want to get (the remainder when doing bignum div calculations.) This includes the work of checking special considerations with GC. It works now, but needs more testing. As an example, I needed to blank the memory between the quotient and the remainder in the case when both quotient and reminder where both bignums. (It should not really be needed, but I think the debug compiled emulator/gc expect everything to be super clean?) - Seconds step is to use the previous work and implement an instruction that can be used instead of call erlang:divrem when possible. This instruction needs a couple of variants I guess: One that return a tuple and one that store remainder in a X register as instructed by compiler. What about that ? :-) /Tony On 20 aug 2014, at 20:04, Bj?rn-Egil Dahlberg wrote: > It should probably be an instruction instead. > > The compiler should recognize if div and rem is used and combine them to one instruction. You have no issue with multiple return values if you do it in core for instance. I did some doodling with this on my previous summer vacation .. along with sub-expr-elim .. I stopped after the doodling phase =) > > No eep necessary if you do it as an optimization pass, only light-eep. > > // Bj?rn-Egil > > > 2014-08-20 19:41 GMT+02:00 Tony Rogvall : > Hi list. > > I have been playing with a new BIF called divrem today. Calling erlang:divrem(A,B) has the the same result > as calling {A div B, A rem B}. (possibly with some strange exceptional cases that remain to be found :-) > > Since the bignum div operation has always calculated the remainder as a "waste product" I thought it was > about time to pick it up and make use if it. > > The speedup when comparing calculation of {Q,R} = erlang:divrem(A,B) and Q=A div B, R=A rem B, > is about 70-80% already around 60 bit arguments (64bit platform) (max speedup is of course 100%), > currently the downside is that divrem for small numbers are a bit slower, since a tuple {Q,R} is constructed > and the emulator have instructions for div and rem. > > The above could probably be handle by regarding divrem as a builtin function with a multiple return value > and have the compiler to generate an instruction for some instances of divrem. > > I remember some work for handling multiple return values? > > What about it ? eep? > > /Tony > > > _______________________________________________ > 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 dmkolesnikov@REDACTED Thu Aug 21 12:15:32 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 21 Aug 2014 13:15:32 +0300 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: <20140821040502.GA10732@debian> References: <20140819125903.GA4902@debian> <53F4B0BF.5060309@erix.ericsson.se> <20140820160135.GA10399@debian> <20140821040502.GA10732@debian> Message-ID: Hello, I am not sure why you are saying that spin-lock do not impact the result. I saw 25% gain on peak (on both loopback and en0 interfaces). - Dmitry On 21 Aug 2014, at 07:05, Jihyun Yu wrote: > The problem is reproducable *with loopback interface*. I tested with two > Erlang instances on same machine, communicating via loopback interface, > and results are same. > > I changed contented lock - qlock in DistEntry - to spinlock, but it does > not affact on throughput(messages per second). 'perf' profiling tool [1] > shows that CPU cycle is moved from kernel to userspace. > > I attach patch and 10-seconds sampling result on mutex and spinlock. > > [1] https://perf.wiki.kernel.org/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Thu Aug 21 12:18:39 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 21 Aug 2014 12:18:39 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Message-ID: Why would you make an instruction for the tuple-returning variant? That would be just calling your divrem BIF. -- Anthony Ramine Le 21 ao?t 2014 ? 12:11, Tony Rogvall a ?crit : > This instruction needs a couple of > variants I guess: One that return a tuple and one that store remainder in > a X register as instructed by compiler. From egil@REDACTED Thu Aug 21 12:34:20 2014 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 21 Aug 2014 12:34:20 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Message-ID: <53F5CB2C.70609@erlang.org> On 2014-08-21 12:11, Tony Rogvall wrote: > May I suggest a two stage commit, in the good old OTP way? > > - First step is to implement a fairly simple bif that call the > functionality I really want to get > (the remainder when doing bignum div calculations.) > > This includes the work of checking special considerations with GC. It > works now, but > needs more testing. As an example, I needed to blank the memory > between the quotient > and the remainder in the case when both quotient and reminder where > both bignums. > (It should not really be needed, but I think the debug compiled > emulator/gc expect everything to be super clean?) > > - Seconds step is to use the previous work and implement an > instruction that can be > used instead of call erlang:divrem when possible. This instruction > needs a couple of > variants I guess: One that return a tuple and one that store remainder in > a X register as instructed by compiler. > > What about that ? Please, not an additional BIF. Do an optimization pass in beam-assembler to rewrite the two gc-bif-instructions to a single divrem instruction. Or better, yet .. just reorder them so you can please the loader and rewrite it in the load-step. No need for an additional assembly instruction in the compiler, just a specific instruction in the beam which is optimized with a load trick. > > :-) > > /Tony > > > On 20 aug 2014, at 20:04, Bj?rn-Egil Dahlberg > > > wrote: > >> It should probably be an instruction instead. >> >> The compiler should recognize if div and rem is used and combine them >> to one instruction. You have no issue with multiple return values if >> you do it in core for instance. I did some doodling with this on my >> previous summer vacation .. along with sub-expr-elim .. I stopped >> after the doodling phase =) >> >> No eep necessary if you do it as an optimization pass, only light-eep. >> >> // Bj?rn-Egil >> >> >> 2014-08-20 19:41 GMT+02:00 Tony Rogvall > >: >> >> Hi list. >> >> I have been playing with a new BIF called divrem today. Calling >> erlang:divrem(A,B) has the the same result >> as calling {A div B, A rem B}. (possibly with some strange >> exceptional cases that remain to be found :-) >> >> Since the bignum div operation has always calculated the >> remainder as a "waste product" I thought it was >> about time to pick it up and make use if it. >> >> The speedup when comparing calculation of {Q,R} = >> erlang:divrem(A,B) and Q=A div B, R=A rem B, >> is about 70-80% already around 60 bit arguments (64bit platform) >> (max speedup is of course 100%), >> currently the downside is that divrem for small numbers are a bit >> slower, since a tuple {Q,R} is constructed >> and the emulator have instructions for div and rem. >> >> The above could probably be handle by regarding divrem as a >> builtin function with a multiple return value >> and have the compiler to generate an instruction for some >> instances of divrem. >> >> I remember some work for handling multiple return values? >> >> What about it ? eep? >> >> /Tony >> >> >> _______________________________________________ >> 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 tony@REDACTED Thu Aug 21 13:36:33 2014 From: tony@REDACTED (Tony Rogvall) Date: Thu, 21 Aug 2014 13:36:33 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: <53F5CB2C.70609@erlang.org> References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> <53F5CB2C.70609@erlang.org> Message-ID: On 21 aug 2014, at 12:34, Bj?rn-Egil Dahlberg wrote: > On 2014-08-21 12:11, Tony Rogvall wrote: >> May I suggest a two stage commit, in the good old OTP way? >> >> - First step is to implement a fairly simple bif that call the functionality I really want to get >> (the remainder when doing bignum div calculations.) >> >> This includes the work of checking special considerations with GC. It works now, but >> needs more testing. As an example, I needed to blank the memory between the quotient >> and the remainder in the case when both quotient and reminder where both bignums. >> (It should not really be needed, but I think the debug compiled emulator/gc expect everything to be super clean?) >> >> - Seconds step is to use the previous work and implement an instruction that can be >> used instead of call erlang:divrem when possible. This instruction needs a couple of >> variants I guess: One that return a tuple and one that store remainder in >> a X register as instructed by compiler. >> >> What about that ? > > Please, not an additional BIF. > Why not? What is the problem ? > Do an optimization pass in beam-assembler to rewrite the two gc-bif-instructions to a single divrem instruction. Or better, yet .. just reorder them so you can please the loader and rewrite it in the load-step. No need for an additional assembly instruction in the compiler, just a specific instruction in the beam which is optimized with a load trick. > I think one boring thing with this is that I need then to be dependent on that the compiler is smart enough to figure this out (even if I have to implement it my self ;-) How can a user be sure that the compiler really this optimisation? I think at least Bj?rn G used to have thought about having to smart compilers ? /Tony >> >> :-) >> >> /Tony >> >> >> On 20 aug 2014, at 20:04, Bj?rn-Egil Dahlberg wrote: >> >>> It should probably be an instruction instead. >>> >>> The compiler should recognize if div and rem is used and combine them to one instruction. You have no issue with multiple return values if you do it in core for instance. I did some doodling with this on my previous summer vacation .. along with sub-expr-elim .. I stopped after the doodling phase =) >>> >>> No eep necessary if you do it as an optimization pass, only light-eep. >>> >>> // Bj?rn-Egil >>> >>> >>> 2014-08-20 19:41 GMT+02:00 Tony Rogvall : >>> Hi list. >>> >>> I have been playing with a new BIF called divrem today. Calling erlang:divrem(A,B) has the the same result >>> as calling {A div B, A rem B}. (possibly with some strange exceptional cases that remain to be found :-) >>> >>> Since the bignum div operation has always calculated the remainder as a "waste product" I thought it was >>> about time to pick it up and make use if it. >>> >>> The speedup when comparing calculation of {Q,R} = erlang:divrem(A,B) and Q=A div B, R=A rem B, >>> is about 70-80% already around 60 bit arguments (64bit platform) (max speedup is of course 100%), >>> currently the downside is that divrem for small numbers are a bit slower, since a tuple {Q,R} is constructed >>> and the emulator have instructions for div and rem. >>> >>> The above could probably be handle by regarding divrem as a builtin function with a multiple return value >>> and have the compiler to generate an instruction for some instances of divrem. >>> >>> I remember some work for handling multiple return values? >>> >>> What about it ? eep? >>> >>> /Tony >>> >>> >>> _______________________________________________ >>> 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 "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 tony@REDACTED Thu Aug 21 13:40:49 2014 From: tony@REDACTED (Tony Rogvall) Date: Thu, 21 Aug 2014 13:40:49 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> Message-ID: <70AA12BB-CC7F-4BB9-893A-2107FBD3CABC@rogvall.se> On 21 aug 2014, at 12:18, Anthony Ramine wrote: > Why would you make an instruction for the tuple-returning variant? That would be just calling your divrem BIF. > Slightly faster execution in some cases, like small, small arguments for example. And also as a preparation for new instructions that could fallback to the more general one? Just guessing. I have not implemented the instructions yet. And maybe never will....? /Tony > -- > Anthony Ramine > > Le 21 ao?t 2014 ? 12:11, Tony Rogvall a ?crit : > >> This instruction needs a couple of >> variants I guess: One that return a tuple and one that store remainder in >> a X register as instructed by compiler. > "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 ok@REDACTED Thu Aug 21 13:58:59 2014 From: ok@REDACTED (ok@REDACTED) Date: Thu, 21 Aug 2014 23:58:59 +1200 Subject: [erlang-questions] divrem eep? In-Reply-To: <70AA12BB-CC7F-4BB9-893A-2107FBD3CABC@rogvall.se> References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> <70AA12BB-CC7F-4BB9-893A-2107FBD3CABC@rogvall.se> Message-ID: <83145f97b81d17107dd12a9f7cf2f22d.squirrel@chasm.otago.ac.nz> Suppose you initially have instructions like DIV src1, src2, dst1 REM src1, src2, dst2 -- made up, I have no idea what BEAM looks like here -- and you fuse them to DIVREM src1, src2, dst1, dst2 Now a call to a tuple-returning function erlang:divrem(X, Y) can be compiled as ( Q = div(X, Y), R = rem(X, Y), {Q,R} ) which then does ( DIVREM X, Y, Q, R {Q, R} ) Why then is a DIVREMTUPLE X, Y, T instruction needed? When it comes to integer quotient and remainder, it would be really nice to have flooring remainder: mod(X, Y) = if Y is zero then X else X - floor(X/Y)*Y It would be OK to have it as erlang:mod/2 or some other name, but the floor semantics would be so handy. From egil@REDACTED Thu Aug 21 15:18:54 2014 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 21 Aug 2014 15:18:54 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> <53F5CB2C.70609@erlang.org> Message-ID: <53F5F1BE.6050504@erlang.org> On 2014-08-21 13:36, Tony Rogvall wrote: > > On 21 aug 2014, at 12:34, Bj?rn-Egil Dahlberg > wrote: > >> On 2014-08-21 12:11, Tony Rogvall wrote: >>> May I suggest a two stage commit, in the good old OTP way? >>> >>> - First step is to implement a fairly simple bif that call the >>> functionality I really want to get >>> (the remainder when doing bignum div calculations.) >>> >>> This includes the work of checking special considerations with GC. >>> It works now, but >>> needs more testing. As an example, I needed to blank the memory >>> between the quotient >>> and the remainder in the case when both quotient and reminder where >>> both bignums. >>> (It should not really be needed, but I think the debug compiled >>> emulator/gc expect everything to be super clean?) >>> >>> - Seconds step is to use the previous work and implement an >>> instruction that can be >>> used instead of call erlang:divrem when possible. This instruction >>> needs a couple of >>> variants I guess: One that return a tuple and one that store >>> remainder in >>> a X register as instructed by compiler. >>> >>> What about that ? >> >> Please, not an additional BIF. >> > Why not? What is the problem ? My issue is that we are already littering erts with BIFs and several of them are probably unnecessary. > >> Do an optimization pass in beam-assembler to rewrite the two >> gc-bif-instructions to a single divrem instruction. Or better, yet .. >> just reorder them so you can please the loader and rewrite it in the >> load-step. No need for an additional assembly instruction in the >> compiler, just a specific instruction in the beam which is optimized >> with a load trick. >> > I think one boring thing with this is that I need then to be dependent > on that the compiler is smart enough to figure > this out (even if I have to implement it my self ;-) > How can a user be sure that the compiler really this optimisation? I > think at least Bj?rn G used to have > thought about having to smart compilers ? I think compilers should be smart and Erlangs compiler should be smarter than it is today. I don't know why you say Bj?rn G. is against smart compilers. I don't presume to speak for him but he has implemented optimization passes for bitsyntax and ref-sends for instance, and that is kind of smart don't you think? There are of course several way one might implement a divrem optimization. And it is an optimization and should thusly be treated as such. Let's assume we implement an erlang:divrem/2 BIF which returns a two-tuple. A late pass in core erlang should recognize erlang:divrem/2 and translate it to a primop with two return values. In addition to that pass you may also have an earlier pass that recognizes the div rem operators and translate them to a divrem BIF so old code can benefit from this without rewriting the code. The primop will be translated to a multiple Dst beam assembly code in v3_codegen .. and the loader just make a normal instruction for it. The BIF will never enter into the equation unless you do apply .. but you could implement divrem(A,B) -> {A div B, A rem B}. in the erlang module and the optimizer would take care of it for you. You will of course build the tuple in that case. This whole thing reduces the divrem BIF to a placeholder, you still need the functionality of course but it will be implemented solely in the instruction. In other words, the BIF is unnecessary, just do it in the compiler and implement it as an instruction. Furthermore, do away with the placeholder BIF and the pass to rewrite the divrem to a primop. Instead, recognize the occurrences of div rem operators and replace *them* with the primop instead. If you fear the optimization will not take, just do erlc +S and look for it .. just like for any other compiler. But you know all this .. you are just yanking my chain =) I say yes to a divrem optimization, it will probably help a few libraries. We have a couple in OTP that would surely benefit from it. I say no to a BIF since it is completely unnecessary .. especially since it is an optimization. // Bj?rn-Egil > > /Tony > > >>> >>> :-) >>> >>> /Tony >>> >>> >>> On 20 aug 2014, at 20:04, Bj?rn-Egil Dahlberg >>> > >>> wrote: >>> >>>> It should probably be an instruction instead. >>>> >>>> The compiler should recognize if div and rem is used and combine >>>> them to one instruction. You have no issue with multiple return >>>> values if you do it in core for instance. I did some doodling with >>>> this on my previous summer vacation .. along with sub-expr-elim .. >>>> I stopped after the doodling phase =) >>>> >>>> No eep necessary if you do it as an optimization pass, only light-eep. >>>> >>>> // Bj?rn-Egil >>>> >>>> >>>> 2014-08-20 19:41 GMT+02:00 Tony Rogvall >>> >: >>>> >>>> Hi list. >>>> >>>> I have been playing with a new BIF called divrem today. Calling >>>> erlang:divrem(A,B) has the the same result >>>> as calling {A div B, A rem B}. (possibly with some strange >>>> exceptional cases that remain to be found :-) >>>> >>>> Since the bignum div operation has always calculated the >>>> remainder as a "waste product" I thought it was >>>> about time to pick it up and make use if it. >>>> >>>> The speedup when comparing calculation of {Q,R} = >>>> erlang:divrem(A,B) and Q=A div B, R=A rem B, >>>> is about 70-80% already around 60 bit arguments (64bit >>>> platform) (max speedup is of course 100%), >>>> currently the downside is that divrem for small numbers are a >>>> bit slower, since a tuple {Q,R} is constructed >>>> and the emulator have instructions for div and rem. >>>> >>>> The above could probably be handle by regarding divrem as a >>>> builtin function with a multiple return value >>>> and have the compiler to generate an instruction for some >>>> instances of divrem. >>>> >>>> I remember some work for handling multiple return values? >>>> >>>> What about it ? eep? >>>> >>>> /Tony >>>> >>>> >>>> _______________________________________________ >>>> 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 > > "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 yjh0502@REDACTED Thu Aug 21 15:58:41 2014 From: yjh0502@REDACTED (Jihyun Yu) Date: Thu, 21 Aug 2014 22:58:41 +0900 Subject: [erlang-questions] Inter-node communication bottleneck In-Reply-To: References: <20140819125903.GA4902@debian> <53F4B0BF.5060309@erix.ericsson.se> <20140820160135.GA10399@debian> <20140821040502.GA10732@debian> Message-ID: <20140821135841.GA34024@debian> Spinlock works well when contension is not heavy, but it starts to fail when there are tens of processes are sending message to same node. Here's some updates - Tuning inet_default_connect_options and inet_default_listen_options improves performance. I tested with following option for both, and throughput increases from ~10MB/s to ~25MB/s [{delay_send,true},{high_watermark,1024000}] I also tried {nodelay, sndbuf, recbuf, buffer} options, but it seems that these option does not affact on throuphout. - Receiving side is also a bottleneck. I ran a benchmark with with different message sizes, and found that receiving node cannot utilize CPU more than 100% (one core). It seems that message decoding and distribution is done in single thread, and it cannot handle lots of small messages fast enough to satuate network bendwidth. Several thoughts - I didn't tested yet but ~25MB/s limitations is per node, so with 4 peer nodes I can satuate 1Gbps with smallest possible messages. The performance might not that bad as I thought. - I can simulate messaging with term_to_binary/1, binary_to_term/1, and tcp socket with {packet, 2} or {packet, 4} option. It lacks some optimization like atom table cache, but It scales. I'll spend some time to fix the issue, but I'm not sure what I can do more... On Thu, Aug 21, 2014 at 01:15:32PM +0300, Dmitry Kolesnikov wrote: > Hello, > > I am not sure why you are saying that spin-lock do not impact the result. > I saw 25% gain on peak (on both loopback and en0 interfaces). > > - Dmitry > > On 21 Aug 2014, at 07:05, Jihyun Yu wrote: > > > The problem is reproducable *with loopback interface*. I tested with two > > Erlang instances on same machine, communicating via loopback interface, > > and results are same. > > > > I changed contented lock - qlock in DistEntry - to spinlock, but it does > > not affact on throughput(messages per second). 'perf' profiling tool [1] > > shows that CPU cycle is moved from kernel to userspace. > > > > I attach patch and 10-seconds sampling result on mutex and spinlock. > > > > [1] https://perf.wiki.kernel.org/ > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > From ddosia@REDACTED Thu Aug 21 16:07:23 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Thu, 21 Aug 2014 18:07:23 +0400 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order Message-ID: Hello, I just spotted one counterintuitive thing for me: when you send messages to process, and then access it's mailbox via erlang:process_info(Pid, messages), all messages you sent is in the same order, oldest messages in the list's head! Example: self() ! m1, self() ! m2, self() ! m3, {messages,[m1,m2,m3]} = erlang:process_info(self(), messages). My expectations was that newest messages will be at the head of the list. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.s.klishin@REDACTED Thu Aug 21 16:10:14 2014 From: michael.s.klishin@REDACTED (Michael Klishin) Date: Thu, 21 Aug 2014 18:10:14 +0400 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: References: Message-ID: On 21 August 2014 at 18:07:33, Daniil Churikov (ddosia@REDACTED) wrote: > > Hello, I just spotted one counterintuitive thing for me: when > you send messages to process, > and then access it's mailbox via erlang:process_info(Pid, > messages), all messages you sent > is in the same order, oldest messages in the list's head! > > Example: > > self() ! m1, > self() ! m2, > self() ! m3, > {messages,[m1,m2,m3]} = erlang:process_info(self(), messages). > > My expectations was that newest messages will be at the head of > the list. How would old messages get a chance at being processed at high message rates, if the order wasn't FIFO?? -- @michaelklishin, github.com/michaelklishin From ddosia@REDACTED Thu Aug 21 20:23:54 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Thu, 21 Aug 2014 22:23:54 +0400 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: References: Message-ID: That make sense, thanks! 2014-08-21 18:10 GMT+04:00 Michael Klishin : > On 21 August 2014 at 18:07:33, Daniil Churikov (ddosia@REDACTED) wrote: > > > Hello, I just spotted one counterintuitive thing for me: when > > you send messages to process, > > and then access it's mailbox via erlang:process_info(Pid, > > messages), all messages you sent > > is in the same order, oldest messages in the list's head! > > > > Example: > > > > self() ! m1, > > self() ! m2, > > self() ! m3, > > {messages,[m1,m2,m3]} = erlang:process_info(self(), messages). > > > > My expectations was that newest messages will be at the head of > > the list. > > How would old messages get a chance at being processed at high message > rates, if the order wasn't FIFO? > -- > @michaelklishin, github.com/michaelklishin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Aug 21 22:01:32 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Thu, 21 Aug 2014 16:01:32 -0400 Subject: [erlang-questions] =?utf-8?q?Multi-Datacenter_Cassandra_on_32_Ras?= =?utf-8?q?pberry_Pi=E2=80=99s_=3A_DataStax?= Message-ID: Now here's an interesting way to demonstrate fault tolerance: http://www.datastax.com/dev/blog/32-node-raspberry-pi-cassandra-cluster Best wishes, LRP Sent from my iPad From darach@REDACTED Thu Aug 21 22:05:15 2014 From: darach@REDACTED (Darach Ennis) Date: Thu, 21 Aug 2014 21:05:15 +0100 Subject: [erlang-questions] =?utf-8?q?Multi-Datacenter_Cassandra_on_32_Ras?= =?utf-8?q?pberry_Pi=E2=80=99s_=3A_DataStax?= In-Reply-To: References: Message-ID: Its far more interesting for the latency tolerance! :) On 21 Aug 2014 21:01, "Lloyd R. Prentice" wrote: > Now here's an interesting way to demonstrate fault tolerance: > > http://www.datastax.com/dev/blog/32-node-raspberry-pi-cassandra-cluster > > Best wishes, > > LRP > > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From huxili@REDACTED Thu Aug 21 19:56:29 2014 From: huxili@REDACTED (Huxi Li) Date: Thu, 21 Aug 2014 19:56:29 +0200 Subject: [erlang-questions] Erlang code reuse Message-ID: Hello all, I am surprised to see the way the following module is coded when studying rabbit MQ server: https://github.com/rabbitmq/rabbitmq-server/blob/master/src/supervisor2.erl It is a duplication of erlang's supervisor.erl with minor changes. So my question is : Are there better ways of code reuse in erlang without duplication of code as found in the above example ? Some sort of polymorphism ? Thanks in advance. Huxi LI -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Thu Aug 21 22:34:04 2014 From: tony@REDACTED (Tony Rogvall) Date: Thu, 21 Aug 2014 22:34:04 +0200 Subject: [erlang-questions] divrem eep? In-Reply-To: <53F5F1BE.6050504@erlang.org> References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> <53F5CB2C.70609@erlang.org> <53F5F1BE.6050504@erlang.org> Message-ID: <400ED766-C59B-435F-93A9-9AADE6BC2E38@rogvall.se> On 21 aug 2014, at 15:18, Bj?rn-Egil Dahlberg wrote: > On 2014-08-21 13:36, Tony Rogvall wrote: >> >> On 21 aug 2014, at 12:34, Bj?rn-Egil Dahlberg wrote: >> >>> On 2014-08-21 12:11, Tony Rogvall wrote: >>>> May I suggest a two stage commit, in the good old OTP way? >>>> >>>> - First step is to implement a fairly simple bif that call the functionality I really want to get >>>> (the remainder when doing bignum div calculations.) >>>> >>>> This includes the work of checking special considerations with GC. It works now, but >>>> needs more testing. As an example, I needed to blank the memory between the quotient >>>> and the remainder in the case when both quotient and reminder where both bignums. >>>> (It should not really be needed, but I think the debug compiled emulator/gc expect everything to be super clean?) >>>> >>>> - Seconds step is to use the previous work and implement an instruction that can be >>>> used instead of call erlang:divrem when possible. This instruction needs a couple of >>>> variants I guess: One that return a tuple and one that store remainder in >>>> a X register as instructed by compiler. >>>> >>>> What about that ? >>> >>> Please, not an additional BIF. >>> >> Why not? What is the problem ? > > My issue is that we are already littering erts with BIFs and several of them are probably unnecessary. > After looking around a bit I found the following languages having a divrem / divmod build in function / operator! Haskell: quoteRem, divMod Python: divmod Ruby: divmod Visual Basic: DivRem C#: DivRem C++: DivRem JScript: DivRem C: div / ldiv So why don't we ? >> >>> Do an optimization pass in beam-assembler to rewrite the two gc-bif-instructions to a single divrem instruction. Or better, yet .. just reorder them so you can please the loader and rewrite it in the load-step. No need for an additional assembly instruction in the compiler, just a specific instruction in the beam which is optimized with a load trick. >>> >> I think one boring thing with this is that I need then to be dependent on that the compiler is smart enough to figure >> this out (even if I have to implement it my self ;-) >> How can a user be sure that the compiler really this optimisation? I think at least Bj?rn G used to have >> thought about having to smart compilers ? > > I think compilers should be smart and Erlangs compiler should be smarter than it is today. I don't know why you say Bj?rn G. is against smart compilers. I don't presume to speak for him but he has implemented optimization passes for bitsyntax and ref-sends for instance, and that is kind of smart don't you think? > > There are of course several way one might implement a divrem optimization. And it is an optimization and should thusly be treated as such. > > Let's assume we implement an erlang:divrem/2 BIF which returns a two-tuple. > A late pass in core erlang should recognize erlang:divrem/2 and translate it to a primop with two return values. > In addition to that pass you may also have an earlier pass that recognizes the div rem operators and translate them to a divrem BIF so old code can benefit from this without rewriting the code. > > The primop will be translated to a multiple Dst beam assembly code in v3_codegen .. and the loader just make a normal instruction for it. > > The BIF will never enter into the equation unless you do apply .. but you could implement divrem(A,B) -> {A div B, A rem B}. in the erlang module and the optimizer would take care of it for you. You will of course build the tuple in that case. A lot of arguments just to avoid a tiny BIF ! :-) I think that return values from exported functions may present a small problem as well ? -module(foo). -export([kaka/2]). kaka(A, B) -> erlang:divrem(A, B). > > This whole thing reduces the divrem BIF to a placeholder, you still need the functionality of course but it will be implemented solely in the instruction. In other words, the BIF is unnecessary, just do it in the compiler and implement it as an instruction. > > Furthermore, do away with the placeholder BIF and the pass to rewrite the divrem to a primop. Instead, recognize the occurrences of div rem operators and replace *them* with the primop instead. > > If you fear the optimization will not take, just do erlc +S and look for it .. just like for any other compiler. > Unless you have a language among the list above. > But you know all this .. you are just yanking my chain =) > Yes. :-) > I say yes to a divrem optimization, it will probably help a few libraries. We have a couple in OTP that would surely benefit from it. > I say no to a BIF since it is completely unnecessary .. especially since it is an optimization. > I would like it both ways. That way I and other developers know what they get when they call divrem, in all other cases the compiler may sometimes (when sunny) optimise div and rem, to exectue a bit faster. > // Bj?rn-Egil >> >> /Tony >> >> >>>> >>>> :-) >>>> >>>> /Tony >>>> >>>> >>>> On 20 aug 2014, at 20:04, Bj?rn-Egil Dahlberg wrote: >>>> >>>>> It should probably be an instruction instead. >>>>> >>>>> The compiler should recognize if div and rem is used and combine them to one instruction. You have no issue with multiple return values if you do it in core for instance. I did some doodling with this on my previous summer vacation .. along with sub-expr-elim .. I stopped after the doodling phase =) >>>>> >>>>> No eep necessary if you do it as an optimization pass, only light-eep. >>>>> >>>>> // Bj?rn-Egil >>>>> >>>>> >>>>> 2014-08-20 19:41 GMT+02:00 Tony Rogvall : >>>>> Hi list. >>>>> >>>>> I have been playing with a new BIF called divrem today. Calling erlang:divrem(A,B) has the the same result >>>>> as calling {A div B, A rem B}. (possibly with some strange exceptional cases that remain to be found :-) >>>>> >>>>> Since the bignum div operation has always calculated the remainder as a "waste product" I thought it was >>>>> about time to pick it up and make use if it. >>>>> >>>>> The speedup when comparing calculation of {Q,R} = erlang:divrem(A,B) and Q=A div B, R=A rem B, >>>>> is about 70-80% already around 60 bit arguments (64bit platform) (max speedup is of course 100%), >>>>> currently the downside is that divrem for small numbers are a bit slower, since a tuple {Q,R} is constructed >>>>> and the emulator have instructions for div and rem. >>>>> >>>>> The above could probably be handle by regarding divrem as a builtin function with a multiple return value >>>>> and have the compiler to generate an instruction for some instances of divrem. >>>>> >>>>> I remember some work for handling multiple return values? >>>>> >>>>> What about it ? eep? >>>>> >>>>> /Tony >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> "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 ok@REDACTED Fri Aug 22 00:43:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 22 Aug 2014 10:43:22 +1200 Subject: [erlang-questions] divrem eep? In-Reply-To: <400ED766-C59B-435F-93A9-9AADE6BC2E38@rogvall.se> References: <83057FC1-23FB-4401-8D18-0B4C568796E2@rogvall.se> <53F5CB2C.70609@erlang.org> <53F5F1BE.6050504@erlang.org> <400ED766-C59B-435F-93A9-9AADE6BC2E38@rogvall.se> Message-ID: <08E0EBEA-5E5E-4D72-B831-6E266561E97D@cs.otago.ac.nz> On 22/08/2014, at 8:34 AM, Tony Rogvall wrote: > After looking around a bit I found the following languages having a divrem / divmod build in function / operator! > > Haskell: quotRem, divMod > Python: divmod > Ruby: divmod > Visual Basic: DivRem > C#: DivRem > C++: DivRem > JScript: DivRem > C: div / ldiv C++ *does* have C's div()/ldiv(). I have been unable to locate any DivRem in the standard; which section is it in? You missed Lisp (floor X Y) (ceiling X Y) (round X Y) (truncate X Y) all return two values, a quotient and a remainder. If there is any language other than a dialect of Lisp that supports all four, I don't know what it might be. You also missed Pop-2. And also SML, where the IntInf structure has divMod (x, y) -> (q, r) (* flooring quotient and remainder *) quotRem (x, y) -> (q, r) (* truncating quotient and remainder *) but strangely, fixed size integers do _not_ have these functions! > So why don't we ? I think you may have misunderstood the reason that C has div(). It's not for efficiency, it's for portability. C originally specified / and % to do whatever the hardware did. C89 introduced div() in order to provide a form of integer division that was supposed to give you the same results everywhere. One of the sad things about the change from SPARC V8 to SPARC V9 was that you weren't any longer supposed to get the remainder as well as the quotient from a divide instruction. (Holy VAX, Batman!) So x % y is implemented as x - (x/y)*y. At least the Solaris Studio compiler turns a = x/y; b = x%y; into a = x/y; b = x - a*y; This shows that C does not need div() for *efficiency*, because you can get whatever efficiency that might offer without it. SML shows clearly that bignums are an important reason for the existence of such a function at some level, but C compilers show it doesn't have to be the source level. From dsheth@REDACTED Thu Aug 21 23:53:42 2014 From: dsheth@REDACTED (Devdutt Sheth) Date: Thu, 21 Aug 2014 21:53:42 +0000 Subject: [erlang-questions] Mystery exit message in ejabberd_odbc Message-ID: I seem to be getting a ton of - {'EXIT',#Port<0.1079543>,normal} ( the pid of course varies) messages in my ejabberd_odbc message queue. I understand that since we have process_flags(trap_exit, true) EXIT signals from linked processes are turned into messages and placed In ejabberd_odbc's message queue. My question is - How do we determine what exactly is #Port<0.1079543> - doing/executing? I obviously cannot do a port_info on this PID since it has already exited, nor am I able to see when it is spawned. I have tried to print out all the ports in the vm via a call to erlang:ports() every second, but I do not see the port that I am receiving the exit message from. This leads me to believe that the port exists for a very brief period ( maybe atomically). Any clues on how I can track down the source of this exit message? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Aug 22 07:08:16 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 22 Aug 2014 08:08:16 +0300 Subject: [erlang-questions] Mystery exit message in ejabberd_odbc In-Reply-To: References: Message-ID: <7E5B7DB3-C75E-4ABF-9D60-A27047FA0B6B@gmail.com> If port exit signal is delivered to you process then it is an port owner. Should you be able to trace the place where it is created at given code? Best Regards, Dmitry >-|-|-(*> > On 22.8.2014, at 0.53, Devdutt Sheth wrote: > > I seem to be getting a ton of - {'EXIT',#Port<0.1079543>,normal} > ( the pid of course varies) messages in my ejabberd_odbc message queue. > I > understand that since we have process_flags(trap_exit, true) EXIT signals from linked processes are turned into messages and placed > In > ejabberd_odbc?s message queue. > My question is ? > How do we determine what exactly is > #Port<0.1079543> > - doing/executing? > I > obviously cannot do a port_info on this PID since it has already exited, nor am I able to see when it is spawned. I have tried to print out all the ports in the vm > via a call to erlang:ports() every second, > but I do not see the port that I am receiving the exit message from. This leads me to believe that the port exists for a very brief period ( maybe atomically). > Any clues on how I can track down the > source of this exit message? > > > Thanks. > _______________________________________________ > 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 Fri Aug 22 13:50:19 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 22 Aug 2014 13:50:19 +0200 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: References: Message-ID: On Thu, Aug 21, 2014 at 4:10 PM, Michael Klishin < michael.s.klishin@REDACTED> wrote: > How would old messages get a chance at being processed at high message > rates, if the order wasn't FIFO? > Sometimes, this is actually a bad idea. LIFO mailboxes would be really really cool to have in certain situations. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Aug 22 13:56:55 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 22 Aug 2014 14:56:55 +0300 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: References: Message-ID: <39620B57-1DA7-4583-9830-237E160C4600@gmail.com> I would think that LIFO are manageable through in-process publish / subscribe. However, in-the-middle process impacts the performance to compare with native queue implementation. What is you use-case for LIFO? Best Regards, Dmitry On 22 Aug 2014, at 14:50, Jesper Louis Andersen wrote: > > On Thu, Aug 21, 2014 at 4:10 PM, Michael Klishin wrote: > How would old messages get a chance at being processed at high message > rates, if the order wasn't FIFO? > > Sometimes, this is actually a bad idea. LIFO mailboxes would be really really cool to have in certain situations. > > > -- > J. > _______________________________________________ > 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 Fri Aug 22 14:01:49 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 22 Aug 2014 14:01:49 +0200 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: <39620B57-1DA7-4583-9830-237E160C4600@gmail.com> References: <39620B57-1DA7-4583-9830-237E160C4600@gmail.com> Message-ID: LIFO is really good when you fail to meet a deadline, if you also have a way to "get rid of the rest of the mailbox". The reason is that in a stack: [a,b,...] you know that b entered before a. So if a is too old, then so must b. Hence you can avoid doing work by simply ignoring the extra work. Currently though, this is easily implementable in Erlang itself, so unless you need very high processing speed it is not a problem. On Fri, Aug 22, 2014 at 1:56 PM, Dmitry Kolesnikov wrote: > I would think that LIFO are manageable through in-process publish / > subscribe. However, in-the-middle process impacts the performance to > compare with native queue implementation. What is you use-case for LIFO? > > Best Regards, > Dmitry > > On 22 Aug 2014, at 14:50, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > > > On Thu, Aug 21, 2014 at 4:10 PM, Michael Klishin < > michael.s.klishin@REDACTED> wrote: > >> How would old messages get a chance at being processed at high message >> rates, if the order wasn't FIFO? >> > > Sometimes, this is actually a bad idea. LIFO mailboxes would be really > really cool to have in certain situations. > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Fri Aug 22 16:24:53 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Fri, 22 Aug 2014 10:24:53 -0400 Subject: [erlang-questions] Structure of a *scalable* application? Message-ID: I can't find much info on this on the web or in the docs... how does one structure a *scalable* Erlang application? By this, I mean a system consisting of multiple nodes, each of which runs the same code, so that we can take advantage of more CPU/memory/disk resources. Structures I can think of: 1. Single instance of application, one worker launched on each node (using rpc). 2. Multiple instances of application, one per node, each with one worker. 3. Multiple nodes, not connected, communicating only via TCP (ick!). 4. Something else?? Thanks. From mloftis@REDACTED Fri Aug 22 18:24:39 2014 From: mloftis@REDACTED (Michael Loftis) Date: Fri, 22 Aug 2014 09:24:39 -0700 Subject: [erlang-questions] Structure of a *scalable* application? In-Reply-To: References: Message-ID: On Fri, Aug 22, 2014 at 7:24 AM, Chris Pacejo wrote: > I can't find much info on this on the web or in the docs... how does > one structure a *scalable* Erlang application? By this, I mean a > system consisting of multiple nodes, each of which runs the same code, > so that we can take advantage of more CPU/memory/disk resources. > > Structures I can think of: > > 1. Single instance of application, one worker launched on each node (using rpc). > 2. Multiple instances of application, one per node, each with one worker. > 3. Multiple nodes, not connected, communicating only via TCP (ick!). > 4. Something else?? Those are all design decisions, none of which will affect your scaling much IMO, but one of your assumptions, only one worker per node, your "scaling" would suck, you'd be taking no advantage of parallelism within a node (And in general in Erlang a node is a machine but certainly not always) . It is completely application and workload dependent as to how exactly and where exactly to parallelize. Most erlang applications are designed to run an instance per node of the application module, they then RPC to other instances as necessary (see mnesia). I can't think of any offhand where a single application instance runs across multiple nodes but I'm sure it exists. Mostly you've got one application instance per node to manage that node and they'll communicate with each other to work together. But you'll basically rarely, if ever, see a single worker, when your'e talking about "Scaling" since that means parallelism in this context, because that single worker just doesn't scale for any workload. But...some workloads cannot be parallelized. Normally though about the only time you have a single worker is when you get down to say, a single external connection. That particular connection will often have a worker process, or it may be handled as part of a pool of worker processes. Erlang processes (not nodes, not OS processes) are lightweight. This is Erlang 101. Further as to 3) the erlang distribution protocol runs over TCP. It has it's own scaling limitations as some have found out - f/ex if you're pushing many megabyte files at a high rate, it might be better to have your own RPC mechanism to transfer those rather than sending them over erlang distribution directly - the distribution protocol comes down to a single thread on a single socket and can become a bottleneck for inter-node communications. Really though the best advice is to get it right first, then get it fast. Early optimization often isn't nearly as much of a win as people think. > > Thanks. > _______________________________________________ > 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 dsheth@REDACTED Fri Aug 22 19:03:36 2014 From: dsheth@REDACTED (Devdutt Sheth) Date: Fri, 22 Aug 2014 17:03:36 +0000 Subject: [erlang-questions] Mystery exit message in ejabberd_odbc In-Reply-To: <7E5B7DB3-C75E-4ABF-9D60-A27047FA0B6B@gmail.com> Message-ID: I realize that, but just by reading my code I am not able to establish where a port is being spawned? I am doing an erlang:ports() call in a tight loop but do not see the PID in question. Is there some utility/function that will list all the ports that have been in existence for a specified period of time ( either currently alive or recently exited)? If not, is there some utility/debugger that would help me with this? Thanks. From: Dmitry Kolesnikov > Date: Thursday, August 21, 2014 at 10:08 PM To: Devdutt Sheth > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] Mystery exit message in ejabberd_odbc If port exit signal is delivered to you process then it is an port owner. Should you be able to trace the place where it is created at given code? Best Regards, Dmitry >-|-|-(*> On 22.8.2014, at 0.53, Devdutt Sheth > wrote: I seem to be getting a ton of - {'EXIT',#Port<0.1079543>,normal} ( the pid of course varies) messages in my ejabberd_odbc message queue. I understand that since we have process_flags(trap_exit, true) EXIT signals from linked processes are turned into messages and placed In ejabberd_odbc's message queue. My question is - How do we determine what exactly is #Port<0.1079543> - doing/executing? I obviously cannot do a port_info on this PID since it has already exited, nor am I able to see when it is spawned. I have tried to print out all the ports in the vm via a call to erlang:ports() every second, but I do not see the port that I am receiving the exit message from. This leads me to believe that the port exists for a very brief period ( maybe atomically). Any clues on how I can track down the source of this exit message? Thanks. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Fri Aug 22 19:34:22 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Fri, 22 Aug 2014 13:34:22 -0400 Subject: [erlang-questions] Structure of a *scalable* application? In-Reply-To: References: Message-ID: On Fri, Aug 22, 2014 at 12:24 PM, Michael Loftis wrote: > Those are all design decisions, none of which will affect your scaling much IMO, Yes that I realize; I just wonder if there is one "accepted" way. > but one of your assumptions, only one worker per node, your > "scaling" would suck, Sorry, I mean in the context of CPU-boundedness. I want to keep the example simple. By "worker", it may be more general to say "agent within the node which can accept and distribute work within the node". > Most erlang applications are designed to run an instance per node of the > application module, they then RPC to other instances as necessary (see > mnesia). I can't think of any offhand where a single application > instance runs across multiple nodes but I'm sure it exists. OK, this makes sense. > Further as to 3) the erlang distribution protocol runs over TCP. It > has it's own scaling limitations as some have found out - f/ex if > you're pushing many megabyte files at a high rate, it might be better > to have your own RPC mechanism to transfer those rather than sending > them over erlang distribution directly - the distribution protocol > comes down to a single thread on a single socket and can become a > bottleneck for inter-node communications. Yes this I'm aware of. The system I'm building is moreso "small number of nodes which are CPU or I/O-bandwidth-bound", not "large number of nodes" nor "I/O-latency bound". > Really though the best advice is to get it right first, then get it > fast. Early optimization often isn't nearly as much of a win as > people think. Yes I know. I just want to make sure I structure my application in such a way that when it comes time to scale, I don't have to refactor everything. Thanks! From mononcqc@REDACTED Fri Aug 22 19:36:33 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 22 Aug 2014 13:36:33 -0400 Subject: [erlang-questions] Mystery exit message in ejabberd_odbc In-Reply-To: References: <7E5B7DB3-C75E-4ABF-9D60-A27047FA0B6B@gmail.com> Message-ID: <20140822173632.GH54532@ferdair.local> On 08/22, Devdutt Sheth wrote: > I realize that, but just by reading my code I am not able to establish where a port is being spawned? I am doing an erlang:ports() call in a tight loop but do not see the PID in question. > Is there some utility/function that will list all the ports that have been in existence for a specified period of time ( either currently alive or recently exited)? > If not, is there some utility/debugger that would help me with this? > > Thanks. > Ports also include TCP, UDP and SCTP sockets, file descriptors, etc. Ifyou do some manipulations over that, you may have ports around. They're linked to their parent/owner process, usually. Regards, Fred. From raould@REDACTED Fri Aug 22 19:36:35 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 22 Aug 2014 10:36:35 -0700 Subject: [erlang-questions] Structure of a *scalable* application? In-Reply-To: References: Message-ID: > I can't find much info on this on the web or in the docs... how does > one structure a *scalable* Erlang application? By this, I mean a > system consisting of multiple nodes, each of which runs the same code, > so that we can take advantage of more CPU/memory/disk resources. i think the last part is not the only answer to the first part, by the way. From raould@REDACTED Fri Aug 22 20:11:15 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 22 Aug 2014 11:11:15 -0700 Subject: [erlang-questions] Structure of a *scalable* application? In-Reply-To: References: Message-ID: > Yes I know. I just want to make sure I structure my application in > such a way that when it comes time to scale, I don't have to refactor > everything. er, well, depending on how much scale, you *will* have to refactor everything. now, you might not get to that point, but if you do, well, there ya go. From kolorahl@REDACTED Fri Aug 22 20:35:52 2014 From: kolorahl@REDACTED (Tyler Margison) Date: Fri, 22 Aug 2014 11:35:52 -0700 Subject: [erlang-questions] Erlang code reuse In-Reply-To: References: Message-ID: I'm not an Erlang expert, so others are more than welcome to correct me on this, but I do not believe Erlang allows "code reuse" in the manner you are suggesting. Erlang has behaviors, which are modules that define an interface and may have additional functionality of their own (see gen_server), but there is no way to inherit from a module and override select functions. I feel like this isn't a common scenario, though. In all of my own projects I very rarely, if ever, find myself re-writing entire modules to suit my own needs. PS: I thnk Elixir might be able to do this, but I haven't looked at the documentation in-depth for a while and I may be wrong. On Thu, Aug 21, 2014 at 10:56 AM, Huxi Li wrote: > Hello all, > > I am surprised to see the way the following module is coded when studying > rabbit MQ server: > > https://github.com/rabbitmq/rabbitmq-server/blob/master/src/supervisor2.erl > > It is a duplication of erlang's supervisor.erl with minor changes. > > So my question is : Are there better ways of code reuse in erlang without > duplication of code as found in the above example ? Some sort of > polymorphism ? > > Thanks in advance. > > Huxi LI > > _______________________________________________ > 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 Aug 22 20:41:22 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 22 Aug 2014 20:41:22 +0200 Subject: [erlang-questions] Erlang code reuse In-Reply-To: References: Message-ID: I don?t see how could any supervisor implementation be extendable in a way that allows all the modifications done in supervisor2. You would have to make the related parts of the code extendable directly in the implementation, just as you would do in Erlang if such extensibility was wanted. -- Anthony Ramine Le 22 ao?t 2014 ? 20:35, Tyler Margison a ?crit : > I'm not an Erlang expert, so others are more than welcome to correct me on this, but I do not believe Erlang allows "code reuse" in the manner you are suggesting. Erlang has behaviors, which are modules that define an interface and may have additional functionality of their own (see gen_server), but there is no way to inherit from a module and override select functions. I feel like this isn't a common scenario, though. In all of my own projects I very rarely, if ever, find myself re-writing entire modules to suit my own needs. > > PS: I thnk Elixir might be able to do this, but I haven't looked at the documentation in-depth for a while and I may be wrong. > > > On Thu, Aug 21, 2014 at 10:56 AM, Huxi Li wrote: > Hello all, > > I am surprised to see the way the following module is coded when studying rabbit MQ server: > > https://github.com/rabbitmq/rabbitmq-server/blob/master/src/supervisor2.erl > > It is a duplication of erlang's supervisor.erl with minor changes. > > So my question is : Are there better ways of code reuse in erlang without duplication of code as found in the above example ? Some sort of polymorphism ? > > Thanks in advance. > > Huxi LI > > _______________________________________________ > 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 federico.carrone@REDACTED Fri Aug 22 22:11:01 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Fri, 22 Aug 2014 17:11:01 -0300 Subject: [erlang-questions] Erlang code reuse In-Reply-To: References: Message-ID: Huxi, you should check https://github.com/opscode/mixer from the Chef guys. I use it a lot and it works perfectly fine. In Elixir you got protocols: https://pminten.github.io/blog/2013/09/11/elixir-patterns-mixins/ They are awesome! I recommend that you try elixir. Protocols , if I am not wrong, come from Clojure land. In a way they are remotely similar to duck typing in Ruby/Python but better (subjective opinion). However even with mixer/mixins, protocols or duck typing I am pretty sure that they would not be useful for the supervisor2 scenario. In that case, as Anthony Ramine pointed out, the supervisor should give you some option to insert the new functionality. Regards, Federico. On Fri, Aug 22, 2014 at 3:35 PM, Tyler Margison wrote: > I'm not an Erlang expert, so others are more than welcome to correct me on > this, but I do not believe Erlang allows "code reuse" in the manner you are > suggesting. Erlang has behaviors, which are modules that define an > interface and may have additional functionality of their own (see > gen_server), but there is no way to inherit from a module and override > select functions. I feel like this isn't a common scenario, though. In all > of my own projects I very rarely, if ever, find myself re-writing entire > modules to suit my own needs. > > PS: I thnk Elixir might be able to do this, but > I haven't looked at the documentation in-depth for a while and I may be > wrong. > > > On Thu, Aug 21, 2014 at 10:56 AM, Huxi Li wrote: > >> Hello all, >> >> I am surprised to see the way the following module is coded when studying >> rabbit MQ server: >> >> >> https://github.com/rabbitmq/rabbitmq-server/blob/master/src/supervisor2.erl >> >> It is a duplication of erlang's supervisor.erl with minor changes. >> >> So my question is : Are there better ways of code reuse in erlang >> without duplication of code as found in the above example ? Some sort of >> polymorphism ? >> >> Thanks in advance. >> >> Huxi LI >> >> _______________________________________________ >> 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 > > -- http://federicocarrone.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hq@REDACTED Fri Aug 22 23:43:05 2014 From: hq@REDACTED (Adam Rutkowski) Date: Fri, 22 Aug 2014 23:43:05 +0200 Subject: [erlang-questions] Sky is the limit? Or how to get sane VM settings. Message-ID: Hey List, What's your strategy regarding Erlang VM settings (I'm particularly interested in socket/port and process limits) for production usage? It might sound naive, but how do you squeeze 100% out of a single box and estimate the number of maximum clients that can be served for a cluster, given that the information you have is: - hardware platforms details (number of cores, RAM available etc.) - software platform details (i.e. kernel version, protocols used, VM version and whatnot) - process/port numbers required per client - the average/approximate sum (?) of stack sizes per client processes Also, what happens if you set VM limits to something that it cannot ever reach? And assuming that you can measure the number of messages/locks flying across nodes, how would you estimate the max size of a single cluster connected with Erlang Distribution Protocol (leaving the network reliability issue aside - assume the alien-technology never-splitting network). Obviously, "run-crash-repeat" would work to get there eventually... Share your thoughts/experience please. Thanks A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huxili@REDACTED Fri Aug 22 23:39:17 2014 From: huxili@REDACTED (Huxi Li) Date: Fri, 22 Aug 2014 23:39:17 +0200 Subject: [erlang-questions] Erlang code reuse In-Reply-To: References: Message-ID: Thanks for your advice. I will check mixer in more detail; it seems interesting. Many people talk about Exilir, but I haven't yet been convinced by Exilir -- although I can't tell exactly why. Regards, Huxi On 22 Aug 2014 22:11, "Federico Carrone" wrote: > Huxi, you should check https://github.com/opscode/mixer from the Chef > guys. I use it a lot and it works perfectly fine. > > In Elixir you got protocols: > https://pminten.github.io/blog/2013/09/11/elixir-patterns-mixins/ > > They are awesome! I recommend that you try elixir. > > Protocols , if I am not wrong, come from > Clojure land. In a way they are remotely similar to duck typing in > Ruby/Python but better (subjective opinion). > > However even with mixer/mixins, protocols or duck typing I am pretty sure > that they would not be useful for the supervisor2 scenario. In that case, > as Anthony Ramine pointed out, the supervisor should give you some option > to insert the new functionality. > > Regards, > Federico. > > > > > > On Fri, Aug 22, 2014 at 3:35 PM, Tyler Margison > wrote: > >> I'm not an Erlang expert, so others are more than welcome to correct me >> on this, but I do not believe Erlang allows "code reuse" in the manner you >> are suggesting. Erlang has behaviors, which are modules that define an >> interface and may have additional functionality of their own (see >> gen_server), but there is no way to inherit from a module and override >> select functions. I feel like this isn't a common scenario, though. In all >> of my own projects I very rarely, if ever, find myself re-writing entire >> modules to suit my own needs. >> >> PS: I thnk Elixir might be able to do this, >> but I haven't looked at the documentation in-depth for a while and I may be >> wrong. >> >> >> On Thu, Aug 21, 2014 at 10:56 AM, Huxi Li wrote: >> >>> Hello all, >>> >>> I am surprised to see the way the following module is coded when >>> studying rabbit MQ server: >>> >>> >>> https://github.com/rabbitmq/rabbitmq-server/blob/master/src/supervisor2.erl >>> >>> It is a duplication of erlang's supervisor.erl with minor changes. >>> >>> So my question is : Are there better ways of code reuse in erlang >>> without duplication of code as found in the above example ? Some sort of >>> polymorphism ? >>> >>> Thanks in advance. >>> >>> Huxi LI >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > http://federicocarrone.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Fri Aug 22 23:53:11 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 22 Aug 2014 14:53:11 -0700 Subject: [erlang-questions] Erlang code reuse In-Reply-To: References: Message-ID: hm, does LFE have ways to do this kind of modularization as well...? :) On Fri, Aug 22, 2014 at 2:39 PM, Huxi Li wrote: > Thanks for your advice. I will check mixer in more detail; it seems > interesting. > > Many people talk about Exilir, but I haven't yet been convinced by Exilir -- > although I can't tell exactly why. > From mjtruog@REDACTED Sat Aug 23 02:46:21 2014 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 22 Aug 2014 17:46:21 -0700 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() Message-ID: <53F7E45D.40701@gmail.com> I have been seeing the erts_poll_wait() thread consume 100% CPU when my configuration makes prim_inet:ignorefd/2 ignore a fd (inet_descriptor has is_ignored set to true) created external to inet (10 file descriptors created this way). I don't have this problem when using the inet code to create tcp sockets, when prim_inet:ignorefd/2 is not used with the same configuration. When setting "#define INET_DRV_DEBUG 1" in "./erts/emulator/drivers/common/inet_drv.c" and "#define ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" all the debugging output looks the same when exercising the file descriptors in the same way. The only difference seems to be the "Entering erts_poll_wait(), timeout=NUMBER" output has non-zero timeout values more often when prim_inet:ignorefd/2 is not used when compare to the output when it is being used. Also, the NUMBER doesn't seem to go about 1000 for me when prim_inet:ignorefd/2 is used, but it can go above 1000 when prim_inet:ignorefd/2 is not used. Why would the erts_poll_wait() loop be refusing to timeout? Is this expected behaviour? Is there an erts configuration flag which is meant to address the problem? Thanks, Michael From mjtruog@REDACTED Sat Aug 23 03:01:56 2014 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 22 Aug 2014 18:01:56 -0700 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: <53F7E45D.40701@gmail.com> References: <53F7E45D.40701@gmail.com> Message-ID: <53F7E804.4070900@gmail.com> To be a little clearer, my prim_inet:ignorefd/2 usage is to use a file descriptor created in the inet source code after passing it through gen_tcp:fdopen/2. So, the sequence is: ... {ok, FileDescriptorInternal} = prim_inet:getfd(Socket), ok = prim_inet:ignorefd(Socket, true), {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions), ... While this might seem odd, this allows me to dup2 the file descriptor without causing obvious problems and handle UNIX domain sockets, which are currently unsupported within inet (by avoiding the internal checking that prevents their use). On 08/22/2014 05:46 PM, Michael Truog wrote: > I have been seeing the erts_poll_wait() thread consume 100% CPU when > my configuration makes prim_inet:ignorefd/2 ignore a fd > (inet_descriptor has is_ignored set to true) created external to inet > (10 file descriptors created this way). I don't have this problem > when using the inet code to create tcp sockets, when > prim_inet:ignorefd/2 is not used with the same configuration. When > setting "#define INET_DRV_DEBUG 1" in > "./erts/emulator/drivers/common/inet_drv.c" and "#define > ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" all > the debugging output looks the same when exercising the file > descriptors in the same way. The only difference seems to be the > "Entering erts_poll_wait(), timeout=NUMBER" output has non-zero > timeout values more often when prim_inet:ignorefd/2 is not used when > compare to the output when it is being used. Also, the NUMBER doesn't > seem to go about 1000 for me when prim_inet:ignorefd/2 is used, but it > can go above 1000 when prim_inet:ignorefd/2 is not used. > > Why would the erts_poll_wait() loop be refusing to timeout? Is this > expected behaviour? Is there an erts configuration flag which is > meant to address the problem? > > Thanks, > Michael From colanderman@REDACTED Sat Aug 23 05:42:35 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Fri, 22 Aug 2014 23:42:35 -0400 Subject: [erlang-questions] Structure of a *scalable* application? In-Reply-To: References: Message-ID: On Fri, Aug 22, 2014 at 1:34 PM, Chris Pacejo wrote: > On Fri, Aug 22, 2014 at 12:24 PM, Michael Loftis wrote: >> Most erlang applications are designed to run an instance per node of the >> application module, they then RPC to other instances as necessary (see >> mnesia). I can't think of any offhand where a single application >> instance runs across multiple nodes but I'm sure it exists. > > OK, this makes sense. However, I must wonder -- what of a system for which some portions should be replicated, but others should not? e.g. consider a system which consists of: * workers, which should run on all nodes; * gateways, which should run only on Internet-connected nodes; and * a database, which should run on exactly one node. Should these functions each be separate applications, with multiple instances of each as appropriate? (And a distributed application in the case of the database?) Should they be a single application instantiated on all nodes, with leader election to determine which node owns the database, and with the gateways idle on non-Internet-connected nodes? Should they be a single (distributed) application with a single instance, which distributes work using rpc? I would lean towards the first option, but I'm hesitant to create so many micro-applications. From colanderman@REDACTED Sat Aug 23 05:52:15 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Fri, 22 Aug 2014 23:52:15 -0400 Subject: [erlang-questions] process restarts and dropped messages Message-ID: Hi list, Consider the case of a gen_server which crashes and is restarted by its supervisor. If the gen_server had outstanding casts in its mailbox, it will lose them. If the server is restarted quickly enough, any clients communicating with it will be unaware of this crash, and thus unaware that these messages were dropped. What is the standard way of avoiding this issue (assuming crashing the client is acceptable)? Favor calls over casts? Link to servers you need reliable communication with? Use a reliable message broker? Thanks. From bchesneau@REDACTED Sat Aug 23 11:25:49 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 23 Aug 2014 11:25:49 +0200 Subject: [erlang-questions] MQTT broker and client in erlang Message-ID: Are there any MATT broker and client that not rabbitmq based on around? I am looking for a simple Erlang application that i can embed in another application, and I am not sure it can be done using rabbitmq. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew.varner@REDACTED Sat Aug 23 12:41:35 2014 From: drew.varner@REDACTED (Drew Varner) Date: Sat, 23 Aug 2014 06:41:35 -0400 Subject: [erlang-questions] MQTT broker and client in erlang In-Reply-To: References: Message-ID: Benoit, Have you looked at https://github.com/jinnipark/fubar? Cheers, Drew > On Aug 23, 2014, at 5:25 AM, Benoit Chesneau wrote: > > Are there any MATT broker and client that not rabbitmq based on around? > > I am looking for a simple Erlang application that i can embed in another application, and I am not sure it can be done using rabbitmq. > > - benoit > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bchesneau@REDACTED Sat Aug 23 12:49:07 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 23 Aug 2014 12:49:07 +0200 Subject: [erlang-questions] MQTT broker and client in erlang In-Reply-To: References: Message-ID: On Sat, Aug 23, 2014 at 12:41 PM, Drew Varner wrote: > Benoit, > > Have you looked at https://github.com/jinnipark/fubar? > > Cheers, > Drew > Nope, I haven't found it during my search, thanks for the link! It looks like exactly what I was looking for. What is its status? Are you using it for a project? Side note, but maybe you could register foobar here: http://mqtt.org/wiki/doku.php/brokers . So anyone will be able to find it easily :) - benoit > > > On Aug 23, 2014, at 5:25 AM, Benoit Chesneau > wrote: > > > > Are there any MATT broker and client that not rabbitmq based on around? > > > > I am looking for a simple Erlang application that i can embed in > another application, and I am not sure it can be done using rabbitmq. > > > > - benoit > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.s.klishin@REDACTED Sat Aug 23 12:27:23 2014 From: michael.s.klishin@REDACTED (Michael Klishin) Date: Sat, 23 Aug 2014 14:27:23 +0400 Subject: [erlang-questions] MQTT broker and client in erlang In-Reply-To: References: Message-ID: On 23 August 2014 at 13:26:23, Benoit Chesneau (bchesneau@REDACTED) wrote: > > I am looking for a simple Erlang application that i can embed > in another application, and I am not sure it can be done using rabbitmq It can be done, although RabbitMQ isn't easy to embed. I've reused rabbitmq-mqtt's MQTT 3.1.1 parser from Elixir as an experiment, if you find no good embeddable solution, at least you can borrow that part easily. -- @michaelklishin, github.com/michaelklishin From francesco@REDACTED Sat Aug 23 16:00:20 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sat, 23 Aug 2014 15:00:20 +0100 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> <3C46B41D-C2C1-45C6-9CB4-BF6B3E3CF575@gmail.com> <53F21096.9000802@ninenines.eu> <53F21632.5020509@ninenines.eu> Message-ID: <53F89E74.90101@erlang-solutions.com> Hi All, just to thank you all for the feedback. Just checked in my part and thrown the rest over to Steve to wrap up. Hope it will be available as early access in the next ten days or so once we've taken into account the comments from Andy, our editor. This has been one of the hardest chapters to write, as there is no unified way of doing things, no one size fits all on the requirements of the products we are all shipping with Erlang, and no single tool to reference. The next iteration will be the feedback from the reviewers and those who have the early access. My gut feeling says we got it right. Once again, thanks for all the comments, both on the list and private. /F -- Founder & Technical Director Erlang Solutions Ltd. From lashifrin@REDACTED Sat Aug 23 17:04:59 2014 From: lashifrin@REDACTED (Leonid Shifrin) Date: Sat, 23 Aug 2014 11:04:59 -0400 Subject: [erlang-questions] erlang:process_info(Pid, messages) result order In-Reply-To: References: Message-ID: Hello! Any plans for labor day weekend? -Thanks Leonid On Aug 21, 2014 10:07 AM, "Daniil Churikov" wrote: > Hello, I just spotted one counterintuitive thing for me: when you send > messages to process, > and then access it's mailbox via erlang:process_info(Pid, messages), all > messages you sent > is in the same order, oldest messages in the list's head! > > Example: > > self() ! m1, > self() ! m2, > self() ! m3, > {messages,[m1,m2,m3]} = erlang:process_info(self(), messages). > > My expectations was that newest messages will be at the head of the list. > > Thanks. > > _______________________________________________ > 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 Aug 23 20:51:30 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 23 Aug 2014 20:51:30 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: <53F0D33B.4050308@erlang-solutions.com> References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: I think it might be a better idea if you explained how booting erlang works *exactly* what happens when you do "erl -boot XYZ.boot" examining a boot file is fun - for example, we can take a look at start.boot (the default boot file) - to see what it does we do the following: $ cd /usr/local/lib/erlang/bin $ erl 1 > {ok, B} = file:read_file("start.boot"). {ok,<<131,104,3,100,0,6,115,99,114,105,112,116,104,2,107, 0,10,69,114,108,97,110,103,47,79,84,80,...>>} 2 > binary_to_term(B). {script, {"Erlang/OTP","17"}, [{preLoaded, [erl_prim_loader,erlang,erts_internal,init,otp_ring0, prim_eval,prim_file,prim_inet,prim_zip,zlib]}, {progress,preloaded}, {path, ["$ROOT/lib/kernel-3.0/ebin","$ROOT/lib/stdlib-2.0/ebin"]}, {primLoad,[error_handler]}, {kernel_load_completed}, {progress,kernel_load_completed}, {path,["$ROOT/lib/kernel-3.0/ebin"]}, {primLoad, [application,application_controller,application_master, application_starter,auth,code,code_server,disk_log, disk_log_1,disk_log_server,disk_log_sup,dist_ac,dist_util, erl_boot_server,erl_ddll,erl_distribution|...]}, ...etc Boot files are just tuples which are interpreted by the function eval_script - (Which on my system starts in line 812 of /usr/local/lib/erlang/lib/erts-6.0/src/init.erl) The *reason* they are written as binaries and use binary_to_term to "see" them is because when the system is loaded the code to parse erlang terms has not yet been loaded - this code gets loaded by the boot loader a little bit later. The stuff in systools and reltool basically takes the pain out of manipulating the boot files. Once you've understood the bootfile structure the rest is easy. This is actually described in http://www.erlang.org/documentation/doc-4.9.1/doc/system_principles/system_principles.html But very few people seem to notice this - it might be an idea to emphasis how easy the start phases are. Once you hide what's really going on with tools you can get into deep waters if the tools stop working and you don't really understand whats happening under the covers ... Anybody who really wants to understand how the system starts should write some simple bootscripts by-hand and see what happens when they are run :-) Cheers /Joe On Sun, Aug 17, 2014 at 6:07 PM, Francesco Cesarini wrote: > Hi, > > I was wrapping up the chapter on release handling for the OTP book and never > having used it before, decided to take a look at reltool. Is anyone using > it? I am finding it counter intuitive and struggling to see how it > simplifies the task of creating releases. > > Feel free to reply to the list or ping me privately. > > Thanks, > F > > -- > Founder & Technical Director > Erlang Solutions Ltd. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jj@REDACTED Sat Aug 23 20:56:11 2014 From: jj@REDACTED (Giovanni Giorgi) Date: Sat, 23 Aug 2014 20:56:11 +0200 Subject: [erlang-questions] Erlang on PPC MacOSX 10.3 gcc 3.3 what OTP version? Message-ID: <1FF784B1-A52F-4317-B446-B0C6E998D840@gioorgi.com> Hi, I am trying a quite daunting task: recompiling erlang 17 on a Pismo PowerBook (G3) with gcc 3.3 I got stuck because gcc 3.3 does not understand the -m32/m64 flag. I think my gcc is too way old to the task, but I was unable to upgrade it (XCode 1.5 seems does not offer a greater gcc version). What OTP version can I hope to compile on this platform? Thank you! -- [ [ [ Giovanni ``Daitan`` Giorgi ] ] ] jj@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From jj@REDACTED Sat Aug 23 21:32:20 2014 From: jj@REDACTED (Giovanni Giorgi) Date: Sat, 23 Aug 2014 21:32:20 +0200 Subject: [erlang-questions] process restarts and dropped messages In-Reply-To: References: Message-ID: Message sent are always successful. This is my scenario: use gen_server behavior. Client A has supervisor A. Server B has supervisor B. if B crashes, client A will receive a badmessage (or no message at all). So A will crash too. The A supervisor will relaunch it, and also B supervisor will do the same for B. So if this error is infrequent, all is fine. Otherwise there is no easy way to fix it. On 23/ago/2014, at 05:52, Chris Pacejo wrote: > Hi list, > > Consider the case of a gen_server which crashes and is restarted by > its supervisor. If the gen_server had outstanding casts in its > mailbox, it will lose them. If the server is restarted quickly > enough, any clients communicating with it will be unaware of this > crash, and thus unaware that these messages were dropped. > > What is the standard way of avoiding this issue (assuming crashing the > client is acceptable)? Favor calls over casts? Link to servers you > need reliable communication with? Use a reliable message broker? > > Thanks. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- [ [ [ Giovanni ``Daitan`` Giorgi ] ] ] jj@REDACTED From jesper.louis.andersen@REDACTED Sat Aug 23 22:24:38 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 23 Aug 2014 22:24:38 +0200 Subject: [erlang-questions] process restarts and dropped messages In-Reply-To: References: Message-ID: On Sat, Aug 23, 2014 at 5:52 AM, Chris Pacejo wrote: > What is the standard way of avoiding this issue (assuming crashing the > client is acceptable)? Favor calls over casts? Link to servers you > need reliable communication with? Use a reliable message broker? > erlang:monitor/2 is the answer you want here, probably. Calls use them internally. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Sat Aug 23 22:55:25 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Sat, 23 Aug 2014 16:55:25 -0400 Subject: [erlang-questions] process restarts and dropped messages In-Reply-To: References: Message-ID: On Sat, Aug 23, 2014 at 4:24 PM, Jesper Louis Andersen wrote: > erlang:monitor/2 is the answer you want here, probably. Calls use them > internally. Oh, good to know. I figured calls only relied on timeouts. From dmkolesnikov@REDACTED Sat Aug 23 23:38:04 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sun, 24 Aug 2014 00:38:04 +0300 Subject: [erlang-questions] Erlang on PPC MacOSX 10.3 gcc 3.3 what OTP version? In-Reply-To: <1FF784B1-A52F-4317-B446-B0C6E998D840@gioorgi.com> References: <1FF784B1-A52F-4317-B446-B0C6E998D840@gioorgi.com> Message-ID: <18AA8FAF-B4C6-4735-BB92-BDBCDD5D992C@gmail.com> Hello, You can try to use macports to get new gcc. I am not sure how hard to install it on Your Mac. Best Regards, Dmitry >-|-|-(*> > On 23 Aug 2014, at 21:56, Giovanni Giorgi wrote: > > Hi, > I am trying a quite daunting task: recompiling erlang 17 on a Pismo PowerBook (G3) with gcc 3.3 > I got stuck because gcc 3.3 does not understand the -m32/m64 flag. > I think my gcc is too way old to the task, but I was unable to upgrade it (XCode 1.5 seems does not offer a greater gcc version). > > What OTP version can I hope to compile on this platform? > Thank you! > > > -- > [ [ [ Giovanni ``Daitan`` Giorgi ] ] ] > jj@REDACTED > > _______________________________________________ > 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 Sat Aug 23 23:41:16 2014 From: bob@REDACTED (Bob Ippolito) Date: Sat, 23 Aug 2014 14:41:16 -0700 Subject: [erlang-questions] Erlang on PPC MacOSX 10.3 gcc 3.3 what OTP version? In-Reply-To: <1FF784B1-A52F-4317-B446-B0C6E998D840@gioorgi.com> References: <1FF784B1-A52F-4317-B446-B0C6E998D840@gioorgi.com> Message-ID: You might have better luck with Linux on that sort of machine, it's not often that developer tool compatibility is maintained that far back on OS X because so much changes in each release. 10.3 is 6 major versions old, soon to be 7. On Sat, Aug 23, 2014 at 11:56 AM, Giovanni Giorgi wrote: > Hi, > I am trying a quite daunting task: recompiling erlang 17 on a Pismo > PowerBook (G3) with gcc 3.3 > I got stuck because gcc 3.3 does not understand the -m32/m64 flag. > I think my gcc is too way old to the task, but I was unable to upgrade it > (XCode 1.5 seems does not offer a greater gcc version). > > What OTP version can I hope to compile on this platform? > Thank you! > > > -- > [ [ [ Giovanni ``Daitan`` Giorgi ] ] ] > jj@REDACTED > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sun Aug 24 04:08:37 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 23 Aug 2014 19:08:37 -0700 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <53F94925.6020103@gmail.com> On 08/23/2014 11:51 AM, Joe Armstrong wrote: > I think it might be a better idea if you explained how booting erlang works > > *exactly* what happens when you do "erl -boot XYZ.boot" > > examining a boot file is fun - for example, we can take a look at start.boot Thank you for mentioning the format of the boot file. For some reason I didn't see that previously though I did create functions for starting and stopping applications within a release outside of the normal Erlang startup at https://github.com/okeuday/reltool_util (I was using the .script file but I added functions for the .boot file). The reltool_util source code is used within CloudI to start internal (Erlang) services, including services that are in a release (as shown here https://github.com/CloudI/CloudI/tree/develop/examples/hello_world1#usage-different-ways-of-adding-the-same-internal-service). So, the reltool_util source code might help others experiment with Erlang releases. > (the default boot file) - to see what it does we do the following: > > $ cd /usr/local/lib/erlang/bin > $ erl > > 1 > {ok, B} = file:read_file("start.boot"). > > {ok,<<131,104,3,100,0,6,115,99,114,105,112,116,104,2,107, > > 0,10,69,114,108,97,110,103,47,79,84,80,...>>} > > 2 > binary_to_term(B). > > {script, > > {"Erlang/OTP","17"}, > > [{preLoaded, > > [erl_prim_loader,erlang,erts_internal,init,otp_ring0, > > prim_eval,prim_file,prim_inet,prim_zip,zlib]}, > > {progress,preloaded}, > > {path, > > ["$ROOT/lib/kernel-3.0/ebin","$ROOT/lib/stdlib-2.0/ebin"]}, > > {primLoad,[error_handler]}, > > {kernel_load_completed}, > > {progress,kernel_load_completed}, > > {path,["$ROOT/lib/kernel-3.0/ebin"]}, > > {primLoad, > > [application,application_controller,application_master, > > application_starter,auth,code,code_server,disk_log, > > disk_log_1,disk_log_server,disk_log_sup,dist_ac,dist_util, > > erl_boot_server,erl_ddll,erl_distribution|...]}, > ...etc > > Boot files are just tuples which are interpreted by the function eval_script - > (Which on my system starts in line 812 of > /usr/local/lib/erlang/lib/erts-6.0/src/init.erl) > > The *reason* they > are written as binaries and use binary_to_term to "see" them is > because when the system > is loaded the code to parse erlang terms has not yet been loaded - > this code gets loaded > by the boot loader a little bit later. > > The stuff in systools and reltool basically takes the pain out of > manipulating the boot files. > Once you've understood the bootfile structure the rest is easy. > > This is actually described in > > http://www.erlang.org/documentation/doc-4.9.1/doc/system_principles/system_principles.html > > But very few people seem to notice this - it might be an idea to > emphasis how easy the > start phases are. Once you hide what's really going on with tools you > can get into deep > waters if the tools stop working and you don't really understand whats > happening under the > covers ... > > Anybody who really wants to understand how the system starts should > write some simple > bootscripts by-hand and see what happens when they are run :-) > > Cheers > > /Joe > > > On Sun, Aug 17, 2014 at 6:07 PM, Francesco Cesarini > wrote: >> Hi, >> >> I was wrapping up the chapter on release handling for the OTP book and never >> having used it before, decided to take a look at reltool. Is anyone using >> it? I am finding it counter intuitive and struggling to see how it >> simplifies the task of creating releases. >> >> Feel free to reply to the list or ping me privately. >> >> Thanks, >> F >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. >> >> _______________________________________________ >> 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 francesco@REDACTED Sun Aug 24 11:31:46 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sun, 24 Aug 2014 11:31:46 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: <9DDD81A2-43E3-4665-B1C7-6A912EF7A272@erlang-solutions.com> We cover the contents of boot files and explain what happens. The purpose is trouble shooting when your system refuses to start. We are not suggesting anyone bypass sys tools and write their own, no matter how fun some might think it is :-) F > On 23 Aug 2014, at 20:51, Joe Armstrong wrote: > > I think it might be a better idea if you explained how booting erlang works > > *exactly* what happens when you do "erl -boot XYZ.boot" > > examining a boot file is fun - for example, we can take a look at start.boot > (the default boot file) - to see what it does we do the following: > > $ cd /usr/local/lib/erlang/bin > $ erl > > 1 > {ok, B} = file:read_file("start.boot"). > > {ok,<<131,104,3,100,0,6,115,99,114,105,112,116,104,2,107, > > 0,10,69,114,108,97,110,103,47,79,84,80,...>>} > > 2 > binary_to_term(B). > > {script, > > {"Erlang/OTP","17"}, > > [{preLoaded, > > [erl_prim_loader,erlang,erts_internal,init,otp_ring0, > > prim_eval,prim_file,prim_inet,prim_zip,zlib]}, > > {progress,preloaded}, > > {path, > > ["$ROOT/lib/kernel-3.0/ebin","$ROOT/lib/stdlib-2.0/ebin"]}, > > {primLoad,[error_handler]}, > > {kernel_load_completed}, > > {progress,kernel_load_completed}, > > {path,["$ROOT/lib/kernel-3.0/ebin"]}, > > {primLoad, > > [application,application_controller,application_master, > > application_starter,auth,code,code_server,disk_log, > > disk_log_1,disk_log_server,disk_log_sup,dist_ac,dist_util, > > erl_boot_server,erl_ddll,erl_distribution|...]}, > ...etc > > Boot files are just tuples which are interpreted by the function eval_script - > (Which on my system starts in line 812 of > /usr/local/lib/erlang/lib/erts-6.0/src/init.erl) > > The *reason* they > are written as binaries and use binary_to_term to "see" them is > because when the system > is loaded the code to parse erlang terms has not yet been loaded - > this code gets loaded > by the boot loader a little bit later. > > The stuff in systools and reltool basically takes the pain out of > manipulating the boot files. > Once you've understood the bootfile structure the rest is easy. > > This is actually described in > > http://www.erlang.org/documentation/doc-4.9.1/doc/system_principles/system_principles.html > > But very few people seem to notice this - it might be an idea to > emphasis how easy the > start phases are. Once you hide what's really going on with tools you > can get into deep > waters if the tools stop working and you don't really understand whats > happening under the > covers ... > > Anybody who really wants to understand how the system starts should > write some simple > bootscripts by-hand and see what happens when they are run :-) > > Cheers > > /Joe > > > On Sun, Aug 17, 2014 at 6:07 PM, Francesco Cesarini > wrote: >> Hi, >> >> I was wrapping up the chapter on release handling for the OTP book and never >> having used it before, decided to take a look at reltool. Is anyone using >> it? I am finding it counter intuitive and struggling to see how it >> simplifies the task of creating releases. >> >> Feel free to reply to the list or ping me privately. >> >> Thanks, >> F >> >> -- >> Founder & Technical Director >> Erlang Solutions Ltd. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From zkessin@REDACTED Sun Aug 24 10:48:26 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Sun, 24 Aug 2014 11:48:26 +0300 Subject: [erlang-questions] [ANN] Chicago Erlang Conference - Sept 22 - aka "Best Lineup Ever" In-Reply-To: References: Message-ID: <53F9A6DA.4030307@gmail.com> Hey, I am flying in For Israel for this! (OK, I was already going to be in the USA) --Zach On 8/20/14, 5:14 PM, Garrett Smith wrote: > We will likely have video recordings as we did last year. That's the plan. > > However, if you live around Chicago or within easy flight access > (O'Hare is generally a cheaper ticket), we'll be blocking your IP > range for the videos, thereby forcing you to come. [1] > > Garrett > > [1] We won't do this. > > On Wed, Aug 20, 2014 at 8:52 AM, Federico Carrone > wrote: >> I am too far away (Buenos Aires) to go. It would be AWESOME if somebody >> could record the talks. >> >> Regards, >> Federico. >> >> >> On Tue, Aug 19, 2014 at 6:33 PM, Garrett Smith wrote: >>> For a single day, September 22, Chicago will become the center of know >>> Erlang universe: >>> >>> http://www.chicagoerlang.com >>> >>> This is a single track conference organized by the Chicago Erlang User >>> Group and Erlang Solutions that is focusing on "Real World Erlang". >>> The talks are very technical and practical: >>> >>> - Joe Armstrong: Modeling the World with Processes, Objects, Functions >>> or Relations >>> >>> - Francesco Cesarini: Thinking in a Concurrent Language >>> >>> - Steve Vinoski: Optimizing Native Code for Erlang >>> >>> - Fred Hebert: Keeping a System Running Forever >>> >>> - Irina Guberman: Maximizing Throughput On Multicore Systems >>> >>> - Reid Draper: Building Fault Tolerant Teams At Basho >>> >>> - Brian Troutwine: Monitoring Complex Systems >>> >>> - Jesse Gumm: Building Web Scale Apps with Nitrogen >>> >>> - Garrett Smith: Writing Quality Code in Erlang >>> >>> Zach Kessin will be hosting the Mostly Erlang podcast live at the after >>> party. >>> >>> Even if you're not in Chicago, really, this is worth a trip. If you >>> are in Chicago, you are simple required to go. It's a requirement. >>> >>> Seriously, come to this conference. >>> >>> Garrett >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> http://federicocarrone.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.santos@REDACTED Sun Aug 24 18:10:17 2014 From: michael.santos@REDACTED (Michael Santos) Date: Sun, 24 Aug 2014 12:10:17 -0400 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: <53F7E804.4070900@gmail.com> References: <53F7E45D.40701@gmail.com> <53F7E804.4070900@gmail.com> Message-ID: <20140824161017.GA10221@ioctl> On Fri, Aug 22, 2014 at 06:01:56PM -0700, Michael Truog wrote: > To be a little clearer, my prim_inet:ignorefd/2 usage is to use a > file descriptor created in the inet source code after passing it > through gen_tcp:fdopen/2. So, the sequence is: > ... > {ok, FileDescriptorInternal} = prim_inet:getfd(Socket), > ok = prim_inet:ignorefd(Socket, true), > {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions), > ... > While this might seem odd, this allows me to dup2 the file > descriptor without causing obvious problems and handle UNIX domain > sockets, which are currently unsupported within inet (by avoiding > the internal checking that prevents their use). Well, if you bypass the internal checks ... :) This doesn't answer your question but I would suggest only using PF_INET and PF_INET6 file descriptors with inet. The inet driver assumes it is working with sockets described by a sockaddr_in structure. Using anything else can lead to undefined behaviour. For example, something trivial like calling getpeername(2) on a PF_UNIX socket would cast the sockaddr_un as a sockaddr_in and presumably return 4 bytes of the Unix socket path as an IPv4 address. The alternative is passing the file descriptor into a port: FD = 7, Port = erlang:open_port({fd, FD, FD}, [stream,binary]). The disadvantage of using this method is the lack of flow control. If that is a concern, a process could monitor the rate of a incoming messages and close the port if it crossed some threshold, re-opening it when the messages have been processed. Closing the port will not close the file descriptor so the sender will eventually block. Otherwise, it's simple to write a small driver that uses erts to poll the fd on your behalf. I wrote one to use with a unix socket library so I could retrieve the socket ancillary data: https://github.com/msantos/inert This is very likely old news to you and you have good reasons for using gen_tcp but maybe it will be helpful for other people going down this path. > On 08/22/2014 05:46 PM, Michael Truog wrote: > >I have been seeing the erts_poll_wait() thread consume 100% CPU > >when my configuration makes prim_inet:ignorefd/2 ignore a fd > >(inet_descriptor has is_ignored set to true) created external to > >inet (10 file descriptors created this way). I don't have this > >problem when using the inet code to create tcp sockets, when > >prim_inet:ignorefd/2 is not used with the same configuration. When > >setting "#define INET_DRV_DEBUG 1" in > >"./erts/emulator/drivers/common/inet_drv.c" and "#define > >ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" > >all the debugging output looks the same when exercising the file > >descriptors in the same way. The only difference seems to be the > >"Entering erts_poll_wait(), timeout=NUMBER" output has non-zero > >timeout values more often when prim_inet:ignorefd/2 is not used > >when compare to the output when it is being used. Also, the > >NUMBER doesn't seem to go about 1000 for me when > >prim_inet:ignorefd/2 is used, but it can go above 1000 when > >prim_inet:ignorefd/2 is not used. > > > >Why would the erts_poll_wait() loop be refusing to timeout? Is > >this expected behaviour? Is there an erts configuration flag > >which is meant to address the problem? > > > >Thanks, > >Michael > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Sun Aug 24 19:04:28 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 24 Aug 2014 19:04:28 +0200 Subject: [erlang-questions] Reltool anyone? In-Reply-To: References: <53F0D33B.4050308@erlang-solutions.com> Message-ID: On Sat, Aug 23, 2014 at 8:51 PM, Joe Armstrong wrote: > I think it might be a better idea if you explained how booting > erlang works > > *exactly* what happens when you do "erl -boot XYZ.boot" > [...] > The *reason* they are written as binaries and use binary_to_term to > "see" them is because when the system is loaded the code to parse > erlang terms has not yet been loaded - this code gets loaded by the > boot loader a little bit later. > > The stuff in systools and reltool basically takes the pain out of > manipulating the boot files. Once you've understood the bootfile > structure the rest is easy. > > This is actually described in > > http://www[...]/doc-4.9.1/doc/system_principles/system_principles.html If you're looking for the same info in a current release, see: http://www.erlang.org/doc/system_principles/system_principles.html $ erl -man script or load http://www.erlang.org/doc/man/script.html $ erl -man systools or load http://www.erlang.org/doc/man/systools.html $ erl -man init or load http://www.erlang.org/doc/man/init.html > But very few people seem to notice this - it might be an idea to > emphasis how easy the start phases are. Once you hide what's really > going on with tools you can get into deep waters if the tools stop > working and you don't really understand whats happening under the > covers ... > > Anybody who really wants to understand how the system starts should > write some simple bootscripts by-hand and see what happens when they > are run :-) From tony@REDACTED Sun Aug 24 21:38:58 2014 From: tony@REDACTED (Tony Rogvall) Date: Sun, 24 Aug 2014 21:38:58 +0200 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: <53F7E804.4070900@gmail.com> References: <53F7E45D.40701@gmail.com> <53F7E804.4070900@gmail.com> Message-ID: I made a afunix version of the inet driver. You can find it here: https://github.com/tonyrog/afunix It will register it self as a socket so that afunix/gen_tcp/inet api is available. The reason I implemented it was the very same reason you had. /Tony On 23 aug 2014, at 03:01, Michael Truog wrote: > To be a little clearer, my prim_inet:ignorefd/2 usage is to use a file descriptor created in the inet source code after passing it through gen_tcp:fdopen/2. So, the sequence is: > ... > {ok, FileDescriptorInternal} = prim_inet:getfd(Socket), > ok = prim_inet:ignorefd(Socket, true), > {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions), > ... > While this might seem odd, this allows me to dup2 the file descriptor without causing obvious problems and handle UNIX domain sockets, which are currently unsupported within inet (by avoiding the internal checking that prevents their use). > > On 08/22/2014 05:46 PM, Michael Truog wrote: >> I have been seeing the erts_poll_wait() thread consume 100% CPU when my configuration makes prim_inet:ignorefd/2 ignore a fd (inet_descriptor has is_ignored set to true) created external to inet (10 file descriptors created this way). I don't have this problem when using the inet code to create tcp sockets, when prim_inet:ignorefd/2 is not used with the same configuration. When setting "#define INET_DRV_DEBUG 1" in "./erts/emulator/drivers/common/inet_drv.c" and "#define ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" all the debugging output looks the same when exercising the file descriptors in the same way. The only difference seems to be the "Entering erts_poll_wait(), timeout=NUMBER" output has non-zero timeout values more often when prim_inet:ignorefd/2 is not used when compare to the output when it is being used. Also, the NUMBER doesn't seem to go about 1000 for me when prim_inet:ignorefd/2 is used, but it can go above 1000 when prim_inet:ignorefd/2 is not used. >> >> Why would the erts_poll_wait() loop be refusing to timeout? Is this expected behaviour? Is there an erts configuration flag which is meant to address the problem? >> >> Thanks, >> Michael > > _______________________________________________ > 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 mjtruog@REDACTED Mon Aug 25 06:25:03 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 24 Aug 2014 21:25:03 -0700 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: <20140824161017.GA10221@ioctl> References: <53F7E45D.40701@gmail.com> <53F7E804.4070900@gmail.com> <20140824161017.GA10221@ioctl> Message-ID: <53FABA9F.8000404@gmail.com> On 08/24/2014 09:10 AM, Michael Santos wrote: > On Fri, Aug 22, 2014 at 06:01:56PM -0700, Michael Truog wrote: >> To be a little clearer, my prim_inet:ignorefd/2 usage is to use a >> file descriptor created in the inet source code after passing it >> through gen_tcp:fdopen/2. So, the sequence is: >> ... >> {ok, FileDescriptorInternal} = prim_inet:getfd(Socket), >> ok = prim_inet:ignorefd(Socket, true), >> {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions), >> ... >> While this might seem odd, this allows me to dup2 the file >> descriptor without causing obvious problems and handle UNIX domain >> sockets, which are currently unsupported within inet (by avoiding >> the internal checking that prevents their use). > Well, if you bypass the internal checks ... :) > > This doesn't answer your question but I would suggest only using PF_INET > and PF_INET6 file descriptors with inet. The inet driver assumes it is > working with sockets described by a sockaddr_in structure. Using anything > else can lead to undefined behaviour. > > For example, something trivial like calling getpeername(2) on a PF_UNIX > socket would cast the sockaddr_un as a sockaddr_in and presumably return > 4 bytes of the Unix socket path as an IPv4 address. I understand. I do have the same source code working with a normal INET tcp connection. The dup2 trick is done separately to support the same code path with unix domain sockets in a way that avoids making the inet source code use any of the socket data structures (so dup2 happens last, before active/once turns on the flow control. So, I know I am doing something a little dirty. My suspicion is that having the old socket Erlang port along with a new fdopen socket port somehow causes the erts event loop to not timeout due to an fd error that is ignored or an event that doesn't get consumed, I just am not sure how. > > The alternative is passing the file descriptor into a port: > > FD = 7, > Port = erlang:open_port({fd, FD, FD}, [stream,binary]). > > The disadvantage of using this method is the lack of flow control. If that > is a concern, a process could monitor the rate of a incoming messages > and close the port if it crossed some threshold, re-opening it when the > messages have been processed. Closing the port will not close the file > descriptor so the sender will eventually block. Yeah, I am still trying to use the inet Erlang/OTP flow control. It is unfortunate that this is not an easy task with unix domain sockets. > > Otherwise, it's simple to write a small driver that uses erts to poll > the fd on your behalf. I wrote one to use with a unix socket library so > I could retrieve the socket ancillary data: > > https://github.com/msantos/inert Thank you for mentioning the inert project. I wasn't aware of it, though I have seen procket, which is cool. If I have to go down that path, I will, but I still wanted to try to utilize the inet flow control, if it is possible to get something maintainable. Thanks, Michael > > This is very likely old news to you and you have good reasons for using > gen_tcp but maybe it will be helpful for other people going down this > path. > >> On 08/22/2014 05:46 PM, Michael Truog wrote: >>> I have been seeing the erts_poll_wait() thread consume 100% CPU >>> when my configuration makes prim_inet:ignorefd/2 ignore a fd >>> (inet_descriptor has is_ignored set to true) created external to >>> inet (10 file descriptors created this way). I don't have this >>> problem when using the inet code to create tcp sockets, when >>> prim_inet:ignorefd/2 is not used with the same configuration. When >>> setting "#define INET_DRV_DEBUG 1" in >>> "./erts/emulator/drivers/common/inet_drv.c" and "#define >>> ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" >>> all the debugging output looks the same when exercising the file >>> descriptors in the same way. The only difference seems to be the >>> "Entering erts_poll_wait(), timeout=NUMBER" output has non-zero >>> timeout values more often when prim_inet:ignorefd/2 is not used >>> when compare to the output when it is being used. Also, the >>> NUMBER doesn't seem to go about 1000 for me when >>> prim_inet:ignorefd/2 is used, but it can go above 1000 when >>> prim_inet:ignorefd/2 is not used. >>> >>> Why would the erts_poll_wait() loop be refusing to timeout? Is >>> this expected behaviour? Is there an erts configuration flag >>> which is meant to address the problem? >>> >>> Thanks, >>> Michael >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Mon Aug 25 06:48:38 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 24 Aug 2014 21:48:38 -0700 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: References: <53F7E45D.40701@gmail.com> <53F7E804.4070900@gmail.com> Message-ID: <53FAC026.7060108@gmail.com> On 08/24/2014 12:38 PM, Tony Rogvall wrote: > I made a afunix version of the inet driver. You can find it here: > > https://github.com/tonyrog/afunix > > It will register it self as a socket so that afunix/gen_tcp/inet api is available. > > The reason I implemented it was the very same reason you had. Thank you for mentioning afunix. This is actually doing unix domain socket support the right way. However, that also is a bit scary because it requires replicating so much source code from the inet C source code. It doesn't seem like there is any easier way though, to do it properly. I know the dup2 trick I am doing is dirty, but I was hoping to avoid creating any C source code to make it work. As it is right now, I was forced to handle the accept in a NIF, so I still need some C source code for the dup2 trick, but it still is small. I guess the only thing better than afunix will be to have unix domain socket support in Erlang/OTP. I really don't understand why it isn't a priority, due to it being a constant concern for over 5 years. I know there is an old email thread about the issue in 2009 http://erlang.org/pipermail/erlang-questions/2009-March/042180.html, but I know the problem goes back further than that along with the creation of unixdom_drv which is part of jungerl. I know unixdom_drv was broken due to new validation that was added to inets as mentioned here https://github.com/mikma/unixdom_drv/issues/3 . If anyone doesn't understand this situation, this doesn't have anything to do with UDP support and this is unrelated to the uds_dist example (which shows a way of using distributed Erlang with unix domain sockets). Named pipes would be the equivalent to unix domain sockets on Windows, despite the differences (http://en.wikipedia.org/wiki/Named_pipe#In_Windows). Is the reason that unix domain sockets don't get support the unix-only association they have? (i.e., no clear Windows equivalent, better than named pipes) I will have to think about using afunix a little more. It is probably the lesser of two evils, but it still seems like a concern. afunix should be the best way to currently approach the unix domain socket problem. However, the afunix source code will be difficult to maintain as the Erlang/OTP inet source code receives fixes. I know the Erlang/OTP source code doesn't change a ton, but it still seems like a concern, if not maintenance then purely due to complexity and SLOC/size (which are all connected). Thank you for releasing afunix as open source. If unix domain sockets were eventually implemented in Erlang/OTP, afunix would provide a way of transitioning to that support in a straightforward way. Thanks, Michael > > /Tony > > > On 23 aug 2014, at 03:01, Michael Truog > wrote: > >> To be a little clearer, my prim_inet:ignorefd/2 usage is to use a file descriptor created in the inet source code after passing it through gen_tcp:fdopen/2. So, the sequence is: >> ... >> {ok, FileDescriptorInternal} = prim_inet:getfd(Socket), >> ok = prim_inet:ignorefd(Socket, true), >> {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions), >> ... >> While this might seem odd, this allows me to dup2 the file descriptor without causing obvious problems and handle UNIX domain sockets, which are currently unsupported within inet (by avoiding the internal checking that prevents their use). >> >> On 08/22/2014 05:46 PM, Michael Truog wrote: >>> I have been seeing the erts_poll_wait() thread consume 100% CPU when my configuration makes prim_inet:ignorefd/2 ignore a fd (inet_descriptor has is_ignored set to true) created external to inet (10 file descriptors created this way). I don't have this problem when using the inet code to create tcp sockets, when prim_inet:ignorefd/2 is not used with the same configuration. When setting "#define INET_DRV_DEBUG 1" in "./erts/emulator/drivers/common/inet_drv.c" and "#define ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" all the debugging output looks the same when exercising the file descriptors in the same way. The only difference seems to be the "Entering erts_poll_wait(), timeout=NUMBER" output has non-zero timeout values more often when prim_inet:ignorefd/2 is not used when compare to the output when it is being used. Also, the NUMBER doesn't seem to go about 1000 for me when prim_inet:ignorefd/2 is used, but it can go above 1000 when >>> prim_inet:ignorefd/2 is not used. >>> >>> Why would the erts_poll_wait() loop be refusing to timeout? Is this expected behaviour? Is there an erts configuration flag which is meant to address the problem? >>> >>> Thanks, >>> Michael >> >> _______________________________________________ >> 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 devgutt@REDACTED Mon Aug 25 07:03:05 2014 From: devgutt@REDACTED (Gustavo Pires) Date: Mon, 25 Aug 2014 02:03:05 -0300 Subject: [erlang-questions] Android and Erlang Data transfer Message-ID: Hello everyone, What do you think I should use to transfer data between Android and an Erlang Server? I think a good approach would be Sockets + Protobuff, but I feel overwhelmed by the myriad of options out there (json, msgpack, thrift, bert, ubf, ...). I read some old threads in the list, but they are too old. I agree with an old Joe's comment about saving as much bandwidth you can, but I'm not sure how stable are programs like basho/protobuff and msgpack for erlang. It seems they don't evolve much in the last two years. Any though about this would be appreciated. Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Mon Aug 25 10:15:22 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 25 Aug 2014 10:15:22 +0200 Subject: [erlang-questions] Android and Erlang Data transfer In-Reply-To: References: Message-ID: Hi, You could make the Android program an Erlang node and use that. Comes with other baggage/functionality too, though. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From alavrik@REDACTED Tue Aug 26 09:03:04 2014 From: alavrik@REDACTED (Anton Lavrik) Date: Tue, 26 Aug 2014 00:03:04 -0700 Subject: [erlang-questions] Android and Erlang Data transfer In-Reply-To: References: Message-ID: Hi Gustavo, Based on my experience connecting remote clients with Erlang servers, Protocol Buffers works quite well. Unless you need something special (e.g. extra performance or extra simplicity), I would stick with it. It is a mature and very powerful tool. Important thing -- there are a couple of stable and well-maintained implementations of Protocol Buffers for Erlang: https://github.com/tomas-abrahamsson/gpb https://github.com/alavrik/piqi-erlang basho/protobuff is a fork of a really old Protobuf implementation for Erlang. It has a lot of limitations and issues. I wouldn't recommend it. I am not very knowledgeable about what people use on Android. One thing I heard that the stock Protocol Buffers for Java implementation may be a bit too heavy for mobile clients. You may want to check this alternative implementation: https://github.com/square/wire For transport, I'd recommend HTTP/HTTPS. Again, unless you need something special. You may also want to take a look at piqi-rpc. It helps to write Erlang servers and gives clients a choice to use Protocol Buffers, JSON or XML for making RPC-style calls over plain HTTP (I am an author of this tool). Anton On Sun, Aug 24, 2014 at 10:03 PM, Gustavo Pires wrote: > Hello everyone, > > What do you think I should use to transfer data between Android and an > Erlang Server? I think a good approach would be Sockets + Protobuff, but I > feel overwhelmed by the myriad of options out there (json, msgpack, thrift, > bert, ubf, ...). > > I read some old threads in the list, but they are too old. I agree with an > old Joe's comment about saving as much bandwidth you can, but I'm not sure > how stable are programs like basho/protobuff and msgpack for erlang. It > seems they don't evolve much in the last two years. > > Any though about this would be appreciated. > > Gustavo > > _______________________________________________ > 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 Tue Aug 26 09:29:25 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Tue, 26 Aug 2014 09:29:25 +0200 Subject: [erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait() In-Reply-To: <53F7E45D.40701@gmail.com> References: <53F7E45D.40701@gmail.com> Message-ID: Hello, On Sat, Aug 23, 2014 at 2:46 AM, Michael Truog wrote: > I have been seeing the erts_poll_wait() thread consume 100% CPU when my > configuration makes prim_inet:ignorefd/2 ignore a fd (inet_descriptor has > is_ignored set to true) created external to inet (10 file descriptors > created this way). I don't have this problem when using the inet code to > create tcp sockets, when prim_inet:ignorefd/2 is not used with the same > configuration. When setting "#define INET_DRV_DEBUG 1" in > "./erts/emulator/drivers/common/inet_drv.c" and "#define > ERTS_POLL_DEBUG_PRINT" in "./erts/emulator/sys/common/erl_poll.c" all the > debugging output looks the same when exercising the file descriptors in the > same way. The only difference seems to be the "Entering erts_poll_wait(), > timeout=NUMBER" output has non-zero timeout values more often when > prim_inet:ignorefd/2 is not used when compare to the output when it is > being used. Also, the NUMBER doesn't seem to go about 1000 for me when > prim_inet:ignorefd/2 is used, but it can go above 1000 when > prim_inet:ignorefd/2 is not used. > If you could add "#define DEBUG 1" at the start of the inet_driver a bunch of asserts should be enabled that might catch this error. What I suspect is happening is that for some reason the fd that was supposed to be ignored has been put into the pollset when it shouldn't have been which could trigger quite bad behaviour. How that has happened I don't know though. > > Why would the erts_poll_wait() loop be refusing to timeout? Is this > expected behaviour? Is there an erts configuration flag which is meant to > address the problem? > I would imagine this is because there is a fd in the pollset that triggers immediately. The thread that does the polling first spins a couple of times over poll with 0 timeout to see if it can get some triggered fd's before it goes to sleep waiting for events. If it does find a triggered fd the spin count is reset and it starts spinning again. > > Thanks, > Michael > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.youngkin@REDACTED Tue Aug 26 21:34:02 2014 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Tue, 26 Aug 2014 13:34:02 -0600 Subject: [erlang-questions] Erlang and Akka Message-ID: Hi all, I'm working on an application written in Erlang. In recent months there have been more and more questions questioning Erlang/OTP. There is general recognition that many of the Erlang/OTP's features (e.g., immutable state,supervision) are beneficial. The questions mostly revolve around availability of Erlang expertise and supporting libraries (e.g., Cassandra support just to name one whereas Akka has the entire JVM ecosystem available to it). Akka has been proposed as an alternative to Erlang. Googling around for good comparisons between Erlang and Akka hasn't turned up a lot of useful information, but there is some (e.g., http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang). I'd be interested if anyone in this community has any advice and/or opinions regarding Erlang vs. Akka. Anyone? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Aug 26 21:41:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 26 Aug 2014 22:41:41 +0300 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: <53FCE2F5.2010705@ninenines.eu> My main concern with anything JVM would be the lack of per process GC which means that latency will suffer (due to stop the world GC). I do not know Akka so my comparison stops there. Maybe you should explain a little what your application is doing/background/... so you can get better advice on whether you should use one or another. On 08/26/2014 10:34 PM, Youngkin, Rich wrote: > Hi all, > > I'm working on an application written in Erlang. In recent months there > have been more and more questions questioning Erlang/OTP. There is > general recognition that many of the Erlang/OTP's features (e.g., > immutable state,supervision) are beneficial. The questions mostly > revolve around availability of Erlang expertise and supporting libraries > (e.g., Cassandra support just to name one whereas Akka has the entire > JVM ecosystem available to it). Akka has been proposed as an alternative > to Erlang. > > Googling around for good comparisons between Erlang and Akka hasn't > turned up a lot of useful information, but there is some (e.g., > http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang). > > I'd be interested if anyone in this community has any advice and/or > opinions regarding Erlang vs. Akka. Anyone? > > Thanks, > Rich > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From lee.sylvester@REDACTED Tue Aug 26 21:45:15 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Tue, 26 Aug 2014 20:45:15 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: My thoughts are simply that, where Erlang was designed from the ground up to cater, Akka has been built on top of a platform that has not. There is much that Erlang provides for free that just makes life easy. Akka may do this, too, but since it?s built on the JVM, you?re bound to run into some headaches. Lee On 26 Aug 2014, at 20:34, Youngkin, Rich wrote: > Hi all, > > I'm working on an application written in Erlang. In recent months there have been more and more questions questioning Erlang/OTP. There is general recognition that many of the Erlang/OTP's features (e.g., immutable state,supervision) are beneficial. The questions mostly revolve around availability of Erlang expertise and supporting libraries (e.g., Cassandra support just to name one whereas Akka has the entire JVM ecosystem available to it). Akka has been proposed as an alternative to Erlang. > > Googling around for good comparisons between Erlang and Akka hasn't turned up a lot of useful information, but there is some (e.g., http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang). > > I'd be interested if anyone in this community has any advice and/or opinions regarding Erlang vs. Akka. Anyone? > > Thanks, > Rich > _______________________________________________ > 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 Tue Aug 26 22:58:03 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Tue, 26 Aug 2014 16:58:03 -0400 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: Rich, This old discussion may be of interest: https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556 On Tue, Aug 26, 2014 at 3:34 PM, Youngkin, Rich wrote: > Hi all, > > I'm working on an application written in Erlang. In recent months there have > been more and more questions questioning Erlang/OTP. There is general > recognition that many of the Erlang/OTP's features (e.g., immutable > state,supervision) are beneficial. The questions mostly revolve around > availability of Erlang expertise and supporting libraries (e.g., Cassandra > support just to name one whereas Akka has the entire JVM ecosystem available > to it). Akka has been proposed as an alternative to Erlang. > > Googling around for good comparisons between Erlang and Akka hasn't turned > up a lot of useful information, but there is some (e.g., > http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang). > > I'd be interested if anyone in this community has any advice and/or opinions > regarding Erlang vs. Akka. Anyone? > > Thanks, > Rich > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From darach@REDACTED Tue Aug 26 23:18:36 2014 From: darach@REDACTED (Darach Ennis) Date: Tue, 26 Aug 2014 22:18:36 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: Hi guys, Comparing Akka to Erlang/OTP is complex by its very nature. Akka streams and transactors have no direct translation to Erlang/OTP for example, at least to my knowledge. Akka as a recent incarnation of the actor model has some ideas that should inspire innovation in OTP. Akka clustering, for example, was inspired by Riak core. So when we compare Akka are we including that? Should we widen OTP to include riak core to have a fairer comparison to Akka? If you are in a JVM environment. It is far better to adopt Akka than to roll your own actor style framework. However, if your domain lends itself well to natural concurrency it will be fairly easier to describe and implement that system using Erlang/OTP. If, on the other hand, you require fine grained concurrency control and multi-threading then the JVM *will* suit you better, on average, but it'll cost you at the long tail, and when the the stop-the-world pause hits you, it can hit you terribly awfuly badly (unless you have mastered the art of JVM and GC tuning - there are over 800 tunables, so good luck!). Its just something one has to get used to when dealing with the JVM. Ultimately, making an informed choice between Erlang/OTP and JVM/Akka requires deeper thinking. There isn't enough overlap between the communities to be easily able to weed out individual or community bias (I am tarring myself with this brush too!) For your application, it is already using Erlang, so why not check out some of the cassandra bindings available such as (in no particular order): https://github.com/dieswaytoofast/erlang_cassandra https://github.com/matehat/cqerl https://github.com/RJ/erlang-cassandra-cql Cheers, Darach. On Tue, Aug 26, 2014 at 8:45 PM, Lee Sylvester wrote: > My thoughts are simply that, where Erlang was designed from the ground up > to cater, Akka has been built on top of a platform that has not. There is > much that Erlang provides for free that just makes life easy. Akka may do > this, too, but since it?s built on the JVM, you?re bound to run into some > headaches. > > Lee > > > On 26 Aug 2014, at 20:34, Youngkin, Rich > wrote: > > Hi all, > > I'm working on an application written in Erlang. In recent months there > have been more and more questions questioning Erlang/OTP. There is general > recognition that many of the Erlang/OTP's features (e.g., immutable > state,supervision) are beneficial. The questions mostly revolve around > availability of Erlang expertise and supporting libraries (e.g., Cassandra > support just to name one whereas Akka has the entire JVM ecosystem > available to it). Akka has been proposed as an alternative to Erlang. > > Googling around for good comparisons between Erlang and Akka hasn't turned > up a lot of useful information, but there is some (e.g., > http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang > ). > > I'd be interested if anyone in this community has any advice and/or > opinions regarding Erlang vs. Akka. Anyone? > > Thanks, > Rich > _______________________________________________ > 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 jesper.louis.andersen@REDACTED Tue Aug 26 23:20:50 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 26 Aug 2014 23:20:50 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: On Tue, Aug 26, 2014 at 9:34 PM, Youngkin, Rich < richard.youngkin@REDACTED> wrote: > Akka has been proposed as an alternative to Erlang. What are the arguments for Akka, as opposed to the arguments for Erlang? Library availability is definitely a valid concern. Yet, any library in any language will have errors and mistakes. A good point about Erlang is that the occasionally bad library tend to hurt your program less for the simple fact that proper isolation saves the day. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciprian.craciun@REDACTED Tue Aug 26 23:30:10 2014 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Wed, 27 Aug 2014 00:30:10 +0300 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) Message-ID: Today I've made a small attempt at finding a suitable JSON encoding / decoding library that fit my needs. (Until now I was using `mochijson2` [1], which seems to be rather old...) However the current email is not about my requirements, or the found libraries, but on the current direction the recent JSON libraries are heading towards, namely how objects are encoded as `[{}] | list({string(), json()})`. First of all a small survey about existing implementations: * `mochijson2` [1] uses (what I call) "mochi", i.e. `{struct, list({string(), json()})}`; * `jsx` [2] uses EEP-0018, i.e. `[{}] | list({string(), json()})`; * `jiffy` [3] uses EEP-0018; * `ejson` [4] uses something in between "mochi" and EEP-0018, namely `{list({string(), json()})}`; * `jsonx` [5] uses "mochi"; * `kvc` [6] (although a querier) uses either "mochi" or EEP-0018; * `valijate` [7] (although only a validator) uses something similar to "mochi"; * others are either "mochi"-compliant or EEP-0018 compliant; (many more seem to be EEP-0018 than "mochi";) Granted that EEP-0018 clearly states that a library could offer the user the option to choose how the object is to be encoded as an Erlang term (options A through F), and it could know how to correctly interpret one as such. (Unfortunately none of the encoding / decoding libraries do support this choice.) At a first scratch there seems nothing wrong with either approach (either "mochi" or EEP-0018). Except maybe the fact that when writing a multi-headed pattern-matching function, in case of EEP-0018 one must match first the list, then the object, or else the object might be misinterpreted as a list. Although I do have to say that "mochi" does have a clearly unambiguous way to detect the value type, that is almost impossible to get wrong. But granted that deconstructing EEP-0018 compliant objects with plain Erlang libraries (like `proplists`) is slightly more straight-forward, because one can use the object value as a list, whereas in "mochi" one would need to first extract the list, which boils down to `Object` vs. `element(2, Object)`. Therefore why do I say EEP-0018 (and conforming libraries) are wrong? (In fact so wrong that I felt the need to write such a lengthy email?) Because when one wants to extend the proposed JSON term syntax, or perhaps use it for something else (but still related to JSON), things start to crumble. Let's take for example `valijate` [7] which allows one to easily validate (among others) JSON values with a simple schema. For example one can say `{array, string}` to denote a schema which matches any list made only of strings. One could write the `validate` function for EEP-0018 as: ~~~~ (not tested) validate (List, {array, ElementSchema}) -> case List of [{}] -> false; [Head | _] when is_tuple (Head) -> false; _ when is_list (List) -> lists:foldl( fun (true, A) -> A; (false, _) -> false end, true, lists:map (fun (Element) -> validate(Element, ElementSchema) end, List)); _ -> false; end; ~~~~ Compared with the following for "mochi": ~~~~ (not tested) validate (List, {array, ElementSchema}) -> if is_list (List) -> lists:foldl( fun (true, A) -> A; (false, _) -> false end, true, lists:map (fun (Element) -> validate(Element, ElementSchema) end, List)); true -> false end; ~~~~ No big issue so far, except a few extra matches (which could become tiresome to write if we have more than one type of schema that applies to lists). Let's move a little bit further. Say we now want to be able to write in `valijate` something like the following Erlang type: `[list(string()), list(integer())]` (i.e. a list made of exactly two elements, the first a list of strings, the second a list of integers). Although I don't know how (or if) `valijate` is able to express this, I would have expected something like this to work: [{array, string}, {array, integer}] Let's complicate it further and assume that we want to be able to validate if a list is a set (i.e. non-repeating elements), and we introduce a new schema type called `set`. Let's see how a schema would look like for a list made of exactly two elements, the first an array of strings, the second a set of integers: [{array, string}, {set, integer}] However, before writing the implementation, let's imagine how a schema for an objects would look like. Assuming we want to keep as close as possible to the original EEP-0018 proposed term syntax, one could imagine something like this: * for an object with any number of attributes, whose keys and values must independently match the given schemas (i.e. the expected object behaves like a dictionary): [{, , , }, ...] Let's try to give two examples: * an object with any key, and a string as value (pick any): [{string, string}] [{any, string}] * an object with exactly one key named either "string", or "any", whose value is a string: [{string, string}] [{any, string}] Let's also try to provide the schema for an object with exactly two attributes, one named `array` and with a string value, the second named `set` with an integer value: [{array, string}, {set, integer}] Darn... I can't discern between the schema for a dictionary of strings or the schema for a record with a single attribute named "string" and a string value. Similarly I can't discern between the schema for a two element array (one element a list, the other a set) or a two attribute object one named "array", the other "set". (Granted I can start complicating the schema syntax, but that would get further from a "simple" approach where the schema resembles closely the actual value.) Let's see if "mochi" could do it: * for a dictionary: {object, {, , , >, of which we are certain it is correctly encoded, thus we don't need to parse it, and we need to "wrap" it into another JSON which holds some meta-data, like for example `{"ok" : true, "outcome" : }`. However as stated we would like the to reuse our favourite JSON library to encode such a wrapper JSON, but without first parsing the JSON binary. We could therefore extend the JSON library to allow us to put inside JSON terms, values which are to be "pasted" directly in the result (this is equivalent to the `RawMessage` from Go's JSON library). However the question is how to flag these raw values? We obviously can't use a binary as that is the representation of a string. We could choose something like `{raw, <<"...">>}`. OK, let's now try to see how a list composed of a single element, namely the raw JSON, would look like: [{raw, <<"...">>}] Doesn't that resemble an object with an attribute named "raw" and a string as value? In EEP-0018 it surely does, but in "mochi" it doesn't (that would be `{object, [{raw, <<"...">>}]}`). (Or maybe we want to be able to use records directly as JSON values, tagged like `{record, }` which would call an external formatter, or even simpler directly using `` provided that it's tag isn't `object`. Or perhaps `{dict, }`, `{gb_tree, }`, etc.) I hope that the two given examples argument my case against `[{}]`. (I.e. it hampers extensibility of the proposed JSON term syntax.) Moreover the other choice `{[{key, value}, ...]}` is marginally better than EEP-0018, because now it suggests that people can match an object by simply stating `is_tuple (JSON)`, which would make implementing extensions like the raw message one harder. The reason that I wrote this email is because I have invested quite some time in writing a "few" JSON utility functions (including complex schema validation, destructuring, etc.) which heavily use and extend the "mochi" variant. Based on this experience and a small analysis I've done today, I concluded that EEP-0018 would be quite cumbersome for expressing any kind of extension without a lot of pattern-matching to catch the extensions. However by no mean do I expect developers to change their libraries to suite such a usage, I only wanted to provide a counter-argument to EEP-0018. Moreover, now that Erlang has hash objects, hopefully these can be used to express objects, and this problem would go away. Hopefully I haven't offended anyone, (I apologize in advance,) Ciprian. [1] https://github.com/mochi/mochiweb/blob/master/src/mochijson2.erl [2] https://github.com/talentdeficit/jsx [3] https://github.com/davisp/jiffy [4] https://github.com/benoitc/ejson [5] https://github.com/iskra/jsonx [6] https://github.com/etrepum/kvc [7] https://github.com/eriksoe/valijate From mfidelman@REDACTED Tue Aug 26 23:33:11 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 26 Aug 2014 17:33:11 -0400 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: <53FCFD17.8040006@meetinghouse.net> Why am I reminded of Greenspun's tenth rule - particularly this common restatement: "Every sufficiently complex application/language/tool will either have to use Lisp or reinvent it the hard way." * *Where highly concurrent systems are concerned, substitute Erlang for Lisp. Lee Sylvester wrote: > My thoughts are simply that, where Erlang was designed from the ground > up to cater, Akka has been built on top of a platform that has not. > There is much that Erlang provides for free that just makes life > easy. Akka may do this, too, but since it?s built on the JVM, you?re > bound to run into some headaches. > > Lee > > > On 26 Aug 2014, at 20:34, Youngkin, Rich > wrote: > >> Hi all, >> >> I'm working on an application written in Erlang. In recent months >> there have been more and more questions questioning Erlang/OTP. >> There is general recognition that many of the Erlang/OTP's features >> (e.g., immutable state,supervision) are beneficial. The questions >> mostly revolve around availability of Erlang expertise and supporting >> libraries (e.g., Cassandra support just to name one whereas Akka has >> the entire JVM ecosystem available to it). Akka has been proposed as >> an alternative to Erlang. >> >> Googling around for good comparisons between Erlang and Akka hasn't >> turned up a lot of useful information, but there is some (e.g., >> http://stackoverflow.com/questions/4491039/how-does-akka-compare-to-erlang). >> >> I'd be interested if anyone in this community has any advice and/or >> opinions regarding Erlang vs. Akka. Anyone? >> >> Thanks, >> Rich >> _______________________________________________ >> 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 felixgallo@REDACTED Tue Aug 26 23:34:26 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Tue, 26 Aug 2014 14:34:26 -0700 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: Just from a teaching and retooling perspective, moving a programmer along the path from Java -> Scala -> Akka is on the surface more straightforward than moving that programmer from Java -> Erlang -> OTP -- many of the paradigms and supporting frameworks and tools are comfortably similar, and old code can just be linked in. That said, I've personally found that the sort of things for which you actually need Erlang or Akka tend to be such discontinuities against the curve of regular practice as to dwarf the effect of comfortable similarity, and that other, more major forcing functions come into play; and further, that anyone who can play in the world of those forcing functions can come to use Erlang or Akka or whatever else they need in the service of getting the code to work. So, like benchmarks, try it out in your specific use case and measure your results yourself. F. On Tue, Aug 26, 2014 at 2:20 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Tue, Aug 26, 2014 at 9:34 PM, Youngkin, Rich < > richard.youngkin@REDACTED> wrote: > >> Akka has been proposed as an alternative to Erlang. > > > What are the arguments for Akka, as opposed to the arguments for Erlang? > > Library availability is definitely a valid concern. Yet, any library in > any language will have errors and mistakes. A good point about Erlang is > that the occasionally bad library tend to hurt your program less for the > simple fact that proper isolation saves the day. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jj@REDACTED Wed Aug 27 11:34:12 2014 From: jj@REDACTED (Giovanni Giorgi) Date: Wed, 27 Aug 2014 11:34:12 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges. Anyway the questions I will do to myself will be: Team know-how For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there. Developement benefits Erlang immutable state is a big hit in the long run. On the other way, Java isolation is very strong. With OSGi frameworks you can even run different version of the SAME library side by side. For instance, new version of Eclipse can run in "compatibility mode" older plugin (with an old API). Also if a eclipse plugin crashes, the ide will not crash. Also JVM stability is very high. For this point of view, IBM has put in Java a lot of its know how about its experience as system-integrator. But do not need Java integration capability, Java could be a pain Performance: a tricky path Erlang scheduler is a plus in my opinion because it maximize resource usage even if your code is not very optimized: in Java/Ruby/PHP/Python this is simply not true and you will need to put a lot of effort to get similar performance. About garbage collection: Java is very strong in this area. Also the new G1, a low latency GC works very well: I use it on my IDEs to reduce GUI freeze. Anyway it is still not production ready (at least on jdk 1.7 you get core dumps from time to time). Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing. With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this. I do not know how much erlang is strong in this area so: do an ad hoc benchmark on your use cases on raw speed and troughput. Library availability Java ecosystem is big. In my opinion too big. If you have the right tool in erlang, give a plus to erlang. The reason is simple: SpringFramework is very very complex. IoC will slow down your developement, and I am not sure will pay its bill. So avoid all the hipe around Spring if you do not think you need it. When I search for erlang clients for some server I use, I find it with no problem, so I think Erlang ecosystem is quite mature. Again, look at your use cases. My two cents :) Il 2014-08-26 23:20 Jesper Louis Andersen ha scritto: > On Tue, Aug 26, 2014 at 9:34 PM, Youngkin, Rich wrote: > >> Akka has been proposed as an alternative to Erlang. > > What are the arguments for Akka, as opposed to the arguments for Erlang? > > Library availability is definitely a valid concern. Yet, any library in any language will have errors and mistakes. A good point about Erlang is that the occasionally bad library tend to hurt your program less for the simple fact that proper isolation saves the day. > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions [1] Links: ------ [1] http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.s.klishin@REDACTED Wed Aug 27 11:36:58 2014 From: michael.s.klishin@REDACTED (Michael Klishin) Date: Wed, 27 Aug 2014 13:36:58 +0400 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: ?On 27 August 2014 at 13:34:31, Giovanni Giorgi (jj@REDACTED) wrote: Not to troll but? > > For instance if I must set up a 60 pepole team, where can I find > the guys easier? Using Akka or Erlang? Neither. > I do not think there are > a very large base of Akka experts out of there. True for both. Also, a 60 people team in 2014? I hope you mean 12 teams of 5 or 6 teams of 10 at most. Some of which can use Java or what have you. -- @michaelklishin, github.com/michaelklishin From n.oxyde@REDACTED Wed Aug 27 11:53:34 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 27 Aug 2014 11:53:34 +0200 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: Message-ID: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Hello, EEP18 will probably never been implemented in OTP, and if it does, it will probably end up using maps to represent objects instead of tuples and lists. Remember that this EEP18 has been written long before maps were implemented. Regards, -- Anthony Ramine Le 26 ao?t 2014 ? 23:30, Ciprian Dorin Craciun a ?crit : > Today I've made a small attempt at finding a suitable JSON > encoding / decoding library that fit my needs. (Until now I was using > `mochijson2` [1], which seems to be rather old...) However the > current email is not about my requirements, or the found libraries, > but on the current direction the recent JSON libraries are heading > towards, namely how objects are encoded as `[{}] | list({string(), > json()})`. > > First of all a small survey about existing implementations: > * `mochijson2` [1] uses (what I call) "mochi", i.e. `{struct, > list({string(), json()})}`; > * `jsx` [2] uses EEP-0018, i.e. `[{}] | list({string(), json()})`; > * `jiffy` [3] uses EEP-0018; > * `ejson` [4] uses something in between "mochi" and EEP-0018, > namely `{list({string(), json()})}`; > * `jsonx` [5] uses "mochi"; > * `kvc` [6] (although a querier) uses either "mochi" or EEP-0018; > * `valijate` [7] (although only a validator) uses something > similar to "mochi"; > * others are either "mochi"-compliant or EEP-0018 compliant; > (many more seem to be EEP-0018 than "mochi";) > > Granted that EEP-0018 clearly states that a library could offer > the user the option to choose how the object is to be encoded as an > Erlang term (options A through F), and it could know how to correctly > interpret one as such. (Unfortunately none of the encoding / decoding > libraries do support this choice.) > > > At a first scratch there seems nothing wrong with either approach > (either "mochi" or EEP-0018). Except maybe the fact that when writing > a multi-headed pattern-matching function, in case of EEP-0018 one must > match first the list, then the object, or else the object might be > misinterpreted as a list. > > Although I do have to say that "mochi" does have a clearly > unambiguous way to detect the value type, that is almost impossible to > get wrong. But granted that deconstructing EEP-0018 compliant objects > with plain Erlang libraries (like `proplists`) is slightly more > straight-forward, because one can use the object value as a list, > whereas in "mochi" one would need to first extract the list, which > boils down to `Object` vs. `element(2, Object)`. > > Therefore why do I say EEP-0018 (and conforming libraries) are > wrong? (In fact so wrong that I felt the need to write such a lengthy > email?) Because when one wants to extend the proposed JSON term > syntax, or perhaps use it for something else (but still related to > JSON), things start to crumble. > > > Let's take for example `valijate` [7] which allows one to easily > validate (among others) JSON values with a simple schema. For example > one can say `{array, string}` to denote a schema which matches any > list made only of strings. > > One could write the `validate` function for EEP-0018 as: > > ~~~~ (not tested) > validate (List, {array, ElementSchema}) -> > case List of > [{}] -> false; > [Head | _] when is_tuple (Head) -> false; > _ when is_list (List) -> > lists:foldl( > fun (true, A) -> A; (false, _) -> false end, true, > lists:map (fun (Element) -> validate(Element, > ElementSchema) end, List)); > _ -> false; > end; > ~~~~ > > Compared with the following for "mochi": > > ~~~~ (not tested) > validate (List, {array, ElementSchema}) -> > if > is_list (List) -> > lists:foldl( > fun (true, A) -> A; (false, _) -> false end, true, > lists:map (fun (Element) -> validate(Element, > ElementSchema) end, List)); > true -> false > end; > ~~~~ > > No big issue so far, except a few extra matches (which could > become tiresome to write if we have more than one type of schema that > applies to lists). > > > Let's move a little bit further. Say we now want to be able to > write in `valijate` something like the following Erlang type: > `[list(string()), list(integer())]` (i.e. a list made of exactly two > elements, the first a list of strings, the second a list of integers). > Although I don't know how (or if) `valijate` is able to express this, > I would have expected something like this to work: > > [{array, string}, {array, integer}] > > Let's complicate it further and assume that we want to be able to > validate if a list is a set (i.e. non-repeating elements), and we > introduce a new schema type called `set`. Let's see how a schema > would look like for a list made of exactly two elements, the first an > array of strings, the second a set of integers: > > [{array, string}, {set, integer}] > > However, before writing the implementation, let's imagine how a > schema for an objects would look like. Assuming we want to keep as > close as possible to the original EEP-0018 proposed term syntax, one > could imagine something like this: > > * for an object with any number of attributes, whose keys and > values must independently match the given schemas (i.e. the expected > object behaves like a dictionary): > > [{, > * for an object with as many attributes as given by the tuples, > whose keys exactly match the given key literals (maybe in a different > order), and whose values match the given schemas (i.e. the expected > object behaves like a record): > > [{, , > }, ...] > > Let's try to give two examples: > * an object with any key, and a string as value (pick any): > [{string, string}] > [{any, string}] > * an object with exactly one key named either "string", or "any", > whose value is a string: > [{string, string}] > [{any, string}] > > Let's also try to provide the schema for an object with exactly > two attributes, one named `array` and with a string value, the second > named `set` with an integer value: > > [{array, string}, {set, integer}] > > Darn... I can't discern between the schema for a dictionary of > strings or the schema for a record with a single attribute named > "string" and a string value. Similarly I can't discern between the > schema for a two element array (one element a list, the other a set) > or a two attribute object one named "array", the other "set". > (Granted I can start complicating the schema syntax, but that would > get further from a "simple" approach where the schema resembles > closely the actual value.) > > > Let's see if "mochi" could do it: > * for a dictionary: > {object, {, * for a record: > {object, [{, * (an actual matching JSON would be encoded as:) > {object, [{, > For example: > {object, {string, string}} -- the string dictionary > {object, [{string, string}]} -- the record with a string attribute > {object, [{array, string}, {set, integer}]} -- the object with > "array" and "set" attributes > [{array, string}, {set, integer}] -- the list with an array of > strings and a set of integers > > > OK... Let's assume that the validation use-case is not of > interest, and we could live with a certain syntax for the JSON values > and another one for the schema. Fine! > > Say however that we want now to make a small extension to our > favourite JSON encoding library to better suit the following scenario: > we need to implement a small web-service which gets a JSON from > somewhere as a binary (maybe from a database or file), i.e. > <<"{...}">>, of which we are certain it is correctly encoded, thus we > don't need to parse it, and we need to "wrap" it into another JSON > which holds some meta-data, like for example `{"ok" : true, "outcome" > : }`. However as stated we would like > the to reuse our favourite JSON library to encode such a wrapper JSON, > but without first parsing the JSON binary. > > We could therefore extend the JSON library to allow us to put > inside JSON terms, values which are to be "pasted" directly in the > result (this is equivalent to the `RawMessage` from Go's JSON > library). > > However the question is how to flag these raw values? We > obviously can't use a binary as that is the representation of a > string. We could choose something like `{raw, <<"...">>}`. > > OK, let's now try to see how a list composed of a single element, > namely the raw JSON, would look like: > > [{raw, <<"...">>}] > > Doesn't that resemble an object with an attribute named "raw" and > a string as value? In EEP-0018 it surely does, but in "mochi" it > doesn't (that would be `{object, [{raw, <<"...">>}]}`). > > (Or maybe we want to be able to use records directly as JSON > values, tagged like `{record, }` which would call an > external formatter, or even simpler directly using `` > provided that it's tag isn't `object`. Or perhaps `{dict, > }`, `{gb_tree, }`, etc.) > > > I hope that the two given examples argument my case against > `[{}]`. (I.e. it hampers extensibility of the proposed JSON term > syntax.) > > > Moreover the other choice `{[{key, value}, ...]}` is marginally > better than EEP-0018, because now it suggests that people can match an > object by simply stating `is_tuple (JSON)`, which would make > implementing extensions like the raw message one harder. > > > The reason that I wrote this email is because I have invested > quite some time in writing a "few" JSON utility functions (including > complex schema validation, destructuring, etc.) which heavily use and > extend the "mochi" variant. Based on this experience and a small > analysis I've done today, I concluded that EEP-0018 would be quite > cumbersome for expressing any kind of extension without a lot of > pattern-matching to catch the extensions. However by no mean do I > expect developers to change their libraries to suite such a usage, I > only wanted to provide a counter-argument to EEP-0018. Moreover, now > that Erlang has hash objects, hopefully these can be used to express > objects, and this problem would go away. > > Hopefully I haven't offended anyone, (I apologize in advance,) > Ciprian. > > > [1] https://github.com/mochi/mochiweb/blob/master/src/mochijson2.erl > [2] https://github.com/talentdeficit/jsx > [3] https://github.com/davisp/jiffy > [4] https://github.com/benoitc/ejson > [5] https://github.com/iskra/jsonx > [6] https://github.com/etrepum/kvc > [7] https://github.com/eriksoe/valijate > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Wed Aug 27 11:55:29 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 27 Aug 2014 12:55:29 +0300 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: Hello, On 27 Aug 2014, at 12:34, Giovanni Giorgi wrote: > About garbage collection: Java is very strong in this area. Also the new G1, a low latency GC works very well Maybe G1 is has been designed to reduce GUI freeze but we had a serious issue in production due to G1 along with one Java library lately. In the nutshell, the system went crazy but consuming all CPU resource. As the result, Java dies but it also killed all Erlang nodes running on same HW. I would skip our internal Java - Erlang ping-pong but investigation shown that one of 3rd party library was not compatible with G1, it cause huge dirty heaps and garbage collection was instant operation? So, we swap GC and had fun with 800 tunables :-) and I would disagree that Java is very string in GC area, Erlang GC is many time superior in terms of latency. It has it own problems but they rare impact the overall system stability Best Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Aug 27 11:57:04 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 27 Aug 2014 12:57:04 +0300 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: <53FDAB70.3090506@ninenines.eu> On 08/27/2014 12:34 PM, Giovanni Giorgi wrote: > Team know-how > For instance if I must set up a 60 pepole team, where can I find the > guys easier? Using Akka or Erlang? I do not think there are a very large > base of Akka experts out of there. A 60 people Erlang team? Just buy Basho or one of the other semi large Erlang companies. Done. On the other hand if you *must* have a 60 people Erlang team *right now* I'm not sure what you're building. It's equivalent to needing a team of 300+ Java developers. I have no idea what kind of project you do with that kind of team. :-) > Erlang immutable state is a big hit in the long run. I'm not sure what you mean by that? > On the other way, Java isolation is very strong. With OSGi frameworks > you can even run different version of the SAME library side by side. For > instance, new version of Eclipse can run in "compatibility mode" older > plugin (with an old API). > Also if a eclipse plugin crashes, the ide will not crash. > Also JVM stability is very high. > For this point of view, IBM has put in Java a lot of its know how about > its experience as system-integrator. > But do not need Java integration capability, Java could be a pain Erlang has systems that have been running continuously for what, 15 years? It's nice that Java has some short term stability but it's pretty far from what Erlang can achieve. > Performance: a tricky path > > Erlang scheduler is a plus in my opinion because it maximize resource > usage even if your code is not very optimized: in Java/Ruby/PHP/Python > this is simply not true and you will need to put a lot of effort to get > similar performance. You can write shitty Erlang code, it's just harder because the language is a lot smaller and everything is explicit. Performance issues generally come from bad architecture decisions instead. > About garbage collection: Java is very strong in this area. Also the > new G1, a low latency GC works very well: I use it on my IDEs to > reduce GUI freeze. Anyway it is still not production ready (at least on > jdk 1.7 you get core dumps from time to time). What do you mean reduce GUI freeze? Why is there any freeze to begin with? How can you live with that? It's cool that Java tries to improve things but it'll never become as good as per process GC. > Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app > server can be tuned easily to avoid full GC /for days/, because > increment GC are "just fine" for the day by day processing. > With very huge heaps (hundres of GBs) you can have problems, and Red Hat > is pushing a new implementation to ovrecome this. See above. > I do not know how much erlang is strong in this area so: do an ad hoc > benchmark on your use cases on raw speed and troughput. Latency is a lot more important to 95% of applications (including your GUI example there, seriously how can you tolerate a freeze?) and Erlang is built for latency. You get low latency by default, regardless of the number of things happening. That's very powerful. Then you can also get throughput although that takes extra work. > Library availability > > Java ecosystem is big. In my opinion too big. If you have the right tool > in erlang, give a plus to erlang. > The reason is simple: SpringFramework is very very complex. > IoC will slow down your developement, and I am not sure will pay its bill. > So avoid all the hipe around Spring if you do not think you need it. > > When I search for erlang clients for some server I use, I find it with > no problem, so I think Erlang ecosystem is quite mature. I wouldn't say Erlang has a complete ecosystem although it's getting there. On the other hand it doesn't take very long to implement a missing library (either by writing it directly or interfacing with C code), and while it may sound like wasting your time, the things that Erlang makes easy (low latency, distribution, scalability, fault tolerance...) make you win a lot more time. -- Lo?c Hoguin http://ninenines.eu From ulf@REDACTED Wed Aug 27 13:53:34 2014 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 27 Aug 2014 13:53:34 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: On 27 Aug 2014, at 11:34, Giovanni Giorgi wrote: > Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges. > > Anyway the questions I will do to myself will be: > > Team know-how > For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there. > As others have pointed out, 60 people is a *huge* team for an Erlang project. I doubt you need that many unless you?re building a monster of an app. The AXD 301 team had roughly that many Erlang programmers for almost 2 million lines of Erlang code; arguably, it was too many people, but the list of requirements was really what drove the size of the project. Basically, look at how many people are needed to wrap their collective heads around the functional requirements. Those guys should all be programming, and you?re not likely to need many more programmers than that. > Erlang immutable state is a big hit in the long run. > On the contrary. The long run is where immutability pays off, mainly in two ways: - Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid. - Performance. It may sound weird, but immutability and acyclic data structures really help the memory management subsystem as well as simplify scaling across multiple cores. The area where it hurts is mostly core that has to sequentially run through large data sets, flipping bits or making other small modifications along the way - the Dijkstra Shortest Path First algorithm comes to mind. But if you?re building a complex system with lots of concurrency, immutability will keep you sane and help your applications scale. Performance losses in this class of systems, using conventional coding techniques, are often due to code complexity as much as anything else: you lose the ability to reason about how the code behaves, and all those fancy tricks that can help performance in smaller systems will only make things worse. But of course it depends on what kind of system you?re building. Erlang is very performant for the kinds of system that it was designed for. There are lots of stories about Erlang-based systems handling outright crazy loads compared to the competition. The Java story is not particularly good when it comes to multicore. You really have to know what you?re doing, or have a problem that is embarrassingly parallel. The main multicore problem in Erlang is that it?s hard to come by as many cores as you think you can utilize. ;-) > On the other way, Java isolation is very strong. > Actually, not compared to Erlang. The reason is shared (mutable) objects. If a thread crashes that shares data with other threads, you are basically lost. Since Erlang uses share-nothing concurrency with copying message passing, a dead process really doesn?t hurt the data of other processes, and can simply be swept away by the GC. > Also JVM stability is very high. > Granted. So is the stability of the Erlang VM. > Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing. > > With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this. > If you just measure the amount of manpower that has gone into Java GC, it should be far superior to the Erlang GC, but GC is a much, much harder problem in Java than it is in Erlang. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jj@REDACTED Wed Aug 27 14:08:12 2014 From: jj@REDACTED (Giovanni Giorgi) Date: Wed, 27 Aug 2014 14:08:12 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> Sorry, I want to say immutability is an advantage in the long run, and pays a lot. I had to debug for quite 12 hours an OOP C# product with ping/pong between objects slot (all a LINQ ORM attached). It was not fun, and I thinked "If I can get rid of these mutable VARIABLES....". And in Java/PHP/Python I found the same problem here and again. I tend to think this it is related to habit in imperative language. And when a program gets bigger, habits are difficult to avoid. By the way the "60" number was a bit exaggerated, to stress the fact you must understand the context constraints. In a lot of project I was forced to use tecnhology X instead of better Y because I have no guys knowing Y (and Y was Hibernate, by the way). In the post I will not trying to advocacy Java or Erlang, I was only trying to put on the carpet the biggest differences of the two Systems By the way, a holy war was on on my mind. Il 2014-08-27 13:53 Ulf Wiger ha scritto: > On 27 Aug 2014, at 11:34, Giovanni Giorgi wrote: > >> Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges. >> >> Anyway the questions I will do to myself will be: >> >> Team know-how >> For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there. > > As others have pointed out, 60 people is a *huge* team for an Erlang project. I doubt you need that many unless you're building a monster of an app. The AXD 301 team had roughly that many Erlang programmers for almost 2 million lines of Erlang code; arguably, it was too many people, but the list of requirements was really what drove the size of the project. Basically, look at how many people are needed to wrap their collective heads around the functional requirements. Those guys should all be programming, and you're not likely to need many more programmers than that. > >> Erlang immutable state is a big hit in the long run. > > On the contrary. The long run is where immutability pays off, mainly in two ways: > > - Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid. > > - Performance. It may sound weird, but immutability and acyclic data structures really help the memory management subsystem as well as simplify scaling across multiple cores. The area where it hurts is mostly core that has to sequentially run through large data sets, flipping bits or making other small modifications along the way - the Dijkstra Shortest Path First algorithm comes to mind. But if you're building a complex system with lots of concurrency, immutability will keep you sane and help your applications scale. Performance losses in this class of systems, using conventional coding techniques, are often due to code complexity as much as anything else: you lose the ability to reason about how the code behaves, and all those fancy tricks that can help performance in smaller systems will only make things worse. > > But of course it depends on what kind of system you're building. Erlang is very performant for the kinds of system that it was designed for. There are lots of stories about Erlang-based systems handling outright crazy loads compared to the competition. > > The Java story is not particularly good when it comes to multicore. You really have to know what you're doing, or have a problem that is embarrassingly parallel. The main multicore problem in Erlang is that it's hard to come by as many cores as you think you can utilize. ;-) > >> On the other way, Java isolation is very strong. > > Actually, not compared to Erlang. The reason is shared (mutable) objects. If a thread crashes that shares data with other threads, you are basically lost. > > Since Erlang uses share-nothing concurrency with copying message passing, a dead process really doesn't hurt the data of other processes, and can simply be swept away by the GC. > >> Also JVM stability is very high. > > Granted. So is the stability of the Erlang VM. > >> Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing. >> >> With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this. > > If you just measure the amount of manpower that has gone into Java GC, it should be far superior to the Erlang GC, but GC is a much, much harder problem in Java than it is in Erlang. > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com [1] Links: ------ [1] http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Wed Aug 27 15:33:30 2014 From: zxq9@REDACTED (zxq9) Date: Wed, 27 Aug 2014 22:33:30 +0900 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: <1540524.u6sXjIbg1u@jalapeno> On Tuesday 26 August 2014 14:34:26 Felix Gallo wrote: > ... and further, > that anyone who can play in the world of those forcing functions can come > to use Erlang or Akka or whatever else they need in the service of getting > the code to work. IMO, Felix has here made the most important statement about the actual state of langX vs langY debates with regard to the developer side of the equation -- which, also in my opinion, is of the greatest importance. From g@REDACTED Wed Aug 27 16:00:47 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 27 Aug 2014 09:00:47 -0500 Subject: [erlang-questions] [ANN] Lambda Pad - Erlang based static site generator, FTW! Message-ID: I'm excited to announce that Erlang now has its very own static site generator! http://lambdapad.io Why and who cares? This was motivated by my frustration with Hyde and Jekyll in being hard to use, at least for me because I'm impatient and easily confused. I want a tool that is straight-forwarder. I want to use this for any conceivable static site content, including my blog, product documentation, and slide presentations. So far Lambda Pad is used for these two sites: http://chicagoerlang.com http://lambdapad.io It's still rough and missing features, but it's functional enough even now to be quite useful. Speaking of functional, you write your config and custom code in Erlang! No YAML here. Straight-forwarder. So check it. Use it. Break it and bend it to your will and send those pull requests! This is a project for the Erlang community -- anyone so inclined is most welcome as a contributor. Garrett -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Aug 27 16:07:59 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 27 Aug 2014 16:07:59 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> Message-ID: On Wed, Aug 27, 2014 at 1:53 PM, Ulf Wiger wrote: > - Software quality: Immutability basically goes together with referential > transparency, and you should aim to write as many functions as possible in > a side-effect free way. Once such a function has been debugged and works > correctly, it *stays* correct, until the requirements change. For this > reason, legacy Erlang code can truly become rock-solid. I've had the same experience in three projects now of larger size: Once your Erlang system is up and running and you weeded out the most glaring bugs, the system becomes rock solid. In all three projects, the requirements are set in stone and won't change right away[0]. All three systems has been running for months now, with no intervention. And they all process around 20-30 requests per second. One particular system has been doing this for over a year without any intervention, no reboot. Subsystems around the Erlang systems have died left and right, but the Erlang-systems themselves do not care about such misbehaviours. They automatically recover once the subsystems become healthy again. I have a hunch that this property is also making Erlang programmers more productive: Once your system is written, there is very little to maintain. So your programmers go off and does more productive stuff. In a world where the system keeps failing, you reset the programmer back to that system again and again. This hampers productivity in the long run. [0] This is one of the ways you know you got the design right. You can isolate the parts of the system which has to change from the parts of the system which don't. When this works, things fall out really well usually. Everything hinges on getting the specification right so you can figure out what parts of the system needs to change going forward. And then freeze/lock down the parts that don't, preferably with property based testing. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darach@REDACTED Wed Aug 27 17:13:30 2014 From: darach@REDACTED (Darach Ennis) Date: Wed, 27 Aug 2014 16:13:30 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: An aside on proper isolation: This is actually available in the Waratek implementation of the JVM and should be standardized in the JDK9 timeframe. Essentially this adds an interpretation of process isolation not dissimilar to that found in Erlang but on the JVM. IBM's J9 has a preview of multi-tenant java as well: http://www.ibm.com/developerworks/java/library/j-multitenant-java/index.html?ca=drs- For folk on the JVM, say you have nice 48 core machine and you have 48 clients running tomcat. What you do not want is 48 JVM instances running tomcat on that machine. Multi-tenant Java adds virtualization and process isolation such that you can run one JVM instance and essentially 'share' a single tomcat instance to 48 tenants, each pinned to a core, or perhaps fixed to some cores and time sharing other cores during burst periods etc.. This is great for things like corralling legacy JVM-based environments onto a single box to save operational cost or for consolidating resource usage to maximise utilisation and so on. The virtualization is basically transparent to the tenants and the hosts can meter based on kWh or bandwidth sent/received etc.. It is possible to monitor (supervise) and to control tenants in much the same way as in OTP based applications with multi-tenant JVM implementations. In Waratek's case this can be done via a JMX based API. But, multi-tenant JVMs with proper process isolation are new and easy to use APIs for monitoring, supervision and control are yet to be defined and standardised. I would add to this that the Erlang model is far simpler, just works and feels natural. It feels like voodoo on the JVM, frankly... But 'proper isolation' as a feature is coming to the JVM and the Erlang model is providing a source of inspiration here as it has already solved this particular problem within its own ecosystem. It has been successful enough that it is influencing innovation within the JVM ecosystem, specifically w.r.t. multi-tenancy which is becoming increasingly important in JVM deployments as Java loses ground to dynamic languages in cloud-based *aaS environments. Cheers, Darach. On Tue, Aug 26, 2014 at 10:20 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Tue, Aug 26, 2014 at 9:34 PM, Youngkin, Rich < > richard.youngkin@REDACTED> wrote: > >> Akka has been proposed as an alternative to Erlang. > > > What are the arguments for Akka, as opposed to the arguments for Erlang? > > Library availability is definitely a valid concern. Yet, any library in > any language will have errors and mistakes. A good point about Erlang is > that the occasionally bad library tend to hurt your program less for the > simple fact that proper isolation saves the day. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daocuong@REDACTED Wed Aug 27 17:07:41 2014 From: daocuong@REDACTED (DAO CUONG) Date: Wed, 27 Aug 2014 11:07:41 -0400 Subject: [erlang-questions] XMPP sync messages between devices Message-ID: Hi guys Im interested in to learn how what app and erlang xmpp frameworks handle the case need to sync messages between devices Please let me know any resources i could read related to this topic Best Dao Cuong -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Wed Aug 27 19:31:07 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 27 Aug 2014 12:31:07 -0500 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: Jiffy doesn't use the EEP18 object representation. It shares the same representation as ejson (namely, a 1-tuple containing a list of 0 or more 2-tuples). Historically, this is based off mochijson2's {struct, [{key(), value()}]} approach. It was decided that the struct atom was superfluous so it got dropped. I dunno about the other mochijson2-style libraries, but mochijson2 at least has an object hook to strip that struct tag if desired. On Wed, Aug 27, 2014 at 4:53 AM, Anthony Ramine wrote: > Hello, > > EEP18 will probably never been implemented in OTP, and if it does, it will probably end up using maps to represent objects instead of tuples and lists. Remember that this EEP18 has been written long before maps were implemented. > > Regards, > > -- > Anthony Ramine > > Le 26 ao?t 2014 ? 23:30, Ciprian Dorin Craciun a ?crit : > >> Today I've made a small attempt at finding a suitable JSON >> encoding / decoding library that fit my needs. (Until now I was using >> `mochijson2` [1], which seems to be rather old...) However the >> current email is not about my requirements, or the found libraries, >> but on the current direction the recent JSON libraries are heading >> towards, namely how objects are encoded as `[{}] | list({string(), >> json()})`. >> >> First of all a small survey about existing implementations: >> * `mochijson2` [1] uses (what I call) "mochi", i.e. `{struct, >> list({string(), json()})}`; >> * `jsx` [2] uses EEP-0018, i.e. `[{}] | list({string(), json()})`; >> * `jiffy` [3] uses EEP-0018; >> * `ejson` [4] uses something in between "mochi" and EEP-0018, >> namely `{list({string(), json()})}`; >> * `jsonx` [5] uses "mochi"; >> * `kvc` [6] (although a querier) uses either "mochi" or EEP-0018; >> * `valijate` [7] (although only a validator) uses something >> similar to "mochi"; >> * others are either "mochi"-compliant or EEP-0018 compliant; >> (many more seem to be EEP-0018 than "mochi";) >> >> Granted that EEP-0018 clearly states that a library could offer >> the user the option to choose how the object is to be encoded as an >> Erlang term (options A through F), and it could know how to correctly >> interpret one as such. (Unfortunately none of the encoding / decoding >> libraries do support this choice.) >> >> >> At a first scratch there seems nothing wrong with either approach >> (either "mochi" or EEP-0018). Except maybe the fact that when writing >> a multi-headed pattern-matching function, in case of EEP-0018 one must >> match first the list, then the object, or else the object might be >> misinterpreted as a list. >> >> Although I do have to say that "mochi" does have a clearly >> unambiguous way to detect the value type, that is almost impossible to >> get wrong. But granted that deconstructing EEP-0018 compliant objects >> with plain Erlang libraries (like `proplists`) is slightly more >> straight-forward, because one can use the object value as a list, >> whereas in "mochi" one would need to first extract the list, which >> boils down to `Object` vs. `element(2, Object)`. >> >> Therefore why do I say EEP-0018 (and conforming libraries) are >> wrong? (In fact so wrong that I felt the need to write such a lengthy >> email?) Because when one wants to extend the proposed JSON term >> syntax, or perhaps use it for something else (but still related to >> JSON), things start to crumble. >> >> >> Let's take for example `valijate` [7] which allows one to easily >> validate (among others) JSON values with a simple schema. For example >> one can say `{array, string}` to denote a schema which matches any >> list made only of strings. >> >> One could write the `validate` function for EEP-0018 as: >> >> ~~~~ (not tested) >> validate (List, {array, ElementSchema}) -> >> case List of >> [{}] -> false; >> [Head | _] when is_tuple (Head) -> false; >> _ when is_list (List) -> >> lists:foldl( >> fun (true, A) -> A; (false, _) -> false end, true, >> lists:map (fun (Element) -> validate(Element, >> ElementSchema) end, List)); >> _ -> false; >> end; >> ~~~~ >> >> Compared with the following for "mochi": >> >> ~~~~ (not tested) >> validate (List, {array, ElementSchema}) -> >> if >> is_list (List) -> >> lists:foldl( >> fun (true, A) -> A; (false, _) -> false end, true, >> lists:map (fun (Element) -> validate(Element, >> ElementSchema) end, List)); >> true -> false >> end; >> ~~~~ >> >> No big issue so far, except a few extra matches (which could >> become tiresome to write if we have more than one type of schema that >> applies to lists). >> >> >> Let's move a little bit further. Say we now want to be able to >> write in `valijate` something like the following Erlang type: >> `[list(string()), list(integer())]` (i.e. a list made of exactly two >> elements, the first a list of strings, the second a list of integers). >> Although I don't know how (or if) `valijate` is able to express this, >> I would have expected something like this to work: >> >> [{array, string}, {array, integer}] >> >> Let's complicate it further and assume that we want to be able to >> validate if a list is a set (i.e. non-repeating elements), and we >> introduce a new schema type called `set`. Let's see how a schema >> would look like for a list made of exactly two elements, the first an >> array of strings, the second a set of integers: >> >> [{array, string}, {set, integer}] >> >> However, before writing the implementation, let's imagine how a >> schema for an objects would look like. Assuming we want to keep as >> close as possible to the original EEP-0018 proposed term syntax, one >> could imagine something like this: >> >> * for an object with any number of attributes, whose keys and >> values must independently match the given schemas (i.e. the expected >> object behaves like a dictionary): >> >> [{, > >> * for an object with as many attributes as given by the tuples, >> whose keys exactly match the given key literals (maybe in a different >> order), and whose values match the given schemas (i.e. the expected >> object behaves like a record): >> >> [{, , >> }, ...] >> >> Let's try to give two examples: >> * an object with any key, and a string as value (pick any): >> [{string, string}] >> [{any, string}] >> * an object with exactly one key named either "string", or "any", >> whose value is a string: >> [{string, string}] >> [{any, string}] >> >> Let's also try to provide the schema for an object with exactly >> two attributes, one named `array` and with a string value, the second >> named `set` with an integer value: >> >> [{array, string}, {set, integer}] >> >> Darn... I can't discern between the schema for a dictionary of >> strings or the schema for a record with a single attribute named >> "string" and a string value. Similarly I can't discern between the >> schema for a two element array (one element a list, the other a set) >> or a two attribute object one named "array", the other "set". >> (Granted I can start complicating the schema syntax, but that would >> get further from a "simple" approach where the schema resembles >> closely the actual value.) >> >> >> Let's see if "mochi" could do it: >> * for a dictionary: >> {object, {, > * for a record: >> {object, [{, > * (an actual matching JSON would be encoded as:) >> {object, [{, > >> For example: >> {object, {string, string}} -- the string dictionary >> {object, [{string, string}]} -- the record with a string attribute >> {object, [{array, string}, {set, integer}]} -- the object with >> "array" and "set" attributes >> [{array, string}, {set, integer}] -- the list with an array of >> strings and a set of integers >> >> >> OK... Let's assume that the validation use-case is not of >> interest, and we could live with a certain syntax for the JSON values >> and another one for the schema. Fine! >> >> Say however that we want now to make a small extension to our >> favourite JSON encoding library to better suit the following scenario: >> we need to implement a small web-service which gets a JSON from >> somewhere as a binary (maybe from a database or file), i.e. >> <<"{...}">>, of which we are certain it is correctly encoded, thus we >> don't need to parse it, and we need to "wrap" it into another JSON >> which holds some meta-data, like for example `{"ok" : true, "outcome" >> : }`. However as stated we would like >> the to reuse our favourite JSON library to encode such a wrapper JSON, >> but without first parsing the JSON binary. >> >> We could therefore extend the JSON library to allow us to put >> inside JSON terms, values which are to be "pasted" directly in the >> result (this is equivalent to the `RawMessage` from Go's JSON >> library). >> >> However the question is how to flag these raw values? We >> obviously can't use a binary as that is the representation of a >> string. We could choose something like `{raw, <<"...">>}`. >> >> OK, let's now try to see how a list composed of a single element, >> namely the raw JSON, would look like: >> >> [{raw, <<"...">>}] >> >> Doesn't that resemble an object with an attribute named "raw" and >> a string as value? In EEP-0018 it surely does, but in "mochi" it >> doesn't (that would be `{object, [{raw, <<"...">>}]}`). >> >> (Or maybe we want to be able to use records directly as JSON >> values, tagged like `{record, }` which would call an >> external formatter, or even simpler directly using `` >> provided that it's tag isn't `object`. Or perhaps `{dict, >> }`, `{gb_tree, }`, etc.) >> >> >> I hope that the two given examples argument my case against >> `[{}]`. (I.e. it hampers extensibility of the proposed JSON term >> syntax.) >> >> >> Moreover the other choice `{[{key, value}, ...]}` is marginally >> better than EEP-0018, because now it suggests that people can match an >> object by simply stating `is_tuple (JSON)`, which would make >> implementing extensions like the raw message one harder. >> >> >> The reason that I wrote this email is because I have invested >> quite some time in writing a "few" JSON utility functions (including >> complex schema validation, destructuring, etc.) which heavily use and >> extend the "mochi" variant. Based on this experience and a small >> analysis I've done today, I concluded that EEP-0018 would be quite >> cumbersome for expressing any kind of extension without a lot of >> pattern-matching to catch the extensions. However by no mean do I >> expect developers to change their libraries to suite such a usage, I >> only wanted to provide a counter-argument to EEP-0018. Moreover, now >> that Erlang has hash objects, hopefully these can be used to express >> objects, and this problem would go away. >> >> Hopefully I haven't offended anyone, (I apologize in advance,) >> Ciprian. >> >> >> [1] https://github.com/mochi/mochiweb/blob/master/src/mochijson2.erl >> [2] https://github.com/talentdeficit/jsx >> [3] https://github.com/davisp/jiffy >> [4] https://github.com/benoitc/ejson >> [5] https://github.com/iskra/jsonx >> [6] https://github.com/etrepum/kvc >> [7] https://github.com/eriksoe/valijate >> _______________________________________________ >> 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 bob@REDACTED Wed Aug 27 19:40:20 2014 From: bob@REDACTED (Bob Ippolito) Date: Wed, 27 Aug 2014 10:40:20 -0700 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: If there was a mochijson3 it would surely use maps rather than {struct, proplist()}. Perhaps EEP18 should be amended for Erlang 17? For some historical context: the mochijson format is the same as the yaws JSON format. mochijson2 switched the representation for text from strings to binary and which allowed me to drop the type tag for array. The {struct, proplist()} representation was simply inherited and I never thought much about changing it because it worked well enough. On Wed, Aug 27, 2014 at 2:53 AM, Anthony Ramine wrote: > Hello, > > EEP18 will probably never been implemented in OTP, and if it does, it will > probably end up using maps to represent objects instead of tuples and > lists. Remember that this EEP18 has been written long before maps were > implemented. > > Regards, > > -- > Anthony Ramine > > Le 26 ao?t 2014 ? 23:30, Ciprian Dorin Craciun > a ?crit : > > > Today I've made a small attempt at finding a suitable JSON > > encoding / decoding library that fit my needs. (Until now I was using > > `mochijson2` [1], which seems to be rather old...) However the > > current email is not about my requirements, or the found libraries, > > but on the current direction the recent JSON libraries are heading > > towards, namely how objects are encoded as `[{}] | list({string(), > > json()})`. > > > > First of all a small survey about existing implementations: > > * `mochijson2` [1] uses (what I call) "mochi", i.e. `{struct, > > list({string(), json()})}`; > > * `jsx` [2] uses EEP-0018, i.e. `[{}] | list({string(), json()})`; > > * `jiffy` [3] uses EEP-0018; > > * `ejson` [4] uses something in between "mochi" and EEP-0018, > > namely `{list({string(), json()})}`; > > * `jsonx` [5] uses "mochi"; > > * `kvc` [6] (although a querier) uses either "mochi" or EEP-0018; > > * `valijate` [7] (although only a validator) uses something > > similar to "mochi"; > > * others are either "mochi"-compliant or EEP-0018 compliant; > > (many more seem to be EEP-0018 than "mochi";) > > > > Granted that EEP-0018 clearly states that a library could offer > > the user the option to choose how the object is to be encoded as an > > Erlang term (options A through F), and it could know how to correctly > > interpret one as such. (Unfortunately none of the encoding / decoding > > libraries do support this choice.) > > > > > > At a first scratch there seems nothing wrong with either approach > > (either "mochi" or EEP-0018). Except maybe the fact that when writing > > a multi-headed pattern-matching function, in case of EEP-0018 one must > > match first the list, then the object, or else the object might be > > misinterpreted as a list. > > > > Although I do have to say that "mochi" does have a clearly > > unambiguous way to detect the value type, that is almost impossible to > > get wrong. But granted that deconstructing EEP-0018 compliant objects > > with plain Erlang libraries (like `proplists`) is slightly more > > straight-forward, because one can use the object value as a list, > > whereas in "mochi" one would need to first extract the list, which > > boils down to `Object` vs. `element(2, Object)`. > > > > Therefore why do I say EEP-0018 (and conforming libraries) are > > wrong? (In fact so wrong that I felt the need to write such a lengthy > > email?) Because when one wants to extend the proposed JSON term > > syntax, or perhaps use it for something else (but still related to > > JSON), things start to crumble. > > > > > > Let's take for example `valijate` [7] which allows one to easily > > validate (among others) JSON values with a simple schema. For example > > one can say `{array, string}` to denote a schema which matches any > > list made only of strings. > > > > One could write the `validate` function for EEP-0018 as: > > > > ~~~~ (not tested) > > validate (List, {array, ElementSchema}) -> > > case List of > > [{}] -> false; > > [Head | _] when is_tuple (Head) -> false; > > _ when is_list (List) -> > > lists:foldl( > > fun (true, A) -> A; (false, _) -> false end, true, > > lists:map (fun (Element) -> validate(Element, > > ElementSchema) end, List)); > > _ -> false; > > end; > > ~~~~ > > > > Compared with the following for "mochi": > > > > ~~~~ (not tested) > > validate (List, {array, ElementSchema}) -> > > if > > is_list (List) -> > > lists:foldl( > > fun (true, A) -> A; (false, _) -> false end, true, > > lists:map (fun (Element) -> validate(Element, > > ElementSchema) end, List)); > > true -> false > > end; > > ~~~~ > > > > No big issue so far, except a few extra matches (which could > > become tiresome to write if we have more than one type of schema that > > applies to lists). > > > > > > Let's move a little bit further. Say we now want to be able to > > write in `valijate` something like the following Erlang type: > > `[list(string()), list(integer())]` (i.e. a list made of exactly two > > elements, the first a list of strings, the second a list of integers). > > Although I don't know how (or if) `valijate` is able to express this, > > I would have expected something like this to work: > > > > [{array, string}, {array, integer}] > > > > Let's complicate it further and assume that we want to be able to > > validate if a list is a set (i.e. non-repeating elements), and we > > introduce a new schema type called `set`. Let's see how a schema > > would look like for a list made of exactly two elements, the first an > > array of strings, the second a set of integers: > > > > [{array, string}, {set, integer}] > > > > However, before writing the implementation, let's imagine how a > > schema for an objects would look like. Assuming we want to keep as > > close as possible to the original EEP-0018 proposed term syntax, one > > could imagine something like this: > > > > * for an object with any number of attributes, whose keys and > > values must independently match the given schemas (i.e. the expected > > object behaves like a dictionary): > > > > [{, > > > * for an object with as many attributes as given by the tuples, > > whose keys exactly match the given key literals (maybe in a different > > order), and whose values match the given schemas (i.e. the expected > > object behaves like a record): > > > > [{, , > > }, ...] > > > > Let's try to give two examples: > > * an object with any key, and a string as value (pick any): > > [{string, string}] > > [{any, string}] > > * an object with exactly one key named either "string", or "any", > > whose value is a string: > > [{string, string}] > > [{any, string}] > > > > Let's also try to provide the schema for an object with exactly > > two attributes, one named `array` and with a string value, the second > > named `set` with an integer value: > > > > [{array, string}, {set, integer}] > > > > Darn... I can't discern between the schema for a dictionary of > > strings or the schema for a record with a single attribute named > > "string" and a string value. Similarly I can't discern between the > > schema for a two element array (one element a list, the other a set) > > or a two attribute object one named "array", the other "set". > > (Granted I can start complicating the schema syntax, but that would > > get further from a "simple" approach where the schema resembles > > closely the actual value.) > > > > > > Let's see if "mochi" could do it: > > * for a dictionary: > > {object, {, > * for a record: > > {object, [{, > * (an actual matching JSON would be encoded as:) > > {object, [{, > > > For example: > > {object, {string, string}} -- the string dictionary > > {object, [{string, string}]} -- the record with a string attribute > > {object, [{array, string}, {set, integer}]} -- the object with > > "array" and "set" attributes > > [{array, string}, {set, integer}] -- the list with an array of > > strings and a set of integers > > > > > > OK... Let's assume that the validation use-case is not of > > interest, and we could live with a certain syntax for the JSON values > > and another one for the schema. Fine! > > > > Say however that we want now to make a small extension to our > > favourite JSON encoding library to better suit the following scenario: > > we need to implement a small web-service which gets a JSON from > > somewhere as a binary (maybe from a database or file), i.e. > > <<"{...}">>, of which we are certain it is correctly encoded, thus we > > don't need to parse it, and we need to "wrap" it into another JSON > > which holds some meta-data, like for example `{"ok" : true, "outcome" > > : }`. However as stated we would like > > the to reuse our favourite JSON library to encode such a wrapper JSON, > > but without first parsing the JSON binary. > > > > We could therefore extend the JSON library to allow us to put > > inside JSON terms, values which are to be "pasted" directly in the > > result (this is equivalent to the `RawMessage` from Go's JSON > > library). > > > > However the question is how to flag these raw values? We > > obviously can't use a binary as that is the representation of a > > string. We could choose something like `{raw, <<"...">>}`. > > > > OK, let's now try to see how a list composed of a single element, > > namely the raw JSON, would look like: > > > > [{raw, <<"...">>}] > > > > Doesn't that resemble an object with an attribute named "raw" and > > a string as value? In EEP-0018 it surely does, but in "mochi" it > > doesn't (that would be `{object, [{raw, <<"...">>}]}`). > > > > (Or maybe we want to be able to use records directly as JSON > > values, tagged like `{record, }` which would call an > > external formatter, or even simpler directly using `` > > provided that it's tag isn't `object`. Or perhaps `{dict, > > }`, `{gb_tree, }`, etc.) > > > > > > I hope that the two given examples argument my case against > > `[{}]`. (I.e. it hampers extensibility of the proposed JSON term > > syntax.) > > > > > > Moreover the other choice `{[{key, value}, ...]}` is marginally > > better than EEP-0018, because now it suggests that people can match an > > object by simply stating `is_tuple (JSON)`, which would make > > implementing extensions like the raw message one harder. > > > > > > The reason that I wrote this email is because I have invested > > quite some time in writing a "few" JSON utility functions (including > > complex schema validation, destructuring, etc.) which heavily use and > > extend the "mochi" variant. Based on this experience and a small > > analysis I've done today, I concluded that EEP-0018 would be quite > > cumbersome for expressing any kind of extension without a lot of > > pattern-matching to catch the extensions. However by no mean do I > > expect developers to change their libraries to suite such a usage, I > > only wanted to provide a counter-argument to EEP-0018. Moreover, now > > that Erlang has hash objects, hopefully these can be used to express > > objects, and this problem would go away. > > > > Hopefully I haven't offended anyone, (I apologize in advance,) > > Ciprian. > > > > > > [1] https://github.com/mochi/mochiweb/blob/master/src/mochijson2.erl > > [2] https://github.com/talentdeficit/jsx > > [3] https://github.com/davisp/jiffy > > [4] https://github.com/benoitc/ejson > > [5] https://github.com/iskra/jsonx > > [6] https://github.com/etrepum/kvc > > [7] https://github.com/eriksoe/valijate > > _______________________________________________ > > 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 josh.rubyist@REDACTED Wed Aug 27 20:03:29 2014 From: josh.rubyist@REDACTED (Josh Adams) Date: Wed, 27 Aug 2014 13:03:29 -0500 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: On Wed, Aug 27, 2014 at 12:40 PM, Bob Ippolito wrote: > If there was a mochijson3 it would surely use maps rather than {struct, > proplist()}. Perhaps EEP18 should be amended for Erlang 17? > I would assume this isn't true until maps are fast with a large number of keys though...would that be accurate? I definitely have plenty of json use cases that would likely perform poorly until that change occurs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Aug 27 20:21:32 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 14:21:32 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples Message-ID: Tuples are clearly unnecessary and a wart in Erlang's design. Consider all the operations tuples provide: Construction: X = {A,B,C} Destruction: {A,B,C} = X Pattern matching: case X of {foo,B,C} -> ... end Note now that these operations are provided equally by lists: Construction: X = [A,B,C] Destruction: [A,B,C] = X Pattern matching: case X of [foo,B,C] -> ... end And note that lists provide the additional functionality of indexing and consing, which tuples do not provide. Clearly, using tuples instead of lists provides no benefit, and to simplify the language they should be deprecated in OTP 18, and removed by OTP 19. To support this transition, a compiler option can be provided to maintain the ill-conceived tuple notation for legacy code; may I suggest +distinguish_homogenous_and_heterogenous_collections. Now, surely detractors will claim that the distinction between tuples and lists signals programmer intent, permits bytecode optimization, and enables rich typechecking in Dialyzer. I claim these purported benefits are bollocks. I, and no doubt others, routinely find the need to iterate over tuple elements, and to store unrelated data together in a single list. Anyone who claims that such things are not necessary clearly has not ever written a complex program. (I suspect anyone who thinks structurally-typed records and key-value maps serve different purposes falls into this group.) I hope you all agree, and that we can look forward to a future Erlang supporting lists and maps as its sole data constructors. - Chris P From n.oxyde@REDACTED Wed Aug 27 20:34:20 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 27 Aug 2014 20:34:20 +0200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> Are we 1st April already? I didn?t implement yet my patch to make tuples 0-indexed. :( But well, that is overseded by your proposal. -- Anthony Ramine Le 27 ao?t 2014 ? 20:21, Chris Pacejo a ?crit : > Tuples are clearly unnecessary and a wart in Erlang's design. > Consider all the operations tuples provide: > > Construction: X = {A,B,C} > Destruction: {A,B,C} = X > Pattern matching: case X of {foo,B,C} -> ... end > > Note now that these operations are provided equally by lists: > > Construction: X = [A,B,C] > Destruction: [A,B,C] = X > Pattern matching: case X of [foo,B,C] -> ... end > > And note that lists provide the additional functionality of indexing > and consing, which tuples do not provide. > > Clearly, using tuples instead of lists provides no benefit, and to > simplify the language they should be deprecated in OTP 18, and removed > by OTP 19. To support this transition, a compiler option can be > provided to maintain the ill-conceived tuple notation for legacy code; > may I suggest +distinguish_homogenous_and_heterogenous_collections. > > Now, surely detractors will claim that the distinction between tuples > and lists signals programmer intent, permits bytecode optimization, > and enables rich typechecking in Dialyzer. I claim these purported > benefits are bollocks. I, and no doubt others, routinely find the > need to iterate over tuple elements, and to store unrelated data > together in a single list. Anyone who claims that such things are not > necessary clearly has not ever written a complex program. (I suspect > anyone who thinks structurally-typed records and key-value maps serve > different purposes falls into this group.) > > I hope you all agree, and that we can look forward to a future Erlang > supporting lists and maps as its sole data constructors. > > - Chris P > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Wed Aug 27 20:37:15 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 27 Aug 2014 21:37:15 +0300 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: Hello, There is a different memory model for tuples and lists. Tuples are more efficient to access random element while list requires iteration. I would not be brave to drop them completely. BTW, when I am writing a program in other languages, I am so missing tuples... Best Regards, Dmitry >-|-|-(*> > On 27 Aug 2014, at 21:21, Chris Pacejo wrote: > > Tuples are clearly unnecessary and a wart in Erlang's design. > Consider all the operations tuples provide: > > Construction: X = {A,B,C} > Destruction: {A,B,C} = X > Pattern matching: case X of {foo,B,C} -> ... end > > Note now that these operations are provided equally by lists: > > Construction: X = [A,B,C] > Destruction: [A,B,C] = X > Pattern matching: case X of [foo,B,C] -> ... end > > And note that lists provide the additional functionality of indexing > and consing, which tuples do not provide. > > Clearly, using tuples instead of lists provides no benefit, and to > simplify the language they should be deprecated in OTP 18, and removed > by OTP 19. To support this transition, a compiler option can be > provided to maintain the ill-conceived tuple notation for legacy code; > may I suggest +distinguish_homogenous_and_heterogenous_collections. > > Now, surely detractors will claim that the distinction between tuples > and lists signals programmer intent, permits bytecode optimization, > and enables rich typechecking in Dialyzer. I claim these purported > benefits are bollocks. I, and no doubt others, routinely find the > need to iterate over tuple elements, and to store unrelated data > together in a single list. Anyone who claims that such things are not > necessary clearly has not ever written a complex program. (I suspect > anyone who thinks structurally-typed records and key-value maps serve > different purposes falls into this group.) > > I hope you all agree, and that we can look forward to a future Erlang > supporting lists and maps as its sole data constructors. > > - Chris P > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sean@REDACTED Wed Aug 27 20:40:25 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 27 Aug 2014 13:40:25 -0500 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> References: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> Message-ID: Must be April 1 somewhere. On Wed, Aug 27, 2014 at 1:34 PM, Anthony Ramine wrote: > Are we 1st April already? I didn?t implement yet my patch to make tuples 0-indexed. :( > > But well, that is overseded by your proposal. > > -- > Anthony Ramine > > Le 27 ao?t 2014 ? 20:21, Chris Pacejo a ?crit : > >> Tuples are clearly unnecessary and a wart in Erlang's design. >> Consider all the operations tuples provide: >> >> Construction: X = {A,B,C} >> Destruction: {A,B,C} = X >> Pattern matching: case X of {foo,B,C} -> ... end >> >> Note now that these operations are provided equally by lists: >> >> Construction: X = [A,B,C] >> Destruction: [A,B,C] = X >> Pattern matching: case X of [foo,B,C] -> ... end >> >> And note that lists provide the additional functionality of indexing >> and consing, which tuples do not provide. >> >> Clearly, using tuples instead of lists provides no benefit, and to >> simplify the language they should be deprecated in OTP 18, and removed >> by OTP 19. To support this transition, a compiler option can be >> provided to maintain the ill-conceived tuple notation for legacy code; >> may I suggest +distinguish_homogenous_and_heterogenous_collections. >> >> Now, surely detractors will claim that the distinction between tuples >> and lists signals programmer intent, permits bytecode optimization, >> and enables rich typechecking in Dialyzer. I claim these purported >> benefits are bollocks. I, and no doubt others, routinely find the >> need to iterate over tuple elements, and to store unrelated data >> together in a single list. Anyone who claims that such things are not >> necessary clearly has not ever written a complex program. (I suspect >> anyone who thinks structurally-typed records and key-value maps serve >> different purposes falls into this group.) >> >> I hope you all agree, and that we can look forward to a future Erlang >> supporting lists and maps as its sole data constructors. >> >> - Chris P >> _______________________________________________ >> 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 -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ From bob@REDACTED Wed Aug 27 20:45:30 2014 From: bob@REDACTED (Bob Ippolito) Date: Wed, 27 Aug 2014 11:45:30 -0700 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: On Wed, Aug 27, 2014 at 11:03 AM, Josh Adams wrote: > On Wed, Aug 27, 2014 at 12:40 PM, Bob Ippolito wrote: > >> If there was a mochijson3 it would surely use maps rather than {struct, >> proplist()}. Perhaps EEP18 should be amended for Erlang 17? >> > > I would assume this isn't true until maps are fast with a large number of > keys though...would that be accurate? I definitely have plenty of json use > cases that would likely perform poorly until that change occurs. > This is all hypothetical anyway, but I would assume that maps are going to be faster in 17.1 or 18 at the latest. I expect that any sort of standardization effort (and for usage of 17+ to hit critical mass) would take at least that long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Aug 27 20:50:54 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 27 Aug 2014 21:50:54 +0300 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> Message-ID: <58276377-496E-4347-8D79-3BD18A1B6FBA@gmail.com> On Churyumov-Gerasimenko comet... Celebrated by local trolls... Best Regards, Dmitry >-|-|-(*> > On 27 Aug 2014, at 21:40, Sean Cribbs wrote: > > Must be April 1 somewhere. > >> On Wed, Aug 27, 2014 at 1:34 PM, Anthony Ramine wrote: >> Are we 1st April already? I didn?t implement yet my patch to make tuples 0-indexed. :( >> >> But well, that is overseded by your proposal. >> >> -- >> Anthony Ramine >> >>> Le 27 ao?t 2014 ? 20:21, Chris Pacejo a ?crit : >>> >>> Tuples are clearly unnecessary and a wart in Erlang's design. >>> Consider all the operations tuples provide: >>> >>> Construction: X = {A,B,C} >>> Destruction: {A,B,C} = X >>> Pattern matching: case X of {foo,B,C} -> ... end >>> >>> Note now that these operations are provided equally by lists: >>> >>> Construction: X = [A,B,C] >>> Destruction: [A,B,C] = X >>> Pattern matching: case X of [foo,B,C] -> ... end >>> >>> And note that lists provide the additional functionality of indexing >>> and consing, which tuples do not provide. >>> >>> Clearly, using tuples instead of lists provides no benefit, and to >>> simplify the language they should be deprecated in OTP 18, and removed >>> by OTP 19. To support this transition, a compiler option can be >>> provided to maintain the ill-conceived tuple notation for legacy code; >>> may I suggest +distinguish_homogenous_and_heterogenous_collections. >>> >>> Now, surely detractors will claim that the distinction between tuples >>> and lists signals programmer intent, permits bytecode optimization, >>> and enables rich typechecking in Dialyzer. I claim these purported >>> benefits are bollocks. I, and no doubt others, routinely find the >>> need to iterate over tuple elements, and to store unrelated data >>> together in a single list. Anyone who claims that such things are not >>> necessary clearly has not ever written a complex program. (I suspect >>> anyone who thinks structurally-typed records and key-value maps serve >>> different purposes falls into this group.) >>> >>> I hope you all agree, and that we can look forward to a future Erlang >>> supporting lists and maps as its sole data constructors. >>> >>> - Chris P >>> _______________________________________________ >>> 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 > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From demeshchuk@REDACTED Wed Aug 27 20:51:12 2014 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Wed, 27 Aug 2014 11:51:12 -0700 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: I, personally, think lists are obsolete too. Instead, everyone should just use maps for everything: { 1 => first_element, 2 => second_element, 3 => third_element }. On Wed, Aug 27, 2014 at 11:21 AM, Chris Pacejo wrote: > Tuples are clearly unnecessary and a wart in Erlang's design. > Consider all the operations tuples provide: > > Construction: X = {A,B,C} > Destruction: {A,B,C} = X > Pattern matching: case X of {foo,B,C} -> ... end > > Note now that these operations are provided equally by lists: > > Construction: X = [A,B,C] > Destruction: [A,B,C] = X > Pattern matching: case X of [foo,B,C] -> ... end > > And note that lists provide the additional functionality of indexing > and consing, which tuples do not provide. > > Clearly, using tuples instead of lists provides no benefit, and to > simplify the language they should be deprecated in OTP 18, and removed > by OTP 19. To support this transition, a compiler option can be > provided to maintain the ill-conceived tuple notation for legacy code; > may I suggest +distinguish_homogenous_and_heterogenous_collections. > > Now, surely detractors will claim that the distinction between tuples > and lists signals programmer intent, permits bytecode optimization, > and enables rich typechecking in Dialyzer. I claim these purported > benefits are bollocks. I, and no doubt others, routinely find the > need to iterate over tuple elements, and to store unrelated data > together in a single list. Anyone who claims that such things are not > necessary clearly has not ever written a complex program. (I suspect > anyone who thinks structurally-typed records and key-value maps serve > different purposes falls into this group.) > > I hope you all agree, and that we can look forward to a future Erlang > supporting lists and maps as its sole data constructors. > > - Chris P > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best regards, Dmitry Demeshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek@REDACTED Wed Aug 27 21:20:46 2014 From: wojtek@REDACTED (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=) Date: Wed, 27 Aug 2014 21:20:46 +0200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <53FE2F8E.3000500@power.com.pl> On 27.08.2014 20:51, Dmitry Demeshchuk wrote: > I, personally, think lists are obsolete too. Instead, everyone should > just use maps for everything: > Use binary trees. http://www.cse.chalmers.se/~bernardy/PP.pdf "In an eloquent 2009 ICFP invited talk, Guy Steele harangued the functional programming crowds to stop using lists and use sequences, represented as balanced trees." A list is just a perfectly imbalanced binary tree, after all. -- Wojtek N. From pwoolcoc@REDACTED Wed Aug 27 20:54:41 2014 From: pwoolcoc@REDACTED (Paul W) Date: Wed, 27 Aug 2014 14:54:41 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: Hey, it works for PHP! On Wed, Aug 27, 2014 at 2:51 PM, Dmitry Demeshchuk wrote: > I, personally, think lists are obsolete too. Instead, everyone should just > use maps for everything: > > { 1 => first_element, 2 => second_element, 3 => third_element }. > > > On Wed, Aug 27, 2014 at 11:21 AM, Chris Pacejo > wrote: > >> Tuples are clearly unnecessary and a wart in Erlang's design. >> Consider all the operations tuples provide: >> >> Construction: X = {A,B,C} >> Destruction: {A,B,C} = X >> Pattern matching: case X of {foo,B,C} -> ... end >> >> Note now that these operations are provided equally by lists: >> >> Construction: X = [A,B,C] >> Destruction: [A,B,C] = X >> Pattern matching: case X of [foo,B,C] -> ... end >> >> And note that lists provide the additional functionality of indexing >> and consing, which tuples do not provide. >> >> Clearly, using tuples instead of lists provides no benefit, and to >> simplify the language they should be deprecated in OTP 18, and removed >> by OTP 19. To support this transition, a compiler option can be >> provided to maintain the ill-conceived tuple notation for legacy code; >> may I suggest +distinguish_homogenous_and_heterogenous_collections. >> >> Now, surely detractors will claim that the distinction between tuples >> and lists signals programmer intent, permits bytecode optimization, >> and enables rich typechecking in Dialyzer. I claim these purported >> benefits are bollocks. I, and no doubt others, routinely find the >> need to iterate over tuple elements, and to store unrelated data >> together in a single list. Anyone who claims that such things are not >> necessary clearly has not ever written a complex program. (I suspect >> anyone who thinks structurally-typed records and key-value maps serve >> different purposes falls into this group.) >> >> I hope you all agree, and that we can look forward to a future Erlang >> supporting lists and maps as its sole data constructors. >> >> - Chris P >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Best regards, > Dmitry Demeshchuk > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Paul Woolcock -------------- next part -------------- An HTML attachment was scrubbed... URL: From samjbarney@REDACTED Wed Aug 27 21:39:30 2014 From: samjbarney@REDACTED (Samuel Barney) Date: Wed, 27 Aug 2014 13:39:30 -0600 Subject: [erlang-questions] Erlang on custom OS Message-ID: I've had an idea churning in the back of my head for a while: Write a custom threadless operating system which uses erlang for pretty much everything. I've written a couple of custom kernels before, but this would be my first time porting a major project to one. Anyone have any experience porting Erlang to different platforms or an idea of where in the erlang source code I should start looking to see what the MINIMAL requirements to compile erlang are? -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Aug 27 21:48:43 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 15:48:43 -0400 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: On Wed, Aug 27, 2014 at 2:03 PM, Josh Adams wrote: > I would assume this isn't true until maps are fast with a large number of > keys though...would that be accurate? I definitely have plenty of json use > cases that would likely perform poorly until that change occurs. I would never expect the general case of accessing data stored in the same logical structure it's transmitted on the wire in to be fast at all. Think about it: real-world large data is typically relationally rich. Large datasets should be indexed in multiple ways to support efficient access, and this indexing is by its very nature (a) domain-specific and (b) informationally redundant. But when sending this data on the wire, you want it to be *compact*, not richly indexed. So to support efficient access, you inevitably need to restructure the data coming off the wire *anyway*. (Not to mention that not restructuring data couples both sides of your implementation to the wire format and to each other, making it brittle in the face of future changes.) From colanderman@REDACTED Wed Aug 27 21:55:03 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 15:55:03 -0400 Subject: [erlang-questions] Erlang on custom OS In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 3:39 PM, Samuel Barney wrote: > I've had an idea churning in the back of my head for a while: Write a custom > threadless operating system which uses erlang for pretty much everything. > I've written a couple of custom kernels before, but this would be my first > time porting a major project to one. Anyone have any experience porting > Erlang to different platforms or an idea of where in the erlang source code > I should start looking to see what the MINIMAL requirements to compile > erlang are? These people have Erlang running directly on the Xen hypervisor: http://erlangonxen.org/ I've been working on my own non-serious-very-much-a-toy project to build an OS in Erlang, running on Linux. (i.e. Erlang is the only non-system process running; everything the user sees goes through the Erlang VM.) I only mention it because you might find the same general approach suitable: keep Linux around, just to provide the services Erlang needs (including those you haven't implemented yet; e.g. native TCP). Linux can be VERY efficient when it's running primarily a single process, so you're not really losing performance that way. From eriksoe@REDACTED Wed Aug 27 22:12:42 2014 From: eriksoe@REDACTED (=?UTF-8?Q?Erik_S=C3=B8e_S=C3=B8rensen?=) Date: Wed, 27 Aug 2014 22:12:42 +0200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: No - down with lists. Tuples for everything! More specifically, 2-tuples only! (But we get to keep nil. Can't do without nil.) Joke aside, thanks for the calendrical confusion. Den 27/08/2014 20.51 skrev "Dmitry Demeshchuk" : > I, personally, think lists are obsolete too. Instead, everyone should just > use maps for everything: > > { 1 => first_element, 2 => second_element, 3 => third_element }. > > > On Wed, Aug 27, 2014 at 11:21 AM, Chris Pacejo > wrote: > >> Tuples are clearly unnecessary and a wart in Erlang's design. >> Consider all the operations tuples provide: >> >> Construction: X = {A,B,C} >> Destruction: {A,B,C} = X >> Pattern matching: case X of {foo,B,C} -> ... end >> >> Note now that these operations are provided equally by lists: >> >> Construction: X = [A,B,C] >> Destruction: [A,B,C] = X >> Pattern matching: case X of [foo,B,C] -> ... end >> >> And note that lists provide the additional functionality of indexing >> and consing, which tuples do not provide. >> >> Clearly, using tuples instead of lists provides no benefit, and to >> simplify the language they should be deprecated in OTP 18, and removed >> by OTP 19. To support this transition, a compiler option can be >> provided to maintain the ill-conceived tuple notation for legacy code; >> may I suggest +distinguish_homogenous_and_heterogenous_collections. >> >> Now, surely detractors will claim that the distinction between tuples >> and lists signals programmer intent, permits bytecode optimization, >> and enables rich typechecking in Dialyzer. I claim these purported >> benefits are bollocks. I, and no doubt others, routinely find the >> need to iterate over tuple elements, and to store unrelated data >> together in a single list. Anyone who claims that such things are not >> necessary clearly has not ever written a complex program. (I suspect >> anyone who thinks structurally-typed records and key-value maps serve >> different purposes falls into this group.) >> >> I hope you all agree, and that we can look forward to a future Erlang >> supporting lists and maps as its sole data constructors. >> >> - Chris P >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Best regards, > Dmitry Demeshchuk > > _______________________________________________ > 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 Wed Aug 27 22:16:59 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 27 Aug 2014 15:16:59 -0500 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> References: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> Message-ID: This is definitely a troll. On Wed, Aug 27, 2014 at 1:34 PM, Anthony Ramine wrote: > Are we 1st April already? I didn?t implement yet my patch to make tuples > 0-indexed. :( > > But well, that is overseded by your proposal. > > -- > Anthony Ramine > > Le 27 ao?t 2014 ? 20:21, Chris Pacejo a ?crit : > > > Tuples are clearly unnecessary and a wart in Erlang's design. > > Consider all the operations tuples provide: > > > > Construction: X = {A,B,C} > > Destruction: {A,B,C} = X > > Pattern matching: case X of {foo,B,C} -> ... end > > > > Note now that these operations are provided equally by lists: > > > > Construction: X = [A,B,C] > > Destruction: [A,B,C] = X > > Pattern matching: case X of [foo,B,C] -> ... end > > > > And note that lists provide the additional functionality of indexing > > and consing, which tuples do not provide. > > > > Clearly, using tuples instead of lists provides no benefit, and to > > simplify the language they should be deprecated in OTP 18, and removed > > by OTP 19. To support this transition, a compiler option can be > > provided to maintain the ill-conceived tuple notation for legacy code; > > may I suggest +distinguish_homogenous_and_heterogenous_collections. > > > > Now, surely detractors will claim that the distinction between tuples > > and lists signals programmer intent, permits bytecode optimization, > > and enables rich typechecking in Dialyzer. I claim these purported > > benefits are bollocks. I, and no doubt others, routinely find the > > need to iterate over tuple elements, and to store unrelated data > > together in a single list. Anyone who claims that such things are not > > necessary clearly has not ever written a complex program. (I suspect > > anyone who thinks structurally-typed records and key-value maps serve > > different purposes falls into this group.) > > > > I hope you all agree, and that we can look forward to a future Erlang > > supporting lists and maps as its sole data constructors. > > > > - Chris P > > _______________________________________________ > > 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 richard.youngkin@REDACTED Wed Aug 27 22:17:39 2014 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Wed, 27 Aug 2014 14:17:39 -0600 Subject: [erlang-questions] Erlang and Akka Message-ID: Hi again, Thanks for all the responses, they're very helpful. Thanks to Leonard for the linkedIn discussion tip ( https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556). Despite a brief descent into a rambling flame post it's worth reading. I'm still trying to wrap my head around many of the comments given that my Akka knowledge is only marginally better than knowing nothing about Akka. One comment that resonated with me is the need to choose the proper tool. My sense is (and was) that both Erlang and Akka can be used effectively to solve similar problems. The need to fit into the JVM ecosystem is one item that might tilt one towards Akka. For other reasons the JVM might tilt one towards Erlang (along other things like immutability and conciseness). To answer a question in Loic's original response, why did I raise this question? See below for that, but I intentionally left the question open-ended in order to get the wider range of responses. One of the reasons I raised the question is an argument I often hear regarding the availability of skilled Erlang developers. While I think this is generally a valid argument, I think it starts to become less of an issue when the value of a functional approach using OTP-like capabilities becomes important. IMO, the conceptual complexity of these 2 areas far outweigh the cost of getting up to speed with Erlang syntax. In this respect I think Erlang and Akka, at least Akka/Scala, will be fairly similar in their learning curves. Any comments? Another reason I raised the question is that we're currently considering refactoring our fairly monolithic Erlang app into a set of smaller, more focused, services. This raised the previous question about the availability of skilled Erlang developers. In pursuing this refactoring there's no reason to chose any single technology for the entire set of new services. So, the best tool for the job is very reasonable, keeping in mind that there's an existing Erlang code base that mostly works pretty well. Thanks again for all the comments, keep them coming if you're so inclined. I've found all of them useful. Cheers, Rich On 27 Aug 2014, at 11:34, Giovanni Giorgi <> wrote: >* Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges. *> >* Anyway the questions I will do to myself will be: *> >* Team know-how *>* For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there. *> As others have pointed out, 60 people is a *huge* team for an Erlang project. I doubt you need that many unless you?re building a monster of an app. The AXD 301 team had roughly that many Erlang programmers for almost 2 million lines of Erlang code; arguably, it was too many people, but the list of requirements was really what drove the size of the project. Basically, look at how many people are needed to wrap their collective heads around the functional requirements. Those guys should all be programming, and you?re not likely to need many more programmers than that. >* Erlang immutable state is a big hit in the long run. *> On the contrary. The long run is where immutability pays off, mainly in two ways: - Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid. - Performance. It may sound weird, but immutability and acyclic data structures really help the memory management subsystem as well as simplify scaling across multiple cores. The area where it hurts is mostly core that has to sequentially run through large data sets, flipping bits or making other small modifications along the way - the Dijkstra Shortest Path First algorithm comes to mind. But if you?re building a complex system with lots of concurrency, immutability will keep you sane and help your applications scale. Performance losses in this class of systems, using conventional coding techniques, are often due to code complexity as much as anything else: you lose the ability to reason about how the code behaves, and all those fancy tricks that can help performance in smaller systems will only make things worse. But of course it depends on what kind of system you?re building. Erlang is very performant for the kinds of system that it was designed for. There are lots of stories about Erlang-based systems handling outright crazy loads compared to the competition. The Java story is not particularly good when it comes to multicore. You really have to know what you?re doing, or have a problem that is embarrassingly parallel. The main multicore problem in Erlang is that it?s hard to come by as many cores as you think you can utilize. ;-) >* On the other way, Java isolation is very strong. *> Actually, not compared to Erlang. The reason is shared (mutable) objects. If a thread crashes that shares data with other threads, you are basically lost. Since Erlang uses share-nothing concurrency with copying message passing, a dead process really doesn?t hurt the data of other processes, and can simply be swept away by the GC. >* Also JVM stability is very high. *> Granted. So is the stability of the Erlang VM. >* Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing. *> >* With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this. *> If you just measure the amount of manpower that has gone into Java GC, it should be far superior to the Erlang GC, but GC is a much, much harder problem in Java than it is in Erlang. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Wed Aug 27 22:21:23 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 16:21:23 -0400 Subject: [erlang-questions] Erlang on custom OS In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 4:12 PM, Samuel Barney wrote: > Sorry if this goes directly to you; first time using a mailing group. > > How exactly did you go about it? For instance, are you running off a > specific distro? http://buildroot.uclibc.org/ -- end of story :) (I originally went about it the hard way -- compile Linux, libc, busybox, Erlang, etc. by hand, make a ramdisk and init script, etc. Buildroot is a simple menu-based tool that does all these steps for you. It even knows about Erlang.) From raould@REDACTED Wed Aug 27 22:21:56 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 27 Aug 2014 13:21:56 -0700 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: >> { 1 => first_element, 2 => second_element, 3 => third_element }. we had a fun flash/amf3 bug where a map with a big int key on the sending side became (tried to become, anyway) a 4gb mostly empty array on the other side. From g@REDACTED Wed Aug 27 22:33:43 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 27 Aug 2014 15:33:43 -0500 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: <60C1873F-B222-4705-8152-FCA0F6A39FB1@gmail.com> Message-ID: I think there's an opportunity to some good here. Let's pick a worthy charity... anyone asked to donate who doesn't has to replace all uses of tuples with lists in his or her code. The No Tuple Challenge. I'm seeing a lot crazy videos here! On Wed, Aug 27, 2014 at 3:16 PM, Tristan Sloughter wrote: > This is definitely a troll. > > > On Wed, Aug 27, 2014 at 1:34 PM, Anthony Ramine wrote: >> >> Are we 1st April already? I didn?t implement yet my patch to make tuples >> 0-indexed. :( >> >> But well, that is overseded by your proposal. >> >> -- >> Anthony Ramine >> >> Le 27 ao?t 2014 ? 20:21, Chris Pacejo a ?crit : >> >> > Tuples are clearly unnecessary and a wart in Erlang's design. >> > Consider all the operations tuples provide: >> > >> > Construction: X = {A,B,C} >> > Destruction: {A,B,C} = X >> > Pattern matching: case X of {foo,B,C} -> ... end >> > >> > Note now that these operations are provided equally by lists: >> > >> > Construction: X = [A,B,C] >> > Destruction: [A,B,C] = X >> > Pattern matching: case X of [foo,B,C] -> ... end >> > >> > And note that lists provide the additional functionality of indexing >> > and consing, which tuples do not provide. >> > >> > Clearly, using tuples instead of lists provides no benefit, and to >> > simplify the language they should be deprecated in OTP 18, and removed >> > by OTP 19. To support this transition, a compiler option can be >> > provided to maintain the ill-conceived tuple notation for legacy code; >> > may I suggest +distinguish_homogenous_and_heterogenous_collections. >> > >> > Now, surely detractors will claim that the distinction between tuples >> > and lists signals programmer intent, permits bytecode optimization, >> > and enables rich typechecking in Dialyzer. I claim these purported >> > benefits are bollocks. I, and no doubt others, routinely find the >> > need to iterate over tuple elements, and to store unrelated data >> > together in a single list. Anyone who claims that such things are not >> > necessary clearly has not ever written a complex program. (I suspect >> > anyone who thinks structurally-typed records and key-value maps serve >> > different purposes falls into this group.) >> > >> > I hope you all agree, and that we can look forward to a future Erlang >> > supporting lists and maps as its sole data constructors. >> > >> > - Chris P >> > _______________________________________________ >> > 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 mononcqc@REDACTED Wed Aug 27 22:39:28 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 27 Aug 2014 16:39:28 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <20140827203927.GQ54532@ferdair.local> On 08/27, Chris Pacejo wrote: > Tuples are clearly unnecessary and a wart in Erlang's design. > Consider all the operations tuples provide: > > Construction: X = {A,B,C} > Destruction: {A,B,C} = X > Pattern matching: case X of {foo,B,C} -> ... end > > Note now that these operations are provided equally by lists: > > Construction: X = [A,B,C] > Destruction: [A,B,C] = X > Pattern matching: case X of [foo,B,C] -> ... end > This proposal lacks foresight. Lists can, for example, be implemented using anonymous functions: -module(mod). -compile(export_all). cons(H, T) -> fun(F) -> F(H, T) end. hd(L) -> L(fun(H,_) -> H end). tl(L) -> L(fun(_,T) -> T end). Which runs as: 1> L = mod:cons(3, mod:cons(2, mod:cons(1, []))). %% equiv to [3|[2|[1|[]]]] #Fun 2> mod:hd(L). 3 3> mod:hd(mod:tl(L)). 2 Clearly other operations on lists are only sugar, and should be reduced. We can also use church numerals for our purposes: zero() -> fun(_F) -> fun(X) -> X end end. succ(N) -> fun(F) -> fun(Z) -> F((N(F))(Z)) end end. one() -> succ(zero()). two() -> succ(one()). %% This one is a cheat to help our feeble minds to_int(F) -> (F(fun(X) -> X+1 end))(0). Which runs as: 4> mod:to_int(mod:two()). 2 5> mod:to_int(mod:one()). 1 6> mod:to_int(mod:succ(mod:succ(mod:two()))). 4 Now lambda calculus and other similar works tell us how we can implement entire systems that way. All we need are processes. But wait, systems like Pi Calculus can be made somewhat equivalent to Erlang, and that one is also turing equivalent, isn't it? Without digressing, I'm sure this mailing list will be able to appreciate how having only one data type -- functions -- makes for a good base. You now only need to optimize one data type and *the entire system* should be faster. It's tempting isn't it? Hrm. Regards, Fred. From nx@REDACTED Wed Aug 27 22:43:10 2014 From: nx@REDACTED (nx) Date: Wed, 27 Aug 2014 16:43:10 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: <20140827203927.GQ54532@ferdair.local> References: <20140827203927.GQ54532@ferdair.local> Message-ID: 01110101011100110110010100100000011000100110100101101110011000010111001001111001 On Wed, Aug 27, 2014 at 4:39 PM, Fred Hebert wrote: > On 08/27, Chris Pacejo wrote: >> Tuples are clearly unnecessary and a wart in Erlang's design. >> Consider all the operations tuples provide: >> >> Construction: X = {A,B,C} >> Destruction: {A,B,C} = X >> Pattern matching: case X of {foo,B,C} -> ... end >> >> Note now that these operations are provided equally by lists: >> >> Construction: X = [A,B,C] >> Destruction: [A,B,C] = X >> Pattern matching: case X of [foo,B,C] -> ... end >> > > This proposal lacks foresight. Lists can, for example, be implemented > using anonymous functions: > > -module(mod). > -compile(export_all). > > cons(H, T) -> fun(F) -> F(H, T) end. > hd(L) -> L(fun(H,_) -> H end). > tl(L) -> L(fun(_,T) -> T end). > > Which runs as: > > 1> L = mod:cons(3, mod:cons(2, mod:cons(1, []))). %% equiv to [3|[2|[1|[]]]] > #Fun > 2> mod:hd(L). > 3 > 3> mod:hd(mod:tl(L)). > 2 > > Clearly other operations on lists are only sugar, and should be reduced. > > We can also use church numerals for our purposes: > > zero() -> fun(_F) -> fun(X) -> X end end. > succ(N) -> fun(F) -> fun(Z) -> F((N(F))(Z)) end end. > one() -> succ(zero()). > two() -> succ(one()). > %% This one is a cheat to help our feeble minds > to_int(F) -> (F(fun(X) -> X+1 end))(0). > > Which runs as: > > 4> mod:to_int(mod:two()). > 2 > 5> mod:to_int(mod:one()). > 1 > 6> mod:to_int(mod:succ(mod:succ(mod:two()))). > 4 > > Now lambda calculus and other similar works tell us how we can implement > entire systems that way. All we need are processes. But wait, systems > like Pi Calculus can be made somewhat equivalent to Erlang, and that one > is also turing equivalent, isn't it? > > Without digressing, I'm sure this mailing list will be able to > appreciate how having only one data type -- functions -- makes for a > good base. You now only need to optimize one data type and *the entire > system* should be faster. It's tempting isn't it? > > Hrm. > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From colanderman@REDACTED Wed Aug 27 22:44:45 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 16:44:45 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: Even given my admittedly poor job trying to channel Swift I figured at least someone would get the reference :/ (http://en.wikipedia.org/wiki/A_Modest_Proposal for those still in the dark.) No, I'm not actually calling for tuples to be removed from Erlang. That would be absurd; Dmitry K pointed out at least one good reason why. But now that maps have been officially introduced, popular opinion seems to overwhelmingly be leaning in the direction of utilizing maps for both values with a static (keys known at compile time) heterogeneous (differing types of values) structure, and values with a dynamic (keys determined at runtime) homogeneous (single type of values) structure. For the same reasons that tuples and lists are (rightly) kept separate (namely declaration of intent, ability to typecheck, and efficiency of implementation), I strongly believe that these two use cases of "map-like-things" should be kept separate. My stance is certainly not without precedent -- older languages such as OCaml and SQL get the distinction right. (In OCaml, it's the difference between an anonymous object and a Map. In SQL, it's the difference between a row and a relation.) But certain modern dynamically typed interpreted languages -- Python, Ruby, JavaScript, to name a few -- lose this important distinction, and conflate all "things that have keys and values" as a single type, whose inefficiencies are masked only by those languages' lack of type discipline and poor implementation performance. (Though JavaScript nominally distinguishes between the two forms -- objects can have only string keys, and there is a Map class -- in practice programmers often don't. See the concurrent JSON thread.) I apologize for the troll, but my past direct attempts to bring this issue to the list's attention have been lost in long threads with little to no discussion. I just fear an Erlang ecosystem in which, five years hence, this singular "map" structure is used for such wildly distinct purposes that we are forced to accept that they are opaque, unanalyzable, and slow, and nothing can be done about it. From mononcqc@REDACTED Wed Aug 27 22:55:55 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 27 Aug 2014 16:55:55 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <20140827205554.GR54532@ferdair.local> On 08/27, Chris Pacejo wrote: > I apologize for the troll, but my past direct attempts to bring this > issue to the list's attention have been lost in long threads with > little to no discussion. I just fear an Erlang ecosystem in which, > five years hence, this singular "map" structure is used for such > wildly distinct purposes that we are forced to accept that they are > opaque, unanalyzable, and slow, and nothing can be done about it. > I fear the same. In http://learnyousomeerlang.com/maps, I made a conscious effort to distinguish maps from records, for example. I don't necessarily fear maps replacing tuples in the general case ({point,X,Y} still is fast to write vs. Point#{x := X, y := Y}), but their overlap with records and the dynamic vs. static set of keys is a lot less obvious. A rich type zoo is fun and practical to have, it would be a shame to conflate all the things in the structure. From colanderman@REDACTED Wed Aug 27 23:15:42 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 17:15:42 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: <20140827205554.GR54532@ferdair.local> References: <20140827205554.GR54532@ferdair.local> Message-ID: On Wed, Aug 27, 2014 at 4:55 PM, Fred Hebert wrote: > I fear the same. In http://learnyousomeerlang.com/maps, I made a > conscious effort to distinguish maps from records, for example. Ha! I think we've come to a different conclusion from the same premise :) I believe the opposite, that maps-as-records are useful, and should replace/supplement records; while dicts (barring performance) are just fine as-is and need no special syntax. But that's a separate discussion (and one I don't feel as strongly about); I'm glad we agree that maps performing double-duty is problematic. (Perhaps the reason maps currently perform double-duty is because both the "I-want-syntax-for-dicts" and the "I-want-structurally-typed-records" people have latched onto maps as their savior.) [Aside: Learn You Some Erlang is great, even as a reference. Thanks for writing and maintaining it!] From tristan.sloughter@REDACTED Wed Aug 27 23:19:50 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 27 Aug 2014 16:19:50 -0500 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: <20140827205554.GR54532@ferdair.local> Message-ID: Maps can in no way replace records. But yes, is a complement to records by providing a record like structure and syntax for use in place of dicts. On Wed, Aug 27, 2014 at 4:15 PM, Chris Pacejo wrote: > On Wed, Aug 27, 2014 at 4:55 PM, Fred Hebert wrote: > > I fear the same. In http://learnyousomeerlang.com/maps, I made a > > conscious effort to distinguish maps from records, for example. > > Ha! I think we've come to a different conclusion from the same > premise :) I believe the opposite, that maps-as-records are useful, > and should replace/supplement records; while dicts (barring > performance) are just fine as-is and need no special syntax. But > that's a separate discussion (and one I don't feel as strongly about); > I'm glad we agree that maps performing double-duty is problematic. > (Perhaps the reason maps currently perform double-duty is because both > the "I-want-syntax-for-dicts" and the > "I-want-structurally-typed-records" people have latched onto maps as > their savior.) > > [Aside: Learn You Some Erlang is great, even as a reference. Thanks > for writing and maintaining it!] > _______________________________________________ > 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 Aug 28 00:14:04 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 28 Aug 2014 00:14:04 +0200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: <20140827205554.GR54532@ferdair.local> Message-ID: On Wed, Aug 27, 2014 at 11:19 PM, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > Maps can in no way replace records. But yes, is a complement to records by > providing a record like structure and syntax for use in place of dicts. Indeed. Only a fool ignores "Types and Programming languages" by Benjamin C. Pierce, regardless of typing discipline. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.rubyist@REDACTED Thu Aug 28 01:08:39 2014 From: josh.rubyist@REDACTED (Josh Adams) Date: Wed, 27 Aug 2014 18:08:39 -0500 Subject: [erlang-questions] Erlang on custom OS In-Reply-To: References: Message-ID: this is where I mention Frank Hunleth and http://nerves-project.org/ -- Josh Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: From eajam@REDACTED Thu Aug 28 01:13:20 2014 From: eajam@REDACTED (Alex Alvarez) Date: Wed, 27 Aug 2014 19:13:20 -0400 Subject: [erlang-questions] Elastic Erlang In-Reply-To: <08146F1A-D2C0-404D-AB0D-60B892186896@gmail.com> References: <08146F1A-D2C0-404D-AB0D-60B892186896@gmail.com> Message-ID: I use Linux instance(s) on AWS EC2, which AFAIK uses the Xen Hypervisor. All monitoring using the EC2 tools provided. Not much to complain about them... On 07/17/2014 05:47 PM, Lee Sylvester wrote: > Hi guys, > > I was wondering, who out there in the list is using Erlang in an elastic cloud environment, and what platforms (hypervisor, monitoring, etc.) are you using? > > Would be good to see how people are deploying Erlang in real world situations. > > Cheers, > Lee > _______________________________________________ > 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 Thu Aug 28 01:27:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 28 Aug 2014 11:27:22 +1200 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: <2F305FC6-E45D-4039-AC4C-770A8CE56B1B@gmail.com> Message-ID: On 28/08/2014, at 7:48 AM, Chris Pacejo wrote: > But when sending this data on the wire, you want it to be *compact*, > not richly indexed. So to support efficient access, you inevitably > need to restructure the data coming off the wire *anyway*. (Not to > mention that not restructuring data couples both sides of your > implementation to the wire format and to each other, making it brittle > in the face of future changes.) +1 From ok@REDACTED Thu Aug 28 01:53:01 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 28 Aug 2014 11:53:01 +1200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <2F6C55CD-AFCE-4CB4-8773-C517D3253D4D@cs.otago.ac.nz> On 28/08/2014, at 6:21 AM, Chris Pacejo wrote: > Tuples are clearly unnecessary and a wart in Erlang's design. > Consider all the operations tuples provide: > > Construction: X = {A,B,C} > Destruction: {A,B,C} = X > Pattern matching: case X of {foo,B,C} -> ... end > > Note now that these operations are provided equally by lists: > > Construction: X = [A,B,C] > Destruction: [A,B,C] = X > Pattern matching: case X of [foo,B,C] -> ... end They are not, however, provided with equal COST. Without looking at the implementation, but based on my knowledge of the WAM, I can tell you that MEMORY - a list of n items could take 2n words - a tuple of n items could take n+1 words INDEXING - accessing the kth element of a list takes O(k) time - accessing the kth element of a tuple takes O(1) time MATCHING - matching an n-element list pattern against an m-element list value fails after O(min(m,n)) time - matching an n-element tuple pattern against an m-element tuple value fails after O(1) time BUILDING - prepending k elements to an n-element list takes O(k) time - prepending k elements to an n-element tuple takes O(k+n) time The result is that some things will go drastically faster with lists than with tuples, with other things will go drastically faster with tuples than with lists. Scheme has vectors as well as lists, for the same good reasons. > > And note that lists provide the additional functionality of indexing > and consing, which tuples do not provide. No, tuples DO provide indexing. They are very good at it. > > Clearly, using tuples instead of lists provides no benefit, Halving the amount of memory required is "no benefit"? O(1) access instead of O(k) is "no benefit"? > > Now, surely detractors will claim that the distinction between tuples > and lists signals programmer intent, permits bytecode optimization, > and enables rich typechecking in Dialyzer. Not me. What *I* claim is that in *any* programming language it can be useful to have multiple implementations of the same concept BECAUSE THEY HAVE DIFFERENT COST PROFILES. Now there is work going back decades on adaptive data structures which flip "under the hood" from one representation to another depending on what you are doing with them. But that puts up the cost of everything. > I claim these purported benefits are bollocks. Well, they're *your* claims, so if you say so... > I, and no doubt others, routinely find the > need to iterate over tuple elements, and to store unrelated data > together in a single list. I've written a lot of code over the years. I can't remember when I last had a need to store *unrelated data* together in a single list, and it's certainly not routine. Iterating over tuple elements, YES, but (1) there is already an EEP proposing tuple generators in comprehensions, and tuple comprehension. (2) thanks to the magic of higher-order functions, it is ALREADY dead simple to iterate over the elements of tuples. (Just not as pretty as using comprehensions.) > I hope you all agree, and that we can look forward to a future Erlang > supporting lists and maps as its sole data constructors. Such an Erlang would fail to support practically *all* existing code. It would be like a revised C++ where vector was there but T[] was not. Could be a usable language, but would not support old code. From ok@REDACTED Thu Aug 28 01:58:15 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 28 Aug 2014 11:58:15 +1200 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: References: Message-ID: <26F4D0F0-E8CD-4788-859D-B21F24490665@cs.otago.ac.nz> On 28/08/2014, at 8:44 AM, Chris Pacejo wrote: > > But now that maps have been officially introduced, popular opinion > seems to overwhelmingly be leaning in the direction of utilizing maps > for both values with a static (keys known at compile time) > heterogeneous (differing types of values) structure, and values with a > dynamic (keys determined at runtime) homogeneous (single type of > values) structure. For the same reasons that tuples and lists are > (rightly) kept separate (namely declaration of intent, ability to > typecheck, and efficiency of implementation), I strongly believe that > these two use cases of "map-like-things" should be kept separate. That was the key point in the frames proposal, with frames being the "static heterogeneous" case. I am frankly ****ed off that maps **** all over that distinction and I have seen no numbers to show that maps can be as efficient as frames for the purpose frames were designed to serve. From eajam@REDACTED Thu Aug 28 01:58:37 2014 From: eajam@REDACTED (Alex Alvarez) Date: Wed, 27 Aug 2014 19:58:37 -0400 Subject: [erlang-questions] Installing 17.1 on a T2 kills it In-Reply-To: References: Message-ID: This sounds like it could be a number of possible issues, not exactly related to Erlang. I would start by checking the file system and partitions. Have you checked to see if there's any partition that's out of space? That could definitely bring your system down and keep you from booting correctly. There might be physical problem with the disk(s) or something messed up with /etc/fstab. And there certainly might be other possible issues. My overall recommendation with such a system is to try to get the latest Solaris (v11.2) DVD, and do a completely new install, while checking the state of the disk(s) in the process. OpenIndiana might work well also. In the new install, try to minimize the number of partitions as possible, while maximizing their sizes. On 07/04/2014 12:06 AM, Richard A. O'Keefe wrote: > On 3/07/2014, at 9:14 PM, Lukas Larsson wrote: > >> On Thu, Jul 3, 2014 at 3:25 AM, Richard A. O'Keefe wrote: >> >> (1) Has anyone else had this problem? >> >> Our sunos 5.11 (SunOS 5.11 oi_151a9 i86pc i386 i86pc) machine does not have this problem. > I was specifically asking about the T2. > Has anyone else had this problem *on a T2*? > > (Part of the problem may be that the machine is actually > a pre-production one. So there may be a hardware issue that > nothing else has tickled.) > > I have OpenSolaris in VirtualBox on my laptop, > and Solaris 11 in VirtualBox on my desktop. > However, neither of those offers 64 virtual CPUS. > >> Unfortunately there is no way to do this. Manually you can remove line 1190 to 1222 in erts/configure.in and that should make it skip the test. > I removed everything, unpacked the .tar file again, made this change, > but something went wrong somehow and the thing went belly up at the > same place again. Lectures resume next week so I'm not going to have > much time to try to resolve this. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colanderman@REDACTED Thu Aug 28 03:27:33 2014 From: colanderman@REDACTED (Chris Pacejo) Date: Wed, 27 Aug 2014 21:27:33 -0400 Subject: [erlang-questions] A modest proposal to eliminate tuples In-Reply-To: <2F6C55CD-AFCE-4CB4-8773-C517D3253D4D@cs.otago.ac.nz> References: <2F6C55CD-AFCE-4CB4-8773-C517D3253D4D@cs.otago.ac.nz> Message-ID: Richard, I must apologize, as my initial post was satirical. Unfortunately it seems I was too opaque; if anyone got the reference to Swift's "A Modest Proposal", they didn't make themselves known. I agree 100% with everything you wrote, and I am glad you stated it. I too am disappointed that maps dispensed with the key subtleties of your frames proposal. I see that SWI-Prolog has recently added "dicts", which, given their similarity to frames, I assume is your work. I do use SWI-Prolog often (pretty much for anything that's not a server of some sort) and am glad to see that I will be able to make use of frames in it. OTP 17 I believe is not past redemption; but I think beyond making my grievance known here, I can only hope that OTP 18 does not cement the current kitchen-sink map design with a misguided "magically parse JSON as some inefficient and non-typecheckable structure that just happens to look like JSON" library. Best, Chris P From samjbarney@REDACTED Wed Aug 27 22:12:24 2014 From: samjbarney@REDACTED (Samuel Barney) Date: Wed, 27 Aug 2014 14:12:24 -0600 Subject: [erlang-questions] Erlang on custom OS In-Reply-To: References: Message-ID: Sorry if this goes directly to you; first time using a mailing group. How exactly did you go about it? For instance, are you running off a specific distro? On Wed, Aug 27, 2014 at 1:55 PM, Chris Pacejo wrote: > On Wed, Aug 27, 2014 at 3:39 PM, Samuel Barney > wrote: > > I've had an idea churning in the back of my head for a while: Write a > custom > > threadless operating system which uses erlang for pretty much everything. > > I've written a couple of custom kernels before, but this would be my > first > > time porting a major project to one. Anyone have any experience porting > > Erlang to different platforms or an idea of where in the erlang source > code > > I should start looking to see what the MINIMAL requirements to compile > > erlang are? > > These people have Erlang running directly on the Xen hypervisor: > http://erlangonxen.org/ > > I've been working on my own non-serious-very-much-a-toy project to > build an OS in Erlang, running on Linux. (i.e. Erlang is the only > non-system process running; everything the user sees goes through the > Erlang VM.) I only mention it because you might find the same general > approach suitable: keep Linux around, just to provide the services > Erlang needs (including those you haven't implemented yet; e.g. native > TCP). Linux can be VERY efficient when it's running primarily a > single process, so you're not really losing performance that way. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Thu Aug 28 05:55:17 2014 From: me@REDACTED (Xiao Jia) Date: Thu, 28 Aug 2014 11:55:17 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> Message-ID: > > It was not fun, and I thinked "If I can get rid of these mutable > VARIABLES....". And in Java/PHP/Python I found the same problem here and > again. > But in such languages as C++/Java/... we are not forced to mutate variables so we can still employ some coding style/guidance of creating new objects instead of mutating existing objects most of the time. For example in C++ const int x1 = 1; const int x2 = x1 + 1; ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Aug 28 07:58:33 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 28 Aug 2014 17:58:33 +1200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> Message-ID: <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> On 28/08/2014, at 3:55 PM, Xiao Jia wrote: > But in such languages as C++/Java/... we are not forced to mutate variables so we can still employ some coding style/guidance of creating new objects instead of mutating existing objects most of the time. > > For example in C++ > const int x1 = 1; > const int x2 = x1 + 1; Books about concurrent programming in Java do strongly recommend using immutable objects where you can. That option is NOT available in C++. In C++, there is no garbage collector. Several people have put enormous effort into trying to get the C++ standard to at least allow garbage collection, but here we are with the third version of the C++ standard out and it's not there yet. Memory management is the programmer's job in C++, which means that any realistic C++ program *has* to use mutable variables or run out of memory in seconds. From alisdairsullivan@REDACTED Thu Aug 28 08:11:43 2014 From: alisdairsullivan@REDACTED (alisdair sullivan) Date: Wed, 27 Aug 2014 23:11:43 -0700 Subject: [erlang-questions] Why EEP-0018 "JSON bifs" (and conforming libraries) are "wrong" about object encoding (i.e. `[{}]`) In-Reply-To: References: Message-ID: <16F05440-2AB9-4F9E-8AB3-5E32B2165830@yahoo.ca> On Aug 26, 2014, at 2:30 PM, Ciprian Dorin Craciun wrote: > > The reason that I wrote this email is because I have invested > quite some time in writing a "few" JSON utility functions (including > complex schema validation, destructuring, etc.) which heavily use and > extend the "mochi" variant. Based on this experience and a small > analysis I've done today, I concluded that EEP-0018 would be quite > cumbersome for expressing any kind of extension without a lot of > pattern-matching to catch the extensions. However by no mean do I > expect developers to change their libraries to suite such a usage, I > only wanted to provide a counter-argument to EEP-0018. Moreover, now > that Erlang has hash objects, hopefully these can be used to express > objects, and this problem would go away. > > Hopefully I haven't offended anyone, (I apologize in advance,) > Ciprian. > if i were to write jsx today i?d still allow serialization of `[{}]` to the empty object ?{}? but i?d also probably allow `{[]}` also. i?d never deserialize json to a proplist though; maps only. i?ve been working on a small experimental attempt at a ?modern? json api here:https://github.com/talentdeficit/json -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Thu Aug 28 09:05:19 2014 From: me@REDACTED (Xiao Jia) Date: Thu, 28 Aug 2014 15:05:19 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: On Thu, Aug 28, 2014 at 1:58 PM, Richard A. O'Keefe wrote: > > Memory management is the programmer's job in C++, which > means that any realistic C++ program *has* to use mutable > variables or run out of memory in seconds. > > Sure, so can we maintain acyclic data structures (as in Erlang, as I understand) with smart pointers in order to eliminate most *manual* memory management and to write in such a style as coding in Erlang? In general maybe using value types, i.e. stack-allocated wrappers for heap-allocated memory (e.g. smart pointers), can help in such coding style? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tty.erlang@REDACTED Thu Aug 28 09:24:17 2014 From: tty.erlang@REDACTED (T Ty) Date: Thu, 28 Aug 2014 08:24:17 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: The entire availability of Erlang developers is a red herring. FP brings along its own set of advantages, one major observation is the smaller team size for the same output in comparison to Java/C++. Several universities in Europe cover Erlang in their courses. Personally having taught numerous Erlang/OTP courses in North America and Europe there are bodies of expertise scattered all over, heck even as far flung as Vietnam. Remember when Python first came out ? Folks were complaining about the lack of braces and how incorrect spaces and tabs can break your code. Absolute non-issue after a few days of coding. Erlang syntax is seldom a gotcha, problem areas with Erlang programming is typically concentrated on understanding recursion and to be honest you can avoid recursion using the 'lists' module. The 'if' expression is another problem area [looks like your normal 'if' doesn't act like your normal 'if'] and I usually tell students to skip that and use 'case' and if you are using 'case' may as well skip that and write a function (nod to Garrett Smith). Regardless if you decide to go with Akka or Erlang there is a learning or training component for either. The architecture, design and mind-set is sufficiently different that there is a need to start with a different set of fundamentals. On Wed, Aug 27, 2014 at 9:17 PM, Youngkin, Rich < richard.youngkin@REDACTED> wrote: > Hi again, > > Thanks for all the responses, they're very helpful. Thanks to Leonard for > the linkedIn discussion tip ( > https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556). > Despite a brief descent into a rambling flame post it's worth reading. > > I'm still trying to wrap my head around many of the comments given that my > Akka knowledge is only marginally better than knowing nothing about Akka. > > One comment that resonated with me is the need to choose the proper tool. > My sense is (and was) that both Erlang and Akka can be used effectively to > solve similar problems. The need to fit into the JVM ecosystem is one item > that might tilt one towards Akka. For other reasons the JVM might tilt one > towards Erlang (along other things like immutability and conciseness). > > To answer a question in Loic's original response, why did I raise this > question? See below for that, but I intentionally left the question > open-ended in order to get the wider range of responses. > > One of the reasons I raised the question is an argument I often hear > regarding the availability of skilled Erlang developers. While I think > this is generally a valid argument, I think it starts to become less of an > issue when the value of a functional approach using OTP-like capabilities > becomes important. IMO, the conceptual complexity of these 2 areas far > outweigh the cost of getting up to speed with Erlang syntax. In this > respect I think Erlang and Akka, at least Akka/Scala, will be fairly > similar in their learning curves. Any comments? > > Another reason I raised the question is that we're currently considering > refactoring our fairly monolithic Erlang app into a set of smaller, more > focused, services. This raised the previous question about the availability > of skilled Erlang developers. In pursuing this refactoring there's no > reason to chose any single technology for the entire set of new services. > So, the best tool for the job is very reasonable, keeping in mind that > there's an existing Erlang code base that mostly works pretty well. > > Thanks again for all the comments, keep them coming if you're so inclined. > I've found all of them useful. > > Cheers, > Rich > > > On 27 Aug 2014, at 11:34, Giovanni Giorgi <> wrote: > > >* Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges. > *> >* Anyway the questions I will do to myself will be: > *> >* Team know-how > *>* For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there. > *> As others have pointed out, 60 people is a *huge* team for an Erlang project. I doubt you need that many unless you?re building a monster of an app. The AXD 301 team had roughly that many Erlang programmers for almost 2 million lines of Erlang code; arguably, it was too many people, but the list of requirements was really what drove the size of the project. Basically, look at how many people are needed to wrap their collective heads around the functional requirements. Those guys should all be programming, and you?re not likely to need many more programmers than that. > > >* Erlang immutable state is a big hit in the long run. > *> > On the contrary. The long run is where immutability pays off, mainly in two ways: > > - Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid. > > - Performance. It may sound weird, but immutability and acyclic data structures really help the memory management subsystem as well as simplify scaling across multiple cores. The area where it hurts is mostly core that has to sequentially run through large data sets, flipping bits or making other small modifications along the way - the Dijkstra Shortest Path First algorithm comes to mind. But if you?re building a complex system with lots of concurrency, immutability will keep you sane and help your applications scale. Performance losses in this class of systems, using conventional coding techniques, are often due to code complexity as much as anything else: you lose the ability to reason about how the code behaves, and all those fancy tricks that can help performance in smaller systems will only make things worse. > > But of course it depends on what kind of system you?re building. Erlang is very performant for the kinds of system that it was designed for. There are lots of stories about Erlang-based systems handling outright crazy loads compared to the competition. > > The Java story is not particularly good when it comes to multicore. You really have to know what you?re doing, or have a problem that is embarrassingly parallel. The main multicore problem in Erlang is that it?s hard to come by as many cores as you think you can utilize. ;-) > >* On the other way, Java isolation is very strong. > * > > Actually, not compared to Erlang. The reason is shared (mutable) objects. If a thread crashes that shares data with other threads, you are basically lost. > > Since Erlang uses share-nothing concurrency with copying message passing, a dead process really doesn?t hurt the data of other processes, and can simply be swept away by the GC. > > >* Also JVM stability is very high. > *> Granted. So is the stability of the Erlang VM. > > >* Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing. > *> >* With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this. > *> If you just measure the amount of manpower that has gone into Java GC, it should be far superior to the Erlang GC, but GC is a much, much harder problem in Java than it is in Erlang. > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.http://feuerlabs.com > > > > _______________________________________________ > 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 Thu Aug 28 14:18:39 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 28 Aug 2014 08:18:39 -0400 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> Message-ID: <20140828121837.GS54532@ferdair.local> On 08/28, Xiao Jia wrote: > But in such languages as C++/Java/... we are not forced to mutate variables > so we can still employ some coding style/guidance of creating new objects > instead of mutating existing objects most of the time. > > For example in C++ > const int x1 = 1; > const int x2 = x1 + 1; > ... Ah but did the people writing the libraries you use think the same way? One of the advantages of Erlang is that because of its constraints, *everyone* programming in it ends up making decisions that are generally amenable to concurrency and to some extent, distribution. Those who don't tend to make libraries that hardly scale on a single node to begin with (with heavy bottlenecks and whatnot). There is value in having an entire community align their development style to what you tend to need, whether forced or not. From jesper.louis.andersen@REDACTED Thu Aug 28 14:40:29 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 28 Aug 2014 14:40:29 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <20140828121837.GS54532@ferdair.local> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <20140828121837.GS54532@ferdair.local> Message-ID: On Thu, Aug 28, 2014 at 2:18 PM, Fred Hebert wrote: > There is value in having an entire community align their development > style to what you tend to need, whether forced or not. > More importantly: when you write an Erlang application/library you buy into the core values of Erlang: * Isolation * Message passing by copying * Strict resource constraints and who owns resources * Error channels in the form of monitors and links * Fully preemptive multitasking among processes * Seperate heap per process with GC per-process * Purely functional core language * Asynchronous messaging with possible loss * Self-describing data layout in memory Erlang programmers cannot avoid any of these core values in any way when they write code. This is not true in Java/Akka, Go, Haskell, OCaml, C++, Python, Ruby, Node.js or what-have-you. In Erlang, any decent library is able to interoperate with other systems quite easily since it has to be isolated by construction. In almost every other language you have to worry about reentrant code, mutex locks around critical sections, that each application library has its own way of doing thread pools and so on. Of course, you can *pick* a style and follow it, blindly. But then you have to adapt any library you are going to use to this style. Node.js fares way better than the comptetion here because it did pick a writing style initially. It picked the wrong one, for several reasons, but consistency wins. Go actually doesn't fare much better here than C++ since it also requires the programmer to be wary of when a given subsystem is safe to use or not. Simply because there is shared memory and shared memory forces you to potentially abort all of the program on any memory-inconsistency error, however small. As an aside, this is also why it is usually not that beneficial to speak about how performant Erlang programs are compared to their counterparts. There is a price for these core values in execution, and you have to pay that price in Erlang. Once you make that sacrifice however, you get the value of robustness and stability. And, perhaps more importantly, maintainability; the by far most costly endeavour in any software project. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vychodil.hynek@REDACTED Thu Aug 28 15:09:57 2014 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Thu, 28 Aug 2014 15:09:57 +0200 Subject: [erlang-questions] Are binaries relocatable? Message-ID: Hi all, I would like to know if binaries are relocatable. If I have binary parameter ErlNifBinary bin; if (!enif_inspect_binary(env, argv[0], &bin)) return enif_make_badarg(env); I store binary in mine own environment ErlNifEnv *priv_env = enif_alloc_env(); enif_make_copy(priv_env, argv[0]); Can I then rely on bin.data pointing into same memory until I free enif_free_env(priv_env) ? I'm asking because I would like to avoid copying and share data or even return it using enif_make_resource_binary to catch and count references. I have code which makes copy of binary data but when I switch to reference bin.data it hangs whole VM. I would like to know if I make some mistake in mine code and it should work or it is wrong idea at all. Thanks Hynek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Aug 28 15:20:43 2014 From: ok@REDACTED (ok@REDACTED) Date: Fri, 29 Aug 2014 01:20:43 +1200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: > On Thu, Aug 28, 2014 at 1:58 PM, Richard A. O'Keefe > wrote: > >> >> Memory management is the programmer's job in C++, which >> means that any realistic C++ program *has* to use mutable >> variables or run out of memory in seconds. >> >> > Sure, so can we maintain acyclic data structures (as in Erlang, as I > understand) with smart pointers in order to eliminate most *manual* memory > management and to write in such a style as coding in Erlang? (a) Smart pointers *are* manual memory management. You have to remember to use them all the time, because if you forget and use the language's native pointers, you're sunk. There are several kinds to choose from, and you have to understand the consequences. Using the wrong kind of xxxx_ptr can be disastrous. (b) Smart pointers are not just manual memory management, they are a particular *style* of memory management. A style that makes *using* a smart pointer quite expensive. In fact, there is space bloat as well: 'smart pointers' really point to 'control blocks' which contain built-in pointers to object (amongst other fields). (c) C++11 smart pointers are sort of thread safe and sort of not. Threads can safely manipulate *different* smart pointers to the same *controi block*. If you're dealing with immutable objects the fact that this doesn't make access to the pointed-to object safe won't matter; the fact that concurrent access to the smart pointer itself may. > > In general maybe using value types, i.e. stack-allocated wrappers for > heap-allocated memory (e.g. smart pointers), can help in such coding > style? C++ never saw a problem it couldn't solve with a few extra templates and some time/space bloat. This is _not_ the way C++ "wants" to be used, and if you try to write Erlang in C++, C++ will punish you by making conceptually simple things look fiendishly complicated. Nor in that case are you likely to get the performance C++ is celebrated for. From jon@REDACTED Thu Aug 28 15:35:23 2014 From: jon@REDACTED (Jon Schneider) Date: Thu, 28 Aug 2014 14:35:23 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: <049bc1958e9107ddcba1889f51944648.squirrel@mail.jschneider.net> By coincidence only last week I fixed a C++ bug where something was being newed using a slightly overcomplicated factory but under some circumstances involving an exception not being deleted. Unfortunately the something held a lock and broke future instances of itself. I used the standard smart_ptr to fix this one and tidy away the deletes completely. I think the moral is if you're buying into (say) C++ best do it fully. Jon > (b) Smart pointers are not just manual memory management, > they are a particular *style* of memory management. From me@REDACTED Thu Aug 28 16:18:18 2014 From: me@REDACTED (Xiao Jia) Date: Thu, 28 Aug 2014 22:18:18 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: I totally agree with your points about libraries and community. Isolation is indeed (ideally) very important for C++ programs that I have experience with. And yes, smart pointers need a strict discipline to be helpful. I just imagined and never tried to write C++ in Erlang style so I can hardly say anything about language usability and performance in this case. On Thu, Aug 28, 2014 at 8:40 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > As an aside, this is also why it is usually not that beneficial to speak > about how performant Erlang programs are compared to their counterparts. > There is a price for these core values in execution, and you have to pay > that price in Erlang. > On Thu, Aug 28, 2014 at 9:20 PM, wrote: > Nor in that case are you likely > to get the performance C++ is celebrated for. > So what if we have both Erlang(-style) concurrency and C++ performance (for number crunching, ...) in some new language (yet to be developed)? Regardless of community size, reusable libraries and other "human-related" issues commonly faced by any new language, can we say such a new language is better than both Erlang and C++ because it (potentially) beats both in performance and concurrency, respectively? -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Thu Aug 28 16:24:38 2014 From: me@REDACTED (Xiao Jia) Date: Thu, 28 Aug 2014 22:24:38 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: That is to say, would it be better if we have a new language with strengths from both Erlang and C++? From my understanding we can do as good as Erlang/C++ in concurrency/performance, and they should not conflict with each other by nature. On Thu, Aug 28, 2014 at 10:18 PM, Xiao Jia wrote: > I totally agree with your points about libraries and community. Isolation > is indeed (ideally) very important for C++ programs that I have experience > with. > > And yes, smart pointers need a strict discipline to be helpful. I just > imagined and never tried to write C++ in Erlang style so I can hardly say > anything about language usability and performance in this case. > > On Thu, Aug 28, 2014 at 8:40 PM, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > >> As an aside, this is also why it is usually not that beneficial to speak >> about how performant Erlang programs are compared to their counterparts. >> There is a price for these core values in execution, and you have to pay >> that price in Erlang. >> > > On Thu, Aug 28, 2014 at 9:20 PM, wrote: > >> Nor in that case are you likely >> to get the performance C++ is celebrated for. >> > > So what if we have both Erlang(-style) concurrency and C++ performance > (for number crunching, ...) in some new language (yet to be developed)? > Regardless of community size, reusable libraries and other "human-related" > issues commonly faced by any new language, can we say such a new language > is better than both Erlang and C++ because it (potentially) beats both in > performance and concurrency, respectively? > -- Regards, Xiao Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Aug 28 17:19:24 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 28 Aug 2014 19:19:24 +0400 Subject: [erlang-questions] How to debug dirty NIF? Message-ID: I'm running CPU bound task (make thumbnails from video) in a NIF under erlang 17 (erts 6.0) I'm using dirty nif scheduling: static ERL_NIF_TERM yuv2jpeg0(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { .... } static ERL_NIF_TERM async_jpeg(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { ERL_NIF_TERM result = yuv2jpeg0(env, argc, argv); return enif_schedule_dirty_nif_finalizer(env, result, enif_dirty_nif_finalizer); } static ERL_NIF_TERM yuv2jpeg(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { return enif_schedule_dirty_nif(env, ERL_NIF_DIRTY_JOB_CPU_BOUND, async_jpeg, argc, argv); } I see strange situation: none of CPU core is not 100% loaded, but processes that are calling yuv2jpeg function are hanging in this function: (flussonic@REDACTED)3> process_info(pid(0,961,0)). [{current_function,{avcodec,yuv2jpeg0,4}}, {initial_call,{proc_lib,init_p,5}}, {status,runnable}, {message_queue_len,11}, {messages,[{jpeg,[{video_frame,video,37885047.833333336, 37885047.833333336,0,h264,keyframe,1, <<0,0,0,2,9,240,0,0,21,...>>, I suppose that I could meet the old problem with wrong scheduler behaviour when NIF is using thread for too long. yuv2jpeg takes usually about 2-4 milliseconds to run. Is it possible to debug this situation? Can I somehow ask erlang if it decided that some scheduler is considered idle? I launch erlang so: erlang/erts-6.0/bin/beam.smp -K true -Bi -A 100 -a 32 -stbt s -MBas aoffcaobf -MBacul 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Thu Aug 28 18:47:55 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Thu, 28 Aug 2014 12:47:55 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang Message-ID: I'd like to tap the collective wisdom of the group for their experiences in onboarding fresh-out-of-college programmers who are new to Erlang. This is assuming the new programmer has mostly imperative experience (C/C++/Java) and have had a fleeting glimpse of functional through Haskell. I'm of the mindset to have them work through a book or two over the 1st couple of weeks with plenty of rubber ducking and/or pairing on simple exercises. After that maybe have them work on a simple feature or two in some prototypical work we're doing on the side, and of course sending them off to the first available 'bootcamp'/training session available. What have you found is the best way to introduce them to the language and bring them up to a level where they can start standing on their own feet? Are there any specific resources (books/sessions/tutorials etc) you've found useful in the past? Any other recommendations? Thanks, Leonard --- From juan.facorro@REDACTED Thu Aug 28 20:14:36 2014 From: juan.facorro@REDACTED (Juan Facorro) Date: Thu, 28 Aug 2014 11:14:36 -0700 (PDT) Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: <4e74d4f2-54ff-4191-a9a0-7f3fd88554ac@googlegroups.com> Hi Leonard, I've been working at Inaka for the past three months as an Erlang developer and it was the first time I had any contact with the language, although I am far from "fresh out of college" and I had some previous practice with other functional languages (Common Lisp, Clojure and some Haskell), you might find my experience still useful. Fred H?bert's "Learn you some Erlang" was a really good resource to get me started with the basics of the language. The first few chapters are mostly about functional programming concepts, which serves as good practice if the person does not have that much experience with FP. Later on the subjects of concurrency, OTP and releases are explained, which is where the real meat is IMO, although in all fairness I still haven't read the chapters about distributed Erlang systems, sockets, ETS and other subjects. Some of these last topics I learned by doing, like common test, maps and such. Another thing which was pretty cool was that I got to work on an open source project [1] (a tiny one but still) the same week I started working with Erlang. It got me started with things such as behaviors, unit testing, make & Makefiles, rebar, etc. I learned a lot from just having a project to work on, plus I felt like I was not only learning but doing something useful. The Erlang team at Inaka had a list of stuff that needed to be done, so after I finished with the tiny project, we voted on what I would do next. The project that we voted turned out to be a little more ambitious (technically speaking) than my previous one, but it was lots of fun [2]. It was really cool to have a say on what my next project would be. This project lasted around a month or so, after which I started working on a client project :D. I guess the learning approach should be adapted to the learner, in my case I'm more of a hands-on person with a keen interest in knowing how stuff works, so having a friendly reference book (Learn you some...) while working on different projects was pretty awesome for me and I think I turned out a pretty decent Erlang developer, only time will tell :P Hope it helps, Juan [1]: https://github.com/inaka/lasse [2]: https://github.com/inaka/elvis On Thursday, August 28, 2014 1:48:08 PM UTC-3, Leonard Boyce wrote: > I'd like to tap the collective wisdom of the group for their > > experiences in onboarding fresh-out-of-college programmers who are new > > to Erlang. This is assuming the new programmer has mostly imperative > > experience (C/C++/Java) and have had a fleeting glimpse of functional > > through Haskell. > > > > I'm of the mindset to have them work through a book or two over the > > 1st couple of weeks with plenty of rubber ducking and/or pairing on > > simple exercises. > > > > After that maybe have them work on a simple feature or two in some > > prototypical work we're doing on the side, and of course sending them > > off to the first available 'bootcamp'/training session available. > > > > What have you found is the best way to introduce them to the language > > and bring them up to a level where they can start standing on their > > own feet? > > > > Are there any specific resources (books/sessions/tutorials etc) you've > > found useful in the past? > > > > Any other recommendations? > > > > Thanks, > > > > Leonard > > --- > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions From arthurcolle@REDACTED Thu Aug 28 19:42:19 2014 From: arthurcolle@REDACTED (=?UTF-8?Q?Arthur_Coll=C3=A9?=) Date: Thu, 28 Aug 2014 13:42:19 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: I am in my last year as a CS major at the University of Maryland. I interned at Goldman this summer where I had heard that Erlang was used in production but I didn't work on it at all, and it was this as well as hearing that Facebook used it initially and also that its last acquisition Whatsapp used it for its backend, these various anecdotes contributed to my desire to begin learning it. In my coursework we covered OCaml and Prolog, and Erlang has a number of features that are very similar to both. (pattern matching from both, and the syntax and "rules-based" logic of Prolog). Message passing seemed like a model of concurrent programming that was very different than the semaphore/mutex/lock based model of threading so I was curious about it and bought "Programming Erlang" 2nd edition by Joe Armstrong (have to admit its a real trip seeing your name come up on emails the day after I signed onto the email list!), "Erlang" by Simon St. Laurent, and those have been my primary sources, as well as the documentation. Learning OTP/Rebar is proving to be more difficult but there are a number of online sources (usually blog posts/tutorials) that make it easier. Not really what you were looking for I suppose but I'm almost fresh out of college and that was my background for wanting to learn Erlang. Maybe describe its important use cases and how they apply to your situation. The syntax can be off putting to newcomers so you really want to highlight its strengths. Like setting up a gen_server and hot swapping code is ridiculously easy in Erlang and in other languages it would be such a pain. Just some thoughts! -Arthur On Thursday, August 28, 2014, Leonard Boyce wrote: > I'd like to tap the collective wisdom of the group for their > experiences in onboarding fresh-out-of-college programmers who are new > to Erlang. This is assuming the new programmer has mostly imperative > experience (C/C++/Java) and have had a fleeting glimpse of functional > through Haskell. > > I'm of the mindset to have them work through a book or two over the > 1st couple of weeks with plenty of rubber ducking and/or pairing on > simple exercises. > > After that maybe have them work on a simple feature or two in some > prototypical work we're doing on the side, and of course sending them > off to the first available 'bootcamp'/training session available. > > What have you found is the best way to introduce them to the language > and bring them up to a level where they can start standing on their > own feet? > > Are there any specific resources (books/sessions/tutorials etc) you've > found useful in the past? > > Any other recommendations? > > Thanks, > > Leonard > --- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpezely@REDACTED Thu Aug 28 20:29:32 2014 From: dpezely@REDACTED (Daniel Pezely) Date: Thu, 28 Aug 2014 18:29:32 +0000 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: Having facilitated this type of learning curve many times, it ultimately comes down to holding someone's interest. Give them a driving problem to solve that is relevant and interesting to them, and a resourceful person will find ways to teach themselves. That said, for Erlang specifically, I've given these recommendations and caveats: 1. Start with Learn You Some Erlang-- low barrier to entry, and it's just what you need to get into the material. 2. Get Armstrong's 2nd Edition-- more thorough for explaining *why* things are the way they are. 3. Go through the "4 day course" http://www.erlang.org/course/course.html It doesn't have to be sequential; in fact, I'd suggest taking a break from one to begin the next and interleave the material to keep it fresh. But everyone learns differently. Some would do better by following screencasts as their starting point. Others should begin by shadowing someone with more experience or getting a tour of existing code for which they already understand something about its user-facing features. -Daniel -- dpezely@REDACTED ________________________________________ From: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED] on behalf of Leonard Boyce [leonard.boyce@REDACTED] Sent: Thursday, August 28, 2014 9:47 AM To: Erlang-Questio. Subject: [erlang-questions] Onboarding programmers who are new to Erlang I'd like to tap the collective wisdom of the group for their experiences in onboarding fresh-out-of-college programmers who are new to Erlang. This is assuming the new programmer has mostly imperative experience (C/C++/Java) and have had a fleeting glimpse of functional through Haskell. I'm of the mindset to have them work through a book or two over the 1st couple of weeks with plenty of rubber ducking and/or pairing on simple exercises. After that maybe have them work on a simple feature or two in some prototypical work we're doing on the side, and of course sending them off to the first available 'bootcamp'/training session available. What have you found is the best way to introduce them to the language and bring them up to a level where they can start standing on their own feet? Are there any specific resources (books/sessions/tutorials etc) you've found useful in the past? Any other recommendations? Thanks, Leonard --- _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From richard.youngkin@REDACTED Thu Aug 28 22:22:50 2014 From: richard.youngkin@REDACTED (Youngkin, Rich) Date: Thu, 28 Aug 2014 14:22:50 -0600 Subject: [erlang-questions] CPU overhead of supervision and lager Message-ID: Hi all, I've made a recent change to an app to improve its supervision strategy and to use lager to help with things like log readability and log rotation. Regarding supervision, the app was changed from a shallow-wide supervision hierarchy to one that has an intermediate level of supervision. The result was to go from 1 supervisor that managed about 20 gen_servers to adding around 5 supervisors at the 2nd level that manage 3 to 5 gen_servers each. I stress tested the application before and after these changes and got some unexpected results. In the post-change test the application exited without writing anything to the sasl log (or the lager crash and error logs). The sasl log didn't show the expected start up messages though so I'm suspicious that sasl log was somehow corrupted. The application log did contain all the expected entries up until the point of failure. CPU utilization at the time of failure was at 300% on a 4 CPU box. I wasn't actively monitoring memory use, but I don't have a strong reason to suspect that was a problem (other than the application exiting). The pre-change test went well past the load level that caused the post-change test to fail. The only difference between the 2 versions, aside from the supervision and lager changes, was that the pre-change version was using about 10% less CPU for the same load. One item of note, using Observer I noticed that lager (lager_event) was getting quite a bit of the CPU resources measured in terms of reductions. Given the lack of sasl log or lager error/crash log information, I'm having a hard time understanding how or why these changes would cause a failure at the same processing load and why the pre-change version was able to scale well beyond the post-change version's failure point. The slight change in CPU utilization doesn't appear significant given that the CPU load at the time of the failure was more or less at 75% of capacity. I'm wondering if anyone has seen similar behavioral differences when introducing supervision and/or lager, and if supervision and lager might account for the slight CPU utilization differences, at the same load, between the 2 versions. Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Thu Aug 28 22:58:13 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 28 Aug 2014 15:58:13 -0500 Subject: [erlang-questions] CPU overhead of supervision and lager In-Reply-To: References: Message-ID: If you didn't change your calls to error_logger to lager calls (with the level included), you can't take advantage of the optimizations that lager provides, aside from it not ballooning in memory usage. If you use the latter and the built-in parse_transform, log messages will be filtered on the sender side, not at the event handler, which scales much better under load. On Thu, Aug 28, 2014 at 3:22 PM, Youngkin, Rich wrote: > Hi all, > > I've made a recent change to an app to improve its supervision strategy and > to use lager to help with things like log readability and log rotation. > > Regarding supervision, the app was changed from a shallow-wide supervision > hierarchy to one that has an intermediate level of supervision. The result > was to go from 1 supervisor that managed about 20 gen_servers to adding > around 5 supervisors at the 2nd level that manage 3 to 5 gen_servers each. > > I stress tested the application before and after these changes and got some > unexpected results. > > In the post-change test the application exited without writing anything to > the sasl log (or the lager crash and error logs). The sasl log didn't show > the expected start up messages though so I'm suspicious that sasl log was > somehow corrupted. The application log did contain all the expected entries > up until the point of failure. CPU utilization at the time of failure was at > 300% on a 4 CPU box. I wasn't actively monitoring memory use, but I don't > have a strong reason to suspect that was a problem (other than the > application exiting). > > The pre-change test went well past the load level that caused the > post-change test to fail. The only difference between the 2 versions, aside > from the supervision and lager changes, was that the pre-change version was > using about 10% less CPU for the same load. One item of note, using > Observer I noticed that lager (lager_event) was getting quite a bit of the > CPU resources measured in terms of reductions. > > Given the lack of sasl log or lager error/crash log information, I'm having > a hard time understanding how or why these changes would cause a failure at > the same processing load and why the pre-change version was able to scale > well beyond the post-change version's failure point. The slight change in > CPU utilization doesn't appear significant given that the CPU load at the > time of the failure was more or less at 75% of capacity. > > I'm wondering if anyone has seen similar behavioral differences when > introducing supervision and/or lager, and if supervision and lager might > account for the slight CPU utilization differences, at the same load, > between the 2 versions. > > Thanks, > Rich > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ From ok@REDACTED Fri Aug 29 00:10:41 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 29 Aug 2014 10:10:41 +1200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> Message-ID: <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> On 29/08/2014, at 2:18 AM, Xiao Jia wrote: > > So what if we have both Erlang(-style) concurrency and C++ performance (for number crunching, ...) in some new language (yet to be developed)? C++ performance relies on several things. One of them is the type system. We know how to get close-to-C performance in a functional language; Xavier Leroy did an impressive job with OCaml. It depends on a good type system. The trick is to extend the type system to send and receive. This seems like the weakest aspect of Dialyzer: I cannot say "X is a process id for a process that expects messages of type Y". Get the type system right and the rest will follow. Of course, one of Erlang's strengths has always been that you don't *have* to use types. Having said that, I must emphasise once more that "I am writing in C++" does NOT imply "my code is efficient". I have known *interpreted* Scheme to run faster than *compiled* C++. Memory management is a tricky subject and manual (delete) or semi-manual (smart pointers) is NOT always faster. > Regardless of community size, reusable libraries and other "human-related" issues commonly faced by any new language, can we say such a new language is better than both Erlang and C++ because it (potentially) beats both in performance and concurrency, respectively? One of the saddest errors in classical philosophy was the use of "better" as though it was unequivocal. Let E be Erlang, C be C++, and N be the new language. It is possible that N >= E (concurrency) N > E (performance) N < E (readability) N < E (human error rate) N > C (concurrency) N >= C (performance) N < C (readability -- unlikely but for the sake of argument) N < C (human error rate -- again unlikely but still) We would then have to say that N is better than E and C AND ALSO that N is worse than E and C. From rtrlists@REDACTED Fri Aug 29 00:35:46 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 28 Aug 2014 23:35:46 +0100 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: Hi Leonard, one of the most important lessons to impart, is showing that there exist several really big different ways of tackling programming problems: imperative, object oriented (class based, object copying, multi dispatch, message passing, ...), functional, declarative, logic, array, concurrent, parallel, distributed, ... And that these overlap in a lot of places. In essence, it is about open minds, the ability to listen to someone else's opinion, without rejecting it outright. At a practical level, for Erlang in particular, this could mean: teach single assignment, pattern matching (aka deconstruction), list based recursion, list and binary comprehension, process linking, supervision and "let it crash". On top of that, encourage the examination of the libraries that come as standard with the Erlang release. Any of the existing Erlang books can help. Also, some people learn better in courses, others from books, most need some kind of practice based in reality. Made up simple problems are nice for exposition, but lack in imparting knowledge that sticks. Regards, Robby On Aug 28, 2014 5:48 PM, "Leonard Boyce" wrote: > I'd like to tap the collective wisdom of the group for their > experiences in onboarding fresh-out-of-college programmers who are new > to Erlang. This is assuming the new programmer has mostly imperative > experience (C/C++/Java) and have had a fleeting glimpse of functional > through Haskell. > > I'm of the mindset to have them work through a book or two over the > 1st couple of weeks with plenty of rubber ducking and/or pairing on > simple exercises. > > After that maybe have them work on a simple feature or two in some > prototypical work we're doing on the side, and of course sending them > off to the first available 'bootcamp'/training session available. > > What have you found is the best way to introduce them to the language > and bring them up to a level where they can start standing on their > own feet? > > Are there any specific resources (books/sessions/tutorials etc) you've > found useful in the past? > > Any other recommendations? > > Thanks, > > Leonard > --- > _______________________________________________ > 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 Fri Aug 29 01:43:13 2014 From: raould@REDACTED (Raoul Duke) Date: Thu, 28 Aug 2014 16:43:13 -0700 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: also: (do you agree or not, i am curious) teach that one should reach for OTP first, rather than assuming one will do it at the "low level" of rolling your own stuff from "base" erlang-w/out-otp. On Thu, Aug 28, 2014 at 3:35 PM, Robert Raschke wrote: > Hi Leonard, > > one of the most important lessons to impart, is showing that there exist > several really big different ways of tackling programming problems: > imperative, object oriented (class based, object copying, multi dispatch, > message passing, ...), functional, declarative, logic, array, concurrent, > parallel, distributed, ... And that these overlap in a lot of places. > > In essence, it is about open minds, the ability to listen to someone else's > opinion, without rejecting it outright. > > At a practical level, for Erlang in particular, this could mean: teach > single assignment, pattern matching (aka deconstruction), list based > recursion, list and binary comprehension, process linking, supervision and > "let it crash". On top of that, encourage the examination of the libraries > that come as standard with the Erlang release. > > Any of the existing Erlang books can help. Also, some people learn better in > courses, others from books, most need some kind of practice based in > reality. Made up simple problems are nice for exposition, but lack in > imparting knowledge that sticks. > > Regards, > Robby > > On Aug 28, 2014 5:48 PM, "Leonard Boyce" > wrote: >> >> I'd like to tap the collective wisdom of the group for their >> experiences in onboarding fresh-out-of-college programmers who are new >> to Erlang. This is assuming the new programmer has mostly imperative >> experience (C/C++/Java) and have had a fleeting glimpse of functional >> through Haskell. >> >> I'm of the mindset to have them work through a book or two over the >> 1st couple of weeks with plenty of rubber ducking and/or pairing on >> simple exercises. >> >> After that maybe have them work on a simple feature or two in some >> prototypical work we're doing on the side, and of course sending them >> off to the first available 'bootcamp'/training session available. >> >> What have you found is the best way to introduce them to the language >> and bring them up to a level where they can start standing on their >> own feet? >> >> Are there any specific resources (books/sessions/tutorials etc) you've >> found useful in the past? >> >> Any other recommendations? >> >> Thanks, >> >> Leonard >> --- >> _______________________________________________ >> 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 Fri Aug 29 02:07:39 2014 From: zxq9@REDACTED (zxq9) Date: Fri, 29 Aug 2014 09:07:39 +0900 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: <5915615.gjkV32RomK@changa> Writing from my experience in a multilingual and multi-paradigm environment (both computer and natural langauges)... On 2014?8?28? ??? 12:47:55 Leonard Boyce wrote: > I'd like to tap the collective wisdom of the group for their > experiences in onboarding fresh-out-of-college programmers who are new > to Erlang. This is assuming the new programmer has mostly imperative > experience (C/C++/Java) and have had a fleeting glimpse of functional > through Haskell. If they've had more than a "fleeting" glimpse in Haskell, Scheme or even C, Python or Ruby done in a functional(ish) way then count yourself lucky. More to the point, if the first quarter of LYSE, LYAH, Real World Haskell or SICP wouldn't be entirely new to their mind then you're dealing with someone from a decent school or who has a genuine interest and you have absolutely nothing to worry about. Teaching these people isn't necessary -- giving them a problem and a partner who has been around a little while is all that is needed. One caveat: "give them a partner" means someone who is there, in person. I don't like the phrase "pair programming" because it brings all the XP buzzword baggage along with it -- but poisoned language aside, this is the essence of what I mean. Two people, one keyboard, unrestricted access to knowledge resources (including other people). I've had some great successes with remote workers, but nothing compares to having a real person, really there. > I'm of the mindset to have them work through a book or two over the > 1st couple of weeks with plenty of rubber ducking and/or pairing on > simple exercises. [1] This sort of process can occur in parallel (and naturally will) for the sort of newcomer I mention above: the ones for whom the first quarter of beginner's literature isn't completely new. Keep a small library handy and in view of a place they will constantly see and magical things will happen. Its best if the senior partner of the coding duo is familiar enough with a few of the books to point out references as new ideas are encountered. Directing this process is not necessary if you have the right sort of person and they have a smidgen of a background. Giving time for it to happen, however, is critical. Standing back for a bit and letting someone learn is the part I see most often gotten wrong. Sometimes it is hard to do, depending on whatever other business pressures you're facing at the time. OTOH, if you're dealing with someone who lacks a functional background entirely... I prefer to start out with something totally alien up front, namely SICP, and see how they do with it.[2] They don't have to master all the material -- what you want is for them to see the basic functional list operations in use, see a data structure implemented as a higher order function, see a Java-style object built out of functions, and understand the difference between iterative/recursive processes and understand the independence of that idea from the idea of a recursive function definition which might create either sort of process. I've thought about writing a pre-SICP short text in something closer to their experience, like Python, but haven't because I'm still on the fence about whether there really is a value in shocking the mind fully at first. In particular, Scheme's near lack of syntax seems to be a very healthy thing for early learning and makes SICP the most speedy entry to flexible ways of thinking about programs I've yet encountered, regardless of the person's prior background. The lack of syntactic sugar forces the learner to reconsider much, which is the whole point. After those bits of SICP, showing them the JSON parser example in Real World Haskell is a big winner. That single example and its commentary gives precisely the sort of background necessary to understand Joe's discussions in Programming Erlang. If your new guy's head hasn't exploded yet (but its totally OK if he's still a bit confused on some details) then you've got the right person. At this point I would feel comfortable handing them over to an experienced programming partner, point them toward LYSE, and advise them to re-read SICP to completion. All of this requires a certain culture of interested exploration within the company, and that's not always an easy thing to create, maintain or find. More of my actual job these days is keeping an eye on the temperature of my working groups than actually coding, precisely because this sort of environment is somewhat delicate. -Craig [1] A note on "pairing on simple exercises". As much of your code as possible should be purely functional (as in, referentially transparent). It follows that you want as much of your code as possible to be dealing with rather simple things. This means that nearly all your production code that isn't doing I/O (in some fashion) should *be* a bunch of simple exercises. The syntax and semantics of LangA or LangB are the trivial problem, how to break the problem into (literally) simple exercises is the real trick an FP newcomer needs to see -- the actual typing part and the details of what characters are used is not important. [2] I particularly like this with the Japanese translation because its a *hard* translation into serious, unambiguous, non-kana, no-cognate Japanese which itself is alien to the cool web kids. Granted, this particular detail is pretty region-specific, of course, and is a bit of a trial by fire. But I'm so absolutely disgusted with Rails and Java types who show up with their Macs, spewing buzzwords as if they make sense, looking for something "cool" and "social" to do on the "web" -- all in incomprehensible katakanized English- injected slangy Japanese -- that I want them to quit right away if a technical translation performed by a mathematician turns them off. From zxq9@REDACTED Fri Aug 29 02:17:04 2014 From: zxq9@REDACTED (zxq9) Date: Fri, 29 Aug 2014 09:17:04 +0900 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: <2079423.97BhUFd3WZ@changa> On 2014?8?28? ??? 16:43:13 Raoul Duke wrote: > also: (do you agree or not, i am curious) teach that one should reach > for OTP first, rather than assuming one will do it at the "low level" > of rolling your own stuff from "base" erlang-w/out-otp. I know this wasn't directed at me, but its an important point, IMO. In my experience teaching someone OTP straight away results in the Erlang equivalent of boiler-plate. A lot of unnecessary gen_server stuff, for example. Its similar to a Java programmer starting out with Python and being class happy and writing setters and getters everywhere. I've found it better to instead pose different bits that OTP handles as problems first, in whatever language, and letting the person work through the issues involved themselves so they know where the problem areas actually are first. Then, showing them OTP is this "wow, thank goodness someone wrote all *that* already!" sort of experience, and they have a firm grip on just what tools are being provided instead of wandering around with this vague sense of problem->tool applicability. Fred seems to made a deliberate effort at this in LYSE and to great effect. The downside is that something like LYSE takes more time to get through than a blog tutorial intended for copypasta programming -- but that's time well spent by my way of thinking. -Craig From lloyd@REDACTED Fri Aug 29 02:35:01 2014 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Thu, 28 Aug 2014 20:35:01 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: <5915615.gjkV32RomK@changa> References: <5915615.gjkV32RomK@changa> Message-ID: Hello, This from a self-taught non-professional programmer: When I discovered Erlang I had experience with BASIC, forth, Cold Fusion, and a smidgen of Python. So you could say I was basically ignorant. I bought over a number of months all the, at the time, big three books. Read, reread, and even tried some of the simpler examples. I was too lazy to type in the longer examples so my learning curve suffered proportionally. But then, slowly, I began to "get it." I even wrote a gen_server or two, but nothing production worthy. Patient and generous responses to my "Mickey the Dunce" queries to the Erlang community, including the amazing Zotonic bunch, definitely helped. The big aha moment was when I learned how to read Erlang OTP source code. Now I'm struggling to understand how to architect more ambitious Erlang projects, e.g. When to use concurrent process and supervisors and when not and how to orchestrate them into beautiful music. No doubt the concepts are there before my eyes. But I have yet to "get it." All the best, LRP Sent from my iPad From sdl.web@REDACTED Fri Aug 29 03:25:54 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 29 Aug 2014 09:25:54 +0800 Subject: [erlang-questions] Onboarding programmers who are new to Erlang References: <5915615.gjkV32RomK@changa> Message-ID: On 2014-08-29 09:07 +0900, zxq9 wrote: > After those bits of SICP, showing them the JSON parser example in Real World > Haskell is a big winner. That single example and its commentary gives > precisely the sort of background necessary to understand Joe's discussions in > Programming Erlang. I am curious if any bits in Joe's book that are particularly challenging. I don't want to miss anything important Joe has written. Cheers, Leo From ok@REDACTED Fri Aug 29 03:34:18 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 29 Aug 2014 13:34:18 +1200 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: <2079423.97BhUFd3WZ@changa> References: <2079423.97BhUFd3WZ@changa> Message-ID: <909722D0-7071-4A89-8697-4A7FE007D45B@cs.otago.ac.nz> On 29/08/2014, at 12:17 PM, zxq9 wrote: > On 2014?8?28? ??? 16:43:13 Raoul Duke wrote: >> also: (do you agree or not, i am curious) teach that one should reach >> for OTP first, rather than assuming one will do it at the "low level" >> of rolling your own stuff from "base" erlang-w/out-otp. Amongst other things, surely this depends on *why* you are teaching Erlang. Starting next week, I'll be teaching Erlang to some 4th year students for 6 weeks. The aim is not to turn them into even mediocre Erlang programmers but to show them a way of doing concurrency that is not POSIX threads and not Java threads. I want them to come away thinking "engineering" not "magic". For this purpose, "lifting the hood" and showing them the basics is exactly right. Erlang is a *means* in this course, not an *end*. For other purposes, getting people to use some of Erlang's behaviours first might be the best way to get them writing interesting code, and then you could explain how it works later. Like the way we get people using hash tables in Python in year 1 these days, and then explaining them in year 2. Of course, this has its down side. It is unpleasantly common for our 3rd year students to automatically use ArrayList whenever they want a sequence instead of wondering whether T[] might be better; I have to spend a week or two in 3rd year trying to un-teach this practice. I suspect the same thing might happen with OTP. From rvirding@REDACTED Fri Aug 29 03:08:52 2014 From: rvirding@REDACTED (Robert Virding) Date: Fri, 29 Aug 2014 03:08:52 +0200 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: <2079423.97BhUFd3WZ@changa> References: <2079423.97BhUFd3WZ@changa> Message-ID: Another problem with going to straight into OTP behaviours is that they hide the concurrency, you can write a large full fledged application without a ! or receive in sight. There is of course nothing wrong with this per se, but sometimes people miss the fact that there is concurrency here and everything is running in separate processes and communicating with messages. They see gen_server:call as a function call. This is definitely a problem. Robert On 29 August 2014 02:17, zxq9 wrote: > On 2014?8?28? ??? 16:43:13 Raoul Duke wrote: > > also: (do you agree or not, i am curious) teach that one should reach > > for OTP first, rather than assuming one will do it at the "low level" > > of rolling your own stuff from "base" erlang-w/out-otp. > > I know this wasn't directed at me, but its an important point, IMO. > > In my experience teaching someone OTP straight away results in the Erlang > equivalent of boiler-plate. A lot of unnecessary gen_server stuff, for > example. > Its similar to a Java programmer starting out with Python and being class > happy and writing setters and getters everywhere. > > I've found it better to instead pose different bits that OTP handles as > problems first, in whatever language, and letting the person work through > the > issues involved themselves so they know where the problem areas actually > are > first. Then, showing them OTP is this "wow, thank goodness someone wrote > all > *that* already!" sort of experience, and they have a firm grip on just what > tools are being provided instead of wandering around with this vague sense > of > problem->tool applicability. > > Fred seems to made a deliberate effort at this in LYSE and to great > effect. The > downside is that something like LYSE takes more time to get through than a > blog tutorial intended for copypasta programming -- but that's time well > spent > by my way of thinking. > > -Craig > _______________________________________________ > 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 Fri Aug 29 03:48:42 2014 From: zxq9@REDACTED (zxq9) Date: Fri, 29 Aug 2014 10:48:42 +0900 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: <5915615.gjkV32RomK@changa> Message-ID: <1878289.1Z2D9GBcqH@changa> On 2014?8?29? ??? 09:25:54 Leo Liu wrote: > On 2014-08-29 09:07 +0900, zxq9 wrote: > > After those bits of SICP, showing them the JSON parser example in Real > > World Haskell is a big winner. That single example and its commentary > > gives precisely the sort of background necessary to understand Joe's > > discussions in Programming Erlang. > > I am curious if any bits in Joe's book that are particularly > challenging. I don't want to miss anything important Joe has written. I don't think anything in Programming Erlang is hard, actually. But interpreting the discussions is difficult for someone who has never thought through the related issues, worked their own way around certain issues in another environment, or dealt with different programming environments. Joe talks about tradeoffs in many places, but not often at length. The commentary is very important to understanding why things are the way they are and what alternatives could have been chosen instead, but if you've never explored any of the alternatives you don't have the personal history to relate to the discussion at all. In that case all those brief, often insightful comments just flit by under the uncomprehending eye, contributing nothing to the learner's experience. I think about half the value of books like Joe's lie outside the scope of cut-and-dried Erlang/OTP knowledge. If we didn't care about that other half we would just read the Erlang docs directly from our first day with the language. Getting one's mind prepped by seeing two radically different (but still functional) environments in SICP and Real World Haskell (in addition to whatever imperative background the new guy has) is useful before reading Joe's book, IMO. Actually, I think re-reading SICP is even more interesting after reading PE and writing a bit of Erlang and C for a while. In the same vein, I also encourage my folks to play around with assembler and follow the "Programming from the Ground Up" examples, because it makes the computer a lot less mysterious, things Knuth says more comprehensible, C make a lot more sense, and full-blown environments like OTP really strike home in the sense that "I can now just focus on the problem my customer faces -- that's amazing!" Without all that background I just don't see coders make intelligent tooling choices and often they do silly things like fixating on a specific language or runtime or whatever. Anyway, this is my perspective. I have customers with actual problems -- things of value moving around, things they can't forget about, people they need to communicate with, etc -- I have no space for monolingual coders who know only one tool and are incapable of forming their own opinions about new tools/environments/situations. To do that, though, they really need a background more broad than a single book or language lest the lessons Joe has put down that go beyond Erlang syntax and address Erlang's nature be missed. -Craig From me@REDACTED Fri Aug 29 05:40:16 2014 From: me@REDACTED (Xiao Jia) Date: Fri, 29 Aug 2014 11:40:16 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> Message-ID: On Fri, Aug 29, 2014 at 6:10 AM, Richard A. O'Keefe wrote: > > The trick is to extend the type system to send and receive. > This seems like the weakest aspect of Dialyzer: I cannot > say "X is a process id for a process that expects > messages of type Y". > This reminds me of session types. But I have to read (and dig) more about session types since I have no experience with them. I have known *interpreted* Scheme to run faster than > *compiled* C++. > What is the underlying issue? I always thought interpreted languages cannot achieve good cache efficiency so they are doomed to be much slower given that the same algorithms and data structures are used. > We would then have to say that N is better than E and C > AND ALSO that N is worse than E and C. > Sure. I meant "better in aspects of performance and concurrency." -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Fri Aug 29 04:21:03 2014 From: barcojie@REDACTED (Barco You) Date: Fri, 29 Aug 2014 10:21:03 +0800 Subject: [erlang-questions] Shenzhen Erlang Programming Meetup Message-ID: Dear Erlangers, The first erlang Meetup group of China has been setup in Shenzhen ( http://meetup.com/Shenzhen-Erlang-Programming-Meetup). I sincerely welcome all enthusiasts of erlang to join this group and let's work together to promote erlang in China, and let's build a more beautiful distributed world together with erlang! Yours faithfully, Barco CTO of MPR Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Aug 29 13:05:19 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 29 Aug 2014 13:05:19 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> Message-ID: On Fri, Aug 29, 2014 at 5:40 AM, Xiao Jia wrote: > What is the underlying issue? I always thought interpreted languages > cannot achieve good cache efficiency so they are doomed to be much slower > given that the same algorithms and data structures are used. The underlying issue is hidden cost. That "smart pointer" thing you are running? It is the equivalent of a weak reference counting model which is easily beaten by a well-tuned garbage collector. Another is building abstraction upon abstraction in an effort to being able to conceptualize what is going on. A Scheme system already conceptualized these things and internalized them in optimized form. Also, some scheme interpreters are extremely efficient due to years of tuning. And yet another problem is that once you add the necessary error handling and robustness to the implementation, its peak performance suffers. Finally, and what most often makes the difference, is that given the same amount of development time, the Scheme programmer will be able to pick better data structures, better algorithms and have a faster iteration. This in turn leads to much more experimentation in the same time-frame and thus better implementations. In many benchmarks, the implementation time isn't fixed which means that you are free to spend 20 times more on building the perfect C++ program. My experience is the same. I wrote BitTorrent clients in Erlang and Haskell. They were more efficient and faster than C/C++/Java counterparts by virtue of better algorithm design, smaller code base and better data structure choices. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Fri Aug 29 14:16:11 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 29 Aug 2014 05:16:11 -0700 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> Message-ID: <1409314571.19205.YahooMailNeo@web163602.mail.gq1.yahoo.com> "X is a process id for a process that expectsmessages of type Y". Difficult issue, in my opinion. I know of a couple of related ways to do this. First, the concurrent versions of ML, among others, often have "typed channels" for process communication. Personally, I find them awkward to use but they do provide a way to type a form of message passing. On Friday, August 29, 2014 12:11 AM, Richard A. O'Keefe wrote: > > > >On 29/08/2014, at 2:18 AM, Xiao Jia wrote: >> >> So what if we have both Erlang(-style) concurrency and C++ performance (for number crunching, ...) in some new language (yet to be developed)? > >C++ performance relies on several things. >One of them is the type system. >We know how to get close-to-C performance in a functional >language; Xavier Leroy did an impressive job with OCaml. >It depends on a good type system. > >The trick is to extend the type system to send and receive. >This seems like the weakest aspect of Dialyzer: I cannot >say "X is a process id for a process that expects >messages of type Y". > >Get the type system right and the rest will follow. > >Of course, one of Erlang's strengths has always been that you >don't *have* to use types. > >Having said that, I must emphasise once more that >"I am writing in C++" does NOT imply "my code is efficient". >I have known *interpreted* Scheme to run faster than >*compiled* C++. Memory management is a tricky subject and >manual (delete) or semi-manual (smart pointers) is NOT always >faster. > >> Regardless of community size, reusable libraries and other "human-related" issues commonly faced by any new language, can we say such a new language is better than both Erlang and C++ because it (potentially) beats both in performance and concurrency, respectively? > >One of the saddest errors in classical philosophy was the use >of "better" as though it was unequivocal. Let E be Erlang, >C be C++, and N be the new language. It is possible that > N >= E (concurrency) > N > E (performance) > N < E (readability) > N < E (human error rate) > N > C (concurrency) > N >= C (performance) > N < C (readability -- unlikely but for the sake of argument) > N < C (human error rate -- again unlikely but still) >We would then have to say that N is better than E and C >AND ALSO that N is worse than E and C. > > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > Second, Sven-Olof Nystr?m's old Erlang type analyzer was, at least in theory, capable of inferring types for erlang messages and processes. However, even if we remove a number of language features, an Erlang process can contain many receives connected by arbitrary control flow. Thus, I'd expect that a gen_fsm or suchlike where you essentially implement protocols could potentially yield a very complex type. (Granted, that statement depends on what sort of precision you're looking for in your types. The more I think of the nature of an "erlang process type", the less clear it gets.) The model checking guys, McErlang etc, might also have some way of dealing with this, but I haven't investigated that. Best, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Fri Aug 29 14:46:09 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Fri, 29 Aug 2014 08:46:09 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: <1878289.1Z2D9GBcqH@changa> References: <5915615.gjkV32RomK@changa> <1878289.1Z2D9GBcqH@changa> Message-ID: Thanks to all of you you provided feedback on this thread. There are definitely some good suggestions. One thing I did would like to point out is something referenced by Daniel who pointed me to this link: http://www.erlang.org/course/course.html This *really* needs to be both edited and updated. It uses "built-in" functions such as list(), integer() which do not seem to exist in erlang, and it's full of obvious errors. It does not really a great light on Erlang when the 'official' examples would not work for someone just working their way through the '4 - Day Course' Example 1: Pattern Matching http://www.erlang.org/course/sequential_programming.html#patterns A = 10 Succeeds - binds A to 10 {B, C, D} = {10, foo, bar} Succeeds - binds B to 10, C to foo and D to bar {A, A, B} = {abc, abc, foo} Succeeds - binds A to abc, B to foo {A, A, B} = {abc, def, 123} Fails [A,B,C] = [1,2,3] Succeeds - binds A to 1, B to 2, C to 3 [A,B,C,D] = [1,2,3] Fails Example 2: Examples of Guards http://www.erlang.org/course/sequential_programming.html#guardexample number(X) - X is a number integer(X) - X is an integer float(X) - X is a float atom(X) - X is an atom tuple(X) - X is a tuple list(X) - X is a list Is there anywhere we can submit pull requests for editorial of the website? Leonard On Thu, Aug 28, 2014 at 9:48 PM, zxq9 wrote: > On 2014?8?29? ??? 09:25:54 Leo Liu wrote: >> On 2014-08-29 09:07 +0900, zxq9 wrote: >> > After those bits of SICP, showing them the JSON parser example in Real >> > World Haskell is a big winner. That single example and its commentary >> > gives precisely the sort of background necessary to understand Joe's >> > discussions in Programming Erlang. >> >> I am curious if any bits in Joe's book that are particularly >> challenging. I don't want to miss anything important Joe has written. > > I don't think anything in Programming Erlang is hard, actually. But > interpreting the discussions is difficult for someone who has never thought > through the related issues, worked their own way around certain issues in > another environment, or dealt with different programming environments. > > Joe talks about tradeoffs in many places, but not often at length. The > commentary is very important to understanding why things are the way they are > and what alternatives could have been chosen instead, but if you've never > explored any of the alternatives you don't have the personal history to relate > to the discussion at all. In that case all those brief, often insightful > comments just flit by under the uncomprehending eye, contributing nothing to > the learner's experience. I think about half the value of books like Joe's lie > outside the scope of cut-and-dried Erlang/OTP knowledge. If we didn't care > about that other half we would just read the Erlang docs directly from our > first day with the language. > > Getting one's mind prepped by seeing two radically different (but still > functional) environments in SICP and Real World Haskell (in addition to > whatever imperative background the new guy has) is useful before reading Joe's > book, IMO. Actually, I think re-reading SICP is even more interesting after > reading PE and writing a bit of Erlang and C for a while. > > In the same vein, I also encourage my folks to play around with assembler and > follow the "Programming from the Ground Up" examples, because it makes the > computer a lot less mysterious, things Knuth says more comprehensible, C make > a lot more sense, and full-blown environments like OTP really strike home in > the sense that "I can now just focus on the problem my customer faces -- > that's amazing!" Without all that background I just don't see coders make > intelligent tooling choices and often they do silly things like fixating on a > specific language or runtime or whatever. > > Anyway, this is my perspective. I have customers with actual problems -- > things of value moving around, things they can't forget about, people they > need to communicate with, etc -- I have no space for monolingual coders who > know only one tool and are incapable of forming their own opinions about new > tools/environments/situations. To do that, though, they really need a > background more broad than a single book or language lest the lessons Joe has > put down that go beyond Erlang syntax and address Erlang's nature be missed. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Fri Aug 29 14:51:24 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 29 Aug 2014 07:51:24 -0500 Subject: [erlang-questions] Shenzhen Erlang Programming Meetup In-Reply-To: References: Message-ID: Barco, This is very exciting news! Congratulations and best of luck! I help out with the Erlang meetup in Chicago [1] and would be very happy to exchange notes, material, whatever if you think it could help. Please feel free to reach out off list or via meetup. Garrett [1] http://www.meetup.com/ErlangChicago/ On Aug 28, 2014 10:58 PM, "Barco You" wrote: > Dear Erlangers, > > The first erlang Meetup group of China has been setup in Shenzhen ( > http://meetup.com/Shenzhen-Erlang-Programming-Meetup). I sincerely > welcome all enthusiasts of erlang to join this group and let's work > together to promote erlang in China, and let's build a more beautiful > distributed world together with erlang! > > Yours faithfully, > Barco > CTO of MPR Technology > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Fri Aug 29 15:02:28 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 29 Aug 2014 15:02:28 +0200 Subject: [erlang-questions] Are binaries relocatable? In-Reply-To: References: Message-ID: <540079E4.5030607@erix.ericsson.se> On 08/28/2014 03:09 PM, Hynek Vychodil wrote: > Hi all, > I would like to know if binaries are relocatable. If I have binary parameter > > ErlNifBinary bin; > if (!enif_inspect_binary(env, argv[0], &bin)) > return enif_make_badarg(env); > > I store binary in mine own environment > > ErlNifEnv *priv_env = enif_alloc_env(); > enif_make_copy(priv_env, argv[0]); > > Can I then rely on bin.data pointing into same memory until I free > enif_free_env(priv_env) ? No. Your bin.data is refering to the original term argv[0] in 'env' which is only valid until the NIF returns. You must do enif_inspect_binary on the copy in order to get a safe pointer that is valid until you do enif_free_env(priv_env). > I'm asking because I would like to avoid copying > and share data or even return it using enif_make_resource_binary to catch > and > count references. Whether a copied binary share data with its original is implementation dependent. Today big binaries (>64 bytes) are shared and small binaries are copied between environments. > I have code which makes copy of binary data but when I switch to reference > bin.data it hangs whole VM. I would like to know if I make some mistake in > mine code and it should work or it is wrong idea at all. > > There is a known bug when calling enif_make_copy after enif_inspect_binary that can cause the binary to get reallocated and thus the bin.data pointer to get invalid before the NIF returns. To detect this bug, you can call enif_inspect_binary(env,argv[0],&bin2) after enif_make_copy and check if bin2.data != bin.data. This bug has been lingering as I thought it was an exotic scenario (apparently not) and I have been a bit unsure how to fix it without ruin performance. /Sverker, Erlang/OTP From g@REDACTED Fri Aug 29 15:56:03 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 29 Aug 2014 08:56:03 -0500 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 11:47 AM, Leonard Boyce wrote: > I'd like to tap the collective wisdom of the group for their > experiences in onboarding fresh-out-of-college programmers who are new > to Erlang. This is assuming the new programmer has mostly imperative > experience (C/C++/Java) and have had a fleeting glimpse of functional > through Haskell. > > I'm of the mindset to have them work through a book or two over the > 1st couple of weeks with plenty of rubber ducking and/or pairing on > simple exercises. Where are the Erlang leaders (those programmers who are building the system today) in this picture? I'd be concerned about sending folks off to a program only to have them mildly more prepared for the realities of your particular environment. This includes your existing code base, programming processes, culture, etc. > After that maybe have them work on a simple feature or two in some > prototypical work we're doing on the side, and of course sending them > off to the first available 'bootcamp'/training session available. It's a huge cost to pull your experienced Erlang programmers out of their day-to-day to help build a team, but you might end up paying that cost eventually anyway. Sending someone to a training will get them trained in whatever course material they're exposed to. That may have very little application in your particular context. On the other hand, getting together with your Erlang leaders and working with them to build a training -- that could yield a more direct path to getting everyone closer to an independent contributing state. > What have you found is the best way to introduce them to the language > and bring them up to a level where they can start standing on their > own feet? As I think many have mentioned in this thread, it's not hard to pick up the basics of the language. IMO it's not that hard to pick up OTP. It's much harder though to put a programmer in position to independently solve real world problems (i.e. your specific business problems). I would not set that as any short term goal. Why are you doing all this in the first place? I imagine you have specific work in mind. Get them working on that, even if in a remedial way at first. Iterate and improve. You'll need cycles from your Erlang leaders though. That's a big cost. If you're not willing to bear that, you might consider hiring experienced Erlang programmers off the bat, or pulling in ESL for a combo consulting/training services for your particular program. Maybe... you could find that pointing smart, new programmers at a concrete, well defined, problem-that-you-have-to-solve that has real stake holders could work over time. It depends on the people obviously. But even in that case, if the team doesn't have some mentors who are working alongside it, even if just occasionally, it will likely flounder. > Are there any specific resources (books/sessions/tutorials etc) you've > found useful in the past? I think $300 will buy you most every Erlang book ever written. Have that material on hand and use it when you need to, but *build real stuff* to learn. I don't mean to be patronizing here, but you might have to adjust to the idea that building an effective team is expensive :) If you don't have help inside, pay a vendor. Garrett From leonard.boyce@REDACTED Fri Aug 29 16:48:29 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Fri, 29 Aug 2014 10:48:29 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: Thanks Garrett, On Fri, Aug 29, 2014 at 9:56 AM, Garrett Smith wrote: > On Thu, Aug 28, 2014 at 11:47 AM, Leonard Boyce > wrote: >> I'd like to tap the collective wisdom of the group for their >> experiences in onboarding fresh-out-of-college programmers who are new >> to Erlang. This is assuming the new programmer has mostly imperative >> experience (C/C++/Java) and have had a fleeting glimpse of functional >> through Haskell. >> >> I'm of the mindset to have them work through a book or two over the >> 1st couple of weeks with plenty of rubber ducking and/or pairing on >> simple exercises. > > Where are the Erlang leaders (those programmers who are building the > system today) in this picture? Right here are ready to mentor. I should clarify that in this specific instance I'm not looking to 'bring in a lead', I'm looking to add very talented juniors to the team and give them time and resources to grow into a more senior role. Yes, I'm well aware of the costs, both time and productivity, that we'll incur, and yes, it's a risk investing so much in young talent who can afford to jump ship. That said, I'm willing to take that chance and make that investment > I'd be concerned about sending folks off to a program only to have > them mildly more prepared for the realities of your particular > environment. This includes your existing code base, programming > processes, culture, etc. This is true for almost anyone joining a team. The only real difference is the 'new language'. The purpose of this thread was to gather information of how best to bring them to a point where 'course work' would not be a total waste, and given the time frame between courses is measured in months. For all I know it would be a moot point by the time the next conference/course comes around. >> After that maybe have them work on a simple feature or two in some >> prototypical work we're doing on the side, and of course sending them >> off to the first available 'bootcamp'/training session available. > > It's a huge cost to pull your experienced Erlang programmers out of > their day-to-day to help build a team, but you might end up paying > that cost eventually anyway. Sending someone to a training will get > them trained in whatever course material they're exposed to. That may > have very little application in your particular context. I see training courses more as 'foundational'. You can never learn everything, and having a good base cannot be hurt. > On the other hand, getting together with your Erlang leaders and > working with them to build a training -- that could yield a more > direct path to getting everyone closer to an independent contributing > state. Fully agree, but again, that's a trade-off. >> What have you found is the best way to introduce them to the language >> and bring them up to a level where they can start standing on their >> own feet? > > As I think many have mentioned in this thread, it's not hard to pick > up the basics of the language. IMO it's not that hard to pick up OTP. While personally I will agree with you, I've been in the situation in the past where stellar candidates just could not wrap their head around functional, even given considerable time. Maybe this is a symptom of the education system in the US (please not intended to start a flame war), but very few grads I've interviewed even covered functional programming at Uni/College. > It's much harder though to put a programmer in position to > independently solve real world problems (i.e. your specific business > problems). I would not set that as any short term goal. > > Why are you doing all this in the first place? I imagine you have > specific work in mind. Get them working on that, even if in a remedial > way at first. Iterate and improve. You'll need cycles from your Erlang > leaders though. That's a big cost. If you're not willing to bear that, > you might consider hiring experienced Erlang programmers off the bat, > or pulling in ESL for a combo consulting/training services for your > particular program. > > Maybe... you could find that pointing smart, new programmers at a > concrete, well defined, problem-that-you-have-to-solve that has real > stake holders could work over time. It depends on the people > obviously. But even in that case, if the team doesn't have some > mentors who are working alongside it, even if just occasionally, it > will likely flounder. > >> Are there any specific resources (books/sessions/tutorials etc) you've >> found useful in the past? > > I think $300 will buy you most every Erlang book ever written. Have > that material on hand and use it when you need to, but *build real > stuff* to learn. The bookshelves are already stocked. You got it right there. "Building real stuff" is key. There are a number of OSS projects we use which could do with some extra love, and this is really where I'd expect to have them do their initial real work. > I don't mean to be patronizing here, but you might have to adjust to > the idea that building an effective team is expensive :) If you don't > have help inside, pay a vendor. Not at all patronizing. We started with a small team and have managed to remain that way without overloading anyone. Our platform has been running stably 24/7 for well over a year now (thanks to Erlang), even through a couple of datacenter migrations. It's time to fill a slot which should have been filled months ago, and as I tried to convey in my initial response, I believe in investing in people. > Garrett From BasWegh@REDACTED Fri Aug 29 15:48:41 2014 From: BasWegh@REDACTED (Bas Wegh) Date: Fri, 29 Aug 2014 15:48:41 +0200 Subject: [erlang-questions] Android and Erlang Data transfer In-Reply-To: References: Message-ID: <540084B9.8040401@gmx.de> Hello Gustavo, I don't know what you are planning to do, yet you could also consider a WAMP (see http://wamp.ws ) router. I am working on an implementation and would be happy to get some feedback of others using it. http://github.com/bwegh/erwa Cheers, Bas On 25.08.2014 07:03, Gustavo Pires wrote: > Hello everyone, > > What do you think I should use to transfer data between Android and an > Erlang Server? I think a good approach would be Sockets + Protobuff, > but I feel overwhelmed by the myriad of options out there (json, > msgpack, thrift, bert, ubf, ...). > > I read some old threads in the list, but they are too old. I agree > with an old Joe's comment about saving as much bandwidth you can, but > I'm not sure how stable are programs like basho/protobuff and msgpack > for erlang. It seems they don't evolve much in the last two years. > > Any though about this would be appreciated. > > Gustavo > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From nx@REDACTED Fri Aug 29 17:43:48 2014 From: nx@REDACTED (nx) Date: Fri, 29 Aug 2014 11:43:48 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: I've had good experience with bringing developers with no Erlang experience on to an Erlang project. In my case it was someone with a Ruby web application development background. I spent most of the time at first explaining Erlang concepts in a way a Ruby user could relate to. "Atoms are like symbols", "Processes are like instances of objects", etc. Other concepts like strings versus binaries, function clauses and pattern matching came as we were pairing on the task at hand. I also picked libraries that were similar to their Ruby counterparts. For example, her task was to implement an Erlang REST API. Rather than go with a webmachine-like REST library (i.e. webmachine, cowboy_rest), I picked axiom, which is reminiscent of Sinatra. After installing Erlang, setting up tools and a couple of days of pairing, she was pretty much moving along on her own and landing pull requests in Github. I think using Github really makes reviewing junior Erlang devs a lot smoother since you can have comments and discussions right on the lines of concern. For example, maybe you see something with nested case statements that could be solved with pattern matching. With Github you can just add an example in the comments. Now you've taught them that concept and they will use it in the future. The key is to just have a real world problem that you're solving using Erlang. Start working on it with the junior dev while finding ways to talk about Erlang concepts from their perspective. Then, when they're introduced, be available for guidance and review incoming code. On Thu, Aug 28, 2014 at 12:47 PM, Leonard Boyce wrote: > I'd like to tap the collective wisdom of the group for their > experiences in onboarding fresh-out-of-college programmers who are new > to Erlang. This is assuming the new programmer has mostly imperative > experience (C/C++/Java) and have had a fleeting glimpse of functional > through Haskell. > > I'm of the mindset to have them work through a book or two over the > 1st couple of weeks with plenty of rubber ducking and/or pairing on > simple exercises. > > After that maybe have them work on a simple feature or two in some > prototypical work we're doing on the side, and of course sending them > off to the first available 'bootcamp'/training session available. > > What have you found is the best way to introduce them to the language > and bring them up to a level where they can start standing on their > own feet? > > Are there any specific resources (books/sessions/tutorials etc) you've > found useful in the past? > > Any other recommendations? > > Thanks, > > Leonard > --- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Fri Aug 29 17:55:01 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 29 Aug 2014 11:55:01 -0400 Subject: [erlang-questions] How to debug dirty NIF? In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 11:19 AM, Max Lapshin wrote: > I'm running CPU bound task (make thumbnails from video) in a NIF under > erlang 17 (erts 6.0) > > I'm using dirty nif scheduling: > > static ERL_NIF_TERM > yuv2jpeg0(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { > .... > } > > > static ERL_NIF_TERM > async_jpeg(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { > ERL_NIF_TERM result = yuv2jpeg0(env, argc, argv); > return enif_schedule_dirty_nif_finalizer(env, result, > enif_dirty_nif_finalizer); > } > > > static ERL_NIF_TERM > yuv2jpeg(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { > return enif_schedule_dirty_nif(env, ERL_NIF_DIRTY_JOB_CPU_BOUND, > async_jpeg, argc, argv); > } > > I see strange situation: none of CPU core is not 100% loaded, but > processes that are calling yuv2jpeg function are hanging in this function: > > > (flussonic@REDACTED)3> process_info(pid(0,961,0)). > > [{current_function,{avcodec,yuv2jpeg0,4}}, > There's always the "printf debugger" :) -- have your entry NIF and your dirty NIF print their respective thread IDs to make sure they're on different threads, and have each print something just before returning. You might also consider writing your own finalizer so you can print from there too. With these in place, you'll at least know where something might be getting hung up. A more involved alternative, though still not all that difficult, would be to build a debuggable runtime and run everything under gdb. I suppose that I could meet the old problem with wrong scheduler behaviour > when NIF is using thread for too long. > Scheduler collapse is possible with regular schedulers but not with dirty schedulers, as the whole point of having the latter is that they're not bound to the regular scheduler constraints. But if your regular schedulers are already collapsed, they'll never run and so will never switch your processes over to a dirty scheduler. yuv2jpeg takes usually about 2-4 milliseconds to run. > > Is it possible to debug this situation? Can I somehow ask erlang if it > decided that some scheduler is considered idle? > You might get some useful info from erlang:system_info using arguments such as schedulers_state, scheduling_statistics, and thread_progress, and maybe also from erlang:statistics(run_queues). See http://www.erlang.org/doc/man/erlang.html for details on these. If there's a way for you to easily package something that I could run for myself to try to duplicate the problem, just let me know and I'll take a look. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonard.boyce@REDACTED Fri Aug 29 18:03:05 2014 From: leonard.boyce@REDACTED (Leonard Boyce) Date: Fri, 29 Aug 2014 12:03:05 -0400 Subject: [erlang-questions] Onboarding programmers who are new to Erlang In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 11:43 AM, nx wrote: > I've had good experience with bringing developers with no Erlang > experience on to an Erlang project. In my case it was someone with a > Ruby web application development background. > > I spent most of the time at first explaining Erlang concepts in a way > a Ruby user could relate to. "Atoms are like symbols", "Processes are > like instances of objects", etc. Other concepts like strings versus > binaries, function clauses and pattern matching came as we were > pairing on the task at hand. This is actually some great advice. Speaking of which, might be helpful for someone with more in-depth knowledge than myself to spend a few minutes and add Erlang here: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions) > I also picked libraries that were similar to their Ruby counterparts. > For example, her task was to implement an Erlang REST API. Rather than > go with a webmachine-like REST library (i.e. webmachine, cowboy_rest), > I picked axiom, which is reminiscent of Sinatra. > > After installing Erlang, setting up tools and a couple of days of > pairing, she was pretty much moving along on her own and landing pull > requests in Github. > > I think using Github really makes reviewing junior Erlang devs a lot > smoother since you can have comments and discussions right on the > lines of concern. For example, maybe you see something with nested > case statements that could be solved with pattern matching. With > Github you can just add an example in the comments. Now you've taught > them that concept and they will use it in the future. Very good suggestion, thank you. Definitely provides a more immediate feedback loop than a scheduled code review > The key is to just have a real world problem that you're solving using > Erlang. Start working on it with the junior dev while finding ways to > talk about Erlang concepts from their perspective. Then, when they're > introduced, be available for guidance and review incoming code. > > On Thu, Aug 28, 2014 at 12:47 PM, Leonard Boyce > wrote: >> I'd like to tap the collective wisdom of the group for their >> experiences in onboarding fresh-out-of-college programmers who are new >> to Erlang. This is assuming the new programmer has mostly imperative >> experience (C/C++/Java) and have had a fleeting glimpse of functional >> through Haskell. >> >> I'm of the mindset to have them work through a book or two over the >> 1st couple of weeks with plenty of rubber ducking and/or pairing on >> simple exercises. >> >> After that maybe have them work on a simple feature or two in some >> prototypical work we're doing on the side, and of course sending them >> off to the first available 'bootcamp'/training session available. >> >> What have you found is the best way to introduce them to the language >> and bring them up to a level where they can start standing on their >> own feet? >> >> Are there any specific resources (books/sessions/tutorials etc) you've >> found useful in the past? >> >> Any other recommendations? >> >> Thanks, >> >> Leonard >> --- >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From pierrefenoll@REDACTED Fri Aug 29 23:50:07 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 29 Aug 2014 23:50:07 +0200 Subject: [erlang-questions] Looking for an internship Message-ID: Hi list, I apologise in advance for this selfish post! I am looking for a 5-months long internship at an Erlang shop in the Valley, starting February of next year. I will be taking the steps to obtain a work visa shortly (as I am of French nationality). I have bundled with this email a generic introduction letter and CV. Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Hi, I am currently enrolled in the last (5th) year of a Masters degree in Computer Science in Paris and am hoping to do a 5 months internship at your Erlang shop, starting February 2015. My last internship was at Erlang Solutions? R&D department in London and lasted 5 months. I previously did some contract work for Concurix, before the startup re-oriented towards a nodejs shop. On my own, I have contributed to Erlang/OTP?s ?parsetools? & ?stdlib? applications and Basho?s build tool ?rebar?. I am also the current maintainer of the somewhat famous erldocs.com website and Erlang application. Keen programmer from a young age, I have done projects in various imperative languages, settling with Erlang during High School as I fell for the language/framework. I am interested in highly-concurrent and distributed systems and the problems that come with them. As I am soon to finish my MSc I am eager to work on real world Erlang applications in a startup environment. I have packaged a r?sum? and will be glad to discuss more about this internship over a meeting. Cheers, -- Pierre Fenoll -------------- next part -------------- A non-text attachment was scrubbed... Name: resume.pdf Type: application/pdf Size: 144169 bytes Desc: not available URL: From sdl.web@REDACTED Sat Aug 30 01:40:53 2014 From: sdl.web@REDACTED (Leo Liu) Date: Sat, 30 Aug 2014 07:40:53 +0800 Subject: [erlang-questions] Onboarding programmers who are new to Erlang References: <5915615.gjkV32RomK@changa> <1878289.1Z2D9GBcqH@changa> Message-ID: On 2014-08-29 10:48 +0900, zxq9 wrote: > In the same vein, I also encourage my folks to play around with assembler and > follow the "Programming from the Ground Up" examples, because it makes the > computer a lot less mysterious, things Knuth says more comprehensible, C make > a lot more sense, and full-blown environments like OTP really strike home in > the sense that "I can now just focus on the problem my customer faces -- > that's amazing!" Without all that background I just don't see coders make > intelligent tooling choices and often they do silly things like fixating on a > specific language or runtime or whatever. This is the right approach to good engineering or at least the one I buy into. My not-so-strong C knowledge (which I never programmed in) has helped me understand many questions that I have with the emulator ;) Leo From vychodil.hynek@REDACTED Sat Aug 30 07:07:06 2014 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Sat, 30 Aug 2014 07:07:06 +0200 Subject: [erlang-questions] Are binaries relocatable? In-Reply-To: <540079E4.5030607@erix.ericsson.se> References: <540079E4.5030607@erix.ericsson.se> Message-ID: Thanks for your answer very much. If I understand it correctly this way it should be safe: ErlNifBinary bin; if (!enif_is_binary(env, argv[0])) return enif_make_badarg(env); ErlNifEnv *priv_env = enif_alloc_env(); ERL_NIF_TERM term = enif_make_copy(priv_env, argv[0]); ErlNifBinary bin; enif_inspect_binary(priv_env, term, &bin); entry->content.bin = (struct my_bin){.env = priv_env, .size = bin.size, .data = bin.data}; And now mine entry->content.bin.data should be safe but unfortunately it still eventually hangs whole VM after few thousands cycles of referencing this data CacheEntryRes_t *res = enif_alloc_resource(dc_entry_type, sizeof(CacheEntryRes_t)); unless (res) return insufficient_memory(env); res->entry = entry; ERL_NIF_TERM result = enif_make_resource_binary(env, res, entry->content.bin.data, entry->content.bin.size); enif_release_resource(res); return result; I do mine own reference count and release by enif_free_env(entry->content.bin.env); It hangs only if I replace enif_alloc() + memcpy() and enif_free() version with above one :-( Thanks Hynek On Fri, Aug 29, 2014 at 3:02 PM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > On 08/28/2014 03:09 PM, Hynek Vychodil wrote: > >> Hi all, >> I would like to know if binaries are relocatable. If I have binary >> parameter >> >> ErlNifBinary bin; >> if (!enif_inspect_binary(env, argv[0], &bin)) >> return enif_make_badarg(env); >> >> I store binary in mine own environment >> >> ErlNifEnv *priv_env = enif_alloc_env(); >> enif_make_copy(priv_env, argv[0]); >> >> Can I then rely on bin.data pointing into same memory until I free >> enif_free_env(priv_env) ? >> > No. > Your bin.data is refering to the original term argv[0] in 'env' which is > only valid until the NIF returns. > You must do enif_inspect_binary on the copy in order to get a safe pointer > that is valid until you do enif_free_env(priv_env). > > > > I'm asking because I would like to avoid copying >> and share data or even return it using enif_make_resource_binary to catch >> and >> count references. >> > Whether a copied binary share data with its original is implementation > dependent. Today big binaries (>64 bytes) are shared > and small binaries are copied between environments. > > > I have code which makes copy of binary data but when I switch to reference >> bin.data it hangs whole VM. I would like to know if I make some mistake in >> mine code and it should work or it is wrong idea at all. >> >> >> There is a known bug when calling enif_make_copy after > enif_inspect_binary > that can cause the binary to get reallocated and thus the bin.data pointer > to get invalid > before the NIF returns. To detect this bug, you can call > enif_inspect_binary(env,argv[0],&bin2) > after enif_make_copy and check if bin2.data != bin.data. > > This bug has been lingering as I thought it was an exotic scenario > (apparently not) and I have > been a bit unsure how to fix it without ruin performance. > > > /Sverker, Erlang/OTP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Aug 30 07:50:32 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 30 Aug 2014 09:50:32 +0400 Subject: [erlang-questions] How to debug dirty NIF? In-Reply-To: References: Message-ID: I couldn't find any detailed information about the problem, but I've cured it somehow by adding: erlang:bump_reductions(5000) after each NIF call. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wojtek@REDACTED Sat Aug 30 11:42:24 2014 From: wojtek@REDACTED (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=) Date: Sat, 30 Aug 2014 11:42:24 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> Message-ID: <54019C80.7070000@power.com.pl> On 29.08.2014 05:40, Xiao Jia wrote: > On Fri, Aug 29, 2014 at 6:10 AM, Richard A. O'Keefe > wrote: > > > The trick is to extend the type system to send and receive. > This seems like the weakest aspect of Dialyzer: I cannot > say "X is a process id for a process that expects > messages of type Y". > > > This reminds me of session types. But I have to read (and dig) more > about session types since I have no experience with them. I'd love to see IMAPv4rev1 session type. It is extremely difficult to verify protocol adherence statically. UBF by Joe Armstrong checks things at runtime, but it's something you can actually use. https://www.sics.se/~joe/ubf/site/home.html -- Wojtek -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Sat Aug 30 12:16:51 2014 From: james@REDACTED (james) Date: Sat, 30 Aug 2014 11:16:51 +0100 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: Message-ID: <5401A493.5060101@mansionfamily.plus.com> > Erlang syntax is seldom a gotcha No, but the lack of a decent type system is a gotcha. If I want to program purely functionally, I'd rather use Haskell. And yet sometimes its very convenient to step outside functional, and Scala and OCaml etc are useful too. From n.oxyde@REDACTED Sat Aug 30 12:55:46 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 30 Aug 2014 12:55:46 +0200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <5401A493.5060101@mansionfamily.plus.com> References: <5401A493.5060101@mansionfamily.plus.com> Message-ID: <6055CF9F-95CB-415E-A6F6-A850FF1BB6C7@gmail.com> That would be ? being different ?, not ? being a gotcha ?. If Erlang got not ? decent ? type system, maybe that?s because type systems were not evolved enough by the time it was written. And I?ve yet to see Cloud Haskell offer as many features as Erlang. -- Anthony Ramine Le 30 ao?t 2014 ? 12:16, james a ?crit : > No, but the lack of a decent type system is a gotcha. From me@REDACTED Sun Aug 31 06:48:48 2014 From: me@REDACTED (Xiao Jia) Date: Sun, 31 Aug 2014 12:48:48 +0800 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <54019C80.7070000@power.com.pl> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> <54019C80.7070000@power.com.pl> Message-ID: On Sat, Aug 30, 2014 at 5:42 PM, Wojtek Narczy?ski wrote: > It is extremely difficult to verify protocol adherence statically. > What do you mean by "difficult"? Lacking tooling support? Requiring too much heavy work on manual annotations? Or something else... -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.sivieri@REDACTED Sun Aug 31 13:13:09 2014 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Sun, 31 Aug 2014 13:13:09 +0200 Subject: [erlang-questions] Spawn funs: code limitations Message-ID: Hi all, quick question, which has probably been already answered many times, but I cannot find an answer myself. Suppose that I have an application with a module that has a function that does some stuff and performs a remote spawn of a fun: I did it some time ago and I seem to remember that there are limitations in the code that the fun is composed of, something on the lines of: if the code is complex I need to send the bytecode of the module, too, and load it remotely. If the fun simply contains invocations of other functions (that are already present in the remote node), then everything goes well. Am I right? To sum up: when I spawn a fun remotely, what kind of data is sent to the remote node? A pointer to the module where the fun code is contained plus its closure (i.e., the value of the variables)? This is what I seem to remember. Sorry if this question is a little bit convoluted... :) -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From prof3ta@REDACTED Sun Aug 31 13:17:20 2014 From: prof3ta@REDACTED (Roberto Aloi) Date: Sun, 31 Aug 2014 13:17:20 +0200 Subject: [erlang-questions] Spawn funs: code limitations In-Reply-To: References: Message-ID: This should help: http://www.javalimit.com/2010/05/passing-funs-to-other-erlang-nodes.html On 31 Aug 2014 13:13, "Alessandro Sivieri" wrote: > Hi all, > > quick question, which has probably been already answered many times, but I > cannot find an answer myself. > > Suppose that I have an application with a module that has a function that > does some stuff and performs a remote spawn of a fun: I did it some time > ago and I seem to remember that there are limitations in the code that the > fun is composed of, something on the lines of: if the code is complex I > need to send the bytecode of the module, too, and load it remotely. If the > fun simply contains invocations of other functions (that are already > present in the remote node), then everything goes well. Am I right? > > To sum up: when I spawn a fun remotely, what kind of data is sent to the > remote node? A pointer to the module where the fun code is contained plus > its closure (i.e., the value of the variables)? This is what I seem to > remember. > > Sorry if this question is a little bit convoluted... :) > > -- > Sivieri Alessandro > alessandro.sivieri@REDACTED > http://sivieri.wordpress.com/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.sivieri@REDACTED Sun Aug 31 13:21:40 2014 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Sun, 31 Aug 2014 13:21:40 +0200 Subject: [erlang-questions] Spawn funs: code limitations In-Reply-To: References: Message-ID: On Sun, Aug 31, 2014 at 1:17 PM, Roberto Aloi wrote: > This should help: > > http://www.javalimit.com/2010/05/passing-funs-to-other-erlang-nodes.html > Ok, so it is a reference to the function itself, as I remembered. And what about its closure? I.e., in the example in the article, if the X as already been assigned before the spawn, its values should be transmitted along with the fun... -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Aug 31 16:10:54 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 31 Aug 2014 16:10:54 +0200 Subject: [erlang-questions] [ANN] swab 1.0 Message-ID: <54032CEE.7010807@wanadoo.fr> Hello ! swab 1.0 has been released. swab is a general purpose buffer handling module that make life easier. https://github.com/crownedgrouse/swab Available in erlang.mk package index, too. swab can : * cast data and sort lines. * decode, encode and convert data, including EBCDIC. * catch data that becomes the new current buffer. * match data and return the current buffer or otherwise continue next directives, if any. * store a buffer queue and maybe use it later to compose another buffer for instance, by merging or concatenating. * do diverse specialized (or custom) actions. swab offer a very easy way to chain directives as you would do by chaining commands with pipes in a shell. Each step can modify the input buffer that becomes a new current buffer, and so on. swab uses many existing Erlang internal functions but manages for you the multiplicity of possible return values ??and exceptions of those ones. swab give the possibility to debug all or part of the directive chain, to do hexdump ? la 'od' and also ASN1 pretty printing ? la 'openssl asn1parse'. I hope you will enjoy this module ! Regards From ok@REDACTED Sun Aug 31 23:40:30 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 1 Sep 2014 09:40:30 +1200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> Message-ID: On 29/08/2014, at 3:40 PM, Xiao Jia wrote: > On Fri, Aug 29, 2014 at 6:10 AM, Richard A. O'Keefe wrote: > > I have known *interpreted* Scheme to run faster than > *compiled* C++. > > What is the underlying issue? I always thought interpreted languages cannot achieve good cache efficiency so they are doomed to be much slower given that the same algorithms and data structures are used. Even that is not true. I used to work at Quintus. Quintus Prolog compiled Prolog to (a variant of) the Warren Abstract Machine, which was implemented as a threaded code interpreter. One of our competitors compiled to native code. For a 1 page program, they ran 4 times faster than us. For a 10 page program, the two systems ran at the same speed. For a 100 page program, the threaded code system ran about 4 times faster than the native code system. Oddly enough, the reason was precisely "good cache efficiency". The threaded code emulator was less than 64 k of code. It got into L1 instruction cache and stayed there. The actual threaded code was quite compact, so you could have quite a bit of it in L2 cache. The native code was much bulkier. However, in the Scheme -vs- C++ example, there were two issues. (1) C++ strings were grotesquely inefficient in that system. (2) The code was fairly allocation-heavy, and while the C++ version did need less memory, it spent a *lot* more time managing it. This is a claim about one specific implementation of Scheme and one specific implementation of C++, at a specific time, on a specific machine that's not on the market any more. Nothing can be inferred from it about Scheme and C++ in general. There is perhaps a general warning: - the fact that a LANGUAGE can be compiled to efficient code does not imply that its LIBRARY is efficient. I could give other examples of interpreted languages beating compiled ones. What the heck, I shall. - Prolog (emulated) vs Fortran (optimised native code). The Fortran program was written by someone else first (in Fortran 77). I then rewrote it in Prolog using a sparse matrix data structure that was very easy in Prolog and would have been very hard in Fortran. (Modern Fortran is a very different thing.) - AWK (threaded code, emulated in C) vs Java (JIT native code). The culprit was java.io.RandomAccessFile. - AWK vs Java again. This time it's 40 more years of programmer experience leading to a much more economical program. There's another general issue to be gleaned here: - the fact that a LANGUAGE can be compiled to efficient code does not imply that efficient ALGORITHMS will be easy to conceive or express in it. Java seems to be particularly bad here. You *can* write fast clean code in it, but somehow, I never meet any. From ok@REDACTED Sun Aug 31 23:47:16 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 1 Sep 2014 09:47:16 +1200 Subject: [erlang-questions] Erlang and Akka In-Reply-To: <1409314571.19205.YahooMailNeo@web163602.mail.gq1.yahoo.com> References: <2ec11b1134cd6c8104ee3996bd75d475@webmail.webfaction.com> <3270b8a25ba1dd2d2686afeb0800cae3@webmail.webfaction.com> <5A3AC1B4-18C5-482B-B172-4BB6F9A72809@cs.otago.ac.nz> <78B008BE-7BC3-4B0B-BC61-9A1D1F9A9EE1@cs.otago.ac.nz> <1409314571.19205.YahooMailNeo@web163602.mail.gq1.yahoo.com> Message-ID: On 30/08/2014, at 12:16 AM, Thomas Lindgren wrote: > > Second, Sven-Olof Nystr?m's old Erlang type analyzer was, at least in theory, capable of inferring types for erlang messages and processes. Is there a reference for that? > However, even if we remove a number of language features, an Erlang process can contain many receives connected by arbitrary control flow. Thus, I'd expect that a gen_fsm or suchlike where you essentially implement protocols could potentially yield a very complex type. Type systems aren't all-or-nothing. For example, Haskell's type system seems pretty amazing and as precise as you could wish for, until you meet dependent type systems like the one in Idris. A process type need not be *precise* to be useful. Indeed, when you think about the fact that the type of a pid is not going to change, while the precise set of messages it is ready to receive *will* change from time to time, it's not clear that a precise type would be useful at all. A process type that can tell you "you idiot, you're trying to send a message that this process will NEVER accept under any conditions" is enough to be useful.